[TLS] Re: Consensus Call: early code point request for draft-ietf-tls-key-share-prediction
Hiya, On 9/25/24 00:07, 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 reckon I fully agree with the goal, but am concerned that the presentation syntax is what people will start from when deciding what to publish in the DNS. 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. Not precise != not right - but it's entirely fair you try force me to also be precise:-) I'll try below... 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. 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? 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. 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 obligated to send a ClientHello that accurate describes its preferences, and the server remains obligated to interpret it according to the rules of RFC 8446. That is all baseline requirements in implementing TLS 1.3 that this working group long decided on. If the result is that the client predicted well, great. We get better performance. If the result is that the client predicted badly, well, that's a shame but the
[TLS] Re: Consensus Call: early code point request for draft-ietf-tls-key-share-prediction
On Tue, Sep 24, 2024, at 16:11, 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. This is almost a distraction, but I think that this is more realistically a set of supported KEMs, even if (EC)DH isn't strictly a KEM in the strictest sense. ___ 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: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. Terrible name: Jacoby, as it tells the other partner what suit to offer. Sincerely, Watson -- Astra mortemque praestare gradatim ___ 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
Please let the list know by 8 October 2023 if you support this “early" > allocation. > I do. ___ 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
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. 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. On Tue, Sep 24, 2024 at 6:24 PM Stephen Farrell 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
[TLS] Re: Consensus Call: early code point request for draft-ietf-tls-key-share-prediction
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 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
[TLS] Re: DTLS DoS (Re: DTLS 1.3 ACKs near the version transition)
On Tue, Sep 24, 2024, at 09:35, David Benjamin wrote: > On Tue, Sep 24, 2024, 12:12 Martin Thomson wrote: >> No DTLS implementation should treat unauthenticated packets as being fatal. >> Though perhaps that could be true prior to completing the handshake, the >> reasons for dying should still be somewhat limited. > > This is unavoidable, no? Suppose I sent you an unauthenticated ACK, or > part of a ClientHello/ServerHello with the wrong contents. Or maybe I > made you think that the server sent HelloRetryRquest or a non-existent > message as the first message. You'll update your internal state > accordingly and fail to complete the handshake, e.g. because the > transcript is wrong or you thought a packet was received but it wasn't. I wasn't talking about something adversarial, but more accidental. I recognize that there will be some messages that will cause an endpoint to believe that they are talking to a valid implementation, but if the message you receive is of a completely new content type, why would that have an effect on the state machine. Maybe this isn't specified, so the result is that we get what we get, but it seems like a pretty brittle implementation if a random datagram causes the connection to be destroyed. (QUIC has some protection against an adversary who is unable to observe packets, but this is not a goal of DTLS.) ___ 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
Once negotiated, the record size limit applies to all records; it applies at the record layer. Handshake messages can span multiple records. On Mon, Sep 23, 2024 at 7:05 PM 崔久峰 wrote: > > After reading the Record Size Limit Extension for TLS RFC 8449, I found out > that record_size_limit has replaced max_fragment_length. For TLS1.2, it is > specified that max_fragment_length will be used for all messages (including > handshake messages), but it seems that I did not find in the text whether > record_steze_limit applies to all messages (including handshake messages, > such as Certificate messages) in TLS1.2. I hope you can help me solve this > problem. > > thanks. > > ___ 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
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] Re: Consensus Call: early code point request for draft-ietf-tls-key-share-prediction
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 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
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 obligated to send a ClientHello that accurate describes its preferences, and the server remains obligated to interpret it according to the rules of RFC 8446. That is all baseline requirements in implementing TLS 1.3 that this working group long decided on. If the result is that the client predicted well, great. We get better performance. If the result is that the client predicted badly, well, that's a shame but the server is already required to correctly send HelloRetryRequest. That is not added complexity or a failed connection because HelloRetryRequest is a required part of RFC 8446. Indeed Section 3.4 of the draft explicitly says that this cannot guarantee you won't get HRR. As in RFC 8446, you remain obligated to fully implement TLS 1.3, including HRR. No DNS-based design can get rid of HRR because DNS and service instances can always get out of sync. That has never been the goal here. All we can do is reduce the cases where it happens. > 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 think the right solution here is honestly to not worry about it too much. 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 some
[TLS] Re: Consensus Call: early code point request for draft-ietf-tls-key-share-prediction
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. :-) 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 obligated to send a ClientHello that accurate describes its > preferences, and the server remains obligated to interpret it according to > the rules of RFC 8446. That is all baseline requirements in implementing > TLS 1.3 that this working group long decided on. > > If the result is that the client predicted well, great. We get better > performance. If the result is that the client predicted badly, well, that's > a shame but the server is already required to correctly send > HelloRetryRequest. That is not added complexity or a failed connection > because HelloRetryRequest is a required part of RFC 8446. Indeed Section > 3.4 of the draft explicitly says that this cannot guarantee you won't get > HRR. As in RFC 8446, you remain obligated to fully implement TLS 1.3, > including HRR. > > No DNS-b
[TLS] Re: DTLS 1.3 ACKs near the version transition
I hate to add to the pile of issues, but we also have to figure out what to do with the outstanding DTLS 1.2 errata as some might still impact DTLS 1.2; see https://www.rfc-editor.org/errata_search.php?rfc=6347&rec_status=15&presentation=table spt > On Sep 23, 2024, at 20:06, Eric Rescorla wrote: > > Hi David, > > Thanks for digging in here. I haven't fully processed your comments, but it > does seem like we probably do need a -bis. Now that we've gotten 8446-bis and > ECH out the door, I don't think this is implausible. Do you feel like you are > getting close to a complete list of issues to be addressed there? > > -Ekr > > > > On Mon, Sep 23, 2024 at 3:44 PM David Benjamin wrote: > For my neck of the woods, DTLS matters for WebRTC. It really should be QUIC, > but alas it isn't and I suspect redesigning all of WebRTC now atop QUIC and > then fully completing the transition would take much longer than getting to > DTLS 1.3, much as the DTLS 1.3 specification needs a -bis document. :-) > > On Mon, Sep 23, 2024 at 6:10 PM Watson Ladd wrote: > Backing up a bit, at what point do we say QUIC Datagram is the right > way to do this? > > This whole adventure sounds like a mess. > > On Fri, Sep 20, 2024 at 8:20 AM David Benjamin wrote: > > > > (Resending since I don't see these two mails in the list archives, so I'm > > not sure if the list software broke again. Apologies if this is a duplicate > > mail!) > > > > On Thu, Sep 19, 2024 at 1:49 PM David Benjamin wrote: > >> > >> On Thu, Sep 19, 2024 at 1:31 PM David Benjamin wrote: > >>> > >>> Ah fun, another issue in this document. So not only are write epoch > >>> lifetimes unspecified and complex with 0-RTT, but read epoch lifetimes > >>> are specified but wrong. > >>> > >>> Section 4.2.1 says: > >>> > >>> > Because DTLS records could be reordered, a record from epoch M may be > >>> > received after epoch N (where N > M) has begun. Implementations SHOULD > >>> > discard records from earlier epochs but MAY choose to retain keying > >>> > material from previous epochs for up to the default MSL specified for > >>> > TCP [RFC0793] to allow for packet reordering. (Note that the intention > >>> > here is that implementers use the current guidance from the IETF for > >>> > MSL, as specified in [RFC0793] or successors, not that they attempt to > >>> > interrogate the MSL that the system TCP stack is using.) > >>> > >>> https://www.rfc-editor.org/rfc/rfc9147.html#section-4.2.1 > >>> > >>> First, it's a bit weird to say you SHOULD discard records but MAY retain > >>> keying material. I assume that meant SHOULD discard records but MAY > >>> process records anyway up to MSL. Anyway, this model implies that only > >>> one read epoch is active at once, but this isn't true. You basically have > >>> to read epoch 1 (early data) as unordered relative to epoches 0 and 2. > >>> Consider a DTLS 1.3 server: > >>> > >>> 1. The server reads ClientHello with early_data extension at epoch 0 and > >>> accepts early data. > >>> 2. The server sends ServerHello (epoch 0), EE..Finished (epoch 2), and > >>> activates write epoch 3 for half-RTT application data. > >>> 3. The server reads early data (epoch 1) from the client. The RFC would > >>> lead you to think the server can close read epoch 0 now, but... > >>> 4. ServerHello gets lost and, if we are to believe > >>> https://www.rfc-editor.org/rfc/rfc9147.html#section-7.1-8, the client > >>> might send an empty plaintext ACK to trigger a retransmit. This ACK will > >>> be at epoch 0. This only works if the server keeps read epoch 0 open! > >>> 5. Client eventually gets the ServerHello but now it only gets half of > >>> the epoch 2 data. It sends an ACK to trigger another retransmit. This ACK > >>> will come at epoch 2. > >>> 6. Server receives that ACK at epoch 2 and retransmits. The RFC would > >>> lead you to think the server can close read epoch 1 now, but... > >>> 7. Let's say that retransmit is lost again, or hasn't arrived yet. From > >>> the client's perspective, it has a connection that has yet to reach the > >>> 1-RTT point, so any data from the calling application will still be sent > >>> as early data. That means the client will continue to send early data at > >>> epoch 1. This only works if the server keeps read epoch 1 open! > >>> 8. The handshake progresses and the server finally gets 1-RTT data at > >>> epoch 3 from the client. Now the spirit of the rule in the text applies > >>> to epoch 1 and the server can close the epoch (after optionally waiting a > >>> spell for reordering) > >> > >> > >> Ah right, Nick Harper points out that servers really should close read > >> epoch 1 [up to a delay to accommodate reordering] as soon as they receive > >> the Finished message (epoch 2) and complete the handshake, not wait for an > >> epoch 3 record. (But it must specifically be on handshake completion, not > >> any epoch 2 record. Record-layer only logic cannot assume 1 < 2 beca
[TLS] I-D Action: draft-ietf-tls-extended-key-update-00.txt
Internet-Draft draft-ietf-tls-extended-key-update-00.txt is now available. It is a work item of the Transport Layer Security (TLS) WG of the IETF. Title: Extended Key Update for Transport Layer Security (TLS) 1.3 Authors: Hannes Tschofenig Michael Tüxen Tirumaleswar Reddy Steffen Fries Yaroslav Rosomakho Name:draft-ietf-tls-extended-key-update-00.txt Pages: 14 Dates: 2024-09-24 Abstract: The Transport Layer Security (TLS) 1.3 specification offers a dedicated message to update cryptographic keys during the lifetime of an ongoing session. The traffic secret and the initialization vector are updated directionally but the sender may trigger the recipient, via the request_update field, to transmit a key update message in the reverse direction. In environments where sessions are long-lived, such as industrial IoT or telecommunication networks, this key update alone is insufficient since forward secrecy is not offered via this mechanism. Earlier versions of TLS allowed the two peers to perform renegotiation, which is a handshake that establishes new cryptographic parameters for an existing session. When a security vulnerability with the renegotiation mechanism was discovered, RFC 5746 was developed as a fix. Renegotiation has, however, been removed from version 1.3 leaving a gap in the feature set of TLS. This specification defines an extended key update that supports forward secrecy. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-extended-key-update/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-tls-extended-key-update-00.html Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] DTLS DoS (Re: DTLS 1.3 ACKs near the version transition)
On Thu, Sep 12, 2024, at 13:31, David Benjamin wrote:
> 1. If a DTLS 1.2 (i.e. does not implement RFC 9147 at all)
> implementation receives an ACK record for whatever reason, what
> happens? This decision we don't get to change. Rather, it is a design
> constraint. Both OpenSSL and BoringSSL treat unexpected record types as
> a fatal error. I haven't checked other implementations. So I think we
> must take as a constraint that you cannot send an ACK unless you know
> the peer is 1.3-capable.
This is tangential, but I find this claim about {Open|Boring}SSL to be a bit
troubling, if true.
No DTLS implementation should treat unauthenticated packets as being fatal.
Though perhaps that could be true prior to completing the handshake, the
reasons for dying should still be somewhat limited.
___
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
> 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. Yes. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: I-D Action: draft-ietf-tls-dtls-rrc-12.txt
Hi! I asked Thomas to submit this version because the -11 version was going to expire on 3 October. We are waiting to send this I-D to our AD (Paul) until after it gets FATT review, but, we haven’t gotten the FATT “process” squared away just yet; see [0] about a virtual interim meeting to review the FATT process. This I-D is at the front of the line to get FATT review when we do. Cheers, spt [0] https://mailarchive.ietf.org/arch/msg/tls/76yqBw5rOLlByPtPGXU8YJl6xO4/ > On Sep 24, 2024, at 11:56, internet-dra...@ietf.org wrote: > > Internet-Draft draft-ietf-tls-dtls-rrc-12.txt is now available. It is a work > item of the Transport Layer Security (TLS) WG of the IETF. > > Title: Return Routability Check for DTLS 1.2 and DTLS 1.3 > Authors: Hannes Tschofenig >Achim Kraus >Thomas Fossati > Name:draft-ietf-tls-dtls-rrc-12.txt > Pages: 23 > Dates: 2024-09-24 > > Abstract: > > This document specifies a return routability check for use in context > of the Connection ID (CID) construct for the Datagram Transport Layer > Security (DTLS) protocol versions 1.2 and 1.3. > > Discussion Venues > > This note is to be removed before publishing as an RFC. > > Discussion of this document takes place on the Transport Layer > Security Working Group mailing list (tls@ietf.org), which is archived > at https://mailarchive.ietf.org/arch/browse/tls/. > > Source for this draft and an issue tracker can be found at > https://github.com/tlswg/dtls-rrc. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-rrc/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-tls-dtls-rrc-12.html > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-dtls-rrc-12 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > ___ > 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] Consensus Call: early code point request for draft-ietf-tls-key-share-prediction
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] I-D Action: draft-ietf-tls-dtls-rrc-12.txt
Internet-Draft draft-ietf-tls-dtls-rrc-12.txt is now available. It is a work item of the Transport Layer Security (TLS) WG of the IETF. Title: Return Routability Check for DTLS 1.2 and DTLS 1.3 Authors: Hannes Tschofenig Achim Kraus Thomas Fossati Name:draft-ietf-tls-dtls-rrc-12.txt Pages: 23 Dates: 2024-09-24 Abstract: This document specifies a return routability check for use in context of the Connection ID (CID) construct for the Datagram Transport Layer Security (DTLS) protocol versions 1.2 and 1.3. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the Transport Layer Security Working Group mailing list (tls@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/tls/. Source for this draft and an issue tracker can be found at https://github.com/tlswg/dtls-rrc. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-rrc/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-tls-dtls-rrc-12.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-dtls-rrc-12 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: DTLS DoS (Re: DTLS 1.3 ACKs near the version transition)
On Tue, Sep 24, 2024, 12:12 Martin Thomson wrote:
> On Thu, Sep 12, 2024, at 13:31, David Benjamin wrote:
> > 1. If a DTLS 1.2 (i.e. does not implement RFC 9147 at all)
> > implementation receives an ACK record for whatever reason, what
> > happens? This decision we don't get to change. Rather, it is a design
> > constraint. Both OpenSSL and BoringSSL treat unexpected record types as
> > a fatal error. I haven't checked other implementations. So I think we
> > must take as a constraint that you cannot send an ACK unless you know
> > the peer is 1.3-capable.
>
> This is tangential, but I find this claim about {Open|Boring}SSL to be a
> bit troubling, if true.
>
> No DTLS implementation should treat unauthenticated packets as being
> fatal. Though perhaps that could be true prior to completing the
> handshake, the reasons for dying should still be somewhat limited.
>
This is unavoidable, no? Suppose I sent you an unauthenticated ACK, or part
of a ClientHello/ServerHello with the wrong contents. Or maybe I made you
think that the server sent HelloRetryRquest or a non-existent message as
the first message. You'll update your internal state accordingly and fail
to complete the handshake, e.g. because the transcript is wrong or you
thought a packet was received but it wasn't.
If the attacker can manipulate the transport for a given connection, they
can cause the connection to fail. That's true in either TLS or DTLS. Of
course, if they can break the integrity or confidentiality of the
connection, that's a problem. Or if one connection can cause *another*
connection to fail by using disproportionate global resources. But things
we do in this working group can't really guarantee availability in the face
of the underlying transport not working at all.
David
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: DTLS DoS (Re: DTLS 1.3 ACKs near the version transition)
On Tue, Sep 24, 2024, 12:35 David Benjamin wrote:
> On Tue, Sep 24, 2024, 12:12 Martin Thomson wrote:
>
>> On Thu, Sep 12, 2024, at 13:31, David Benjamin wrote:
>> > 1. If a DTLS 1.2 (i.e. does not implement RFC 9147 at all)
>> > implementation receives an ACK record for whatever reason, what
>> > happens? This decision we don't get to change. Rather, it is a design
>> > constraint. Both OpenSSL and BoringSSL treat unexpected record types as
>> > a fatal error. I haven't checked other implementations. So I think we
>> > must take as a constraint that you cannot send an ACK unless you know
>> > the peer is 1.3-capable.
>>
>> This is tangential, but I find this claim about {Open|Boring}SSL to be a
>> bit troubling, if true.
>>
>> No DTLS implementation should treat unauthenticated packets as being
>> fatal. Though perhaps that could be true prior to completing the
>> handshake, the reasons for dying should still be somewhat limited.
>>
>
> This is unavoidable, no? Suppose I sent you an unauthenticated ACK, or
> part of a ClientHello/ServerHello with the wrong contents. Or maybe I made
> you think that the server sent HelloRetryRquest
>
Sorry I meant to say HelloVerifyRequest, since that is no longer allowed in
DTLS 1.3.
or a non-existent message as the first message. You'll update your internal
> state accordingly and fail to complete the handshake, e.g. because the
> transcript is wrong or you thought a packet was received but it wasn't.
>
> If the attacker can manipulate the transport for a given connection, they
> can cause the connection to fail. That's true in either TLS or DTLS. Of
> course, if they can break the integrity or confidentiality of the
> connection, that's a problem. Or if one connection can cause *another*
> connection to fail by using disproportionate global resources. But things
> we do in this working group can't really guarantee availability in the face
> of the underlying transport not working at all.
>
> David
>
>>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: DTLS 1.3 ACKs near the version transition
On Tue, Sep 24, 2024 at 8:33 AM Sean Turner wrote: > I hate to add to the pile of issues, but we also have to figure out what > to do with the outstanding DTLS 1.2 errata as some might still impact DTLS > 1.2; see > > https://www.rfc-editor.org/errata_search.php?rfc=6347&rec_status=15&presentation=table Ah yeah. Looking through them, I think none of them apply anymore: eid3917: Fixed in RFC 9147 eid4103: n/a to RFC 9147 eid5186: n/a to RFC 9147 eid4104: n/a to RFC 9147 (although we did mess something up around epoch overflow: https://mailarchive.ietf.org/arch/msg/tls/6y8wTv8Q_IPM-PCcbCAmDOYg6bM/) eid4105: n/a to RFC 9147 eid4642: n/a to RFC 9147 (can't find discussion of 1's complement anymore) eid5026: n/a to RFC 9147 (looks like we deleted that sentence) eid5903: n/a to RFC 9147 (looks like we deleted that sentence) eid8089: n/a to RFC 9147 (no HelloVerifyRequest in the first place) Looks like that matches what you concluded here: https://mailarchive.ietf.org/arch/msg/tls/_oYWTElq14ad83RygED2AiUI4ek/ > > On Sep 23, 2024, at 20:06, Eric Rescorla wrote: > > > > Hi David, > > > > Thanks for digging in here. I haven't fully processed your comments, but > it does seem like we probably do need a -bis. Now that we've gotten > 8446-bis and ECH out the door, I don't think this is implausible. Do you > feel like you are getting close to a complete list of issues to be > addressed there? > I mean, I don't think anyone can ever say they're done realizing things they hadn't thought of before. :-) But this was in the service of (my second round of) trying to absorb the handshake reassembly changes in the RFC in preparation for implementing this part of DTLS 1.3. I've now switched from staring at the spec to writing code, so that round is done. Of course, we'll realize something else in the course of writing code, I dunno. But I think there'll also be plenty of time in between now and the WGLC for the as-yet-nonexistent -bis document for that. > > > > -Ekr > > > > > > > > On Mon, Sep 23, 2024 at 3:44 PM David Benjamin > wrote: > > For my neck of the woods, DTLS matters for WebRTC. It really should be > QUIC, but alas it isn't and I suspect redesigning all of WebRTC now atop > QUIC and then fully completing the transition would take much longer than > getting to DTLS 1.3, much as the DTLS 1.3 specification needs a -bis > document. :-) > > > > On Mon, Sep 23, 2024 at 6:10 PM Watson Ladd > wrote: > > Backing up a bit, at what point do we say QUIC Datagram is the right > > way to do this? > > > > This whole adventure sounds like a mess. > > > > On Fri, Sep 20, 2024 at 8:20 AM David Benjamin > wrote: > > > > > > (Resending since I don't see these two mails in the list archives, so > I'm not sure if the list software broke again. Apologies if this is a > duplicate mail!) > > > > > > On Thu, Sep 19, 2024 at 1:49 PM David Benjamin > wrote: > > >> > > >> On Thu, Sep 19, 2024 at 1:31 PM David Benjamin > wrote: > > >>> > > >>> Ah fun, another issue in this document. So not only are write epoch > lifetimes unspecified and complex with 0-RTT, but read epoch lifetimes are > specified but wrong. > > >>> > > >>> Section 4.2.1 says: > > >>> > > >>> > Because DTLS records could be reordered, a record from epoch M may > be received after epoch N (where N > M) has begun. Implementations SHOULD > discard records from earlier epochs but MAY choose to retain keying > material from previous epochs for up to the default MSL specified for TCP > [RFC0793] to allow for packet reordering. (Note that the intention here is > that implementers use the current guidance from the IETF for MSL, as > specified in [RFC0793] or successors, not that they attempt to interrogate > the MSL that the system TCP stack is using.) > > >>> > > >>> https://www.rfc-editor.org/rfc/rfc9147.html#section-4.2.1 > > >>> > > >>> First, it's a bit weird to say you SHOULD discard records but MAY > retain keying material. I assume that meant SHOULD discard records but MAY > process records anyway up to MSL. Anyway, this model implies that only one > read epoch is active at once, but this isn't true. You basically have to > read epoch 1 (early data) as unordered relative to epoches 0 and 2. > Consider a DTLS 1.3 server: > > >>> > > >>> 1. The server reads ClientHello with early_data extension at epoch 0 > and accepts early data. > > >>> 2. The server sends ServerHello (epoch 0), EE..Finished (epoch 2), > and activates write epoch 3 for half-RTT application data. > > >>> 3. The server reads early data (epoch 1) from the client. The RFC > would lead you to think the server can close read epoch 0 now, but... > > >>> 4. ServerHello gets lost and, if we are to believe > https://www.rfc-editor.org/rfc/rfc9147.html#section-7.1-8, the client > might send an empty plaintext ACK to trigger a retransmit. This ACK will be > at epoch 0. This only works if the server keeps read epoch 0 open! > > >>> 5. Client eventually gets the ServerHello but now it only gets half > of the e
[TLS] Re: DTLS DoS (Re: DTLS 1.3 ACKs near the version transition)
On Tue, Sep 24, 2024, 13:03 Martin Thomson wrote: > > > On Tue, Sep 24, 2024, at 09:35, David Benjamin wrote: > > On Tue, Sep 24, 2024, 12:12 Martin Thomson wrote: > >> No DTLS implementation should treat unauthenticated packets as being > fatal. Though perhaps that could be true prior to completing the > handshake, the reasons for dying should still be somewhat limited. > > > > This is unavoidable, no? Suppose I sent you an unauthenticated ACK, or > > part of a ClientHello/ServerHello with the wrong contents. Or maybe I > > made you think that the server sent HelloRetryRquest or a non-existent > > message as the first message. You'll update your internal state > > accordingly and fail to complete the handshake, e.g. because the > > transcript is wrong or you thought a packet was received but it wasn't. > > I wasn't talking about something adversarial, but more accidental. I > recognize that there will be some messages that will cause an endpoint to > believe that they are talking to a valid implementation, but if the message > you receive is of a completely new content type, why would that have an > effect on the state machine. Maybe this isn't specified, so the result is > that we get what we get, but it seems like a pretty brittle implementation > if a random datagram causes the connection to be destroyed. > > (QUIC has some protection against an adversary who is unable to observe > packets, but this is not a goal of DTLS.) > Sure. I don't have any feelings about dropping vs erroring on unexpected content types. (On our end, this behavior was just carried over from OpenSSL and we never had any particular cares to change it either way.) But this behavior isn't related to DoS or packet authentication because one can already unavoidably do much more with the ability to inject unauthenticated packets. Once we're taking about *accidentally* getting garbage packets in, authentication is just a fancy checksum. Though I don't think believing it talking to a valid implementation is quite the right characterization. If there isn't a valid implementation on the other side, it can't matter if you fail on the record because there's no one to handshake with anyway! Failing on the record is only a concern if there *is* a valid peer, but somehow you processed a packet thinking it was from the peer's DTLS code, but it wasn't. If that packet was injected maliciously, it can easily interfere with your connection to the peer at the plaintext stage of the connection, content type rejection or no. If it was injected accidentally, well, I guess now we need to reason about the probability distribution of accidents and whether it's likely to have a valid plaintext header (version and length prefix) but wrong content type. Given the 1.3 record header dispatch, it's probably natural now to just toss the record, but I don't think it's a huge deal either way. David > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
