(Was on vacation last week, so I'm still catching up on everything.) On Tue, Sep 9, 2025 at 4:23 AM Marc Penninga <m...@kavula.fi> 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 -- 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
