From ietf-dane at dukhovni.org Fri Jul 13 09:22:20 2018 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Fri, 13 Jul 2018 03:22:20 -0400 Subject: DANE-TA(2) private CAs and SHA-1 Message-ID: <20180713072220.GR87142@straasha.imrryr.org> By using DANE-TA(2) TLSA records you can associate your SMTP server with a either a public or private (your own) issuer CA. This can simplify the management of TLSA records of multiple MX hosts by using a CNAME to a common location where you publish the shared CA key hash. Some care needs to be take to make sure that certificate chains issued by a private CA can be successfully validated by correctly configured DANE TLS clients. 1. Make sure the MX hostname of the end-entity server is one of the names in the subjectAltName extension of the server certificate. This is optional for DANE-EE(3), but is required for DANE-TA(2). Some MX hosts are known by different names when serving different domains. I don't recommend this, but can't stop you from doing it. In that case, all the names should appear in the certificate, or (if using server-side SNI) each name should appear in the corresponding certificate. 2. Make sure that the server certificate is replaced in a timely manner before it expires. This is also optional with DANE-EE(3), and required with DANE-TA(2). 3. [The motivation for this message]. Use broadly accepted cryptographic algorithms and parameters. For example, recent versions of GnuTLS by default no longer accept SHA-1 signatures in certificate chains. Some versions of Exim that support DANE are linked with GnuTLS, and the Exim maintainers are not presently inclined to re-enable SHA-1 support. Therefore, sites using private CAs with SHA-1 signatures may encounter problems receiving some email. (Public CA/B forum CAs no longer issue SHA-1 certificates.) For best interoperability use the SHA256 digest algorithm in certificate signatures. For best interoperability, use RSA key sizes of at least 1280 bits, and no more than 4096. The most common choice is 2048-bits. For ECDSA, stick with NIST P-256 (OpenSSL names for this ECDSA curve are prime256v1 and secp256r1). Today (after most of the small number of domains using SHA-1 with private CAs re-issued their certificates) the DANE survey finds only one MX host of one domain with SHA-1 private-CA signatures: semidefinite.de. IN MX 10 mail.semidefinite.de. so the impact of the GnuTLS policy is low. With a bit of luck, this post will help others avoid the same issue, and perhaps also the postmaster of the above domain will see it on one of the dane-users, postfix-users or exim-users lists, so the number of affected domains may soon be zero. -- Viktor. From dennis at baaten.com Fri Jul 13 15:15:57 2018 From: dennis at baaten.com (Dennis Baaten) Date: Fri, 13 Jul 2018 15:15:57 +0200 Subject: DANE rollover: selector type Message-ID: <004401d41aab$a3467320$e9d35960$@baaten.com> Hi Viktor, In your presentation named "Real World DANE Inter-domain email transport" (https://static.ptbl.co/static/attachments/169319/1520904692.pdf) you describe two approaches to handle a certificate change from a DANE perspective: "current + next", and "current + issuer CA". In the given example you use a "1" (certificate public key) for the TLSA parameter "selector". I'm wondering whether this example is meant to imply that selector type "1" is preferred over selector type "0" (full certificate)? In my opinion the selector type should not matter, making a "311 + 211" just as good as a "301 + 211". Would you agree? Regards, Dennis -------------- next part -------------- An HTML attachment was scrubbed... URL: From ietf-dane at dukhovni.org Fri Jul 13 16:42:31 2018 From: ietf-dane at dukhovni.org (Viktor Dukhovni) Date: Fri, 13 Jul 2018 10:42:31 -0400 Subject: DANE rollover: selector type In-Reply-To: <004401d41aab$a3467320$e9d35960$@baaten.com> References: <004401d41aab$a3467320$e9d35960$@baaten.com> Message-ID: <20180713144231.GD33554@straasha.imrryr.org> On Fri, Jul 13, 2018 at 03:15:57PM +0200, Dennis Baaten wrote: > In your presentation named "Real World DANE Inter-domain email transport" > (https://static.ptbl.co/static/attachments/169319/1520904692.pdf) you > describe two approaches to handle a certificate change from a DANE > perspective: "current + next", and "current + issuer CA". In the given > example you use a "1" (certificate public key) for the TLSA parameter > "selector". I'm wondering whether this example is meant to imply that > selector type "1" is preferred over selector type "0" (full certificate)? Yes, "1" is preferred for public CAs, where you don't control the timing of issuer certificate renewals, and typically (e.g. Let's Encrypt) the CA continues to use the same key, with a newly issued certificate. > In my opinion the selector type should not matter, making a "311 + 211" just > as good as a "301 + 211". Would you agree? As for DANE-EE(3), "3 1 1" is also preferred, though if you always change keys when renewing the certificate, then it indeed it does not matter very much. -- Vikktor. From bart.knubben at forumstandaardisatie.nl Tue Jul 17 22:20:58 2018 From: bart.knubben at forumstandaardisatie.nl (Knubben, B.S.J. (Bart) - Forum Standaardisatie) Date: Tue, 17 Jul 2018 20:20:58 +0000 Subject: Overview of outbound DANE for SMTP support Message-ID: Hi, We made the following overview of products/services with outbound DANE support (i.e. DANE verification). Any remarks/additions are welcome. I. Supported: - Postfix (since version 2.11.0, January 2014): http://www.postfix.org/TLS_README.html#client_tls_dane - Halon (since version 3.4-r2, November 2015): https://halon.io/dane and https://wiki.halon.io/DANE - OpenSSL (since version 1.1.0, August 2016): https://www.openssl.org/docs/manmaster/man3/SSL_CTX_dane_enable.html and https://www.openssl.org/docs/manmaster/man1/openssl-s_client.html - Cloudmark (since version 5.2, March 2017): https://blog.cloudmark.com/2017/03/27/dane-and-email-security/ - Exim (since version 4.91, April 2018): https://www.exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html - Mail-in-a-Box (uses Postfix): https://github.com/mail-in-a-box/mailinabox/blob/master/security.md - ldns (uses OpenSSL): https://www.nlnetlabs.nl/documentation/ldns/dane_8h.html II. Requested: - Cisco: Bug ID: CSCuo87918 - [ Feature Request] TLS DANE Support for Email Security Appliance, https://bst.cloudapps.cisco.com/bugsearch/bug/CSCuo87918/ - MS O365: https://office365.uservoice.com/forums/273493-office-365-admin/suggestions/13415532-dnssec-support-in-office-365/ and https://office365.uservoice.com/forums/289138-office-365-security-compliance/suggestions/32360299-dnssec-support-in-office-365 - Fortinet: https://fortinet.uservoice.com/forums/23797-fortipartner-feature-requests/suggestions/7029885-fortimail-dnssec-support - Protonmail: https://protonmail.uservoice.com/forums/284483-feedback/suggestions/34338826-implement-dane-for-added-security-and-privacy and https://protonmail.uservoice.com/forums/284483-feedback/suggestions/16593601-support-dane BTW a simple outbound DANE test can be found on https://havedane.net. -- Best regards, Bart Knubben Dutch Standardisation Forum https://www.forumstandaardisatie.nl/content/english Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het elektronisch verzenden van berichten. This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages. From ml+dane-users at esmtp.org Tue Jul 17 23:01:38 2018 From: ml+dane-users at esmtp.org (ml+dane-users at esmtp.org) Date: Tue, 17 Jul 2018 14:01:38 -0700 Subject: Overview of outbound DANE for SMTP support In-Reply-To: References: Message-ID: <20180717210138.GA23344@x2.esmtp.org> On Tue, Jul 17, 2018, Knubben, B.S.J. (Bart) - Forum Standaardisatie wrote: > We made the following overview of products/services with outbound > DANE support (i.e. DANE verification). Any remarks/additions are > welcome. > I. Supported: MeTA1 http://www.meta1.org/ since about 2016-08 (with OpenSSL 1.1) From dane-users-phil at spodhuis.org Wed Jul 18 02:43:57 2018 From: dane-users-phil at spodhuis.org (Phil Pennock) Date: Tue, 17 Jul 2018 20:43:57 -0400 Subject: Overview of outbound DANE for SMTP support In-Reply-To: References: Message-ID: <20180718004357.GA25951@osmium.lan> On 2018-07-17 at 20:20 +0000, Knubben, B.S.J. (Bart) - Forum Standaardisatie wrote: > We made the following overview of products/services with outbound DANE support (i.e. DANE verification). Any remarks/additions are welcome. > > I. Supported: > - Exim (since version 4.91, April 2018): https://www.exim.org/exim-html-current/doc/html/spec_html/ch-encrypted_smtp_connections_using_tlsssl.html That was the promotion from Experimental status. Exim has supported DANE, if desired, since version 4.85, released 2015-01-13.