Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track
Stephen Farrell wrote: > That'd be a fairly giant outer client hello Well, is there a latency histogram? The reality I've seen ignored in these discussions is that these large handshake messages are in fact very slow or broken on older implementations, but that it might not matter. The very slow tail in the trailing 5-10% area will never be updated anyway, so it makes no sense to consider them in PQ discussions. For example, we also have folks claiming we must accommodate very old TLS 1.2 implementations. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track
sgtm On Wed, Dec 13, 2023 at 4:36 PM Russ Housley wrote: > Bas: > > Thanks. I've adjusted the proposed text to address your comments: > >Implementations must use a ciphersuite that includes a symmetric >encryption algorithm with sufficiently large keys. For protection >against the future invention of a CRQC, the symmetric key needs to be >at least 128 bits. While Grover’s algorithm (described in >Section 7.1 of [I-D.ietf-pquip-pqc-engineers]) allows a quantum >computer to perform a brute force key search using quadratically >fewer steps than would be required with classical computers, there >are a number of mitigating factors suggesting that Grover’s algorithm >will not speed up brute force symmetric key search as dramatically as >one might suspect. First, quantum computing hardware will likely be >more expensive to build and use than classical hardware. Second, to >obtain the full quadratic speedup, all the steps of Grover’s >algorithm must be performed in series. However, attacks on >cryptography use massively parallel processing, the advantage of >Grover’s algorithm will be smaller. > >Implementations must use sufficiently large external PSKs. For >protection against the future invention of a CRQC, the external PSK >needs to be at least 128 bits. > > Russ > > > On Dec 13, 2023, at 8:18 AM, Bas Westerbaan wrote: > > I think there is a companion point to be made. I suggest: >> >>Implementations must use a ciphersuite that includes a symmetric >>encryption algorithm with sufficiently large keys. For protection >>against the future invention of a CRQC, the symmetric key needs to be >>at least 256 bits. >> > > Not true.128 bit symmetric keys are fine for PQ. > > Right, I think that means that ECH as-is can be used, but in the face >> of a CRQC, ECH as-is won't protect against the leakage about which >> John was concerned. > > > Not true. ECH, as-is, can be configured to use a PQ KEM. (Whether it's > deployable, and whether its performance is acceptable, is something we > should figure out.) > > Best, > > Bas > > > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track
> By contrast the PQ version "just" has key size issues to worry about > with the DNS advertising bits and maybe some structures that get > tight. > I have the same intuition. Instead of guessing, we should plop Kyber in ECH and see if it works. If not then there are still other paths besides PSK — for instance using BAT [1]. Best, Bas [1] https://eprint.iacr.org/2022/031 ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track
On Wed, Dec 13, 2023 at 10:29 AM Christian Huitema wrote: > > Doing a PQ version of ECH would be hard. On the other hand, doing an > 8773-like enhancement to ECH should not be all that hard. It would > require that the outer CH contains a PSK shared between the client and > the fronting server, and then combining that PSK and a classic public > key to derive the key encrypting the inner CH. Managing shared symmetric keys between clients and servers at scale is very much a "sufficient thrust" situation. An actually deployable version of this, without huge latency would be very tricky: would have to use tickets, have a way to hand them out, etc. ECH is of limited utility without this kind of scale. By contrast the PQ version "just" has key size issues to worry about with the DNS advertising bits and maybe some structures that get tight. Sincerely, Watson -- Astra mortemque praestare gradatim ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track
On 12/12/2023 2:50 PM, Stephen Farrell wrote: Hiya, On 12/12/2023 17:08, Russ Housley wrote: Stephen: I've been thinking about your point. Some people want to use RFC 8773 to protect data that is transmitted today and recorded from the future invention of a quantum computer. To do this, the handshake includes the identifier for the external PSK, and an observer can get tracking data by watching which clients and servers have the same external PSK. This tracking data does not need the same long-term protection as the TLS protected content. So, the high-level guidance in the proposed text seems appropriate. That is, rotation of the external PSK identity or the use of the Encrypted Client Hello extension. I think you are correct, the "with algorithms that a secure against a CRQC" should be dropped. Right, I think that means that ECH as-is can be used, but in the face of a CRQC, ECH as-is won't protect against the leakage about which John was concerned. If one is worried about a future CRQC, then using ECH as-is should be fine and protects for now against that leakage. (One might even add a bit of text recommending that this extension only be present in the inner CH whenever ECH is in use?) Using some future PQ version of ECH can't be done yet, and figuring out how a PQ-version of ECH would work and not involve too-large a CH is another day's work. Doing a PQ version of ECH would be hard. On the other hand, doing an 8773-like enhancement to ECH should not be all that hard. It would require that the outer CH contains a PSK shared between the client and the fronting server, and then combining that PSK and a classic public key to derive the key encrypting the inner CH. To get quantum reliance we would need two PSK -- one with the fronting server, one with the protected server. The outer PSK would be used to harden the ECH encryption key. The inner PSK would be used to harden the session key. Actually, if the fronting server can pass a secret to the protected server, this secret could be used instead of the "inner PSK" to harden the session key. Still another day's work, but seems doable -- and keeping with spirit of 8773, using only old tech like PSK and ECDH instead of relying on post-quantum algorithms. -- Christian Huitema ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track
Bas: Thanks. I've adjusted the proposed text to address your comments: Implementations must use a ciphersuite that includes a symmetric encryption algorithm with sufficiently large keys. For protection against the future invention of a CRQC, the symmetric key needs to be at least 128 bits. While Grover’s algorithm (described in Section 7.1 of [I-D.ietf-pquip-pqc-engineers]) allows a quantum computer to perform a brute force key search using quadratically fewer steps than would be required with classical computers, there are a number of mitigating factors suggesting that Grover’s algorithm will not speed up brute force symmetric key search as dramatically as one might suspect. First, quantum computing hardware will likely be more expensive to build and use than classical hardware. Second, to obtain the full quadratic speedup, all the steps of Grover’s algorithm must be performed in series. However, attacks on cryptography use massively parallel processing, the advantage of Grover’s algorithm will be smaller. Implementations must use sufficiently large external PSKs. For protection against the future invention of a CRQC, the external PSK needs to be at least 128 bits. Russ > On Dec 13, 2023, at 8:18 AM, Bas Westerbaan wrote: > >> I think there is a companion point to be made. I suggest: >> >>Implementations must use a ciphersuite that includes a symmetric >>encryption algorithm with sufficiently large keys. For protection >>against the future invention of a CRQC, the symmetric key needs to be >>at least 256 bits. > > Not true.128 bit symmetric keys are fine for PQ. > >> Right, I think that means that ECH as-is can be used, but in the face >> of a CRQC, ECH as-is won't protect against the leakage about which >> John was concerned. > > Not true. ECH, as-is, can be configured to use a PQ KEM. (Whether it's > deployable, and whether its performance is acceptable, is something we should > figure out.) > > Best, > > Bas ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'
Hi Ilari, thanks for the clarification! I attempted to correct the text. Would you be willing to review the change? It's here: https://github.com/richsalz/tls12-frozen/commit/a1ce7ede97897e291af44f0c2f4fc225a2ca4447 thanks, Nimrod On Tue, 12 Dec 2023 at 19:22, Ilari Liusvaara wrote: > On Fri, Dec 08, 2023 at 05:47:01PM +, Salz, Rich wrote: > > > > Good point. https://github.com/richsalz/tls12-frozen/pull/12 has the > > change. I’ll wait until/if this is adopted by the WG to merge it. > > Reading through the document, I noticed the following: > > "To securely deploy TLS 1.2, either renegotiation must be disabled > entirely, or this extension must be present." (where this extension > means renegotiation_info) > > > Entirely disabling renegotiation is not sufficient to fix the > renegotiation issue in TLS 1.2. For fixing the issue, renegotiation_info > MUST be required both ways. > > And then there is the other part to the triple handshake attack where > using TLS exporters for authentication without extended_master_secret > extension is insecure, even if renegotiation is not supported at all > by either side and both sides implement renegotiation_info. > > And then there is more dangerously flawed stuff, e.g., session tickets > (technically an extension). > > > > > -Ilari > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track
> > PS: I do not want us to hold up producing the ECH RFC while > we figure that out - we should get the current thing out the > door first! > Completely agree. Bas ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track
Hiya, On 13/12/2023 13:18, Bas Westerbaan wrote: Not true. ECH, as-is, can be configured to use a PQ KEM. (Whether it's deployable, and whether its performance is acceptable, is something we should figure out.) I guess we're just interpreting "as-is" differently. What I meant by "as-is" was an implementation of the current draft. I agree that we can figure out how to use a PQ KEM with ECH but that's work still to be done, and hence wasn't included in what I meant by "ECH as-is." Cheers, S. PS: I do not want us to hold up producing the ECH RFC while we figure that out - we should get the current thing out the door first! OpenPGP_0xE4D8E9F997A833DD.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track
> > I think there is a companion point to be made. I suggest: > >Implementations must use a ciphersuite that includes a symmetric >encryption algorithm with sufficiently large keys. For protection >against the future invention of a CRQC, the symmetric key needs to be >at least 256 bits. > Not true.128 bit symmetric keys are fine for PQ. Right, I think that means that ECH as-is can be used, but in the face > of a CRQC, ECH as-is won't protect against the leakage about which > John was concerned. Not true. ECH, as-is, can be configured to use a PQ KEM. (Whether it's deployable, and whether its performance is acceptable, is something we should figure out.) Best, Bas ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track
Stephen: > >> I've been thinking about your point. Some people want to use RFC >> 8773 to protect data that is transmitted today and recorded from the >> future invention of a quantum computer. To do this, the handshake >> includes the identifier for the external PSK, and an observer can get >> tracking data by watching which clients and servers have the same >> external PSK. This tracking data does not need the same long-term >> protection as the TLS protected content. So, the high-level guidance >> in the proposed text seems appropriate. That is, rotation of the >> external PSK identity or the use of the Encrypted Client Hello >> extension. I think you are correct, the "with algorithms that a >> secure against a CRQC" should be dropped. > > Right, I think that means that ECH as-is can be used, but in the face > of a CRQC, ECH as-is won't protect against the leakage about which > John was concerned. > > If one is worried about a future CRQC, then using ECH as-is should be > fine and protects for now against that leakage. (One might even add a > bit of text recommending that this extension only be present in the > inner CH whenever ECH is in use?) > > Using some future PQ version of ECH can't be done yet, and figuring > out how a PQ-version of ECH would work and not involve too-large a CH > is another day's work. I think that is correct, one a CRQC comes along, the attacker will be able to decrypt the identifiers for the external PSK and gain tracking information, but not the payload content. In the future, when the TLS WG tackles a quantum-resistant ECH, then this concern will be resolved. Russ signature.asc Description: Message signed with OpenPGP ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'
Whilst I don’t know Peter, my intervention in San Francisco on this topic was on the same line. Am working with the CISO teams of organizations that have to keep their infrastructure for 50 to 100 years long plans (nuclear power stations, hydraulic infrastructures, etc.). And among organizations I engage with, several DO have active plans to migrate out from TLS1.2 … but this is very hard! I learnt the hard way that migration projects are always the hardest possible projects vs say build something from scratch. Unfortunately there is one large part of the community which is not at the IETF ever or anymore to voice those concerns. Now, on the other hand, I do support the ‘active signals’ approach proposed by Rich and the adoption of this text exactly for the reasons expressed by Rich. My only ‘amendment’ is how we could stay connected with the community which is still on TLS1.2 and what is the magnitude of their issues, why, etc. This is why I asked the question whether there would be volunteers to design a ‘survey’ approach. This could bring data points from the broader community that could help guide this particular area of the work. If there would be some appetite, designing such a survey is not an easy task but should we agree, I would certainly be happy to gain the support from my organization to deploy this survey and get feedback from as many organizations as possible. My 0.02 CHF From: TLS on behalf of Salz, Rich Date: Tuesday, 12 December 2023 at 18:53 To: Rob Sayre , Peter Gutmann Cc: TLS@ietf.org Subject: Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze' Peter knows more about long-term embedded systems that use TLS than anyone else on this list. I trust him. Don’t think of things connected to the public Internet, but rather things like client-auth missle launching systems, seismic (nuclear) monitoring equipment, and the like. Stuff that you cannot pick up anywhere retail off-the-shelf, but is rather purpose-built. Having said that, I don’t want this draft to make his job harder; I’d rather my electric grid didn’t break :) But given that, and since he doesn’t have a specific concern in-hand right now, and that I think it is important and useful to send a clear signal to the global community, I’d still like to see the draft adopted and eventually published. It sends an active signal about new features, as opposed to a passive signal of just not accepting work. In my experience in security, active signals are better than passive ones. -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it. smime.p7s Description: S/MIME Cryptographic Signature ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
