On Tue, Sep 24, 2024 at 8:04 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote:
> > Avoiding HRR is a matter of predicting the group that the > > server would have picked given yours and the server's preferences. For > > example, consider a server that supports: > > > > A > B > C > D > E > F > > > > By the short list theory, you might think the server should publish, say, > > "A, B, C". However all that accomplishes is that a client that only > > supports D, E, and F won't know that it should predict D. The right > > behavior is to publish your full preference list, so that all clients (up > > to differences in selection algorithm) have the best shot of predicting > > correctly. > > I agree with the "best shot" goal. "Full preference list" still > seems ambiguous and not the same as supported. > "Supported foo" is the standard terminology we've always used in TLS for "full preference list". It is "tell me all the things you are willing to use (i.e. support) and order them based on which you prefer". See RFC 8446. > The "supported_versions" extension is used by the client to indicate > which versions of TLS it supports and by the server to indicate which > version it is using. The extension contains a list of supported > versions in preference order, with the most preferred version first. > When sent by the client, the "supported_groups" extension indicates > the named groups which the client supports for key exchange, ordered > from most preferred to least preferred. If the TLS working group wishes to deviate from the TLS working group's pre-existing TLS naming convention for this exact TLS concept, we can certainly do that. But I think we should have a very clear reason and all be on the same page as to what we're doing here. > > Could you elaborate on how a long list could result in a failure or add > > complexity? > > Again, I'll try:-) > > Let's say we have targets T1 and T2. And server instances S1, S2 > where T1 is served by both S1 and S2 but T2 only by S2. > > T1 is an ordinary thing and it's best list to publish is the usual > good thing we'll call L1. T2 however is a special and has some oddball > clients that need to use oddball groups and so has a supported (or > preferred:-) list that's L1+oddballs. > > If we publish L1+oddballs for T1 and the CH is sent to S1 then we > will see a fail if a T1 client happens to prefer an oddball group. > > In that case ISTM the right thing is to publish L1 for T1 and > L1+oddballs for T2. > > Publishing L1 for T1 doesn't seem to me to represent publishing > the list of supported groups, as S2 can in fact handle more. > > My guess is the emerging PQ-zoo plus how that zoo maps to > geographies (and hence data centres) may lead to such issues. > I could well be wrong of course. > Ah okay, I think there may be some misunderstanding here about how HTTPS works and also the consequences of mispredicting. Let's break this down: > If we publish L1+oddballs for T1 and the CH is sent to S1 then we will see a fail if a T1 client happens to prefer an oddball group. If you publish L1+oddballs for all routes to T1 and the client then predicts oddballs to S1, *this is not a failure*. The server will simply send HelloRetryRequest, as is required by RFC 8446. It is *suboptimal*, but it is not a failure, nor added complexity for S1 because S1 was already obligated to implement HRR. > In that case ISTM the right thing is to publish L1 for T1 and L1+oddballs for T2. That would *also* suboptimal for T1. Suppose the client supports oddballs, saw L1, and predicted something in L1. Then they connect to S2 but actually S2 really wants oddballs when the client supports it. Then S2 will HRR. The only way to do this right is to make sure the client sees S1's supported groups when connecting to S1, and S2's supported groups when connecting to S2. HTTPS already has a general solution for this: Publish two HTTPS records for T1. HTTPS records are not service-wide. They describe individual service endpoints. That's why the records themselves contain a TargetName field. If you, for some reason, decided to persistently (i.e. not an artifact of rollout) serve T1 heterogeneously, you should publish two HTTPS records. The first one has a TargetName that points only to S1 and has S1's supported groups. The second has a TargetName that points only to S2 and has S2's supported groups. This is the same as any other SvcParam. If you want to use different SvcParams for different instances of your service, split them up by HTTPS/SVCB. (If you recall the discussion about multi-CDN use cases, this is that use case.) But, again, the consequence of getting this wrong is not a connection failure. It is simply a suboptimal prediction. > >> I think a presentation syntax of "tls-preferred-groups" would > >> fix the issue. > > > > Hopefully the above makes it clear that the rename both would not fix the > > issue, and doesn't really reflect the semantics we need here. > > I'm fine with any presentation syntax name that reflects what is > in the end the desired semantic including ambiguity. Or with some > text that says that even if the name is "tls-supported-groups" > that's not what we really mean. The latter seems undesirable though, > but if there were a bunch of code-bases already using > "tls-supported-groups" or zones that had published such, then > weasel-wording around that may be the right answer. (I'm not aware > that that's the case, so I think it may be timely to try address > this before allocating a codepoint.) > But that is *exactly* what we mean. We want to know all the groups that this service endpoint supports. We don't want to know a preferred subset, because that preferred subset will be incomplete for clients that only support the omitted ones. In other words, we want exactly what RFC 8446 says here, but for the server: > When sent by the client, the "supported_groups" extension indicates > the named groups which the client supports for key exchange, ordered > from most preferred to least preferred. I see I used slightly different phrasing in the draft > This document defines the tls-supported-groups SvcParamKey [RFC9460], which specifies the endpoint's TLS supported group preferences, as a non-empty sequence of TLS NamedGroup codepoints in order of decreasing preference, with no duplicates. What if we simply mirrored the already WG-agreed text from RFC 8446? Something like... > This document defines the tls-supported-groups SvcParamKey [RFC9460], which indicates the TLS named group which the endpoint supports for key exchange, ordered from most preferred to least preferred, with no duplicates. > > I think the right solution here is honestly to not worry about it too > much. > > Perhaps. Or maybe we should worry just the right amount:-) > Yup. The "right amount" is "not too much". :-) Per above, the consequences of being temporarily out of sync are not a failure. They are merely an (unavoidable anyway due to DNS caching) temporary performance blip. I can draft some text to explain that a bit better, though it's a pretty general HTTPS-RR and DNS concept that caching and rollout transitions means you'll get out of sync. (If you're in a persistent split, as in your T1/T2/S1/S2 example, *then* you want multiple HTTPS records. But that is also a general HTTPS/SVCB concept and thoroughly covered by the HTTPS/SVCB RFC, since that was the whole design principle behind it all.) > > Maybe we could add a bit of text to point this situation out, but > otherwise > > I don't think there's anything we can or should change in the protocol > > itself. At transition points, it is already inevitable, due to DNS > caching, > > that you'll get out of sync. That's fine. TLS 1.3 already handles that. > > Whether DNS servers the new or old population of servers isn't really > going > > to change that. We could maybe include a suggestion to pick like the > > majority one or something, but it doesn't hugely matter. > > I don't think any change to the wire protocol is needed. > > I do think changing the presentation syntax name used may help > avoid future problems if e.g. someone reads "supported" and > figures that means they ought add all the mappings to TLS > codepoints they can envisage from what the get running the > `openssl ecparam -list_curves` command. > If they were to do that, the service would still work, just predict badly. But I don't think this is a huge risk as, empirically, we have not had the same problem with TLS's use of the exact same name for the exact same concept. > Cheers, > S. > > > > > David > > > > On Tue, Sep 24, 2024 at 6:49 PM Stephen Farrell < > stephen.farr...@cs.tcd.ie> > > wrote: > > > >> > >> 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 > >>>> > >>> > >> > >> > > > >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
