Hi all,I did some /preliminary/ analysis; I would like to share a couple of cents to reconcile.
TL;DR: /My/ current understanding is that both John and D. J. Bernstein are right, but talking about slightly different things, i.e., system-level and protocol-level, respectively.
In case it helps anyone, the way I reconcile the two apparently diverging opinions is that:
D. J. Bernstein is looking at signatures in /CertificateVerify/. Consistent with /computational/ proofs mentioned by him [0], my preliminary /symbolic/ analysis in ProVerif is that EUF-CMA does not break my proofs. I used DHKE because he said it does not matter, and it is something I am more comfortable and confident. I model EUF-CMA signatures using additional /rewrite rule/ to allow this functionality for the adversary. In TLS, client uses a fresh nonce which makes the use of multiple signatures -- on the /same/ transcript hash -- useless for the adversary. John is looking at systems using signatures in TLS /Certificates/, such as firewalls using allowlist. EUF-CMA allows multiple certificates for same message (in this case, it refers to the contents of certificate, in particular binding of identity and public key). So blocked client (acting as attacker) can bypass allowlist by using another certificate with same contents. From the perspective of the server, it is a valid attack unless all valid certificates for that message are blocklisted. I don't have a model for it. It is my intuition/understanding from research. While protocol-level is important, system-level view is important too. === Hi D. J. Bernstein,Thank you for the detailed clarifications. I need more precise details to model the claimed attacks correctly.
Please feel free to correct me if I have misunderstood something. Quoting below as requested in [1]: On 06.06.26 14:13, D. J. Bernstein wrote:
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.What TLS cares about is whether the message was legitimately signed---which in this case it was---rather than whether this particular signature was the one that the signer produced.
Thanks, that matches my understanding.
My security objection to draft-ietf-tls-mldsa
doesn't actually rely on this---a minor tweak to ECC+PQ to first sign
with ECC and then use PQ to sign the message-signature pair, which is
one of the recommendations in, e.g.,
https://pqcrypto.eu.org/deliverables/d2.5.pdf#subsection.3.3
in 2018, would stop this "attack"---but, more importantly, it's not an
attack on TLS in the first place.
I appreciate the concern. I would be happy if you could share concrete feedback on the artifacts[2] to make them more comprehensive. We did some extensions which are not yet public because of papers under submission and I would be happy to give you access to private repos for review once you are done with your review of [2].TLS 1.3 was advertised as insisting on proofs. The reality wasn't as comprehensive as the marketing---there wasn't an insistence on proofs covering all protocol details and reaching a satisfactory quantitative security level and being computer-checked.
For TLS, could you please clarify if "multi-user" refers to attacker (acting as client) opening multiple connections concurrently to the same server?This is quantified as "mu-EUF-CMA", which is a "multi-user" version of EUF-CMA where the attacker wins by breaking one out of many uses of signatures.
You ask whether I'm aware of any paper challenging the idea that EUF-CMA is sufficient for TLS. No, I'm not, nor do I have any idea how such a challenge could be justified, given how TLS uses signatures.
Thanks. That precisely answers my question.
[...] 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.**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.Sure, TLS is also signing more, but my point applies to all of the messages signed in TLS. What matters about signatures for the TLS security goals is simply that each of the signed messages was in fact signed by the legitimate owner of the public key.
Thanks.We are now on the same page.
Sure, I didn't intend to mean complexity; just the observation of what we currently have.FWIW, what we have in ProVerif proofs is ideal signatures and SUF-CMA makes it closer to the proofs.Well, it's not rocket science to do a symbolic analysis that allows signature malleability, but either way the symbolic analysis is at best a simplified analogy of an EUF-CMA analysis or an SUF-CMA analysis.
Thanks for the confirmation. I am using DHKE in my model, which I am more comfortable with.What are your assumptions -- if any -- on the key exchange part of TLS in the attack? Do you assume KEMs or DHKE or hybrids?Doesn't matter.
You agree above that it signs /more/ than just the key exchange, but still keep saying "signing the key exchange." This is confusing for me. It would be helpful to say something like signing the transcript hash. EncryptedExtensions is not critical, but Certificate message has a security-critical role to play, unless you make additional assumptions.The only way TLS stops an attacker from posing as the server is by signing the key exchange under the server's public key.
Could you please clarify "equivalent secret key" in the paper?As the paper says, the attack "recovers an equivalent key---part of the secret key---and uses the equivalent key to rapidly forge signatures on arbitrary attacker-chosen messages, signatures that verify under the original ML-DSA-44 public key"; Section 4 says concretely what's being recovered; the paper's supplement includes attack demos.From TLS perspective, does it mean attacker recovers the server's long-term private key?No: "This attack does not recover 'the secret key' (and does not justify [87]'s claim regarding that)". However, as the paper says: "some extra work in signing lets the attacker compute 'hints' that pass verification even without knowing the rest of the secret key". Full details are in the attack demo.
Combining the above two, as I understand, attacker only computes part of the server's secret key, which is sufficient to produce valid signatures that the client will happily accept (and hence you call it 'equivalent secret key'). Is this a good summary?
Since the key is 'equivalent,' a reasonable symbolic model seems to be that the actual key gets leaked/is exfiltrated.Would that be a faithful model? If not, then why not?
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.I'm not sure what distinctions you're drawing here. Impersonation is an active attack with an online part. MITM is an example of that where the attacker is also talking to the server.
Maybe there is terminology mismatch here. Could you please clarify the "online part?"
Something I still don't understand is that attacker can pre-establish two connections with the server, do all the calculations for 'equivalent secret key.' Much later in time, it can simply use that key without needing to do anything with the server at that later time. Do you still call it 'online part?'
Despite agreement above, I am still a bit confused about the continued use of "key exchanges" now even with "concretely." As explained in my previous email and once above, it would be helpful to use transcript hash instead.## *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?The server signs two messages (concretely, two key exchanges) under its public key.
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?)?I don't understand your #1/#2/#3/#4 division: e.g., #4 sounds like it's talking about the Dolev--Yao abstraction, but #1 sounds like it's talking about the real world; more to the point, the forgeries in my attack demos (which you seem to have under #2) rely on specific software bugs (which you seem to have under #1), so these aren't independent assumptions.
Ok, here is my understanding of the attack vector: 1. Server with buggy standalone ML-DSA implementation 2. Because of bug, attacker can extract 'equivalent secret key' by establishing two connections to get two CertificateVerify messages and public key from Certificate. 3. With the 'equivalent secret key,' attacker can now issue fake signature in CertificateVerify message for /any/ connection of that server that the client will accept 4. Attack succeeds if time to complete handshake including forging signature for that specific connection < client time out
Do you know of any more recent measurements of TLS client timeout behavior? This paper is now more than one decade old.## *Practicality of attacks* Do you have practical numbers on what is: * typical client time out from standard TLS libraries with referenceshttps://weakdh.org/imperfect-forward-secrecy-ccs15.pdf exhibited attacks involving roughly a minute of online computation; typical clients were not timing out that quickly.
There's something to be said for trying to enforce short timeouts to stop attacks, but realistically trying to set a timeout below 1 second would be an interoperability nightmare, so for faster attacks than that it isn't necessary to study client behavior---there will certainly be many vulnerable clients.
Could you please clarify or point me to reference /where/ something is to be said?
Best regards, -Usama [0] https://eprint.iacr.org/2020/1029[1] https://mailarchive.ietf.org/arch/msg/last-call/oKrCjFfDUYoePOVSyWQ-URQU9Fk/
[2] https://github.com/CCC-Attestation/formal-spec-id-crisis
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
