[TLS] Re: [EXTERNAL] Re: Consensus Call: early code point request for draft-ietf-tls-key-share-prediction
If we want a new name, then I propose kex_hint — keyshare is a DH concept. I'm happy with all proposals so far though — we have been bad at naming, but fortunately consistently so. On Wed, Sep 25, 2024 at 7:06 PM Andrei Popov wrote: > I think it's more important to keep consistent naming between TLS and DNS > than to come up with some perfect terminology for this concept. > Publishing the full list of groups supported by the server also appears to > be more useful: any partial list is but a partial solution to the problem. > > Cheers, > > Andrei > > -Original Message- > From: Stephen Farrell > Sent: Wednesday, September 25, 2024 9:30 AM > To: David Benjamin > Cc: TLS List > Subject: [EXTERNAL] [TLS] Re: Consensus Call: early code point request for > draft-ietf-tls-key-share-prediction > > > Two quick bits... > > On 9/25/24 16:59, David Benjamin wrote: > > > If you publish L1+oddballs for all routes to T1 and the client then > > predicts oddballs to S1, *this is not a failure*. > > Yeah, I was imprecise again:-) Yes HRR will kick in, but I think that > scenario highlights a failure for this spec to help. > > That said... > > >> 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. > > With s/would/could/ that's a fair point, though I don't think we're trying > to represent that "really wants...when" > via this spec, so one could argue that's out of scope. > > Anyway, I reckon I've made my point, if others agree they'll chime in, if > not, I assume we'll stick with the current presentation syntax, maybe with > a bit more clarification, and the DEs will like that or not. > > Cheers, > S. > > ___ > 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] Re: Consensus Call: early code point request for draft-ietf-tls-key-share-prediction
Two quick bits... On 9/25/24 16:59, David Benjamin wrote: If you publish L1+oddballs for all routes to T1 and the client then predicts oddballs to S1, *this is not a failure*. Yeah, I was imprecise again:-) Yes HRR will kick in, but I think that scenario highlights a failure for this spec to help. That said... 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. With s/would/could/ that's a fair point, though I don't think we're trying to represent that "really wants...when" via this spec, so one could argue that's out of scope. Anyway, I reckon I've made my point, if others agree they'll chime in, if not, I assume we'll stick with the current presentation syntax, maybe with a bit more clarification, and the DEs will like that or not. Cheers, S. OpenPGP_signature.asc Description: OpenPGP digital signature ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: hello, I would like to ask a question
Hi Peter, back in 2020 I've implemented RFC 8449 for DTLS 1.2 in Eclipse/Californium. My interest was out of the original scope, I mainly use it to indirect indicate the preferred UDP message size. In my opinion, the original scope didn't match the available UDP APIs, see https://mailarchive.ietf.org/arch/msg/tls/NxSdyUk3Err0gJGOjnjCysuAT04/ br Achim Am 25.09.24 um 05:41 schrieb Peter Gutmann: Martin Thomson writes: Once negotiated, the record size limit applies to all records; it applies at the record layer. Handshake messages can span multiple records. Just out of interest, does anything actually use this? max_fragment_length seemed to be universally ignored, and then record_size_limit was defined... in case people noticed it this time round? Peter. ___ 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] Re: Consensus Call: early code point request for draft-ietf-tls-key-share-prediction
On Tue, Sep 24, 2024 at 8:04 PM Stephen Farrell 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 synt
[TLS] Re: Consensus Call: early code point request for draft-ietf-tls-key-share-prediction
On Tue, Sep 24, 2024 at 8:19 PM Watson Ladd wrote: > On Tue, Sep 24, 2024 at 5:07 PM Stephen Farrell > wrote: > > > > > > > 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. > > You've forgotten SNI. The support by server can also vary by target, > not just the physical box or IP that gets hit by the connection (and > that IP may itself be dependent on L not just S). But I agree, > supported may have the wrong connotation as compared to what we want, > which is the list in preference order that the server will accept. > Varying by SNI just means that S2/T1 and S2/T2 are actually two different service endpoints that happen to share a physical box and IP. It's very easy to capture that in DNS because the DNS query already tells you whether you're looking up T1 or T2. If T1 and T2 are served by different kinds of service endpoints, serve different HTTPS/SVCB records for them. Specifically, T1 should serve an HTTPS-RR for S1/T1 with S1/T1's properties and one for S2/T1 with S2/T1's properties. T2 should serve an HTTPS-RR for S2/T2 with S2/T2's properties. (See my reply to Stephen for the rest of how this situation is resolved, and TLS's long-standing precedent in the naming.) ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: [EXTERNAL] Re: Consensus Call: early code point request for draft-ietf-tls-key-share-prediction
I think it's more important to keep consistent naming between TLS and DNS than to come up with some perfect terminology for this concept. Publishing the full list of groups supported by the server also appears to be more useful: any partial list is but a partial solution to the problem. Cheers, Andrei -Original Message- From: Stephen Farrell Sent: Wednesday, September 25, 2024 9:30 AM To: David Benjamin Cc: TLS List Subject: [EXTERNAL] [TLS] Re: Consensus Call: early code point request for draft-ietf-tls-key-share-prediction Two quick bits... On 9/25/24 16:59, David Benjamin wrote: > If you publish L1+oddballs for all routes to T1 and the client then > predicts oddballs to S1, *this is not a failure*. Yeah, I was imprecise again:-) Yes HRR will kick in, but I think that scenario highlights a failure for this spec to help. That said... >> 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. With s/would/could/ that's a fair point, though I don't think we're trying to represent that "really wants...when" via this spec, so one could argue that's out of scope. Anyway, I reckon I've made my point, if others agree they'll chime in, if not, I assume we'll stick with the current presentation syntax, maybe with a bit more clarification, and the DEs will like that or not. Cheers, S. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Consensus Call: early code point request for draft-ietf-tls-key-share-prediction
> We should reap what we sow and just use supported_groups Agreed 🥲 On Wed, Sep 25, 2024 at 10:54 AM Bob Beck wrote: > > > On Tue, Sep 24, 2024 at 5:12 PM David Benjamin > wrote: > >> I should add, another reason to call it tls-supported-groups is that this >> is essentially what the server would have put in the supported_groups >> extension, if negotiation order in TLS were inverted. Since TLS already saw >> fit[*] to name this concept supported_groups, I think that's a fine name >> for the equivalent DNS incarnation. >> > >> David >> >> [*] Mind you, supported_groups is a horrible name, but because of >> "groups", not "supported". It refers to Diffie-Hellman groups, but we're >> sticking PQ KEMs in there now. But we already disruptively renamed "curves" >> to "groups" and another rename would do it again. Honestly, we should have >> just kept it at "curves", and saved our disruption budget for a >> more appropriate name, but so it goes. :-) >> > > ^^^ This. having a third term to attempt to describe a concept because > we keep changing our minds is not going to help implementers, but just > cause confusion > > I don't personally like supported_curves^Wgroups but turning that into > supported^Wpreferred_curves^Wgroups^Wkems is just adding confusion and > possibly code churn for variable renaming. We should reap what we sow and > just use supported_groups > > If we absolutely must name the DNS thing something else, treat it as an > opaque list of strings and don't be opinionated about what those > strings contain. The DNS doesn't know or care anyway. name it for what it's > purpose is (keyshare_hint). > > > >> On Tue, Sep 24, 2024 at 7:07 PM David Benjamin >> wrote: >> >>> Ah, I see. I don't think "supported" vs "preferred" captures this >>> because "preferred" in the context of TLS usually isn't a binary property >>> but a preference order. But I agree there is some ambiguity over what to >>> list if you've got a couple different values. >>> >>> I think, other than potentially changing the name, it's not likely that >>> this will have any impact on the presentation syntax. At the end of the >>> day, we're going to want to send a list of things that your service (being >>> intentionally vague about multiple server instances) supports. But since >>> "supported" vs "preferred" is not the right descriptor, I suspect we won't >>> do better than "supported" anyway. In particular... >>> >>> > 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. >>> >>> That's not right. 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. >>> >>> > 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.) >>> >>> Variations in server instances may indeed result in mispredictions. If >>> the variation is due to a temporary rollout inconsistency, this variation >>> is shortlived and will eventually sort itself out. During that period of >>> inconsistency, neither list is more correct than the other because you want >>> to make the correct prediction for each server. >>> >>> If the variation is persistent because you've intentionally deployed >>> different instances of your service differently... first of all, don't do >>> that. The security properties are not what you might. (An attacker can >>> always direct the client to the weaker of the two.) If, despite the >>> security flaws, you insist on doing this, I suppose you can use different >>> HTTPS records for each and use all the machinery that HTTPS-RR already has >>> here. That's all orthogonal to this draft because describing multiple >>> routes to a single service is a general HTTPS-RR feature. >>> >>> > 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.) >>> >>> Could you e
[TLS] Re: Consensus Call: early code point request for draft-ietf-tls-key-share-prediction
Hiya, On 9/25/24 15:50, Bob Beck wrote: If we absolutely must name the DNS thing something else, I don't think we absolutely must change, but do think deciding now is timely, and also that a change is likely better. If we stick with what's in the I-D now, I'd say a bit of apologetic text saying why might help the DEs in agreeing to allocate a codepoint. treat it as an opaque list of strings and don't be opinionated about what those strings contain. The DNS doesn't know or care anyway. Sure. But the DEs do care about stability IIUC. name it for what it's purpose is (keyshare_hint). I like that one - as you say, naming it for what it does is good. Cheers, S. OpenPGP_signature.asc Description: OpenPGP digital signature ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Consensus Call: early code point request for draft-ietf-tls-key-share-prediction
On Tue, Sep 24, 2024 at 5:12 PM David Benjamin wrote: > I should add, another reason to call it tls-supported-groups is that this > is essentially what the server would have put in the supported_groups > extension, if negotiation order in TLS were inverted. Since TLS already saw > fit[*] to name this concept supported_groups, I think that's a fine name > for the equivalent DNS incarnation. > > David > > [*] Mind you, supported_groups is a horrible name, but because of > "groups", not "supported". It refers to Diffie-Hellman groups, but we're > sticking PQ KEMs in there now. But we already disruptively renamed "curves" > to "groups" and another rename would do it again. Honestly, we should have > just kept it at "curves", and saved our disruption budget for a > more appropriate name, but so it goes. :-) > ^^^ This. having a third term to attempt to describe a concept because we keep changing our minds is not going to help implementers, but just cause confusion I don't personally like supported_curves^Wgroups but turning that into supported^Wpreferred_curves^Wgroups^Wkems is just adding confusion and possibly code churn for variable renaming. We should reap what we sow and just use supported_groups If we absolutely must name the DNS thing something else, treat it as an opaque list of strings and don't be opinionated about what those strings contain. The DNS doesn't know or care anyway. name it for what it's purpose is (keyshare_hint). > On Tue, Sep 24, 2024 at 7:07 PM David Benjamin > wrote: > >> Ah, I see. I don't think "supported" vs "preferred" captures this because >> "preferred" in the context of TLS usually isn't a binary property but a >> preference order. But I agree there is some ambiguity over what to list if >> you've got a couple different values. >> >> I think, other than potentially changing the name, it's not likely that >> this will have any impact on the presentation syntax. At the end of the >> day, we're going to want to send a list of things that your service (being >> intentionally vague about multiple server instances) supports. But since >> "supported" vs "preferred" is not the right descriptor, I suspect we won't >> do better than "supported" anyway. In particular... >> >> > 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. >> >> That's not right. 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. >> >> > 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.) >> >> Variations in server instances may indeed result in mispredictions. If >> the variation is due to a temporary rollout inconsistency, this variation >> is shortlived and will eventually sort itself out. During that period of >> inconsistency, neither list is more correct than the other because you want >> to make the correct prediction for each server. >> >> If the variation is persistent because you've intentionally deployed >> different instances of your service differently... first of all, don't do >> that. The security properties are not what you might. (An attacker can >> always direct the client to the weaker of the two.) If, despite the >> security flaws, you insist on doing this, I suppose you can use different >> HTTPS records for each and use all the machinery that HTTPS-RR already has >> here. That's all orthogonal to this draft because describing multiple >> routes to a single service is a general HTTPS-RR feature. >> >> > 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.) >> >> Could you elaborate on how a long list could result in a failure or add >> complexity? >> >> At the end of the day, all this does is influence what key shares the >> client predicts. No matter which group the client predicts, the client >> remains
