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. -Jan * 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? _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
