> -----Original Message----- > From: TLS <tls-boun...@ietf.org> On Behalf Of Russ Housley > Sent: Friday, February 21, 2020 2:29 PM > To: Martin Thomson <m...@lowentropy.net> > Cc: IETF TLS <tls@ietf.org> > Subject: Re: [TLS] Requesting working group adoption of draft-stebila-tls- > hybrid-design > > > > > On Feb 12, 2020, at 6:22 PM, Martin Thomson <m...@lowentropy.net> > wrote: > > > > On Thu, Feb 13, 2020, at 10:01, Carrick Bartle wrote: > >> I'm brand new to the IETF, so please forgive me if I'm totally off > >> base here, but my understanding is that Informational RFCs are > >> explicitly not recommendations (let alone mandates)? > > > > This would of course be information, but my comment was about phrasing. > This document comes off as being quite prescriptive, where it doesn't really > need to be. Absent actual algorithms, it's just a set of guidelines. That's > reflected in its Informational status, but it would be better if the verbiage > also reflected that more clearly. > > > > To address Stephen's comment at the same time: I think that we can > publish an RFC on this before the competition completes if it is just a > framework. That might in fact make standardizing the one true composite > scheme easier. > > I do not agree. I do not think the WG should adopt this draft. > > The CFRG has stated a position that the IETF should wait for the NIST > standardization process to be complete.
I disagree with Russ's statement that what the CFRG has stated actually applies to this draft. This draft does not specify what postquantum algorithms should be used (which is what the CFRG is talking about). What it tries to address is "once we have an approved algorithm, how do we integrate it into TLS". Surely it would be better to get that preliminary work out of the way first, rather than waiting for the NIST process to conclude, and then start spending the time working on the integration process. > There are at least two approaches > to mixing symmetric keying material into the TLS 1.3 key schedule for > information that needs to be protected for the next few decades. (The two > that I know about are draft-ietf-tls-tls13-cert-with-extern-psk and draft- > vanrein-tls-kdh.) These approaches make existing key establishment > techniques secure even if a quantum computer gets developed as long as > the symmetric key is not disclosed. In my opinion, those techniques will hold > us until the NIST standardization process finishes. Symmetric keys solve the problem, but are usable only in scenarios where you have a pre-existing relationship between the client and the server. It doesn't work in a more general "web-surfing" type scenario. > > I do not understand the goal of mixing (EC)DH with one of candidate > algorithms. We do not know enough about the candidate algorithms in the > NIST process. If the goal is to add quantum resistance, we do not have > enough information to pick well. And, again, the draft does not attempt to pick one. > If the goal is to learn about mixing in > general, then I question the project altogether. Once the NIST > standardization process is complete, we can simply use the selected > algorithm without mixing. I can see someone disagreeing. Whatever postquantum algorithm NIST selects, it will be a relatively recent one (and hence one that hasn't gone through as much cryptographical scrutiny as one would like) [1]. And, given that slapping on an ECDH exchange is relatively cheap (both in computation and especially in bandwidth), I can see someone wanting to put it in there as a safety measure, in case that the postquantum algorithm turns out to have a weakness to classical computers. In any case, even if we ignore mixing, there are questions that need to be considered for a postquantum algorithm (which doesn't behave precisely like DH). For example, to what extent should we insist that fresh key shared be used each time? Should we require the key exchange mechanism to have "CCA" security (which DH does, as long as you perform the proper validation tests), or is "CPA" security sufficient? Should we attempt to support key exchanges with huge (e.g. a Megabyte) public keys? Those questions can be considered even before we learn which postquantum algorithms we will eventually use. [1]: Exception: McEliece has been around a long time, and has picked up enough scrutiny for us to trust it. However, it's also the one with Megabyte keys, and even if we were to support it, it's likely to be only rarely used; the issue will still remain with whatever other postquantum key exchange we also support _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
