From john at klam.ca Wed Mar 1 02:36:59 2017 From: john at klam.ca (John Allen) Date: Tue, 28 Feb 2017 20:36:59 -0500 Subject: NSEC3 Params Message-ID: How often should the NSEC3 params (salt in particular) be changed. I was sent an article on "rainbow"? attacks, and there was mention of changing/updating the NSEC3 salt might be beneficial. One problem I had with the piece was that I could not find a date for, so it might be obsolete, secondly I cold not find the author though the piece was reported to be from Digital Ocean. JohnA PS. Sorry to post this here I thought there was a DNSSEC mailing list, but everything gets rejected! From ietf-dane at dukhovni.org Wed Mar 1 03:12:51 2017 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Tue, 28 Feb 2017 21:12:51 -0500 Subject: NSEC3 Params In-Reply-To: References: Message-ID: > On Feb 28, 2017, at 8:36 PM, John Allen wrote: > > How often should the NSEC3 params (salt in particular) be changed. For now, never. Choose a suitable random value around 8 octets long, and keep it fixed. Transitions between different NSEC3PARAM values may not be seamless, and for many domains the bulk of the names are trivially found via PTR lookups for their IPv4 blocks. You probably don't have any strong reasons to attempt to hide the names in your domain. I also don't encourage large iteration counts, 10 or less, perhaps 0 is best in most cases. This reduces the CPU load on your server in generating negative replies. The ".com" zone an iteration count of zero and an empty salt: com. NSEC3PARAM 1 0 0 - This is a good starting point. -- Viktor. From john at klam.ca Wed Mar 1 04:50:37 2017 From: john at klam.ca (John Allen) Date: Tue, 28 Feb 2017 22:50:37 -0500 Subject: NSEC3 Params In-Reply-To: References:

Message-ID: oooooops! I just set the nsec3 params to 1 0 17 "16 digit random number" I guess I will just have to back off. As you point out a PTR lookup probably does everything that an attack would do any way. If that is the case is it pointless to have nsec3 set at all. JohnA On 2017-02-28 9:12 PM, Viktor Dukhovni wrote: >> On Feb 28, 2017, at 8:36 PM, John Allen wrote: >> >> How often should the NSEC3 params (salt in particular) be changed. > For now, never. Choose a suitable random value around 8 octets long, > and keep it fixed. > > Transitions between different NSEC3PARAM values may not be seamless, > and for many domains the bulk of the names are trivially found via PTR > lookups for their IPv4 blocks. > > You probably don't have any strong reasons to attempt to hide the names > in your domain. I also don't encourage large iteration counts, 10 or > less, perhaps 0 is best in most cases. This reduces the CPU load on > your server in generating negative replies. > > The ".com" zone an iteration count of zero and an empty salt: > > com. NSEC3PARAM 1 0 0 - > > This is a good starting point. > From ralph at nlnetlabs.nl Fri Mar 3 11:15:48 2017 From: ralph at nlnetlabs.nl (Ralph Dolmans) Date: Fri, 3 Mar 2017 11:15:48 +0100 Subject: Don't forget to add TLSA records for black-hole MX hosts In-Reply-To: <3107E22F-A11B-4E7D-9C3E-071636466017@mac.com> References: <20170210202541.GZ28349@mournblade.imrryr.org> <3107E22F-A11B-4E7D-9C3E-071636466017@mac.com> Message-ID: Hi Alex, Sorry for the late reply, I was just pointed to this message. Please note that internet.nl already does check the existence and validity of TLSA records for all MX hosts, as part of the STARTTLS test. In your example case it displays "no TLSA record found (DANE) ". Regards, -- Ralph On 13-02-17 14:40, Alexander Dupuy wrote: > The wonderful Internet.nl website and e-mail > security and standards compliance checker, which was the first thing I > thought of when I saw this message from Viktor, doesn?t currently check > for TLSA records for MX hosts (although it does check for DNSSEC on the > zones of MX hostnames, > e.g. https://internet.nl/mail/dns-example.info/results#). It would be > wonderful if that functionality could be added in a future update to > their site. Does NLnet Labs , > which develops the software for this great checking tool, have a public > repository for it? If so, I would be happy to submit a pull-request or > patch to add that functionality. > > @alex > > p.s. could someone at Internet.nl please add > Verisign Public DNS > (https://www.verisign.com/en_US/security-services/public-dns/index.xhtml) to > the list of DNSSEC-validating public DNS services > at https://internet.nl/faqs/dnssec/? They are the first major public DNS > service after Google Public DNS to provide this feature, present from > day one of their service (even though they don?t mention it), and they > should be listed. > >> On 2017-02-10, at 15:25, Viktor Dukhovni > > wrote: >> >> >> Some domains with DANE-TLSA records for their primary MX hosts >> neglect to publish DANE TLSA for secondary and/or "black-hole" >> (spam magnet) MX hosts. >> >> Consider nic.cz, until recently their "bh.nic.cz" host had no TLSA >> records (and SMTP connections to that host would time out). This >> gives an active on-path MiTM attacker opportunity to block connections >> to the working MX hosts, and accept unauthenticated connections to >> the black-hole MX host. After they were notified of the problem, >> they made changes, and now we see TLSA records associated with >> all the MX hosts, including "bh.nic.cz": >> >> nic.cz. IN MX 10 mail.nic.cz. ; NOERROR AD=1 >> nic.cz. IN MX 20 mx.nic.cz. ; NOERROR AD=1 >> nic.cz. IN MX 30 bh.nic.cz. ; NOERROR AD=1 >> ; >> mail.nic.cz. IN A 217.31.204.67 ; NOERROR AD=1 >> mail.nic.cz. IN AAAA 2001:1488:800:400::400 ; NOERROR AD=1 >> _25._tcp.mail.nic.cz. IN TLSA 3 1 1 >> 4f9736249ab586f37fc110856f6a3358adadbf99db03628866466194f5bb2e09 ; >> NOERROR AD=1 >> ; >> mx.nic.cz. IN A 217.31.58.56 ; NOERROR AD=1 >> mx.nic.cz. IN AAAA 2001:1ab0:7e1e:c574:7a2b:cbff:fe33:7019 ; >> NOERROR AD=1 >> _25._tcp.mx.nic.cz. IN TLSA 3 1 1 >> aa7b93daab084536530bd3256e9ceff4557cb43512640f7ab64487dc9ca14fab ; >> NOERROR AD=1 >> ; >> bh.nic.cz. IN A 217.31.204.252 ; NOERROR AD=1 >> bh.nic.cz. IN AAAA ? ; NODATA AD=1 >> _25._tcp.bh.nic.cz. IN TLSA 3 1 1 >> 4f9736249ab586f37fc110856f6a3358adadbf99db03628866466194f5bb2e09 ; >> NOERROR AD=1 >> >> I've not yet nagged "iis.se " or "wia.cz", and there we >> see that >> only one of the two MX hosts has a TLSA record: >> >> iis.se . IN MX 5 mx1.iis.se . ; >> NOERROR AD=1 >> iis.se . IN MX 5 mx2.iis.se . ; >> NOERROR AD=1 >> ; >> mx1.iis.se . IN A 91.226.36.35 ; NOERROR AD=1 >> mx1.iis.se . IN AAAA 2a00:801:f0:106::35 ; >> NOERROR AD=1 >> _25._tcp.mx1.iis.se . IN TLSA 3 1 1 >> 0894a6827f435ccb7435552290ff13e704776e4568235bbc899f515de3314ce3 ; >> NOERROR AD=1 >> ; >> mx2.iis.se . IN A 91.226.37.39 ; NOERROR AD=1 >> mx2.iis.se . IN AAAA 2001:67c:124c:2007::39 ; >> NOERROR AD=1 >> _25._tcp.mx2.iis.se . IN TLSA ? ; NXDOMAIN AD=1 >> >> wia.cz. IN MX 10 antispam.wia.cz. ; NOERROR AD=1 >> wia.cz. IN MX 20 bntispam.wia.cz. ; NOERROR AD=1 >> ; >> antispam.wia.cz. IN A 80.250.3.18 ; NOERROR AD=1 >> antispam.wia.cz. IN AAAA ? ; NODATA AD=1 >> _25._tcp.antispam.wia.cz. IN TLSA 3 1 1 >> 3b67e777e8a11d373fae958c3ea5a200bd791813c0e6e9be34e2965bcfcc071e ; >> NOERROR AD=1 >> ; >> bntispam.wia.cz. IN A 31.7.247.78 ; NOERROR AD=1 >> bntispam.wia.cz. IN AAAA ? ; NODATA AD=1 >> _25._tcp.bntispam.wia.cz. IN TLSA ? ; NXDOMAIN AD=1 >> >> While during initial deployment it is natural to proceed incrementally >> and add TLSA records to one MX host at a time, and test thoroughly >> before moving on to the rest, the end-state should be to publish >> TLSA records for all MX hosts, not a proper subset. >> >> -- >> Viktor. > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 455 bytes Desc: OpenPGP digital signature URL: From andreas.schulze at datev.de Mon Mar 6 10:39:03 2017 From: andreas.schulze at datev.de (Andreas Schulze) Date: Mon, 6 Mar 2017 10:39:03 +0100 Subject: NSEC3 Params In-Reply-To: References:

Message-ID: <7a439a5e-f975-9346-0baf-35324fcb9163@datev.de> Am 01.03.2017 um 03:12 schrieb Viktor Dukhovni: >> How often should the NSEC3 params (salt in particular) be changed. > > For now, never. Choose a suitable random value around 8 octets long, > and keep it fixed. Hello Viktor, Your suggestion differ from RFC 5155. https://tools.ietf.org/html/rfc5155#appendix-C.1: "It is RECOMMENDED that the salt be changed for every re-signing" Could you explain your choice more verbose? Thanks Andreas -- A. Schulze DATEV eG From ietf-dane at dukhovni.org Mon Mar 6 15:20:09 2017 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Mon, 6 Mar 2017 09:20:09 -0500 Subject: NSEC3 Params In-Reply-To: <7a439a5e-f975-9346-0baf-35324fcb9163@datev.de> References:

<7a439a5e-f975-9346-0baf-35324fcb9163@datev.de> Message-ID: > On Mar 6, 2017, at 4:39 AM, Andreas Schulze wrote: > > Hello Viktor, > > Your suggestion differ from RFC 5155. > https://tools.ietf.org/html/rfc5155#appendix-C.1: "It is RECOMMENDED that the salt be changed for every re-signing" > > Could you explain your choice more verbose? If you do manual full-zone re-signing, feel free. Most zones are re-signed incrementally and automatically, but the entire NSEC3 chain must use a single salt (or two chains need to be built during the transition). In any case, the main benefit of NSEC3 is "opt-out" to allow sparse signing in TLDs, hiding the zone content is only an emotional impulse, there's little rational use for it in the vast majority of cases. Others may of course disagree, ... Be sensible, but focus on operational reliability above all other considerations. -- Viktor. From pk at DENIC.DE Mon Mar 6 15:40:15 2017 From: pk at DENIC.DE (Peter Koch) Date: Mon, 6 Mar 2017 15:40:15 +0100 Subject: NSEC3 Params In-Reply-To: References:

<7a439a5e-f975-9346-0baf-35324fcb9163@datev.de> Message-ID: <20170306144015.GH9436@x27.adm.denic.de> On Mon, Mar 06, 2017 at 09:20:09AM -0500, Viktor Dukhovni wrote: > > > On Mar 6, 2017, at 4:39 AM, Andreas Schulze wrote: > > > > Hello Viktor, > > > > Your suggestion differ from RFC 5155. > > https://tools.ietf.org/html/rfc5155#appendix-C.1: "It is RECOMMENDED that the salt be changed for every re-signing" > > > > Could you explain your choice more verbose? > > If you do manual full-zone re-signing, feel free. Most zones > are re-signed incrementally and automatically, but the entire > NSEC3 chain must use a single salt (or two chains need to be > built during the transition). see also section 5.3.3 of RFC 6781, but take it with, well, a grain of salt. > In any case, the main benefit of NSEC3 is "opt-out" to allow > sparse signing in TLDs, hiding the zone content is only an > emotional impulse, there's little rational use for it in the > vast majority of cases. In the context of (future) DANE applications, enumeration resistance might become more critical even for those cases. The point probably is that if you chose a salt - rather than indeed applying NSEC3 for opt-out only - then you might want to change that, occasionally. -Peter From alex.dupuy at mac.com Mon Mar 6 15:50:53 2017 From: alex.dupuy at mac.com (Alexander Dupuy) Date: Mon, 06 Mar 2017 09:50:53 -0500 Subject: NSEC3 Params In-Reply-To: References:

Message-ID: John Allen wrote: > As you point out a PTR lookup probably does everything that an attack would do any way. If that is the case is it pointless to have nsec3 set at all. This is not entirely true, as you may have multiple names that resolve to one address, with only a single PTR record. If you put the names of upcoming products and such in your domain names, you may find that NSEC3 offers some protection (at least if you change the salt often enough to prevent brute-force attacks). But if you don?t care about zone walking, there are many advantages to using NSEC, not just simpler signing and smaller responses. In particular, some recursive resolvers already use cached NSEC responses to synthesize NXDOMAIN responses (https://tools.ietf.org/html/draft-ietf-dnsop-nsec-aggressiveuse-08 ? currently only Unbound and Google Public DNS). This can provide some mitigation of random-prefix DoS attacks on your authoritative name servers. The RFC does describe the possibility of using cached NSEC3 responses but this is more complicated, and because of NSEC hashing, the effectiveness is reduced (the recursive resolver has to cache many more NSEC3 responses to get the coverage it can get from much smaller sets of NSEC responses. It is absolutely true that there is no point ever using NSEC3 for reverse (in-addr or ip6) .ARPA zones, since you can use NXDOMAIN responses on partial results do an efficient search of only the populated parts of the zone time proportional to number of domains in the reverse zone rather than the number of addresses in the delegated name space (in other words, even IPv6 is no protection). See https://tools.ietf.org/html/rfc7707#section-5.1.4 . A reasonable split-the-difference approach can be to use NSEC for your domain?s top-level zone (example.com) where the domain names are likely to be ?www? ?mail? ?smtp? and so forth, and only use NSEC3 for delegated subdomains where confidentiality may be more important (dev.example.com). @alex -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP URL: From ietf-dane at dukhovni.org Sat Mar 25 21:50:45 2017 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Sat, 25 Mar 2017 16:50:45 -0400 Subject: Update on stats Message-ID: <20170325205044.GQ26167@straasha.imrryr.org> As of today I count 137620 domains with correct DANE TLSA records for SMTP. As expected the bulk of the DANE domains are hosted the handful of DNS/hosting providers who've enabled DANE support in bulk for the domains they host. The top 10 MX host providers by domain count are: 60764 domeneshop.no 43961 transip.nl 15734 udmedia.de 3040 bhosted.nl 1493 nederhost.net 904 ec-elements.com 431 core-networks.de 307 uvt.nl 301 bit.nl 287 omc-mail.com The real numbers are surely larger, because I don't have access to the full zone data for most ccTLDs, in particular .de, .nl and .no. There are 2449 unique zones in which the underlying MX hosts are found, this counts each of the above providers as just one zone, so is a measure of the breadth of adoption in terms of servers deployed. Alternatively, a similar number is seen in the count (2613) of distinct MX host server certificates that support the same ~137000 domains. A related number is 4172 TLSA RRsets found for MX host TCP port 25. This includes secondary MX hosts and domains none of whose primary MX hosts have TLSA records. The number of domains that at some point were listed in Gmail's email transparency report is now 105 (this is my ad-hoc criterion for a domain being a large-enough actively used email domain). Of these, 56 are in recent reports (March 2017): gmx.at jpberlin.de overheid.nl nic.br lrz.de pathe.nl registro.br mail.de wooniezie.nl gmx.ch posteo.de xs4all.nl open.ch ruhr-uni-bochum.de domeneshop.no anubisnetworks.com tum.de webcruitermail.no gmx.com uni-erlangen.de debian.org mail.com unitymedia.de domainmail.org piratenexus.com web.de freebsd.org pirateperfection.com enron.email gentoo.org pre-sustainability.com octopuce.fr ietf.org t-2.com comcast.net netbsd.org trashmail.com dd24.net netcoolusers.org xfinity.com gmx.net openssl.org bayern.de hr-manager.net samba.org bund.de t-2.net torproject.org elster.de xs4all.net minmyndighetspost.se fau.de asp4all.nl skatteverket.se gmx.de ouderportaal.nl A different metric is how many of the DANE-enabled domains received email from at least 10 Gmail senders in a recent 8 day interval. Back in Dec/2016 I reported that ~2200 out of ~105k domains met that criterion. This month, the number was ~3900 out of ~137k domains. So it seems that a non-negligible fraction of the increase is from real domains that receive email, and not just parked domains. Of the ~137000 domains, 655 have "partial" TLSA records, that cover only a subset of the MX hosts. While this protects traffic to some of the MX hosts, such domains are still vulnerable to the usual active attacks via the remaining MX hosts. The number of domains with incorrect TLSA records or failure to advertise STARTTLS (even though TLSA records are published) stands today at 96 (~30 are recent additions that may be resolved soon, the remaining ~60 are the for now stable population of broken domains). This month I'm posting the list of the 44 underlying MX hosts that serve these domains and whose TLSA records don't match reality. Hall of Shame: mail.dipietro.id.au www.mtg.de mail.inu.nl clubeararaquarense.org.br mx1.spamsponge.de mail.jekuiken.nl mail.antiphishing.ch mail.nonoserver.info mail.myzt.nl mail.digitalwebpros.com mx.datenknoten.me bounder.steelyard.nl mail.dnsmadefree.com mx.giesen.me mx.wm.net.nz demo.liveconfig.com mail.castleturing.net baobrien.org ny-do.pieterpottie.com datawebb.dafcorp.net smtp.copi.org diablo.sgt.com anubis.delphij.net eumembers.datacentrix.org tusk.sgt.com dorothy.goldenhairdafo.net smtp2.amadigi.ovh mx.bels.cz hs.kuzenkov.net webmail.headsite.se johniez.cz oostergo.net protector.rajmax.si mail.pksvice.cz ren.warunek.net arch-server.hlfh.space srv01.101host.de mail.e-rave.nl mail.blackcherry-management.co.uk mail.cdbm.de mail.hhsk.nl email.themcintyres.us mail.manima.de box.inpoint-mailt.nl The number of domains with bad DNSSEC support is 322. The top 10 DNS providers (by broken domain count) are: 52 axc.nl - Slated to be resolved 38 infracom.nl - Slated to be resolved 18 loopia.se 18 active24.cz 14 jsr-it.nl 12 rdw.nl 9 cas-com.net 8 metaregistrar.nl 6 tiscomhosting.nl 6 thednscompany.com Around 60 of the broken domains have at least one working nameserver, and so are email-reachable, given enough retries. -- Viktor. From john at klam.ca Tue Mar 28 19:18:57 2017 From: john at klam.ca (John Allen) Date: Tue, 28 Mar 2017 13:18:57 -0400 Subject: TLSA TTL value Message-ID: <6c7b04f0-bab6-0eb5-88e1-777f9ae628d1@klam.ca> I asked this question a while back, and apparently I did not make a note of the answer, sorry. What would be a "good" TTL for TLSA records. Because of there use in validating encryption certs, etc I assume that the shorter the better. I currently use 15min, is this too long or too short? John A From ietf-dane at dukhovni.org Tue Mar 28 19:36:41 2017 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Tue, 28 Mar 2017 13:36:41 -0400 Subject: TLSA TTL value In-Reply-To: <6c7b04f0-bab6-0eb5-88e1-777f9ae628d1@klam.ca> References: <6c7b04f0-bab6-0eb5-88e1-777f9ae628d1@klam.ca> Message-ID: <9E4A6E89-8705-4727-9B08-657D05D7B05A@dukhovni.org> > On Mar 28, 2017, at 1:18 PM, John Allen wrote: > > What would be a "good" TTL for TLSA records. Because of there use in > validating encryption certs, etc I assume that the shorter the better. I > currently use 15min, is this too long or too short? Set the TTL slightly shorter than the time it takes you to notice and fix a problem with the records. If you're unlikely to respond to any issues in under an hour, a TTL of much less than an hour will not be beneficial. Very short TTLs also add latency to mail delivery. On the other hand, very long TTLs make prolong problem duration. -- Viktor. From pk at DENIC.DE Tue Mar 28 20:06:06 2017 From: pk at DENIC.DE (Peter Koch) Date: Tue, 28 Mar 2017 20:06:06 +0200 Subject: TLSA TTL value In-Reply-To: <6c7b04f0-bab6-0eb5-88e1-777f9ae628d1@klam.ca> References: <6c7b04f0-bab6-0eb5-88e1-777f9ae628d1@klam.ca> Message-ID: <20170328180606.GB6254@x27.adm.denic.de> On Tue, Mar 28, 2017 at 01:18:57PM -0400, John Allen wrote: > What would be a "good" TTL for TLSA records. Because of there use in > validating encryption certs, etc I assume that the shorter the better. I > currently use 15min, is this too long or too short? the TTL is part of the DNS control plane and not strongly related to validity of the data (and neither is the DNSSEC signature lifetime, btw). What threat or failure would suggest that 15 minutes was "too long"? -Peter From john at klam.ca Wed Mar 29 17:48:42 2017 From: john at klam.ca (John Allen) Date: Wed, 29 Mar 2017 11:48:42 -0400 Subject: TLSA TTL value In-Reply-To: <20170328180606.GB6254@x27.adm.denic.de> References: <6c7b04f0-bab6-0eb5-88e1-777f9ae628d1@klam.ca> <20170328180606.GB6254@x27.adm.denic.de> Message-ID: <8d79ce7c-2c9e-75c8-d15b-e0e851c5eb54@klam.ca> I thought that one of the ideas behind TLSA is the ability to validate CA certificates. In the event that a certificate is compromised, I would have thought that removing any information that might make the compromised cert appear valid should be removed ASAP. In the event that the certificate is replaced then that information should be updated to reflect the old cert is "gone" and that new cert is in use. As I believe there is not a particularly good mechanism for publishing certificate revocations TLSA appears to provide a mechanism assist in revoking certs. On 3/28/17 2:06 PM, Peter Koch wrote: > On Tue, Mar 28, 2017 at 01:18:57PM -0400, John Allen wrote: > >> What would be a "good" TTL for TLSA records. Because of there use in >> validating encryption certs, etc I assume that the shorter the better. I >> currently use 15min, is this too long or too short? > the TTL is part of the DNS control plane and not strongly related to > validity of the data (and neither is the DNSSEC signature lifetime, btw). > > What threat or failure would suggest that 15 minutes was "too long"? > > -Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From ietf-dane at dukhovni.org Wed Mar 29 18:28:22 2017 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Wed, 29 Mar 2017 12:28:22 -0400 Subject: TLSA TTL value In-Reply-To: <8d79ce7c-2c9e-75c8-d15b-e0e851c5eb54@klam.ca> References: <6c7b04f0-bab6-0eb5-88e1-777f9ae628d1@klam.ca> <20170328180606.GB6254@x27.adm.denic.de> <8d79ce7c-2c9e-75c8-d15b-e0e851c5eb54@klam.ca> Message-ID: > On Mar 29, 2017, at 11:48 AM, John Allen wrote: > > In the event that a certificate is compromised, I would have thought > that removing any information that might make the compromised cert > appear valid should be removed ASAP. Sure, if the private key is compromised you want to promptly replace the key+cert (key-pair) and publish an updated TLSA record. However, you're unlikely to notice such compromise within just a few minutes of the event. So a pragmatic choice is to accept that in the event of key compromise there will be a window of exposure, and that lowering the TTLs has diminishing returns once the TTL is much lower than the time it takes you to discover the problem. The other factor to consider is the duration of disruption if you replace your server key before the prior TLSA RRset expires from client caches. During that time clients may defer email to your domain because they have the old TLSA RR, but encounter a new server key-pair. With my recommended "3 1 1 + 2 1 1" approach, if only one of the two keys is compromised, then you can keep the other in place, while rotating only the compromised key. If you publish only "3 X X" or only "2 X X" records, then unplanned key rotation can disrupt mail flow for up to the TTL unless you publish the new TLSA record first, and wait a full TTL before deploying the replacement key-pair. Bottom line, I still think a TTL of an hour or two is fine for TLSA records, and that "3 1 1 + 2 1 1" is a better solution than very short TTLs. The CA key can be off-line (if private) or difficult to compromise at the same time as your server key (if a public CA). Of course with a public CA (e.g. the very popular Let's Encrypt) you have other risks (weak proof of domain control with DV). -- Viktor. From ietf-dane at dukhovni.org Fri Mar 31 06:33:17 2017 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Fri, 31 Mar 2017 00:33:17 -0400 Subject: Cloudmark DANE support Message-ID: <01253195-D8DB-4A75-B2CB-D2B14A688688@dukhovni.org> https://blog.cloudmark.com/2017/03/27/dane-and-email-security/ -- Viktor. DANE and Email Security Mon, 27 Mar 2017 Andrew Conway The forthcoming Cloudmark Security Platform for Email 5.2 will include support for DNS-Based Authentication of Named Entities (DANE), a new protocol that enables increased security for email communications. In this article we?ll look at how DANE works, how it can contribute to a more secure email environment, and how it is starting to gain acceptance. ... DANE does not stop all possibility of email compromise, but it does drastically reduce the surface for man in the middle attacks. By including DANE in Cloudmark Security Platform for Email 5.2, we are pleased to be able to contribute to more secure email communications for our clients and their users.