On Fri, May 1, 2026 at 2:08 PM Jan Schaumann <jschauma= [email protected]> wrote:
> Eric Rescorla <[email protected]> wrote: > > > I agree with these statements. Jan used the word "session" which I > decided > > to read them in informally, even though it's not really as much of a > > concept in TLS 1.3, but it's good to be precise. > > > > While we're on the topic, it *also* lets them collect things like cookies > > and passwords, which would also allow client impersonation in many cases. > > Yes, I'm not looking to downplay the impact. And of > course if we assume the adversary has a CRQC capable > of (actively and in real time*) compromising the key > exchange, then it stands to reason that they can > _also_ fake a classical signature / cert, but that is > not the concern of the recommendation in the draft, > lest it would have to talk about PQ signatures and > we're back further up the thread. :-) > > To me a successful MitM implies I have the ability to > impersonate the server in the same way as if I had > compromised their server certificate, which is why I > bristle at the phrasing in the draft equating key > exchange compromise with (full) MitM. > I agree with you about the facts of the situation. I feel like what we're running into is a lack of precision in the term MITM, so perhaps the fix is just to not use the term and instead lay out the precise consequences in the way David did upthread. (Of course, another argument here for just changing the IANA value in the other spec in AUTH48 and skipping all this wordsmithing). * This, btw, is a separate assumption here. If a > CRQC can only break RSA in, say, minutes, then you > still can't use it for on-path decryption and still > need to harvest first. A CRQC that breaks RSA in > miliseconds for on-path decryption is yet a different > story, isn't it? > Just to avoid the certificate point, maybe let's say X25519 :) I mostly agree with you, though of course long-lived sessions exist, and in that case it seems like you could use it for some on-path decryption right?
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
