Again, responding to old emails... > -----Original Message----- > From: TLS <tls-boun...@ietf.org> On Behalf Of Stephen Farrell > Sent: Friday, April 29, 2022 8:25 PM > To: TLS@ietf.org > Subject: Re: [TLS] WGLC for draft-ietf-tls-hybrid-design > > - section 2: if "classic" DH were broken, and we then depend on a PQ-KEM, > doesn't that re-introduce all the problems seen with duplicating RSA private > keys in middleboxes? If not, why not? If so, I don't recall that discussion in > the WG (and we had many mega-threads on RSA as abused by MITM folks so > there has to be stuff to be said;-)
Actually, unless the client uses a PQ-KEM private key permanently, no one can do a MITM. It is similar to Diffie-Hellman; the client picks a key share; the server picks a response key share; the both derive the same shared secret. The draft allows (but does not encourage) the reuse of KEM private values (and while it must limit the reuse to what the specification of the KEM allows, in practice, that's not a restriction). Should we modify the draft to forbid reuse? Kyber public/private key generation is fast enough to make this practical. Looking through the TLS 1.3 RFC, I don’t see any text addressing the reuse of ECDHE private values; is that implicit by the definition of DHE? I do see in the text "If fresh (EC)DHE keys are used for each connection, then the output keys are forward secret."; that wording would imply the possibility of not using a fresh (EC)DHE key for each exchange... > > - similar to the above: if PQ KEM public values are like RSA public keys, how > does the client know what value to use in the initial, basic 1-RTT > ClientHello? > (sorry if that's a dim question:-) If the answer is to use something like a > ticket > (for a 2nd connection) then that should be defined here I'd say, if it were to > use yet another SVCB field that also ought be defined (or at least hinted > at:-) Actually, it's the client that selects the KEM public key. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
