Hi Scott, mutt+links can't cope with your text/html using [p class="MsoNormal" style="margin-left:.5in"] for quoting (and the text/plain multipart alternative is completely busted), so I have to trim PHB's original in most instances.
On Sat, Aug 06, 2022 at 03:18:31AM +0000, Scott Fluhrer (sfluhrer) wrote: > > > I have the luxury of having 0 users. So I can completely redesign my > > architecture if needs be. > > I would disagree; after all, we do have existing TLS 1.3 implementations. I > believe it is important to avoid unnecessary changes, for two reasons: PHB's use of the first-person singular implies he's talking about the mathematical mesh, not TLS at all. > I’m trying to figure out what you’re saying; at least one of us is confused. > NIST asked for a Key Exchange Mechanism (KEM), and Kyber meets that > definition (which is essentially what you describe; both sides gets a shared > secret). That is the functionality that TLS needs, and is the functionality > that NIST (and others) evaluated. Yes, there are internal functions within > Kyber; no one is suggesting those be used directly. And, yes, NIST might > tweak the precise definition of Kyber before it is formally approved; any > such tweak would be minor (and there might not be any at all); if they do > make such a change, it should not be difficult to modify any draft we put out > to account for that change. I thought KEM expanded to "Key Encapsulation Mechanism" (viz RFC 9180). Indeed, my understanding is that PHB's specific point is that it is *not* an exchange, and rather that the sender picks a key and the recipient just gets that key without contributing do it. (Well, I think there is maybe also some bit in PHB's note that's quibbling about how the sender doesn't actually pick the key, and rather the local output of the KEM is the encapsulated blob plus the shared key, with the shared key not being an input to the KEM ... but I haven't read NIST's report yet and can't confirm or reject that assertion.) I am reading PHB as saying that the "internal function" within Kyber that is an "actual KEM" is one that takes the shared key as input and produces the encapsulated blob as output (again, cannot confirm or reject). > It was my understanding that TLS 1.3 didn’t do rekeys (ChangeCipherSuite). > Instead, the key agreement is done only at connection establishment time, and > could be broken into: > > * Full negotiation (the client not having any context) > * Resumption (0-RTT or 1-RTT) negotiation (where the client has some > secret data from a previous full negotiation) > Because those are both fresh negotiations, I don’t see any alternative to > using a postquantum key exchange for both. There's also KeyUpdate. And the PSK handshake mode that's just psk_ke, not psk_dhe_ke. But I don't think I understand PHB's proposed taxonomy yet, either. -Ben _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
