[ -last-call +TLS as per AD instructions ] Hi D. J. Bernstein,
First off, thank you for the detailed clarifications and I am so sorry if part of my email seemed like repeating the complaints on EUF-CMA that others have made. FWIW, I feel like I haven't yet got the answers that I am trying to get. To clarify my perspective, I am trying to understand your latest attack and analyzing that at the symbolic level in ProVerif to understand the precise assumptions required for the attack from TLS perspective. I haven't seen anyone jumping in to say that he is modeling this one, so I sincerely hope my questions below move the discussion forward and are not repetitive. While some of my questions may sound nitpicking, I believe they have an important role to play in my ProVerif model -- at least the way I currently understand your latest attacks. Sincere apologies in advance, and please feel free to correct me if I have misunderstood something.
I am skipping the risk part, because I believe it's subjective and we will most likely not converge on it. Focusing on formally verifiable parts, I request the following clarifications:
# *EUF-CMA vs. SUF-CMA*I understand you quoting that ECDSA is EUF-CMA and is used in TLS but that is rather an indirect answer to my questions in [0] and reminder in [1]. To focus on what I was actually asking, I am assuming that you are not aware of any follow-up paper which challenged/refuted/invalidated the claims that EUF-CMA is /sufficient/ for TLS. Could you please explicitly confirm? To my naive understanding, that seems to be the central part of your claim on this matter.
Quoting as requested in [2]: **
**The first part does not seem right to me. In TLS 1.3, CertificateVerify is not just signing the key exchange, it's signing /all messages/ up to and including Certificate message. The key exchange part is in ClientHello and ServerHello messages. The transcript hash in CertificateVerify also covers EncryptedExtension and Certificate messages. My point is: it's integrity of the handshake up to and including Certificate message, not just integrity of the key exchange. The baseline ProVerif models (by Karthik et al., our extensions, and the latest updates by Nadim) correctly model it as including the transcript hash up to and including Certificate.*[...] This isn't because of a lack of study; it's because TLS is _signing the key exchange_ to ensure _integrity of the key exchange_, while integrity of the _signature_ is irrelevant.*
Integrity of signature may not necessarily be irrelevant in all usages of TLS. At least in some cases, it may be a weakness. Do you consider /all/ examples John has provided with references in [3] to be irrelevant, or do you view them differently? Even if you have that position, I believe stronger security should be preferable for robustness. FWIW, what we have in ProVerif proofs is ideal signatures and SUF-CMA makes it closer to the proofs.
# *Implementation bugs*Setting the above theory aside, a core argument in your attack seems to be implementation bug, where the implementation was not correctly following the spec. If that is correct, others (e.g., [3]) have raised substantial technical issues in the implementation of draft-ietf-lamps-pq-composite-sigs. So I view it as in the category of 'risk' too.
# *Attack setup and assumptions*Also to focus discussion, please talk about your latest attack on ML-DSA (Section 6 of your paper in my understanding) and not on Dilithium 1.0 so that we don't confuse things:
Here is my understanding of the setup of your attack: please correct me if I get something wrong:
Your claim is a MITM attack where an attacker forges the signature in CertificateVerify message in real-time because of an implementation bug.
And your assumptions are: 1. Server with buggy standalone ML-DSA implementation ==> see "Implementation bugs" above 2. Attacker can forge signature in CertificateVerify message for a /specific/ connection ==> see "Missing info" below 3. Time to complete handshake including forging signature for that specific connection < client time out ==> see "Practicality of attacks" below 4. Attacker controls one of the routers between client and server ==> this is fair and legitimate Dolev-Yao adversary Is this correct? # *Missing info* Something missing from my perspective in all of this is the following: ## *Keys*What are your assumptions -- if any -- on the key exchange part of TLS in the attack? Do you assume KEMs or DHKE or hybrids?
Also, in all of your email, where you are using "a key," "the key," "that key," etc., I would request to specify exactly which key from the TLS key schedule you are talking about, with precisely the name as in RFC8446bis-14, such as client_handshake_traffic_secret.
Could you please clarify "equivalent secret key" in the paper? From TLS perspective, does it mean attacker recovers the server's long-term private key? If the private key is recovered, then why the online part is required. Attacker can simply keep signing anything with that key and fully impersonate the legitimate server rather than MITM. ISTM that I am missing something here.
## *Two legitimate signatures*I may be missing something cryptographically, but can you please explain what exactly you mean by two legitimate signatures under that key? Does it mean for /any/ connection for /any/ message using /that/ key? Would this not be sufficient for an attacker (acting as client) to establish two connections with the legitimate server to get these two signatures (in the form of CertificateVerify messages)?
At the /symbolic/ (not cryptographic) level, if you have above 4 assumptions, I don't understand why you need two legitimate signatures under that key? To be on the same page, are you saying that it is a pre-condition to one of the above 4 assumptions (#2 maybe?)?
## *Practicality of attacks* Do you have practical numbers on what is: * typical client time out from standard TLS libraries with references * time to forge signatures in your attack: as I understand, it is 1s.Thanks for any clarifications or insights you can share for better understanding.
Best regards, -Usama[0] https://mailarchive.ietf.org/arch/msg/last-call/MY0_F_2oANES0gmKyCjsyUn55No/
[1] https://mailarchive.ietf.org/arch/msg/last-call/9xOUATVB8YIpEB8mfBNwGDjpqPo/
[2] https://mailarchive.ietf.org/arch/msg/last-call/oKrCjFfDUYoePOVSyWQ-URQU9Fk/
[3] https://mailarchive.ietf.org/arch/msg/last-call/C9b21fNHsMqgif5Tj3hWHwb62kc/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
