[TLS] Re: I-D Action: draft-ietf-tls-key-share-prediction-03.txt

[David Benjamin <[e-mail]>]

(Was on vacation last week, so I'm still catching up on everything.)

On Tue, Sep 9, 2025 at 4:23 AM Marc Penninga <[e-mail]> wrote:

>
>
> 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.
>

Ah, makes sense. Yeah, it's probably safe for a server to omit the tail of
its list? Though there's probably also not much benefit. Dunno if it's
worth the verbiage. *shrug*


> >     -   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"?
>

Ah yeah, that is confusing. I was just thinking "the function doesn't
return an error for whatever reason", but yeah let's just drop the word.
I've updated the PR. "If the client finds a mutually supported group" seems
to prompt the questions about what happens if there are multiple matches.


> >     -   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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>