Hi Nadim, thanks for this work you put in to extend the formal models. Even though some of the results are not surprising (as you mention), I hope that the up-to-date models might help to prevent surprises with some extensions in the future.
I have a technical question regarding finding 3 (broken KEM -> broken authentication). The specific phrasing I have seen is that > What the attacker defeats is the guarantee that a server actually completed a > matching session Can you explain in simple terms why that is, under which circumstances it may happen, and what consequences (beyond the MITM possible after the handshake) this may have? My (mostly absent) understanding of a "matching session" is "with roughly the same messages". Looking at the server state machine in RFC 8446, Appendix A.2, every honest server sending a CertificateVerify (which I understand is still required even with a broken KEM) will thereafter also "complete a handshake" with "some" Finished F1. Now, an attacker may supply a client with a Finished F2. It feels like most of our AEADs with Recommended=Y exhibit the property that decryption for a given key, nonce and associated data is injective [0]. If so, and under some assumptions on the record layer, then for F1 != F2 I would assume that the client would see a different verify_data, which would then via the same assumption on the AEAD imply that the plaintext signature was different. So is this ultimately an SUF-CMA problem? Feel free to correct me if I have completely misunderstood some concept. Best, -- TBB [0] All of AES-GCM, AES-CCM and ChaCha20-Poly1305 are basically an injective counter mode with one valid tag which is checked for equality to a computed value during the decryption process. _______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
