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
On Fri, Sep 5, 2025 at 8:08 AM Marc Penninga <m...@kavula.fi> wrote: > A few nits. I'm relatively new to this mailing list, so apologies if any > of these have been brought up before. > > - It's not clear to me whether a server should declare _all_ named > groups it supports in tls-supported-groups, or only the ones it prefers. > The name of the service parameter, as well as the text in section 3.2, > suggests the former, but other places in the text speak of a server's > "preferences". > Oh hmm, I think I've always used your "TLS preferences" to describe your full set of preferences, though I'm not sure how standard that terminology is. RFC 8446 has the word a little, but not that commonly. I've reworded it a bit in the PR. Does that read better? 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". > - If a server includes a named group in tls-supported-groups, is it then > obliged to accept a client's key_share for that named group, or may it > still respond with a HelloRetryRequest? > No obligations. Section 3.4 talks a bit about cases where HelloRetryRequest may happen anyway. https://tlswg.org/tls-key-share-prediction/draft-ietf-tls-key-share-prediction.html#name-misprediction > - Section 1: the sentence > > "Named groups in this subset may be used in one, while named > groups outside the subset requires a HelloRetryRequest and two round trips." > > would be easier to understand (at least for me) if it were phrased as > > "Named groups in this subset can be used in one round trip, while > named groups outside the subset require a HelloRetryRequest and hence two > round trips." > Much better. Thanks! Applied in the PR > - 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? - Section 3.4: in the second item of the list, the word "temporary" > should be "temporarily". > Ah thanks, fixed! > - Section 4: the structure of this section would be clearer if the > second and third paragraphs were formatted as list items rather than > top-level paragraphs. > Done in PR. I had to rework a bit of the text to make that work. > - 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? > - 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?
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
