Hi D. J. Bernstein, Following up on previous email with more working.
Thank you for the detailed clarifications. And sorry, I need more precise details.
FWIW, I already requested that the TLS key schedule is subtle and it is easy to talk past each other without explicitly naming them.
FWIW, I still respectfully disagree with the signing of "key exchange" in TLS. Signing includes Certificate message.
Please feel free to correct me if I have misunderstood something. Quoting below as per your permission in [0]: On 07.06.26 12:41, D. J. Bernstein wrote:
Muhammad Usama Sardar writes: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.For TLS, could you please clarify if "multi-user" refers to attacker (acting as client) opening multiple connections concurrently to the same server?Or opening multiple connections to multiple servers.
I actually don't understand how this works with multiple servers unless there is the assumption that these multiple servers have the same public key.
Isn't it typical that multiple servers will have their own public key? As I understand, to do your latest attack, the attacker needs 2 signatures and the public key corresponding to /those/ signatures. So how does establishing two connections with two different servers with two /different/ signing keys help at all?
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.Let me emphasize my perspective here. The security goals for the TLS standard are server authentication (and optional client authentication), data confidentiality, and data integrity. TLS protects data using keys obtained from key exchange, but how does the client know it's exchanging keys with the right server? For TLS (and SIGMA more broadly), the answer is that the server signs the key exchange. Because of various TLS complications, people often have trouble figuring out which parts of the TLS protocol really qualify as the key exchange.
FWIW, that does not seem right to me. Please see Fig. 1 in RFC8446bis [1] which clearly shows that the two messages in key exchange are ClientHello and ServerHello. I don't see what Certificate message has got to do with the key exchange. That's clearly related to authentication.
Could you please clarify which messages /exactly/ do you believe are part of key exchange?
Is "exchanged key" representing "(EC)DHE" in the key schedule in 8446bis? If not, please name it explicitly exactly as in specs.There's a security risk if some context relevant to the exchanged key is missed.
What in your opinion is /necessary/? Are you claiming that there are no attacks if transcript hash for CertificateVerify does not cover the Certificate message?That's why TLS now signs the whole transcript---a simple way to make sure everything is covered; no harm in signing more than necessary.
But the point is to sign the key exchange, so that the client knows it's sharing a key with the legitimate server.
Which key? client_handshake_traffic_secret?
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').Right.
Thanks, that's very helpful.
Thanks, that we already have in our models. Properties hold unless the public key is not lost, and in this case, it is violated because it is lost.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?That's a reasonable choice for a symbolic model.
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?"The attack has two parts. There's an offline part where the attacker, given the server's public key and two signatures, computes an equivalent secret key. Then there's an online part where the attacker, given that equivalent secret key and a message, forges a signature on the message. The online-offline distinction is between computations that the attacker carries out during the session where the attacker is impersonating the server and computations that the attacker carries out before the session.
I noticed that you did not confirm 4 steps of attack vector outlined in [2] in my understanding. Could you confirm my understanding?
So in the 4 steps of attack in [2], steps 1 and 2 are offline and steps 3 and 4 are online, right?
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?'Yes, the attacker is doing this online with the client even if the attacker decides not to talk to the server at that moment. Realistically, if a client is doing something like logging in to a server, then the attacker will want to be in the middle of that to see what's happening after the login.
Thanks for the clarification.
If the attack goal is instead, say, sneaking into a software supply chain by replacing a software download from a public repository with attacker-modified software, then the attacker can build a copy of the repository at any moment and doesn't need to talk to the server while sending malware to the client.
That sounds like a concern. Could you possibly explain more?
Do you know of any more recent measurements of TLS client timeout behavior?https://web.eecs.umich.edu/~genkin/papers/9lives.pdf is more recent and says "30 seconds for almost all browsers".
Thanks.
Maybe. I think it depends on the deployment, e.g., same region or across continents.Network round-trip times are often hundreds of milliseconds (and sometimes longer) [...]
Best regards, -Usama[0] https://mailarchive.ietf.org/arch/msg/last-call/oKrCjFfDUYoePOVSyWQ-URQU9Fk/
[1] https://www.ietf.org/archive/id/draft-ietf-tls-rfc8446bis-14.html#figure-1
[2] https://mailarchive.ietf.org/arch/msg/tls/gyqsw9W5YUX-ySRfkisv3zNPcdY/
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
