[TLS] Re: The problem(s) with ECH public names
> If I understand Martin+Jonathan's idea correctly, it is mainly about > indistinguishability of ECH handshakes across TLS servers. I found this idea hard to understand because, in the ECH privacy threat model, distinct servers are always distinguishable by destination IP address. To start, I would like to see a realistic alternative threat model that motivates the proposed variation on ECH. I suspect the motivating threat model for some of these proposals is based on timescale assumptions: 1. The server can only acquire new public_name domains (with corresponding certificates) infrequently, due to the cost of domain registration (~weeks) 2. The attacker can only update its table of service identifiers (IPs and domain names associated with particular services) periodically due to operational overheads (~days) 3. The server can unlinkably rotate its IP address frequently using public cloud infrastructure (~hours). Assumptions like these could motivate designs that reduce the information revealed in the public_name. However, there are also good reasons to challenge some of these assumptions. I would also like to see closer analysis of the fallback flow in these proposals. In my view, the fallback flow has little value if it depends on the server to retain a private key. Instead, the server should retain the ECH private keys long enough to remove the need for fallback*. Then the public_name can be set to a reserved value like "ech.arpa" (or perhaps omitted entirely). --Ben Schwartz * We can discuss if this raises concerns about forward secrecy, given the actual distribution of lagging ECHConfig lifetimes. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt
I've read the draft and support doing this. However, I wanted to +1 Martin's suggestion of restricting this to 2-move PAKEs (1 round trip) if possible, and if so, defining a new key_share rather than a new extension that disables key_share. It seems like this would be a much simpler design. Chris P. On Sat, Mar 15, 2025 at 7:22 PM Laura Bauman wrote: > Thanks to everyone that has taken a look at draft-bmw-tls-pake13-01.txt > and provided feedback so far. As more people start reading it, I wanted to > clarify that the current draft version does not yet reflect the change we > intend to make to allow Certificates and the pake extension to be used > together. We’ve filed a GitHub issue here tracking our intent to change > this: https://github.com/chris-wood/draft-bmw-tls-pake13/issues/25. > > Thanks, > > Laura Bauman > l_bau...@apple.com > ___ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: checking a bit of ECH behaviour
On Tue, Mar 25, 2025, at 07:31, David Benjamin wrote: > That's a 2^-64 > probability, which was discussed here: > https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.html#section-10.9-2 Yeah, I was thinking holistically, but the argument made there is that the per-connection probability is far lower than the natural connection failure rate. Never mind. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: checking a bit of ECH behaviour
On Sun, Mar 23, 2025 at 8:59 PM Martin Thomson wrote: > On Sun, Mar 23, 2025, at 10:20, David Benjamin wrote: > > This case is a protocol error and should abort the handshake, > > Is it though? It would appear that the probability of this occurring is > about 50% after about 4 billion ECH grease handshakes that operate in > "don't stick out" mode: > https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.html#name-do-not-stick-out > > It's probably OK to abort in that case. The odds are low enough that a > failed connection is likely preferable to the alternative, but it's > definitely a non-negligible risk. > Hmm, where are you getting those numbers from? Working backwards, I assume you are thinking of the birthday paradox on some 64-bit value? The only 64-bit value I can think of is the ServerHello confirmation signal. Is that the concern? That's not the scenario being discussed here. As I understand it, the scenario being discussed here is: 1. Client gets a HelloRetryRequest with ECH acceptance signal 2. Client gets a ServerHello without ECH acceptance signal There is nothing probabilistic going on here. An ECH acceptance signal in HelloRetryRequest has no "don't stick out" mode. It's just an extension in HelloRetryRequest. Moreover, the ECH confirmation signal is not subject to the birthday paradox. We don't care about two random values colliding, but with the server's random value conflicting with the specific 8 bytes that the client is expecting. That's a 2^-64 probability, which was discussed here: https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.html#section-10.9-2 David ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt
On Mon, Mar 24, 2025 at 5:17 PM Martin Thomson wrote: > On Tue, Mar 25, 2025, at 02:37, Eric Rescorla wrote: > > 1. Getting PQ resistance for free even with non-PQ PAKEs. > > 2. Reducing the combinatoric explosion of "groups" > > I don't know that you are really getting PQ resistance if your PAKE > remains vulnerable. You might maintain confidentiality for that single > connection, but if there is a possibility of impersonation (are you relying > on the PAKE for authentication of the server?) then you lose. > This is what we are doing right now by rolling out PQ for key establishment but not for authentication: we provide security against harvest now decrypt later attacks, but not against impersonation if there is a CRQC. Avoiding the combinatoric problem seems like a pretty high complexity tax. > Sure, we are already in the position where we have N (number of ECC groups) > x M (number of PQ groups) groups. Adding a PAKE makes that N x M x P > (number of PAKEs). However, these are all small numbers. Building a > parallel extension is relatively straightforward if you model it like key > exchange and use the obvious combiner. But then, why did we not do that > with PQ as well? > I agree it's a judgement call, but IMO PQ key establishment via KEMs is more like DH key establishment than PAKEs are. For instance, neither needs to connect with some password database. For this reason and others,it's not clear to me that in fact it will be simpler to have combined PAKE + ECC + PQ groups than to have the PAKE be separate. -Ekr ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Gorry Fairhurst's No Objection on draft-ietf-tls-tls12-frozen-06: (with COMMENT)
Gorry Fairhurst has entered the following ballot position for draft-ietf-tls-tls12-frozen-06: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/ -- COMMENT: -- Thank you for writing a simple and easily read document ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt
I agree we shouldn't *disable* key_share, but it seems like the right answer here is to instead combine the PAKE output with the existing key establishment. -Ekr On Mon, Mar 24, 2025 at 7:56 AM Christopher Patton wrote: > I've read the draft and support doing this. However, I wanted to +1 > Martin's suggestion of restricting this to 2-move PAKEs (1 round trip) if > possible, and if so, defining a new key_share rather than a new extension > that disables key_share. It seems like this would be a much simpler design. > > Chris P. > > On Sat, Mar 15, 2025 at 7:22 PM Laura Bauman 40apple@dmarc.ietf.org> wrote: > >> Thanks to everyone that has taken a look at draft-bmw-tls-pake13-01.txt >> and provided feedback so far. As more people start reading it, I wanted to >> clarify that the current draft version does not yet reflect the change we >> intend to make to allow Certificates and the pake extension to be used >> together. We’ve filed a GitHub issue here tracking our intent to change >> this: https://github.com/chris-wood/draft-bmw-tls-pake13/issues/25. >> >> Thanks, >> >> Laura Bauman >> l_bau...@apple.com >> ___ >> TLS mailing list -- tls@ietf.org >> To unsubscribe send an email to tls-le...@ietf.org >> > ___ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt
On Mon, Mar 24, 2025 at 8:34 AM Christopher Patton wrote: > Hi EKR, > > >> I agree we shouldn't *disable* key_share, but it seems like the right >> answer here is to instead combine the PAKE output with the existing key >> establishment. >> > > I probably just missed this in the discussion, but what would be the > advantage of combining PAKE with the existing key exchange? > 1. Getting PQ resistance for free even with non-PQ PAKEs. 2. Reducing the combinatoric explosion of "groups" -Ekr > I'm not necessarily opposed. My main motivation is to reduce some > complexity in the draft. > > Chris P. > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Feedback on draft-bmw-tls-pake13-01.txt
Hi EKR, > I agree we shouldn't *disable* key_share, but it seems like the right > answer here is to instead combine the PAKE output with the existing key > establishment. > I probably just missed this in the discussion, but what would be the advantage of combining PAKE with the existing key exchange? I'm not necessarily opposed. My main motivation is to reduce some complexity in the draft. Chris P. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Mohamed Boucadair's Discuss on draft-ietf-tls-tls12-frozen-06: (with DISCUSS and COMMENT)
On Mon, Mar 24, 2025 at 12:37 AM Mohamed Boucadair via Datatracker < nore...@ietf.org> wrote: > Mohamed Boucadair has entered the following ballot position for > draft-ietf-tls-tls12-frozen-06: Discuss > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ > for more information about how to handle DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/ > > > > -- > DISCUSS: > -- > > Hi Rich, > > Thank you for the effort put in this effort. > > Thanks to Jen Linkova for the opsdir review. I understood that her comment > will > be fixed. > > I’m supportive of this work. I will be balloting “Yes” after the DISCUSS > point > is addressed. > > ## On urgent security conditions > > CURRENT: >This >document specifies that outside of urgent security fixes, and the >exceptions listed in Section 4, no changes will be approved for TLS >1.2. > > Who will make the call about what is “urgent”? Is it the TLS WG? As a threshold matter, I would think yes. I.e., the TLS WG is responsible for any such security fixes, so just like any change to core TLS, I would expect that the TLS WG should determine acceptability, subject to IETF consensus on eventual publication if the TLS WG did decide to take it on. Else? What > about extensions that may be required by applications defined in other WGs? > I read this document as prohibiting other WGs from defining such extensions outside of the parameters specified here. -Ekr > > -- > COMMENT: > -- > > FWIW, my full review can be found at: > > * pdf: > > https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-tls-tls12-frozen-06-rev%20Med.pdf > * doc: > > https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-tls-tls12-frozen-06-rev%20Med.doc > > Only a subset of items are echoed here. The author can refer to the full > review > for nits/edits/etc. > > # Abstract > > ## Reword for better clarity > > OLD: >Use of TLS 1.3 is growing and fixes some known deficiencies in TLS >1.2. > > NEW: >Use of TLS 1.3, which fixes some known deficiencies in TLS >1.2, is growing. > > ## I think “for TLS 1.2-only” would be more accurate as some of these are > applicable to TLS1.3 as well. Consider updating accordingly: > > CURRENT: >This document specifies that except urgent security fixes, >new TLS Exporter Labels, or new Application-Layer Protocol >Negotiation (ALPN) Protocol IDs, no changes will be approved for TLS >1.2. > > # Introduction > > ## Reword for better clarity > > OLD: >Both versions have several extension points, so items like new >cryptographic algorithms, new supported groups (formerly "named >curves"), etc., can be added without defining a new protocol. > > NEW: >Both TLS versions have several extension points. Items such as new >cryptographic algorithms, new supported groups (formerly "named >curves"), etc., can be added without defining a new protocol. > > As a side note on “etc.”, I’d like to check if we should be more explicit > here > given that we have notes in the registry such as: “Although TLS 1.3 uses > the > same cipher suite space as previous versions of TLS, TLS 1.3 cipher suites > are > defined differently, only specifying the symmetric ciphers and hash > function, > and cannot be used for TLS 1.2. Similarly, TLS 1.2 and lower cipher suite > values cannot be used with TLS 1.3.” > > # Section 2 > > ## Provider examples of “huge impact” mentioned in this text: > > CURRENT: >Cryptographically relevant quantum computers, once available, will >have a huge impact on RSA, FFDH, and ECC which are currently used in >TLS. > > ## On the various NIST citations: Are there any other similar pointers to > list > for non-US regions? > > # Section 4: > > ## I think the IANA registries should be authoritative here, not the RFC. > > CURRENT: >No registries [TLS13REG] are being closed by this document. > > ## Call out this is about TLS registries: > > OLD: >No registries [TLS13REG] are being closed by this document. > > NEW: > No registries in TLS registry groups [REF] are being closed by this > document. > > ## Not any random registry, but TLS: > > OLD: >Any registries created after this document is approved for >publication should indicate whether the actions defined here are >applicable. > > NEW: >Any TLS registry created after
[TLS] The problem(s) with ECH public names
Hi all, unfortunately I wasn't able to attend the meeting this week, but I had a chance to catch up on youtube ( https://www.youtube.com/watch?v=bQ-Bz60AppI). I wanted to add one more point to the ECH discussion that might be helpful for moving this topic forward. There were three presentations about the ECH public name, from Nick, Martin, and Jonathan. I think some folks were talking about these presentations as if they're solving the same problem, but to my thinking, Nick's draft would solve a slightly different problem than Martin+Jonathan. Nick's draft is about reachability. Whether a TLS server is reachable via ECH depends on whether the handshakes with ECH clients are treated differently by the network than other handshakes. We say that ECH "doesn't stick out" if it's indistinguishable from some "cover protocol" the network is known to tolerate, which would imply reachability. This is the idea behind GREASE ECH as well as middlebox compatibility mode for TLS 1.3. Both ECH and TLS 1.3 are distinguishable from their cover protocols, but less so than their predecessors (ESNI and early drafts of TLS 1.3 respectively). If I understand Martin+Jonathan's idea correctly, it is mainly about indistinguishability of ECH handshakes across TLS servers. This would be a great property to have, and not just for privacy: If deployed at a large enough scale, I think either mechanism would provide some degree of "fate sharing" in the sense it would be hard to block ECH traffic to one server without blocking ECH traffic to all servers. However I don't think this would imply reachability for the internet as it is today, at least not without some sort of cover protocol. On the other hand, GREASE ECH is already widely deployed. Both properties are nice to have, but we may have to prioritize one over the other. One approach is to make handshakes look like existing handshakes; this is more or less what TLSWG has done so far. Another approach is to make all handshakes look like each other; this is the idea behind pseudorandom cTLS [1]. I'd wager we all would like to build the latter world, but the real world probably looks more like the former. Best, Chris P. [1] https://www.ietf.org/archive/id/draft-cpbs-pseudorandom-ctls-01.html ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] [IANA #1413503] expert review for draft-ietf-tls-esni (tls-extensiontype-values)
Dear Yoav Nir (cc: tls WG, tls-reg-review mailing list), Following up on this; as a designated expert for the TLS ExtensionType Values registry, can you review the proposed registration in draft-ietf-tls-esni-23 for us? Please note that Nick Sullivan is a co-author for this draft and that Rich had already approved. Please see: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ The due date was March 18. If this is OK, when the IESG approves the document for publication, we'll make the registration at: https://www.iana.org/assignments/tls-extensiontype-values/ We'll act after both experts approve the registration. With thanks, David Dong IANA Services Sr. Specialist On Sat Mar 15 01:27:51 2025, david.dong wrote: > Dear Yoav Nir (cc: tls WG, tls-reg-review mailing list), > > Following up on this; as a designated expert for the TLS ExtensionType > Values registry, can you review the proposed registration in draft- > ietf-tls-esni-23 for us? Please note that Nick Sullivan is a co-author > for this draft and that Rich had already approved. > > Please see: > > https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ > > The due date is March 18. > > If this is OK, when the IESG approves the document for publication, > we'll make the registration at: > > https://www.iana.org/assignments/tls-extensiontype-values/ > > We'll act after both experts approve the registration. > > With thanks, > > David Dong > IANA Services Sr. Specialist > > > On Thu Mar 06 21:31:55 2025, david.dong wrote: > > Dear Yoav Nir (cc: tls WG, tls-reg-review mailing list), > > > > As a designated expert for the TLS ExtensionType Values registry, can > > you review the proposed registration in draft-ietf-tls-esni-23 for > > us? > > Please note that Nick Sullivan is a co-author for this draft and that > > Rich had already approved. > > > > Please see: > > > > https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ > > > > The due date is March 18. > > > > If this is OK, when the IESG approves the document for publication, > > we'll make the registration at: > > > > https://www.iana.org/assignments/tls-extensiontype-values/ > > > > We'll act after both experts approve the registration. > > > > With thanks, > > > > David Dong > > IANA Services Sr. Specialist > > > > On Wed Feb 26 18:26:30 2025, david.dong wrote: > > > Hi Nick, > > > > > > Yes, that's correct; this review request is for the two new > > > registrations in section 11.1 in the TLS ExtensionType Values > > > registry, which has the registration procedure of Specification > > > Required. > > > > > > Thank you. > > > > > > Best regards, > > > > > > David Dong > > > IANA Services Sr. Specialist > > > > > > On Wed Feb 26 08:10:28 2025, nicholas.sulli...@gmail.com wrote: > > > > I’m conflicted out as mentioned, but I want to clarify: this > > > > request > > > > is for > > > > the code points in the existing extension (section 11.1), not the > > > > request > > > > for the alert code point (11.2) or the new extension registry > > > > (11.3), > > > > correct? > > > > > > > > On Wed, Feb 26, 2025 at 3:15 AM Salz, Rich > > > > wrote: > > > > > > > > > I approve. > > > > > > > > > > The draft does not say if the existing TLS DE's will do the new > > > > > table, but > > > > > I am okay with taking on that additional workload :) > > > > > > > > > > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Mohamed Boucadair's Discuss on draft-ietf-tls-tls12-frozen-06: (with DISCUSS and COMMENT)
Mohamed Boucadair has entered the following ballot position for draft-ietf-tls-tls12-frozen-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/ -- DISCUSS: -- Hi Rich, Thank you for the effort put in this effort. Thanks to Jen Linkova for the opsdir review. I understood that her comment will be fixed. I’m supportive of this work. I will be balloting “Yes” after the DISCUSS point is addressed. ## On urgent security conditions CURRENT: This document specifies that outside of urgent security fixes, and the exceptions listed in Section 4, no changes will be approved for TLS 1.2. Who will make the call about what is “urgent”? Is it the TLS WG? Else? What about extensions that may be required by applications defined in other WGs? -- COMMENT: -- FWIW, my full review can be found at: * pdf: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-tls-tls12-frozen-06-rev%20Med.pdf * doc: https://github.com/boucadair/IETF-Drafts-Reviews/blob/master/2025/draft-ietf-tls-tls12-frozen-06-rev%20Med.doc Only a subset of items are echoed here. The author can refer to the full review for nits/edits/etc. # Abstract ## Reword for better clarity OLD: Use of TLS 1.3 is growing and fixes some known deficiencies in TLS 1.2. NEW: Use of TLS 1.3, which fixes some known deficiencies in TLS 1.2, is growing. ## I think “for TLS 1.2-only” would be more accurate as some of these are applicable to TLS1.3 as well. Consider updating accordingly: CURRENT: This document specifies that except urgent security fixes, new TLS Exporter Labels, or new Application-Layer Protocol Negotiation (ALPN) Protocol IDs, no changes will be approved for TLS 1.2. # Introduction ## Reword for better clarity OLD: Both versions have several extension points, so items like new cryptographic algorithms, new supported groups (formerly "named curves"), etc., can be added without defining a new protocol. NEW: Both TLS versions have several extension points. Items such as new cryptographic algorithms, new supported groups (formerly "named curves"), etc., can be added without defining a new protocol. As a side note on “etc.”, I’d like to check if we should be more explicit here given that we have notes in the registry such as: “Although TLS 1.3 uses the same cipher suite space as previous versions of TLS, TLS 1.3 cipher suites are defined differently, only specifying the symmetric ciphers and hash function, and cannot be used for TLS 1.2. Similarly, TLS 1.2 and lower cipher suite values cannot be used with TLS 1.3.” # Section 2 ## Provider examples of “huge impact” mentioned in this text: CURRENT: Cryptographically relevant quantum computers, once available, will have a huge impact on RSA, FFDH, and ECC which are currently used in TLS. ## On the various NIST citations: Are there any other similar pointers to list for non-US regions? # Section 4: ## I think the IANA registries should be authoritative here, not the RFC. CURRENT: No registries [TLS13REG] are being closed by this document. ## Call out this is about TLS registries: OLD: No registries [TLS13REG] are being closed by this document. NEW: No registries in TLS registry groups [REF] are being closed by this document. ## Not any random registry, but TLS: OLD: Any registries created after this document is approved for publication should indicate whether the actions defined here are applicable. NEW: Any TLS registry created after this document is approved for publication should indicate whether the actions defined here are applicable. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
