On 08-09-2025 at 23:09, David Benjamin wrote:
Thanks! These are great comments! I uploaded a PR with text that tries to
address it here:
https://github.com/tlswg/tls-key-share-prediction/pull/15
<https://github.com/tlswg/tls-key-share-prediction/pull/15>
Thanks you for your extensive response and the PR! The new text looks good to
me. A few more detailed responses below, inline .
There isn't really a well-defined distinction in TLS between "preferred" things vs "supported" things.
Suppose the server's supported groups, in preference order, are ML-KEM-768, X25519, P-256, P-384. Which ones are the
"preferred" ones? Just ML-KEM-768? The first two? The first three? All but the last one? I mean maybe the human making
that list was thinking, "yeah, I really like the first three but I guess I'll tolerate P-384", but there isn't really a
functional difference between any other prefix being "preferred".
The situation I was thinking of is a server that prefers hybrid KEMs, but is
willing to tolerate ECC-only to support older clients. In such a case the
server might consider not advertising the ECC-only groups in
tls-supported-groups at all. But putting them at the end of
tls-supported-groups should be enough to make clear that those are the
least-preferred groups.
- Section 3.3: what should a client do if there are several named groups
in common? Should it send a key_share for the first match, or for its preferred
one, or for all matches?
Hmm, yeah, the text is unclear. Thinking about what it /should/ say, I suspect the answer
is "it depends". On the one hand, all but one key share is guaranteed to be a
waste of bandwidth and CPU. So that suggests you should simply pick the one you think the
server would have picked and then send that one. On the other hand, you might guess wrong
for a variety of reasons mentioned in Section 3.4. So maybe you want to send multiple
matches to cover for that.
But since this is a pretty clear "the server supports these groups" signal, I
would err towards sending just the one match over sending a bunch as spares. You
particularly wouldn't want to predict a large or computationally expensive option lightly.
I've expanded on the text a bit in the PR. Does that look better?
It does; the new text makes clear that it's up to the client to make a decision
here. I also like that the new text explicitly mentions the considerations that
may play a role in such a decision.
One thing that does still bother me a bit is the phrase "successfully predicts". The client doesn't
know the server's selection mechanism, so it cannot know at this point whether its prediction will be
successful or not. Maybe you should leave out the word "successfully", or say something like
"if the client finds a mutually supported group"?
- Section 4: the two last sentences in the third paragraph contain
important information for server implementors; I suggest promoting these to a
separate section on server behavior, following section 3.3 on client behavior.
Hmm. Had a hard time moving that since it was tied up in the rest of the
discussion. Though it's also just restarting a corollary from RFC 8446. The
main point of this section is that servers are already expected to implement
something that makes this safe. (An earlier draft had something much more
complicated and the conclusion then was to take all that out.) I reworded this
text a bit though, so maybe that's better?
I had originally read this as an extra requirement on servers, not as restating
an existing one from RFC8446. I think the new text is clearer.
- Section 4, final paragraph: there is a gap between the first sentence
(which speaks of reducing the risk of downgrade attacks) and the rest of this
paragraph (which discusses other reasons why a client may ignore
tls-supported-groups). I suggest moving that rest (which isn't security
related) elsewhere, e.g. to section 3.3.
Hmm, we're talking about "To reduce the risk of downgrade attacks with incorrectly
deployed servers, [...]", right? The rest of the sentence is talking about how you
might limit the influence to PQ groups, so that an attacker cannot downgrade to ECDH,
even if the server was incorrectly deployed. That's talking about the downgrade attack.
Rephrased it a bit in the PR so maybe that's clearer?
I had originally read this as promoting the use of pq-groups rather than
preventing downgrade attacks; with the new text it's clear that it belongs here.
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
