Hiya,
On 9/24/24 23:36, David Benjamin wrote:
Could you clarify what you mean by supported vs preferred? I'm not sure I follow what the difference is, in the context of a TLS implementation.
I can try:-)
The intention is that you list all the NamedGroups you support, in order of decreasing preference. That gives the client enough information to make a reasonable prediction.
I interpret supported as being the set of all groups that could work with either all or at least one of the server instances currently listening at the target's IPs. (I don't think the draft says which of "all" or "at least one" is the intended semantic.) I interpret preferred as being a list that the target thinks will help clients avoid HRR, and help clients choose what is considered "best" (e.g. wrt PQ) and that should work with all server instances concerned, and that's likely the shortest such list. The issue with "supported" may be that some server instances might have support for all sorts of oddball groups, and it might be counterproductive to list all of those for the target. (And/or to collect/merge the list if we're thinking about e.g. the wkech thing.) I'm fine that the text is a bit ambiguous on that for now, but if the presentation syntax says "supported" then someone may take that literally and publish very long lists that could result in failures, for some server instances. (Or else could add complexity in how e.g. a front-end thing like haproxy has to process client hellos.) Section 3.2 maybe encapsulates the ambiguity: "Services SHOULD include supported TLS named groups, in order of decreasing preference in the tls-supported-groups parameter of their HTTPS or SVCB endpoints. As TLS preferences are updated, services SHOULD update the DNS record to match." The 2nd sentence could be read as referring to the ordering or to the content of the list. And the example would indicate the latter. (To me anyway.) I think a presentation syntax of "tls-preferred-groups" would fix the issue. Cheers, S.
On Tue, Sep 24, 2024 at 6:24 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:Hiya, I read the draft again just now. ISTM overall a fine idea. I think the current draft is a bit ambiguous as to whether the SvcParamKey reflects preferred or supported groups. It may be better to resolve that before allocating a codepoint. However, if the DEs considered a possible later change to the presentation syntax as being consistent with allocating a codepoint now, then I'd be fine with going ahead now, but IIRC DNS folks do also care about presentation syntax stability when it comes to codepoints. (I could be wrong there or things could have changed, which could change my conclusion.) The quickest way to resolve this might be to rev the draft and just change the presentation syntax term from supported to preferred. (Assuming we agree that the HTTPS RR values will typically reflect overall group preferences for the target and not everything actually supported by all the server instances concerned.) Cheers, S. On 9/24/24 19:17, Sean Turner wrote:Hi! After discussions with the author (David Benjamin) of draft-ietf- tls-key-share-prediction [0], I would like to determine whether there is consensus to request an “early” * code point request for a 'tls-supported-group' entry in the Service Parameter Keys registry; see Section 5 of the I-D. The point of this consensus call is to determine whether you think this I-D is stable enough to request a code point in the Expert Review range [1]. Please let the list know by 8 October 2023 if you support this “early" allocation. * Early is in quotes because, technically, this is not an early IANA allocation as defined in [2]; I am just calling it “early" because it’s before the I-D is an RFC. I confirmed with the Service Parameter Keys DEs (Designated Experts) that we can get a code point in the Expert Review space if the I-D is stable; if not, then we should be using the Private Use space. spt [0] https://datatracker.ietf.org/doc/draft-ietf-tls-key-share- prediction/ [1] https://www.iana.org/assignments/dns-svcb/dns- svcb.xhtml [2] https://datatracker.ietf.org/doc/rfc7120/ _______________________________________________ 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
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
