Salz, Rich wrote:
>I am curious why this is worse than, say, knowing that the server reports
>SSLKEYLOGFILE into a public
>S3 bucket or similar? And do you think a real adversary would self-report that
>they are using
>ephemeral keys?
I was comparing these three options:
A. Key shares being reused without any signaling to the other peer.
B. Signaling that the key share is reused (similar to
draft-rhrd-tls-tls13-visibility).
C. Two different code point. One forbidding reuse and one allowing reuse
(similar to TLS_ECDHE_ECDSA vs. TLS_ECDH_ECDSA).
Of these three, I think A is the worst. Of course making all session key public
would be worse, but SSLKEYLOGFILE forbids any use in production systems.
Viktor Dukhivni wrote:
>However, you'll be thrilled to learn that it is not possible for a TLS
>server to reuse its ML-KEM keyshare when a client uses a fresh ephemeral
>ML-KEM keyshare.
Yes, that solves half the problem, but I would also like my servers to not talk
to clients reusing key shares with other servers.
Cheers,
John
From: Viktor Dukhovni <ietf-d...@dukhovni.org>
Date: Sunday, 9 March 2025 at 14:39
To: tls@ietf.org <tls@ietf.org>
Subject: [TLS] Re: FW: I-D Action: draft-kwiatkowski-tls-ecdhe-mlkem-03.txt
On Sun, Mar 09, 2025 at 12:33:38PM +0000, John Mattsson wrote:
> I find the current situation of key shares being reused without the
> other peer knowing inacceptable and frankly the worst possible option.
In general terms, your expectations are unrealistic, the best you can
do, if you think you're in a position to influence remote server
behaviour, rather than just take an ineffective principled stand, is
detect a duplicate keyshare from a previous connection and abort.
However, you'll be thrilled to learn that it is not possible for a TLS
server to reuse its ML-KEM keyshare when a client uses a fresh ephemeral
ML-KEM keyshare. TLS servers don't have ML-KEM keys, they just perform
encapsulation against the client's public key, so there's nothing for
the server to reuse (KEMs aren't (EC)DH key exchange).
So while the X25519 portion of the server's key could be reused, the
ML-KEM portion will not be.
--
Viktor.
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
