I'm not precisely sure what you are really saying. Are you claiming that, even though currently known PQ key exchange don't give all the flexibility that (EC)DH has, you're pretty sure that'll change in the future? Or, are you saying that relying on the full flexibility of (EC)DH isn't a problem, as the WG will be willing to make changes to the TLS 1.3 0-RTT infrastructure in the future?
The issue really is the 0-RTT infrastructure, and its static key share. Unlike (EC)DH, known postquantum key agreement protocols either don't securely support static key shares (largely because it is impossible to distinguish a valid client keyshare from an invalid one, and how the server reacts to an invalid client keyshare depends on the server's private keyshare value), or they are really public key encryption systems being used to do key agreement, and the client's key share in the 0-RTT exchange can't be used to negotiate a long term set of keys. Outside of 0-RTT, there doesn't appear to be an issue. In those cases, the client gives an ephemeral key share, the server responds with an ephemeral key share, they both derive a shared secret, and everyone (other than the NSA, who can't listen in :-) is happy. However, 0-RTT is an important part of the protocol; we can't forbid it in a postquantum setting. Of course, we can in the future, we can revise the TLS 1.3 protocol to adapt to the functionality that postquantum algorithms will give us. However (based on the protocols we know about) the changes required by the protocol would be nontrivial. My hope is to make it so that algorithm agility is enough; that all the protocol needs to know is that there's this additional ciphersuite that, from a blackbox standpoint, does precisely the same job as the other ciphersuites, and that nothing outside of the crypto code needs to change. However, given that the postquantum algorithms we know about can't do everything that (EC)DH can do, it would appear to be prudent not to assume (in either our protocol or in our proofs) this additional functionality. From: Rene Struik [mailto:[email protected]] Sent: Monday, March 07, 2016 2:49 PM To: Scott Fluhrer (sfluhrer); Tony Arcieri Cc: [email protected] Subject: (TLS1.3 - algorithm agility support is enough; no need to crystal ball gaze PQ right now, except as pass-time) Re: [TLS] RSA-PSS in TLS 1.3 Hi Scott: I think it is really premature to speculate on features PQ-secure algorithms can or cannot provide (*) and try and have this influence *current* TLS1.3 protocol design. Should one wish to include PQ algorithms in a future update of TLS1.3, one can simply specify which protocol ingredients those updates relate to. As long as the current TLS1.3 specification has some facility for implementing algorithm agility, one can shy away from crystal ball gazing for now. Best regards, Rene (*) I am not sure everyone would concur with your speculation, but crypto conferences may be a better venue to discuss this than a TLS mailing list. On 3/7/2016 12:21 PM, Scott Fluhrer (sfluhrer) wrote: From: Tony Arcieri [mailto:[email protected]] Sent: Monday, March 07, 2016 11:40 AM To: Scott Fluhrer (sfluhrer) Cc: Nikos Mavrogiannopoulos; Hanno Böck; Blumenthal, Uri - 0553 - MITLL; [email protected]<mailto:[email protected]> Subject: Re: [TLS] RSA-PSS in TLS 1.3 On Mon, Mar 7, 2016 at 8:34 AM, Scott Fluhrer (sfluhrer) <[email protected]<mailto:[email protected]>> wrote: Defenses against the first type of attack (passive evesdropping by someone who will build a QC sometime in the future) are something that this WG should address; even if the PKI people don't have an answer, we would at least be secure from someone recording the traffic and decrypting it later I think it would make sense to wait for the CFRG to weigh in on post-quantum crypto. Moving to a poorly studied post-quantum key exchange algorithm exclusively runs the risk that when it does receive wider scrutiny new attacks will be found. I think we need to define hybrid pre/post-quantum key exchange algorithms (e.g. ECC+Ring-LWE+HKDF), and that sounds like work better suited for the CFRG than the TLS WG. I'm sorry that I wasn't clearer; I agree that *now* isn't the time to define a postquantum ciphersuite/named group; we're not ready yet (and this WG probably isn't the right group to define it). However, I believe that we will need to do at some point; my guess is that it'll be sooner rather than later. What (IMHO) this WG should be doing now is making sure that there isn't something in TLS 1.3 that'll make it harder to transition to postquantum crypto when we do have a concrete proposal. One thing that proposed QR key exchanges have is that they don't have the full flexibility that (EC)DH have; either they aren't secure with static key shares, or we can't use the same key share as both an 'initiator' and a 'responder' key share. This would indicate to me that we need to make sure that TLS 1.3 should be engineered to use (EC)DH as only a simple, ephemeral-only key exchange - yes, it has more flexibility than that, however taking advantage of such flexibility might cause us problems in the future _______________________________________________ TLS mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/tls -- email: [email protected]<mailto:[email protected]> | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
