Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt
On Thu, Jun 23, 2022 at 05:33:32PM -0400, John Levine wrote: > Kind of. I use the same key for all of the certs for the many names > that each of my mail servers have so I have one TLSA record and a lot > of CNAMEs. That's probably bad practice for some reason but whatever. Actually, I'd say that TLSA record CNAMEs are a fine practice. If the underlying servers in fact share the same key, then centralising the TLSA record management in one place reduces the odds that you'd forget to update one of them when the server key rolls over. Better a robust well managed shared key, than lots of keys poorly managed. Speaking of DANE deployment, today mijndomein.nl enabled inbound DANE for 184k customer domains, making them the #3 DANE SMTP hosting provider by MX-hosted domain count. The total number of DANE SMTP domains is now 3.53 million. Yes, Gmail and so MTA-STS probably has more users, but DANE has 2 to 3 orders of magnitude more domains. Looking at the top 15 MX hosting providers of DNSSEC-signed customer domains the numbers are: # domains hosting zoneDNSSEC/DANE? - 2,322,925 google.com - 1,461,637 ovh.net - 1,249,420 one.com DANE 578,352 outlook.com - 279,564 hostpoint.chDANE 194,551 googlemail.com - 185,512 mijndomein.nl DANE 172,483 infomaniak.ch DANE 167,874 argewebhosting.nl DANE 156,585 transip.email DANE 139,405 aftermarket.pl DNSSEC 115,664 hostnet.nl DANE 110,050 mailprotect.be - 107,427 domeneshop.no DANE 98,172 loopia.se DANE -- Viktor. ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt
It appears that Viktor Dukhovni said: >On Thu, Jun 23, 2022 at 01:42:46PM -0400, John R Levine wrote: > >> Among the reasons that DANE in e-mail is less common is that it is tricky. > >DANE is only "tricky" when you're trying to integrate TLSA record >updates with ACME cert rollovers and don't configure key reuse. Kind of. I use the same key for all of the certs for the many names that each of my mail servers have so I have one TLSA record and a lot of CNAMEs. That's probably bad practice for some reason but whatever. One tricky part is setting things up, ensuring that you know all the names the server has and that the certs are all issued and the TLSA or CNAME installed. The other tricky part is automating the renewals which requires either DNS API access or a hack with a web server with the same name as each mail server name. Neither is horribly difficult but they're things mail operators haven't had to do in the past. R's, John ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt
On Thu, Jun 23, 2022 at 01:42:46PM -0400, John R Levine wrote: > Among the reasons that DANE in e-mail is less common is that it is tricky. DANE is only "tricky" when you're trying to integrate TLSA record updates with ACME cert rollovers and don't configure key reuse. Otherwise the same "3 1 1" record continues to work across cert rollovers for multiple domains, regardless of the MX hostname used. For example: digitalehuisbaas.be. IN MX 10 mail.digitalehuisbaas.be. mail.digitalehuisbaas.be. IN A 141.138.169.203 mail.digitalehuisbaas.be. IN 2a03:3c00:a002:203::1001 _25._tcp.mail.digitalehuisbaas.be. IN TLSA 3 1 1 e415b82b2e85867110f488617b98c9492cadf727b405eabea7d96e97744dfafb mail.digitalehuisbaas.be[141.138.169.203]: pass: TLSA match: depth = 0 name = webhostingserver.nl pkey sha256 [matched] <- 3 1 1 e415b82b2e85867110f488617b98c9492cadf727b405eabea7d96e97744dfafb mail.digitalehuisbaas.be[2a03:3c00:a002:203::1001]: pass: TLSA match: depth = 0 name = webhostingserver.nl pkey sha256 [matched] <- 3 1 1 e415b82b2e85867110f488617b98c9492cadf727b405eabea7d96e97744dfafb headshot.amsterdam. IN MX 10 mail.headshot.amsterdam. mail.headshot.amsterdam. IN A 141.138.169.226 mail.headshot.amsterdam. IN 2a03:3c00:a002:226::1000 _25._tcp.mail.headshot.amsterdam. IN TLSA 3 1 1 e415b82b2e85867110f488617b98c9492cadf727b405eabea7d96e97744dfafb mail.headshot.amsterdam[141.138.169.226]: pass: TLSA match: depth = 0 name = webhostingserver.nl pkey sha256 [matched] <- 3 1 1 e415b82b2e85867110f488617b98c9492cadf727b405eabea7d96e97744dfafb mail.headshot.amsterdam[2a03:3c00:a002:226::1000]: pass: TLSA match: depth = 0 name = webhostingserver.nl pkey sha256 [matched] <- 3 1 1 e415b82b2e85867110f488617b98c9492cadf727b405eabea7d96e97744dfafb creatievestudio.be. IN MX 10 mail.creatievestudio.be. mail.creatievestudio.be. IN A 141.138.169.210 mail.creatievestudio.be. IN 2a03:3c00:a002:210::100d _25._tcp.mail.creatievestudio.be. IN TLSA 3 1 1 e415b82b2e85867110f488617b98c9492cadf727b405eabea7d96e97744dfafb mail.creatievestudio.be[141.138.169.210]: pass: TLSA match: depth = 0 name = webhostingserver.nl pkey sha256 [matched] <- 3 1 1 e415b82b2e85867110f488617b98c9492cadf727b405eabea7d96e97744dfafb mail.creatievestudio.be[2a03:3c00:a002:210::100d]: pass: TLSA match: depth = 0 name = webhostingserver.nl pkey sha256 [matched] <- 3 1 1 e415b82b2e85867110f488617b98c9492cadf727b405eabea7d96e97744dfafb ... ~95 thousand more ... -- Viktor. ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt
On 6/23/22 11:02 AM, Viktor Dukhovni wrote: On Sat, Jun 18, 2022 at 11:56:30AM -0600, Peter Saint-Andre wrote: On 5/27/22 7:51 AM, Stephen Farrell wrote: - section 3.2: I wondered why no mention of MTA-STS or DANE? Could/should we say that MTA implementations SHOULD include support for such strictness? Hi Stephen, Although these technologies (RFC 8461 and RFC 7672) seem sensible, I don't think we authors have a good handle on whether they are widely deployed enough to justify a SHOULD in a BCP. We will reach out to folks in the email community for guidance. Both DANE and MTA-STS have now been around for some years and there is a body of operational experience with these protocols. The story is roughly that: - Both require no changes in the receiving MTA, it just needs to support STARTTLS and be configured with a "suitable" certificate chain that meets the promised constraints (be they DANE, MTA-STS or both). - Inbound DANE is supported on ~3.34 million domains. * Many are small domains MX hosted by the likes of: 1,229,567 one.com 278,987 hostpoint.ch 170,237 infomaniak.ch 161,743 transip.nl 158,849 argewebhosting.nl 112,901 hostnet.nl 107,719 domeneshop.no 100,270 jouwweb.nl 96,866 loopia.se 95,410 webhostingserver.nl ... * Some are email service providers hosting many users and perhaps also customer domains, for example: web.de gmx.de protonmail.ch mailbox.org posteo.de ... - Inbound MTA-STS is supported by a much smaller number (a few thousand not millions) of domains, but notably these include many of the largest email service providers: $ for d in gmail.com hotmail.com outlook.com yahoo.com aol.com; do printf "%-20s " "$d" curl -sLo - https://mta-sts.$d/.well-known/mta-sts.txt | grep '^mode:' || echo done gmail.commode: enforce hotmail.com mode: enforce outlook.com mode: enforce yahoo.commode: testing aol.com - Outbound deployment is considerably harder to measure, but IIRC outbound DANE is supported by: * outlook.com and Azure hosted Exchange customer domains * one.com * transip.nl * protonmail.ch * mailbox.org * posteo.de * ... - The sending MTA does all the heavy lifting of implementing peer validation per DANE or MTA-STS as applicable. - Software support for outbound DANE is included in Postfix, Exim, Halon MTA, Power MTA, Cisco ESA, Microsoft hosted Exchange, ... with partial support last I looked also in Sendmail and perhaps some Qmail forks... - Software support for MTA-STS is NOT included in either Postfix or Exim due to its rather unwieldy architectural footprint, with a mixture of HTTPS and SMTP and complex per destination caches. At least in the case Postfix and Exim support for MTA-STS is unlikely in the near term. The developers have expressed explicit distaste for the protocol. Returning to the question asked: SHOULD MTAS support DANE and/or MTA-STS? - If the question is about the software stack, then: * Any MTA that supports STARTTLS already supports both inbound. * Outbound support for MTA-STS is unlikely the leading open source MTAs * Outbound support for DANE is starting to be available even in some of the cloud provider stacks, but is not yet prevalent. - If the question is about operator diligence then: * Inbound DANE requires DNSSEC support from both the recipient domain and its MX host domain. The primary operational burden is on the MX host operator, and DANE scales very well when a single skilled operator MX hosts many domains. Adoption by the domain hosting operator is growing, especially in northern Europe, where DNSSEC-signing is presently also more prevalent. * Inbound MTA-STS requires an HTTPS server for policy publication, with support for the ".well-known/mta-sts.txt" URL. * Both DANE and MTA-STS require careful management of associated DNS records, in particular correct timing of DNS updates relative to changes in certificate chains or the MTA-STS policy respectively. * Outbound DANE requires a local validating resolver on the MTA, which is comparatively easy to set up, but is an extra step that holds back some smaller less-skilled operators. It also requires an X.509 layer in the TLS library that supports DANE-style certificate chain validation.
Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt
It appears that Viktor Dukhovni said: >- If the question is about the software stack, then: > > * Any MTA that supports STARTTLS already supports both inbound. Almost -- it needs to have a cert that matches its name and is signed and/or matches the TLSA record. A lot of the default installations I've seen still generate a self-signed cert. This isn't a huge burden but it's not entirely trivial, particularly since the acme web validation method doesn't work unless you can spin up a web server with the same name as the mail server. > * Outbound support for MTA-STS is unlikely in the leading open source >MTAs > * Outbound support for DANE is starting to be available even in >some of the cloud provider stacks, but is not yet prevalent. Yup. I think that publishing stuff for inbound mta-sts is worth it since for most people a large fraction of incoming mail will check it. R's, John ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt
On Thu, 23 Jun 2022, Peter Saint-Andre wrote: - section 3.2: I wondered why no mention of MTA-STS or DANE? Could/should we say that MTA implementations SHOULD include support for such strictness? Hi John, thanks for sharing these insights. I'll reach out to a few Comcast colleagues regarding DANE. We the authors of course want to recommend what's best current practice, thus the interest in how widely deployed these technologies are. Another wrinkle is that MTA-STS is specific to the email world, whereas DANE has at least been defined as a more generalized technology and deployment might vary across application protocols (e.g., I know there has been some adoption of DANE in the XMPP community but it is far from ubiquitous). Among the reasons that DANE in e-mail is less common is that it is tricky. Until MTA-STS and DANE, when a mail server started a TLS session it could and usually did present a random self-signed certificate and nothing checked it. But now it has to present a cert that matches the name that the client expects. It is very common for a single mail server to handle mail for a zillion different domains. Sometimes all the MX records point to the same name for the mail server, e.g.. all of Gmail's hosted domains point to aspmx.l.google.com., but sometimes each domain has its own name, e.g. the MX for tucows.com is mx.tucows.com.cust.hostedemail.com. This means the mail server has to have a cert for every name that points to it and use SNI to return the correct one. I added SNI to my mail server and have a library of 100 certs for the 100 domains it handles but as you know I am strange. Regards, John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt
On Thu, Jun 23, 2022 at 01:02:57PM -0400, Viktor Dukhovni wrote: > * Some are email service providers hosting many users and >perhaps also customer domains, for example: > >web.de >gmx.de >protonmail.ch >mailbox.org >posteo.de >... Apologies to comcast.net, one the earliest adopters, re forgetting to include them on this list. They've been doing such a good job for a long time that I've not had to think about them for some time... :-) > - Outbound deployment is considerably harder to measure, but > IIRC outbound DANE is supported by: > > * outlook.com and Azure hosted Exchange customer domains > * one.com > * transip.nl > * protonmail.ch > * mailbox.org > * posteo.de > * ... Ditto. -- Viktor. ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt
On 6/23/22 10:44 AM, John Levine wrote: It appears that Peter Saint-Andre said: On 5/27/22 7:51 AM, Stephen Farrell wrote: - section 3.2: I wondered why no mention of MTA-STS or DANE? Could/should we say that MTA implementations SHOULD include support for such strictness? Hi Stephen, Although these technologies (RFC 8461 and RFC 7672) seem sensible, I don't think we authors have a good handle on whether they are widely deployed enough to justify a SHOULD in a BCP. We will reach out to folks in the email community for guidance. MTA-STS is in wide use. All of the large mail systems I know publish mta-sts records and a lot of the smaller ones. DANE is less widely used but Viktor would have the numbers. I know that Comcast buth publishes DANE records and checks them on their outbound mail so they might be willing to share some observations. Hi John, thanks for sharing these insights. I'll reach out to a few Comcast colleagues regarding DANE. We the authors of course want to recommend what's best current practice, thus the interest in how widely deployed these technologies are. Another wrinkle is that MTA-STS is specific to the email world, whereas DANE has at least been defined as a more generalized technology and deployment might vary across application protocols (e.g., I know there has been some adoption of DANE in the XMPP community but it is far from ubiquitous). Peter ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt
On Sat, Jun 18, 2022 at 11:56:30AM -0600, Peter Saint-Andre wrote: > On 5/27/22 7:51 AM, Stephen Farrell wrote: > > > - section 3.2: I wondered why no mention of MTA-STS or > > DANE? Could/should we say that MTA implementations > > SHOULD include support for such strictness? > > Hi Stephen, > > Although these technologies (RFC 8461 and RFC 7672) seem sensible, I > don't think we authors have a good handle on whether they are widely > deployed enough to justify a SHOULD in a BCP. We will reach out to folks > in the email community for guidance. Both DANE and MTA-STS have now been around for some years and there is a body of operational experience with these protocols. The story is roughly that: - Both require no changes in the receiving MTA, it just needs to support STARTTLS and be configured with a "suitable" certificate chain that meets the promised constraints (be they DANE, MTA-STS or both). - Inbound DANE is supported on ~3.34 million domains. * Many are small domains MX hosted by the likes of: 1,229,567 one.com 278,987 hostpoint.ch 170,237 infomaniak.ch 161,743 transip.nl 158,849 argewebhosting.nl 112,901 hostnet.nl 107,719 domeneshop.no 100,270 jouwweb.nl 96,866 loopia.se 95,410 webhostingserver.nl ... * Some are email service providers hosting many users and perhaps also customer domains, for example: web.de gmx.de protonmail.ch mailbox.org posteo.de ... - Inbound MTA-STS is supported by a much smaller number (a few thousand not millions) of domains, but notably these include many of the largest email service providers: $ for d in gmail.com hotmail.com outlook.com yahoo.com aol.com; do printf "%-20s " "$d" curl -sLo - https://mta-sts.$d/.well-known/mta-sts.txt | grep '^mode:' || echo done gmail.commode: enforce hotmail.com mode: enforce outlook.com mode: enforce yahoo.commode: testing aol.com - Outbound deployment is considerably harder to measure, but IIRC outbound DANE is supported by: * outlook.com and Azure hosted Exchange customer domains * one.com * transip.nl * protonmail.ch * mailbox.org * posteo.de * ... - The sending MTA does all the heavy lifting of implementing peer validation per DANE or MTA-STS as applicable. - Software support for outbound DANE is included in Postfix, Exim, Halon MTA, Power MTA, Cisco ESA, Microsoft hosted Exchange, ... with partial support last I looked also in Sendmail and perhaps some Qmail forks... - Software support for MTA-STS is NOT included in either Postfix or Exim due to its rather unwieldy architectural footprint, with a mixture of HTTPS and SMTP and complex per destination caches. At least in the case Postfix and Exim support for MTA-STS is unlikely in the near term. The developers have expressed explicit distaste for the protocol. Returning to the question asked: SHOULD MTAS support DANE and/or MTA-STS? - If the question is about the software stack, then: * Any MTA that supports STARTTLS already supports both inbound. * Outbound support for MTA-STS is unlikely the leading open source MTAs * Outbound support for DANE is starting to be available even in some of the cloud provider stacks, but is not yet prevalent. - If the question is about operator diligence then: * Inbound DANE requires DNSSEC support from both the recipient domain and its MX host domain. The primary operational burden is on the MX host operator, and DANE scales very well when a single skilled operator MX hosts many domains. Adoption by the domain hosting operator is growing, especially in northern Europe, where DNSSEC-signing is presently also more prevalent. * Inbound MTA-STS requires an HTTPS server for policy publication, with support for the ".well-known/mta-sts.txt" URL. * Both DANE and MTA-STS require careful management of associated DNS records, in particular correct timing of DNS updates relative to changes in certificate chains or the MTA-STS policy respectively. * Outbound DANE requires a local validating resolver on the MTA, which is comparatively easy to set up, but is an extra step that holds back some smaller less-skilled operators. It also requires an X.509 layer in the TLS library that supports DANE-style certificate chain validation. This is currently available in OpenSSL, but last I looked not in e.g. BoringSSL or
Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt
It appears that Peter Saint-Andre said: >On 5/27/22 7:51 AM, Stephen Farrell wrote: > >> - section 3.2: I wondered why no mention of MTA-STS or >> DANE? Could/should we say that MTA implementations >> SHOULD include support for such strictness? > >Hi Stephen, > >Although these technologies (RFC 8461 and RFC 7672) seem sensible, I >don't think we authors have a good handle on whether they are widely >deployed enough to justify a SHOULD in a BCP. We will reach out to folks >in the email community for guidance. MTA-STS is in wide use. All of the large mail systems I know publish mta-sts records and a lot of the smaller ones. DANE is less widely used but Viktor would have the numbers. I know that Comcast buth publishes DANE records and checks them on their outbound mail so they might be willing to share some observations. R's, John ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt
On 5/27/22 7:51 AM, Stephen Farrell wrote: - section 3.2: I wondered why no mention of MTA-STS or DANE? Could/should we say that MTA implementations SHOULD include support for such strictness? Hi Stephen, Although these technologies (RFC 8461 and RFC 7672) seem sensible, I don't think we authors have a good handle on whether they are widely deployed enough to justify a SHOULD in a BCP. We will reach out to folks in the email community for guidance. I also wonder how far this document should go in making recommendations for various application protocols - SIP, IRC, XMPP, NNTP, etc. Peter ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt
Hi John, thank you very much for your review. We are tracking your comments here: * https://github.com/yaronf/I-D/issues/377 * https://github.com/yaronf/I-D/issues/378 * https://github.com/yaronf/I-D/issues/379 * https://github.com/yaronf/I-D/issues/380 * https://github.com/yaronf/I-D/issues/381 * https://github.com/yaronf/I-D/issues/382 * https://github.com/yaronf/I-D/issues/383 * https://github.com/yaronf/I-D/issues/384 With regards to: - of time (e.g., measured in days) "Days" is ridiculasly long for non-constrained use cases. ANSSI requires ephemeral diffie-hellman every hour or 100 GB for IPsec. Signal and WireGuard are doing Diffie-Hellman much more often than that. I think "measured in days" give the wrong idea. I suggest changing to "e.g., every hour". Days seems like a recommendation taken from the year 2000. If needed separate contrained and non-constrained use cases. This was already fixed in the editor’s copy (by Ben): * https://github.com/yaronf/I-D/pull/358/commits/c39180c cheers, thanks! From: Uta on behalf of John Mattsson Date: Friday, 10 June 2022 at 14:25 To: uta@ietf.org Subject: Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt Hi, I reviwed the whole document. Looks fine in general. Some comments: - "Those who implement and deploy TLS and DTLS, in particular versions 1.2 or earlier of these protocols" Delete "or earlier". As these versions are "MUST NOT negotiate". Might be good to mention this deprecation in the introduction. - Would be good for the reader if the intro said something to explain the TLS handshake and record layer. DTLS and QUIC also use the TLS handshake but with a different record layer. Would be good to point out that a lot of the recommendations for "TLS" apply to all uses of the TLS handshake such as DTLS and QUIC. - I think QUIC should be mentioned in the introduction. Otherwise the document feels old already when it is published. QUIC already makes up a huge part of internet traffic. Over 25% in some ISP. Many of the recommendations apply to QUIC as well - 3.3. Compression Would be good to add that TLS certificate compression is fine to use. - of time (e.g., measured in days) "Days" is ridiculasly long for non-constrained use cases. ANSSI requires ephemeral diffie-hellman every hour or 100 GB for IPsec. Signal and WireGuard are doing Diffie-Hellman much more often than that. I think "measured in days" give the wrong idea. I suggest changing to "e.g., every hour". Days seems like a recommendation taken from the year 2000. If needed separate contrained and non-constrained use cases. - "Renegotiation in TLS 1.2 was replaced" Change to "partly replaced". Diffie-Hellman, server authentication, and update of the exporter secret are all missing. - Section 4.1 I am missing a recommendation related to AEAD. I would make sense to add that "Implementations SHOULD NOT negotiate non-AEAD cipher suites." - "Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the first proposal to any server, unless they have prior knowledge that the server cannot respond to a TLS 1.2 client_hello message." I would delere ", unless ...". This does not align with MUST NOT negotiate 1.1 - "When using RSA, servers SHOULD authenticate using certificates with at least a 2048-bit modulus for the public key." This needs to be "MUST" to alging with "MUST NOT negotiate cipher suites offering less than 112 bits of security" - The document should talk about the need to start phasing out RSA-2048 and 2048-bit DH keys which both gives 112-bit security. BSI requires that RSA-2048 disabled by January 2023. CA Browser forum has already forbidden RSA-2048 for use with code signing. - 7.1. The document should make it clear without Host Name Validation there is typically no authentication. The TLS handshake only provides proof-of-possestion of the private key and transfers certificates so that the application can do authentication. Cheers, John From: Uta on behalf of internet-dra...@ietf.org Date: Thursday, 26 May 2022 at 23:22 To: i-d-annou...@ietf.org Cc: uta@ietf.org Subject: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Using TLS in Applications WG of the IETF. Title : Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Authors : Yaron Sheffer Peter Saint-Andre Thomas Fossati Filename: draft-ietf-uta-rfc7525bis-07.txt Pages : 39 Date: 2022-05-26 Abstract: Transport Layer
Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt
Hi, I reviwed the whole document. Looks fine in general. Some comments: - "Those who implement and deploy TLS and DTLS, in particular versions 1.2 or earlier of these protocols" Delete "or earlier". As these versions are "MUST NOT negotiate". Might be good to mention this deprecation in the introduction. - Would be good for the reader if the intro said something to explain the TLS handshake and record layer. DTLS and QUIC also use the TLS handshake but with a different record layer. Would be good to point out that a lot of the recommendations for "TLS" apply to all uses of the TLS handshake such as DTLS and QUIC. - I think QUIC should be mentioned in the introduction. Otherwise the document feels old already when it is published. QUIC already makes up a huge part of internet traffic. Over 25% in some ISP. Many of the recommendations apply to QUIC as well - 3.3. Compression Would be good to add that TLS certificate compression is fine to use. - of time (e.g., measured in days) "Days" is ridiculasly long for non-constrained use cases. ANSSI requires ephemeral diffie-hellman every hour or 100 GB for IPsec. Signal and WireGuard are doing Diffie-Hellman much more often than that. I think "measured in days" give the wrong idea. I suggest changing to "e.g., every hour". Days seems like a recommendation taken from the year 2000. If needed separate contrained and non-constrained use cases. - "Renegotiation in TLS 1.2 was replaced" Change to "partly replaced". Diffie-Hellman, server authentication, and update of the exporter secret are all missing. - Section 4.1 I am missing a recommendation related to AEAD. I would make sense to add that "Implementations SHOULD NOT negotiate non-AEAD cipher suites." - "Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the first proposal to any server, unless they have prior knowledge that the server cannot respond to a TLS 1.2 client_hello message." I would delere ", unless ...". This does not align with MUST NOT negotiate 1.1 - "When using RSA, servers SHOULD authenticate using certificates with at least a 2048-bit modulus for the public key." This needs to be "MUST" to alging with "MUST NOT negotiate cipher suites offering less than 112 bits of security" - The document should talk about the need to start phasing out RSA-2048 and 2048-bit DH keys which both gives 112-bit security. BSI requires that RSA-2048 disabled by January 2023. CA Browser forum has already forbidden RSA-2048 for use with code signing. - 7.1. The document should make it clear without Host Name Validation there is typically no authentication. The TLS handshake only provides proof-of-possestion of the private key and transfers certificates so that the application can do authentication. Cheers, John From: Uta on behalf of internet-dra...@ietf.org Date: Thursday, 26 May 2022 at 23:22 To: i-d-annou...@ietf.org Cc: uta@ietf.org Subject: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Using TLS in Applications WG of the IETF. Title : Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Authors : Yaron Sheffer Peter Saint-Andre Thomas Fossati Filename: draft-ietf-uta-rfc7525bis-07.txt Pages : 39 Date: 2022-05-26 Abstract: Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases. An earlier version of this document was published as RFC 7525 when the industry was in the midst of its transition to TLS 1.2. Years later this transition is largely complete and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, the document updates RFC 5288 and RFC 6066 in view of recent attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-uta-rfc7525bis/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-uta-rfc7525bis-07.html A diff from the previous version is availab
Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt
Thanks Stephen, opened 4 issues, https://github.com/yaronf/I-D/issues?q=is%3Aissue+is%3Aopen+label%3ABCP195 Yaron On 5/27/22, 16:51, "Uta on behalf of Stephen Farrell" wrote: Hiya, I had a read of this. Seems to me to be in fine shape but a couple of comments below. If those have already been discussed, apologies, and do ignore 'em. I don't think any of my comments need addressing before publication, but figured it was no harm sending 'em anyway:-) - section 3.2: I wondered why no mention of MTA-STS or DANE? Could/should we say that MTA implementations SHOULD include support for such strictness? - 4.2: there's been some cfrg [1] discussion (but not much and without so far reaching a conclusion) on deterministic signatures (RFC6979) and fault injection attacks. I wonder if we want to say anything about that? It might be worth just adding a reference that describes the problem, but I don't think we can expect the cfrg discussion to have resolved before this gets published. Those attacks are probably not that important for a typical TLS server but more interesting for small devices with TLS servers so maybe it's a bit too niche a concern to include? - 7.4: is it still true that "many TLS implementations reuse Diffie-Hellman and Elliptic Curve Diffie-Hellman exponents across multiple connections"? If not, then maybe s/many/some/ or cast the sentence into the past tense? - refs: is rfc6125 still the right reference given the -bis work? - refs: The 2015 date for the bettercrypto.org seems wrong. I guess that site has been updated since? It says 2018 on their front page anyway, but I'm not sure what'd be the right reference. Cheers, S. [1] https://datatracker.ietf.org/meeting/113/materials/slides-113-cfrg-signatures-deterministic-vs-randomized-00 ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt
Hiya, I had a read of this. Seems to me to be in fine shape but a couple of comments below. If those have already been discussed, apologies, and do ignore 'em. I don't think any of my comments need addressing before publication, but figured it was no harm sending 'em anyway:-) - section 3.2: I wondered why no mention of MTA-STS or DANE? Could/should we say that MTA implementations SHOULD include support for such strictness? - 4.2: there's been some cfrg [1] discussion (but not much and without so far reaching a conclusion) on deterministic signatures (RFC6979) and fault injection attacks. I wonder if we want to say anything about that? It might be worth just adding a reference that describes the problem, but I don't think we can expect the cfrg discussion to have resolved before this gets published. Those attacks are probably not that important for a typical TLS server but more interesting for small devices with TLS servers so maybe it's a bit too niche a concern to include? - 7.4: is it still true that "many TLS implementations reuse Diffie-Hellman and Elliptic Curve Diffie-Hellman exponents across multiple connections"? If not, then maybe s/many/some/ or cast the sentence into the past tense? - refs: is rfc6125 still the right reference given the -bis work? - refs: The 2015 date for the bettercrypto.org seems wrong. I guess that site has been updated since? It says 2018 on their front page anyway, but I'm not sure what'd be the right reference. Cheers, S. [1] https://datatracker.ietf.org/meeting/113/materials/slides-113-cfrg-signatures-deterministic-vs-randomized-00 OpenPGP_0x5AB2FAF17B172BEA.asc Description: OpenPGP public key OpenPGP_signature Description: OpenPGP digital signature ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt
Thanks! Opened https://github.com/yaronf/I-D/issues/350 Yaron On 5/27/22, 09:21, "Martin Thomson" wrote: I made some comments in discussion of 6125bis that I think this document should address. Basically, the document would benefit from a discussion on multi-server deployments in a few arrangements: * deployments where multiple servers speak for the same names, but with different protocols. ALPACA showed us that cross-protocol confusion, particularly for protocols that do not define the use of ALPN, can be exploited by directing protocols toward endpoints that use different protocols * deployments where multiple servers and services with overlapping names that have different TLS configurations. DROWN showed us that the security of these servers depends on the *weakest* server configuration. If the weak instance can be attacked, that affects all services that share the same name. This depends a little on the nature of the attack. An attack like this can render ALPN protections useless. See also https://github.com/richsalz/draft-ietf-uta-rfc6125bis/issues/43 On Fri, May 27, 2022, at 07:26, Yaron Sheffer wrote: > This version addresses numerous comments, mostly (but not always) > editorial, by Francesca and Paul W. > > As a reminder, the document is in IETF LC until May 30. > > Thanks, > Yaron > > > On 5/27/22, 00:22, "uta-boun...@ietf.org on behalf of > internet-dra...@ietf.org" internet-dra...@ietf.org> wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Using TLS in Applications WG of > the IETF. > > Title : Recommendations for Secure Use of > Transport Layer Security (TLS) and Datagram Transport Layer Security > (DTLS) > Authors : Yaron Sheffer > Peter Saint-Andre > Thomas Fossati > Filename: draft-ietf-uta-rfc7525bis-07.txt > Pages : 39 > Date: 2022-05-26 > > Abstract: >Transport Layer Security (TLS) and Datagram Transport Layer Security >(DTLS) are widely used to protect data exchanged over application >protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the >years, the industry has witnessed several serious attacks on TLS and >DTLS, including attacks on the most commonly used cipher suites and >their modes of operation. This document provides the latest >recommendations for ensuring the security of deployed services that >use TLS and DTLS. These recommendations are applicable to the >majority of use cases. > >An earlier version of this document was published as RFC 7525 when >the industry was in the midst of its transition to TLS 1.2. Years >later this transition is largely complete and TLS 1.3 is widely >available. This document updates the guidance given the new >environment and obsoletes RFC 7525. In addition, the document >updates RFC 5288 and RFC 6066 in view of recent attacks. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-uta-rfc7525bis/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-uta-rfc7525bis-07.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-rfc7525bis-07 > > > Internet-Drafts are also available by rsync at > rsync.ietf.org::internet-drafts > > > ___ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > > > ___ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt
I made some comments in discussion of 6125bis that I think this document should address. Basically, the document would benefit from a discussion on multi-server deployments in a few arrangements: * deployments where multiple servers speak for the same names, but with different protocols. ALPACA showed us that cross-protocol confusion, particularly for protocols that do not define the use of ALPN, can be exploited by directing protocols toward endpoints that use different protocols * deployments where multiple servers and services with overlapping names that have different TLS configurations. DROWN showed us that the security of these servers depends on the *weakest* server configuration. If the weak instance can be attacked, that affects all services that share the same name. This depends a little on the nature of the attack. An attack like this can render ALPN protections useless. See also https://github.com/richsalz/draft-ietf-uta-rfc6125bis/issues/43 On Fri, May 27, 2022, at 07:26, Yaron Sheffer wrote: > This version addresses numerous comments, mostly (but not always) > editorial, by Francesca and Paul W. > > As a reminder, the document is in IETF LC until May 30. > > Thanks, > Yaron > > > On 5/27/22, 00:22, "uta-boun...@ietf.org on behalf of > internet-dra...@ietf.org" internet-dra...@ietf.org> wrote: > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Using TLS in Applications WG of > the IETF. > > Title : Recommendations for Secure Use of > Transport Layer Security (TLS) and Datagram Transport Layer Security > (DTLS) > Authors : Yaron Sheffer > Peter Saint-Andre > Thomas Fossati > Filename: draft-ietf-uta-rfc7525bis-07.txt > Pages : 39 > Date: 2022-05-26 > > Abstract: >Transport Layer Security (TLS) and Datagram Transport Layer Security >(DTLS) are widely used to protect data exchanged over application >protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the >years, the industry has witnessed several serious attacks on TLS and >DTLS, including attacks on the most commonly used cipher suites and >their modes of operation. This document provides the latest >recommendations for ensuring the security of deployed services that >use TLS and DTLS. These recommendations are applicable to the >majority of use cases. > >An earlier version of this document was published as RFC 7525 when >the industry was in the midst of its transition to TLS 1.2. Years >later this transition is largely complete and TLS 1.3 is widely >available. This document updates the guidance given the new >environment and obsoletes RFC 7525. In addition, the document >updates RFC 5288 and RFC 6066 in view of recent attacks. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-uta-rfc7525bis/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-uta-rfc7525bis-07.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-rfc7525bis-07 > > > Internet-Drafts are also available by rsync at > rsync.ietf.org::internet-drafts > > > ___ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > > > ___ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt
This version addresses numerous comments, mostly (but not always) editorial, by Francesca and Paul W. As a reminder, the document is in IETF LC until May 30. Thanks, Yaron On 5/27/22, 00:22, "uta-boun...@ietf.org on behalf of internet-dra...@ietf.org" wrote: A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Using TLS in Applications WG of the IETF. Title : Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Authors : Yaron Sheffer Peter Saint-Andre Thomas Fossati Filename: draft-ietf-uta-rfc7525bis-07.txt Pages : 39 Date: 2022-05-26 Abstract: Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases. An earlier version of this document was published as RFC 7525 when the industry was in the midst of its transition to TLS 1.2. Years later this transition is largely complete and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, the document updates RFC 5288 and RFC 6066 in view of recent attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-uta-rfc7525bis/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-uta-rfc7525bis-07.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-rfc7525bis-07 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
[Uta] I-D Action: draft-ietf-uta-rfc7525bis-07.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Using TLS in Applications WG of the IETF. Title : Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Authors : Yaron Sheffer Peter Saint-Andre Thomas Fossati Filename: draft-ietf-uta-rfc7525bis-07.txt Pages : 39 Date: 2022-05-26 Abstract: Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the years, the industry has witnessed several serious attacks on TLS and DTLS, including attacks on the most commonly used cipher suites and their modes of operation. This document provides the latest recommendations for ensuring the security of deployed services that use TLS and DTLS. These recommendations are applicable to the majority of use cases. An earlier version of this document was published as RFC 7525 when the industry was in the midst of its transition to TLS 1.2. Years later this transition is largely complete and TLS 1.3 is widely available. This document updates the guidance given the new environment and obsoletes RFC 7525. In addition, the document updates RFC 5288 and RFC 6066 in view of recent attacks. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-uta-rfc7525bis/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-uta-rfc7525bis-07.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-uta-rfc7525bis-07 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
