[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support
> On Nov 5, 2024, at 16:25, Sean Turner wrote: > > REQUEST: Let’s not rehash all the context. It is provided for those who > might not remember or those that were not around for the duration. > > CONTEXT: Way back in 2016 after the WG had embarked on developing TLS 1.3, > Peter Gutmann suggested that another way to “fix” TLS was to specify a > version of TLS that indicates a “known-good config drawn from the maybe 10 > extension-RFCs”; see [0]. Peter submitted his “TLS 1.2 Update for Long-term > Support”; see [1]. There was some list discussion; see [2]. Peter asked us > about adopting the I-D; see [3]. He made changes based on that feedback; see > [4]. At IETF 98, the WG discussed adopting this I-D and the sense of the room > was to not adopt the I-D; see [5]. Progress on this document was paused while > the WG worked on TLS 1.3. Once RFC 8447 was published, a code point was > assigned for the “tls-lts” extensions; see [6] and [7]. Now that we are > looking to publish Feature Freeze for TLS 1.2 [8][9] we want to make sure > that the working group sentiment has not changed over time so we are running > an adoption call for TLS-LTS. > > MESSAGE: This message is to judge consensus on whether there is support to > adopt TLS 1.2 Update for Long-term Support; see [1]. If you support adoption > and are willing to review and contribute text, please send a message to the > list. If you do not support adoption of this draft, please send a message to > the list and indicate why. This call will close on November X, 2024. Whoops November 26, 2024. > Thanks, > spt > > [0] https://mailarchive.ietf.org/arch/msg/tls/Lr7VwcPCjzDJelUTRTIUJf_8-ww/ > [1] https://datatracker.ietf.org/doc/draft-gutmann-tls-lts/ > [2] https://mailarchive.ietf.org/arch/msg/tls/r4w75rooy-r8Ky-xXAUoslYTL_U/ > [3] https://mailarchive.ietf.org/arch/msg/tls/6tBftKBmxYz_wUcq79_zH8yDTQk/ > [4] https://mailarchive.ietf.org/arch/msg/tls/aw9BOS4HJ9uum0snEZqSuKA4BYw/ > [5] https://datatracker.ietf.org/meeting/98/materials/minutes-98-tls-00 > [6] > https://mailarchive.ietf.org/arch/msg/tls-reg-review/bP84S3tHSG9gAmc45CLTjpiA0z8/ > [7] https://mailarchive.ietf.org/arch/msg/tls/xmhnVQTckDmUkoxhx4wx1bfpYXM/ > Thanks to Peter because he helped us iron out the > wrinkles in the tls-reg-review process. > [8] https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/ > [9] https://mailarchive.ietf.org/arch/msg/tls/f62yvLL_4mDEsRzAY46L4QLjakU/ ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Adoption call for TLS 1.2 Update for Long-term Support
REQUEST: Let’s not rehash all the context. It is provided for those who might not remember or those that were not around for the duration. CONTEXT: Way back in 2016 after the WG had embarked on developing TLS 1.3, Peter Gutmann suggested that another way to “fix” TLS was to specify a version of TLS that indicates a “known-good config drawn from the maybe 10 extension-RFCs”; see [0]. Peter submitted his “TLS 1.2 Update for Long-term Support”; see [1]. There was some list discussion; see [2]. Peter asked us about adopting the I-D; see [3]. He made changes based on that feedback; see [4]. At IETF 98, the WG discussed adopting this I-D and the sense of the room was to not adopt the I-D; see [5]. Progress on this document was paused while the WG worked on TLS 1.3. Once RFC 8447 was published, a code point was assigned for the “tls-lts” extensions; see [6] and [7]. Now that we are looking to publish Feature Freeze for TLS 1.2 [8][9] we want to make sure that the working group sentiment has not changed over time so we are running an adoption call for TLS-LTS. MESSAGE: This message is to judge consensus on whether there is support to adopt TLS 1.2 Update for Long-term Support; see [1]. If you support adoption and are willing to review and contribute text, please send a message to the list. If you do not support adoption of this draft, please send a message to the list and indicate why. This call will close on November X, 2024. Thanks, spt [0] https://mailarchive.ietf.org/arch/msg/tls/Lr7VwcPCjzDJelUTRTIUJf_8-ww/ [1] https://datatracker.ietf.org/doc/draft-gutmann-tls-lts/ [2] https://mailarchive.ietf.org/arch/msg/tls/r4w75rooy-r8Ky-xXAUoslYTL_U/ [3] https://mailarchive.ietf.org/arch/msg/tls/6tBftKBmxYz_wUcq79_zH8yDTQk/ [4] https://mailarchive.ietf.org/arch/msg/tls/aw9BOS4HJ9uum0snEZqSuKA4BYw/ [5] https://datatracker.ietf.org/meeting/98/materials/minutes-98-tls-00 [6] https://mailarchive.ietf.org/arch/msg/tls-reg-review/bP84S3tHSG9gAmc45CLTjpiA0z8/ [7] https://mailarchive.ietf.org/arch/msg/tls/xmhnVQTckDmUkoxhx4wx1bfpYXM/ Thanks to Peter because he helped us iron out the wrinkles in the tls-reg-review process. [8] https://datatracker.ietf.org/doc/draft-ietf-tls-tls12-frozen/ [9] https://mailarchive.ietf.org/arch/msg/tls/f62yvLL_4mDEsRzAY46L4QLjakU/ ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Changing WG Mail List Reputation
> On Nov 4, 2024, at 15:35, Joseph Salowey wrote: > > On Mon, Nov 4, 2024 at 10:48 AM Salz, Rich wrote: > > While there is overlap between professional behavior and the perceived > > focus on browser specific use cases; I think we should try to separate out > > the topic. > > My memory, perhaps faulty, is that "will browsers implement this" has been a > process-gating question in the past. Recognizing that not everything the WG > will do is useful or applicable to all participants is, I think, a useful > reminder for, well, all participants. Not faulty, I definitely asked this at the end of the TLS 1.3 development, because we really wanted to make sure we got buy in. It may have happened other times too, but I don’t remember it happening recently. We should be saying "who will implement." > Yes. I think we can do that as a separate reminder I tend to agree and I would like to propose that we update the FAQ and then send a separate reminder to list about the FAQ. More reminders, I think, can’t hurt. spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Adoption call for Large Record Sizes for TLS and DTLS
Hi! This is just another reminder that this WG adoption call is still ongoing. spt > On Oct 25, 2024, at 03:46, Sean Turner wrote: > > At the TLS meeting at IETF 119 we discussed the Large Record Sizes for TLS > and DTLS I-D; see [0] and [1]. There has been some list discussion; see [2] > and [3]. The I-D has been revised a few times since IETF 119 to incorporate > list feedback. This message is to judge consensus on whether there is support > to adopt this I-D. If you support adoption and are willing to review and > contribute text, please send a message to the list. If you do not support > adoption of this draft, please send a message to the list and indicate why. > This call will close on November 7, 2024. > > Thanks, > Deirdre, Joe, and Sean > > [0] > https://datatracker.ietf.org/doc/draft-mattsson-tls-super-jumbo-record-limit/ > [1] > https://datatracker.ietf.org/meeting/119/materials/slides-119-tls-large-record-sizes-for-tls-and-dtls-00 > > [2] https://mailarchive.ietf.org/arch/msg/tls/ZnGzqIWOkpm_F6zaqAxxtReHpVg/ > [3] https://mailarchive.ietf.org/arch/msg/tls/cRH9x6nbLeAnkG-fhOS3ASDA3oU/ ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: I-D Action: draft-ietf-tls-rfc8447bis-10.txt
Joe: Thanks for getting this posted. TLS WG: This version address the comments we got (Rich was the only one). It is ready to go to the AD. spt > On Nov 3, 2024, at 22:26, internet-dra...@ietf.org wrote: > > Internet-Draft draft-ietf-tls-rfc8447bis-10.txt is now available. It is a work > item of the Transport Layer Security (TLS) WG of the IETF. > > Title: IANA Registry Updates for TLS and DTLS > Authors: Joe Salowey >Sean Turner > Name:draft-ietf-tls-rfc8447bis-10.txt > Pages: 18 > Dates: 2024-11-03 > > Abstract: > > This document updates the changes to TLS and DTLS IANA registries > made in RFC 8447. It adds a new value "D" for discouraged to the > recommended column of the selected TLS registries and adds a > "Comments" column to all active registries. > > This document updates the following RFCs: 3749, 5077, 4680, 5246, > 5705, 5878, 6520, 7301, and 8447. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-10.html > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-rfc8447bis-10 > > 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] Re: Adoption call for Large Record Sizes for TLS and DTLS
Just a reminder that this adoption call is still on going. spt > On Oct 24, 2024, at 22:46, Sean Turner wrote: > > At the TLS meeting at IETF 119 we discussed the Large Record Sizes for TLS > and DTLS I-D; see [0] and [1]. There has been some list discussion; see [2] > and [3]. The I-D has been revised a few times since IETF 119 to incorporate > list feedback. This message is to judge consensus on whether there is support > to adopt this I-D. If you support adoption and are willing to review and > contribute text, please send a message to the list. If you do not support > adoption of this draft, please send a message to the list and indicate why. > This call will close on November 7, 2024. > > Thanks, > Deirdre, Joe, and Sean > > [0] > https://datatracker.ietf.org/doc/draft-mattsson-tls-super-jumbo-record-limit/ > [1] > https://datatracker.ietf.org/meeting/119/materials/slides-119-tls-large-record-sizes-for-tls-and-dtls-00 > > [2] https://mailarchive.ietf.org/arch/msg/tls/ZnGzqIWOkpm_F6zaqAxxtReHpVg/ > [3] https://mailarchive.ietf.org/arch/msg/tls/cRH9x6nbLeAnkG-fhOS3ASDA3oU/ ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: WG Last Call for draft-ietf-tls-rfc8447bis, "IANA Registry Updates for TLS and DTLS”
Thanks Rich. These all look good to me. spt > On Oct 16, 2024, at 15:23, Salz, Rich > wrote: > > This email starts the working group last call for "IANA Registry Updates for > TLS and DTLS” I-D, located here: > > I found a few nits. Diff at https://github.com/tlswg/rfc8447bis/pull/58/files > > ___ > 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-tlsflags
> On Oct 25, 2024, at 10:52, Salz, Rich wrote: > > I mean "IANA cannot have designated..." > > I blame auto-correct. Or outlook. Anyone other than me. > > On 10/25/24, 10:50 AM, "Salz, Rich" wrote: > >> The following PR creates the TLS Flags sub-registry where we can manage the >> actual flags. I asserted that the chairs control adding values, which won’t >> be true once (and if) the registry goes to IANA (it’ll be the DEs: Rich, >> Nick, and Yoav), and populated the 1st value from the draft: >> resumption_across_names. Assuming this is good, I will merge the PR. > > > Apparently IANA can have designated experts control things until the RFC is > published. Oh, if DEs can (or are willing) to do it then I am all about having you manage it! PR updated: https://github.com/tlswg/wg-materials/pull/22/files > Does this mean we'll need a new RFC to switch things? Or can it be done by > IESG telling IANA? If the latter, than maybe we do a little dance to say IESG > designated control to the TLS WG Chairs and then IESG designates control to > the regular TLS designated experts? But if the proposal you're saying works, > great. I'm just interested in trying to avoid administrivia while we wait to > get this new sub-registry into our hot little hands :) My thinking is that the repo is just going to get PRed to just refer to the IANA sub-registry when it is created ;) spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Changing WG Mail List Reputation
Hello list, The TLS list is infamous in that it is regarded by some as [insert your descriptive word; where the chairs have heard the following words used: noxious, toxic, unwelcoming, and rude]. The chairs want to change this reputation and we hope you do too. A big part of this is on the chairs to be be more proactive about moderating behavior that goes against IETF WG procedures, code of conduct, etc. The chairs are also going to send a monthly reminder, which is included below, that will serve to remind everyone from those who joined just today to those who joined many, many years ago of the policies and procedures that apply to IETF mailing lists. Monthly email reminder follows: --- Hello list, As a regular reminder, this list is governed by IETF’s Working Group Procedures [BCP25], which also includes Anti-Harassment Procedures, and by participating you agree to the Note Well [NW] and to follow the Code of Conduct [CoC]. Thank you for contributing as part of the TLS Working Group. As moderators of this list, the chairs are charged with determining when messages are “disruptive to the WG process”, phrase from RFC 3934, and, at a minimum, the chairs consider the following to be disruptive: • Unsolicited bulk e-mail (from RFC 3683) • Discussion of subjects unrelated to IETF policy, meetings, activities, or technical concerns (from RFC 3683) • Unprofessional commentary, regardless of the general subject (from RFC 3683) • Repetition of arguments without providing substantive new information • Requesting an unreasonable amount of work to provide information To elaborate on unprofessional commentary, the chairs believe that this also includes uncivil commentary as defined by the IETF List Moderators that includes threats of violence, personal attacks, and derogatory language; see [Language]. RFC 3683 also includes “announcements of conferences, events, or activities that are not sponsored or endorsed by the Internet Society or the IETF”. Please contact the chairs if you wish to share these types of announcements, but in general the chairs do not believe they are disruptive unless they are excessive and lack relevance. Reminder that if at anytime you feel that if somebody is out of line you can say so on list or directly to us (mailto:tls-cha...@ietf.org), the ADs (mailto:sec-...@ietf.org), or the Ombudsteam (mailto:ombudst...@ietf.org). --- Obviously, if we receive significant feedback about any of the above, we can revisit the message. Even though there are three of us, we are still not always immediately available to respond and because of that we would like your help in keeping the tone of the list professional and civil. Remember that if somebody else is behaving badly please refrain from reciprocating. Cheers, The Chairs [BCP25] https://datatracker.ietf.org/doc/bcp25/ [NW] https://www.ietf.org/about/note-well/ [CoC] https://datatracker.ietf.org/doc/bcp54/ [Language] https://github.com/ietf/Moderators/blob/main/uncivil-commentary.md#descriptions ___ 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-tlsflags
Hi! The chairs have judged that there is consensus to request an early code point for this draft-ietf-tls-tlsflags. I will send a message to the DEs and IANA to get this code point assigned. The following PR creates the TLS Flags sub-registry where we can manage the actual flags. I asserted that the chairs control adding values, which won’t be true once (and if) the registry goes to IANA (it’ll be the DEs: Rich, Nick, and Yoav), and populated the 1st value from the draft: resumption_across_names. Assuming this is good, I will merge the PR. spt > On Sep 27, 2024, at 15:00, Sean Turner wrote: > > Hi! We paused progression of draft-ietf-tls-tlsflags until we had > implementations. We (the chairs) have gotten requests for an early IANA code > point; if you remember draft-ietf-tls-cross-sni-resumption, a WG I-D that is > now expired, and draft-jhoyla-req-mtls-flag, a individual I-D, would both > need this code point. Note that like draft-ietf-tls-dtls-rrc, > draft-ietf-tls-tlsflags also creates a new sub-registry, but IANA cannot > create a temporary registry and then manage it for us. We will do that in the > WG/I-D; there is not much to manage because at this point it’s only two > values. With that said …. > > We (the Chairs) would like to determine whether there is consensus to request > an early code point request for "tls_flags” in the TLS ExtensionType Values > registry registry; see Section 4 of the I-D [0]. The point of this consensus > call is to determine whether you think this I-D is stable enough to request a > code point from the DEs. Please let the list know by 11 October 2024 if you > support this request. > > Cheers, > spt > (as TLS Co-Chair) > > [0] https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Adoption call for Large Record Sizes for TLS and DTLS
At the TLS meeting at IETF 119 we discussed the Large Record Sizes for TLS and DTLS I-D; see [0] and [1]. There has been some list discussion; see [2] and [3]. The I-D has been revised a few times since IETF 119 to incorporate list feedback. This message is to judge consensus on whether there is support to adopt this I-D. If you support adoption and are willing to review and contribute text, please send a message to the list. If you do not support adoption of this draft, please send a message to the list and indicate why. This call will close on November 7, 2024. Thanks, Deirdre, Joe, and Sean [0] https://datatracker.ietf.org/doc/draft-mattsson-tls-super-jumbo-record-limit/ [1] https://datatracker.ietf.org/meeting/119/materials/slides-119-tls-large-record-sizes-for-tls-and-dtls-00 [2] https://mailarchive.ietf.org/arch/msg/tls/ZnGzqIWOkpm_F6zaqAxxtReHpVg/ [3] https://mailarchive.ietf.org/arch/msg/tls/cRH9x6nbLeAnkG-fhOS3ASDA3oU/ ___ 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
Hi! The chairs have judged that there is consensus to request an early code point for this I-D. While there was some discussion about what the Name value should be, there was no consensus on a new Name value and it is not clear that choosing a different name from where the values comes from is of benefit. spt > On Sep 24, 2024, at 14: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] Re: TLS WG Interim summary (was Re: TLS WG Virtual Interim on FATT Process)
Whoops - Corrected! spt > On Oct 17, 2024, at 17:14, Russ Housley wrote: > > The minutes have not been posted to that page yet. > > Russ > >> On Oct 17, 2024, at 2:24 PM, Sean Turner wrote: >> >> Hi! We had a quick (45min) interim to discuss the FATT Process. Slides & >> minutes for (and eventually a recording of) the session can be found here: >> https://datatracker.ietf.org/meeting/interim-2024-tls-02/session/tls >> >> The summary is that the process described in the slides is basically the >> right shape. We obviously have to address how we get formal security >> analysis if one is requested but the authors do not have the expertise to >> provide one. >> >> Also, draft-ietf-tls-8773bis is mid-process and needs a FATT Liaison so the >> chairs are going to work to get one. >> >> Cheers, >> spt >> >>> On Oct 1, 2024, at 20:15, Sean Turner wrote: >>> >>> Thanks to all those who participated in the poll. Unfortunately, we >>> couldn’t schedule a time where everybody could attend. The following time >>> slot had the most people: >>> >>>> Begin forwarded message: >>>> >>>> From: IETF Meeting Session Request Tool >>>> Subject: interim-2024-tls-02 interim approved >>>> Date: October 1, 2024 at 20:09:13 EDT >>>> To: , >>>> >>>> >>>> An interim meeting for tls has been approved or does not require >>>> additional approval. >>>> A message has been sent to the secretariat requesting the interim be >>>> announced. >>>> >>>> >>>> - >>>> Working Group Name: Transport Layer Security >>>> Area Name: Security Area >>>> Session Requester: Sean Turner >>>> >>>> Meeting Type: Virtual Meeting >>>> >>>> Session 1: >>>> >>>> Date: 2024-10-16 >>>> Start Time: 14:00 America/New_York >>>> Duration: 02:00 >>>> Remote Participation Information: >>>> https://meetings.conf.meetecho.com/interim/?group=7627d881-2175-4086-899f-657548e64b52 >>>> Agenda Note: >>>> >>>> ———— >>> >>> I will make sure to send reminders out prior to meeting. We will also >>> record this session. And, we plan to have “the plan” out in advance (like a >>> week) so that those that can’t make it in person can provide comments. >>> >>> Cheers, >>> spt >>> >>>> On Sep 23, 2024, at 16:53, Sean Turner wrote: >>>> >>>> Hi! Thanks to all those who have already filled out the poll. I am hoping >>>> to close this out by Friday so I will send daily reminders until then. >>>> >>>> Cheers, >>>> spt >>>> >>>>> On Sep 23, 2024, at 12:05, Sean Turner wrote: >>>>> >>>>> The chairs would like to have an interim to review the FATT (Formal >>>>> Analysis Triage Team) process. We are still working out the proposal, but >>>>> we would like to get this meeting scheduled to review any feedback / >>>>> comments once we do post the process. Please fill out the following with >>>>> your available times if you are interested in attending: >>>>> >>>>> https://doodle.com/meeting/participate/id/aMoXAp1d >>>>> >>>>> Thanks, >>>>> Deirdre, Joe, & Sean >>>> >>> >> >> ___ >> 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: AD review draft-ietf-tls-rfc8446bis-11
> On Oct 17, 2024, at 15:29, Paul Wouters > wrote: > > RFC8996 seems to be a broken reference ? Might be a tooling issue but it is > already broken in the xml file on the datatracker. I’ll check on this. https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8996.xml seems to just hang. spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] TLS WG Interim summary (was Re: TLS WG Virtual Interim on FATT Process)
Hi! We had a quick (45min) interim to discuss the FATT Process. Slides & minutes for (and eventually a recording of) the session can be found here: https://datatracker.ietf.org/meeting/interim-2024-tls-02/session/tls The summary is that the process described in the slides is basically the right shape. We obviously have to address how we get formal security analysis if one is requested but the authors do not have the expertise to provide one. Also, draft-ietf-tls-8773bis is mid-process and needs a FATT Liaison so the chairs are going to work to get one. Cheers, spt > On Oct 1, 2024, at 20:15, Sean Turner wrote: > > Thanks to all those who participated in the poll. Unfortunately, we couldn’t > schedule a time where everybody could attend. The following time slot had the > most people: > >> Begin forwarded message: >> >> From: IETF Meeting Session Request Tool >> Subject: interim-2024-tls-02 interim approved >> Date: October 1, 2024 at 20:09:13 EDT >> To: , >> >> >> An interim meeting for tls has been approved or does not require additional >> approval. >> A message has been sent to the secretariat requesting the interim be >> announced. >> >> >> ----- >> Working Group Name: Transport Layer Security >> Area Name: Security Area >> Session Requester: Sean Turner >> >> Meeting Type: Virtual Meeting >> >> Session 1: >> >> Date: 2024-10-16 >> Start Time: 14:00 America/New_York >> Duration: 02:00 >> Remote Participation Information: >> https://meetings.conf.meetecho.com/interim/?group=7627d881-2175-4086-899f-657548e64b52 >> Agenda Note: >> >> > > I will make sure to send reminders out prior to meeting. We will also record > this session. And, we plan to have “the plan” out in advance (like a week) so > that those that can’t make it in person can provide comments. > > Cheers, > spt > >> On Sep 23, 2024, at 16:53, Sean Turner wrote: >> >> Hi! Thanks to all those who have already filled out the poll. I am hoping to >> close this out by Friday so I will send daily reminders until then. >> >> Cheers, >> spt >> >>> On Sep 23, 2024, at 12:05, Sean Turner wrote: >>> >>> The chairs would like to have an interim to review the FATT (Formal >>> Analysis Triage Team) process. We are still working out the proposal, but >>> we would like to get this meeting scheduled to review any feedback / >>> comments once we do post the process. Please fill out the following with >>> your available times if you are interested in attending: >>> >>> https://doodle.com/meeting/participate/id/aMoXAp1d >>> >>> Thanks, >>> Deirdre, Joe, & Sean >> > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] TLS WG Interim (Trust Tussle) summary (was Re: interim-2024-tls-01 interim approved)
Hi! We had a fairly well attended virtual interim on 1 October; 40 attendees to be exact. Slides and minutes for and a recording of the interim can be found here: https://datatracker.ietf.org/meeting/interim-2024-tls-01/session/tls My purposely brief summary is that we did a pretty good job of sticking to the intended agenda, which was focusing on the problem statement. We did two polls that both resulted in consensus for "Yes"; the polls follow: 1. Do you understand the problem we are trying to solve (see screen)? Where the screen was from Chris’ Trust Tussle slides (18 of 19): Avoid client trust conflicts by enabling servers to reliably and efficiently support clients with diverse trust anchor lists, particularly in larger PKIs where the existing certificate_authorities extension is not viable. 2. Do you think we should work on this problem? We are now at the point where those that are interested in pursuing this work can submit an I-D for WG consideration. The working group can then evaluate the I-D against the problem statement and other criteria. If there is sufficient interest the chairs will run a call for adoption. Thanks to all those who participated. And, a special shout out to Chris Wood for volunteering kick session off! spt > On Sep 27, 2024, at 19:35, Sean Turner wrote: > > To add a little more context about the interim ... > > We are taking a step back to focus on the problem statement/space. As you > can see from the agenda items, we are going to tease out whether we can agree > on a problem statement and then wether we should try to solve that problem. > As a result, I retitled the topic in the agenda to be “Trust Tussle” to > better reflect what we are actually going to discuss. Feel free to read the > I-Ds we discussed at IETF 120, draft-davidben-tls-trust-expr and > draft-beck-tls-trust-anchor-ids, for background but we are not planning on > discussing the I-Ds specifically. > > Cheers, > spt > >> On Sep 27, 2024, at 13:37, Sean Turner wrote: >> >> HI! Just another reminder that we have an interim scheduled for Oct 1st @ >> 9am Pacific time. I have uploaded the agenda:* >> https://datatracker.ietf.org/doc/agenda-interim-2024-tls-01-tls-01/ >> Here is a link to the remote meeting instructions (it’s MeetEcho): >> https://meetings.conf.meetecho.com/interim/?group=f3d0d4f9-2480-4bdc-8a2d-4765d8aedd73 >> >> See you then! >> >> spt >> >> * Thanks Chris! >> >>> On Sep 17, 2024, at 12:18, Sean Turner wrote: >>> >>> Hi! Another reminder that we have a virtual interim scheduled for >>> 2024-10-01 @ 9am Pacific time. We are still working out the details but >>> the topic is Trust Expressions / Trust Anchor Transition. >>> >>> Cheers, >>> spt >>> >>>> On Sep 10, 2024, at 13:33, Sean Turner wrote: >>>> >>>> Hi! We have scheduled a virtual interim to discuss Trust Expressions / >>>> Trust Anchors Transition. We are in the process of defining some ground >>>> rules for the meeting as well as setting some expected outcomes, but we >>>> wanted to get the interim on the calendar. >>>> >>>> Cheers, >>>> spt >>>> >>>>> On Sep 10, 2024, at 13:31, IETF Meeting Session Request Tool >>>>> wrote: >>>>> >>>>> >>>>> An interim meeting for tls has been approved or does not require >>>>> additional approval. >>>>> A message has been sent to the secretariat requesting the interim be >>>>> announced. >>>>> >>>>> >>>>> - >>>>> Working Group Name: Transport Layer Security >>>>> Area Name: Security Area >>>>> Session Requester: Sean Turner >>>>> >>>>> Meeting Type: Virtual Meeting >>>>> >>>>> Session 1: >>>>> >>>>> Date: 2024-10-01 >>>>> Start Time: 12:00 America/New_York >>>>> Duration: 03:00 >>>>> Remote Participation Information: >>>>> https://meetings.conf.meetecho.com/interim/?group=f3d0d4f9-2480-4bdc-8a2d-4765d8aedd73 >>>>> Agenda Note: >>>>> >>>>> - >>>>> >>>> >>> >> > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: [Errata Rejected] RFC8446 (6136)
Paul, Technically we did address this: https://github.com/tlswg/tls13-spec/pull/1364/files spt > On Oct 17, 2024, at 13:22, RFC Errata System > wrote: > > The following errata report has been rejected for RFC8446, > "The Transport Layer Security (TLS) Protocol Version 1.3". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6136 > > -- > Status: Rejected > Type: Technical > > Reported by: Ben Smyth > Date Reported: 2020-04-28 > Rejected by: Paul Wouters (IESG) > > Section: 4.1.4 > > Original Text > - > Upon receipt of a HelloRetryRequest, the client MUST check the > legacy_version, legacy_session_id_echo, cipher_suite, and > legacy_compression_method as specified in Section 4.1.3 > > Corrected Text > -- > > > Notes > - > Section 4.1.3 defines no checks for legacy_version nor > legacy_compression_method > --VERIFIER NOTES-- > It does have the listed fields and values it should contain (to check) in > the previous 4.1.3 section. > > -- > RFC8446 (draft-ietf-tls-tls13-28) > -- > Title : The Transport Layer Security (TLS) Protocol Version 1.3 > Publication Date: August 2018 > Author(s) : E. Rescorla > Category: PROPOSED STANDARD > Source : Transport Layer Security > Stream : IETF > Verifying Party : IESG > > ___ > 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: Publication has been requested for draft-ietf-tls-rfc8446bis-11
Hi! With -rfc8447bis in WGLC, it’s time to get this I-D moving along the standardization path. Cheers, spt > On Oct 16, 2024, at 22:59, Sean Turner via Datatracker > wrote: > > Sean Turner has requested publication of draft-ietf-tls-rfc8446bis-11 as > Proposed Standard on behalf of the TLS working group. > > Please verify the document's state at > https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis/ > > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Publication has been requested for draft-ietf-tls-rfc8446bis-11
Sean Turner has requested publication of draft-ietf-tls-rfc8446bis-11 as Proposed Standard on behalf of the TLS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis/ ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: [DNSOP] Re: Re: Re: Re: AD review draft-ietf-tls-svcb-ech
Authors (Ben, Mike, and Eric), Thank for the PR with some examples: https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/18 Once you’ve settled the debate (hopefully before Monday), please go ahead and merge so that Paul can get the IETF LC started. Cheers, spot > On Oct 9, 2024, at 09:38, Sean Turner wrote: > > Authors (Ben, Mike, and Eric), > > It looks like we haves some agreement here. There’s some agreement that the > PR [1] addresses the concern and there’s some agreement to agree to disagree > on other points. Please go ahead and merge the PR [1]. > > spt > > [1] https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/16 > >> On Oct 8, 2024, at 21:38, Eric Rescorla wrote: >> >> I agree that you can't trust a resolver that you only know about from ADD. >> >> -Ekr >> >> >> On Tue, Oct 8, 2024 at 8:31 AM Paul Wouters wrote: >> I agree with your points. Our only difference of opinion seems to be about >> how much one should trust a TRR. >> I still prefer to need to trust them the least possible, meaning I would >> want DNSSEC validation to at least >> detect tampering at the TRR. With more ECH deployed, and less visibility of >> SNI, there will be increase >> pressure on TRRs to do so. >> >> But this discussion is not really in scope for the ECH SVCB draft, other >> than that I am concerned about the >> illusion of ECH privacy being lost because of a "trusted by the network via >> ADD" resolver being used. >> >> Paul >> >> On Mon, Oct 7, 2024 at 9:36 PM Eric Rescorla wrote: >> Paul, >> >> I don't understand your threat model here. >> >> 1. As already noted upthread, ECH inherently leaks the name you are >> resolving to the resolver. This leak doesn't depend on the resolver >> tampering with the response, so DNSSEC verification on the client >> doesn't help here [0]. >> >> 2. If the client accepts the network resolver, as opposed to requiring >> a TRR, then a malicious network will always be able to force the user >> into leaking their browsing history on that network. Thus, as you >> say, if you want ECH to guarantee privacy you need to use encrypted >> transport to a TRR. >> >> 3. As Ben observed, if the client caches the response from the >> recursive, then an ECH record from malicious resolver A (e.g., in the >> airport) might allow A to continue to learn the SNI even when you are >> using non-malicious resolver B (e.g., at your house). But the only >> way to get into this hole is to use the network provided (potentially >> malicious) resolver. >> >> 4. The specific attack in (3) can be prevented if the client only >> cached ECH records when they were DNSSEC signed, but this still >> leaves you leaking to the malicious network's resolver whenever >> you try to retrieve an uncached value, so it's much better to >> just insist on using a TRR, which protects against this attack >> entirely, at which point DNSSEC provides limited value. >> >> If you think this analysis is wrong, please explain the attack >> which is prevented by client-side DNSSEC validation, remembering >> that it can only be done reliably when the client already is >> using a TRR. >> >> -Ekr >> >> >> [0] DNSSEC validation at the recursive might help, but that's not what >> we're talking about. >> >> On Mon, Oct 7, 2024 at 9:16 AM Paul Wouters wrote: >> >> On Mon, Oct 7, 2024 at 9:26 AM Eric Rescorla wrote: >> >> >> On Mon, Oct 7, 2024 at 6:01 AM Paul Wouters wrote: >> >> On Sun, Oct 6, 2024 at 12:17 PM Eric Rescorla wrote: >> This is explicitly prohibited rfc9460 as it would provide linkability. >> See rfc9460 section 12: "Clients MUST ensure that their DNS cache is >> partitioned for each local network, or flushed on network changes, to >> prevent a local adversary in one network from implanting a forged DNS record >> that allows them to track users or hinder their connections after they leave >> that network." >> >> Not if the ECH record is DNSSEC signed. >> >> Except that no browser client does DNSSEC validation and there is no >> realistic prospect of that changing. >> >> If you have a TRR configured that does DNSSEC, you can send the DO bit and >> still have the advantage of the >> upstream DNSSEC without doing the work in the browser. >> >> If you do encrypted DNS to a TRR, then you're not subject to attack by >> resolvers on the local netwo
[TLS] Re: [DNSOP] Re: Re: Re: Re: AD review draft-ietf-tls-svcb-ech
Authors (Ben, Mike, and Eric), It looks like we haves some agreement here. There’s some agreement that the PR [1] addresses the concern and there’s some agreement to agree to disagree on other points. Please go ahead and merge the PR [1]. spt [1] https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/16 > On Oct 8, 2024, at 21:38, Eric Rescorla wrote: > > I agree that you can't trust a resolver that you only know about from ADD. > > -Ekr > > > On Tue, Oct 8, 2024 at 8:31 AM Paul Wouters wrote: > I agree with your points. Our only difference of opinion seems to be about > how much one should trust a TRR. > I still prefer to need to trust them the least possible, meaning I would want > DNSSEC validation to at least > detect tampering at the TRR. With more ECH deployed, and less visibility of > SNI, there will be increase > pressure on TRRs to do so. > > But this discussion is not really in scope for the ECH SVCB draft, other than > that I am concerned about the > illusion of ECH privacy being lost because of a "trusted by the network via > ADD" resolver being used. > > Paul > > On Mon, Oct 7, 2024 at 9:36 PM Eric Rescorla wrote: > Paul, > > I don't understand your threat model here. > > 1. As already noted upthread, ECH inherently leaks the name you are > resolving to the resolver. This leak doesn't depend on the resolver > tampering with the response, so DNSSEC verification on the client > doesn't help here [0]. > > 2. If the client accepts the network resolver, as opposed to requiring > a TRR, then a malicious network will always be able to force the user > into leaking their browsing history on that network. Thus, as you > say, if you want ECH to guarantee privacy you need to use encrypted > transport to a TRR. > > 3. As Ben observed, if the client caches the response from the > recursive, then an ECH record from malicious resolver A (e.g., in the > airport) might allow A to continue to learn the SNI even when you are > using non-malicious resolver B (e.g., at your house). But the only > way to get into this hole is to use the network provided (potentially > malicious) resolver. > > 4. The specific attack in (3) can be prevented if the client only > cached ECH records when they were DNSSEC signed, but this still > leaves you leaking to the malicious network's resolver whenever > you try to retrieve an uncached value, so it's much better to > just insist on using a TRR, which protects against this attack > entirely, at which point DNSSEC provides limited value. > > If you think this analysis is wrong, please explain the attack > which is prevented by client-side DNSSEC validation, remembering > that it can only be done reliably when the client already is > using a TRR. > > -Ekr > > > [0] DNSSEC validation at the recursive might help, but that's not what > we're talking about. > > On Mon, Oct 7, 2024 at 9:16 AM Paul Wouters wrote: > > On Mon, Oct 7, 2024 at 9:26 AM Eric Rescorla wrote: > > > On Mon, Oct 7, 2024 at 6:01 AM Paul Wouters wrote: > > On Sun, Oct 6, 2024 at 12:17 PM Eric Rescorla wrote: > This is explicitly prohibited rfc9460 as it would provide linkability. > See rfc9460 section 12: "Clients MUST ensure that their DNS cache is > partitioned for each local network, or flushed on network changes, to prevent > a local adversary in one network from implanting a forged DNS record that > allows them to track users or hinder their connections after they leave that > network." > > Not if the ECH record is DNSSEC signed. > > Except that no browser client does DNSSEC validation and there is no > realistic prospect of that changing. > > If you have a TRR configured that does DNSSEC, you can send the DO bit and > still have the advantage of the > upstream DNSSEC without doing the work in the browser. > > If you do encrypted DNS to a TRR, then you're not subject to attack by > resolvers on the local network, regardless of whether they do DNSSEC. > > But still you should verify your trusted resolver where you can. Zerotrust > mentality. > > Of course even better is using RFC 7901 Chain Query and run the few signature > validations yourself. It only costs > 1RTT, just like a regular DNS lookup. > > The issue with local DNSSEC validation isn't primarily performance; it's > breakage by nonconforming intermediaries. > > There are no intermediaries if you connect to proper functioning TRRs (like > 1.1.1.1., 8.8.8.8, 9.9.9.9) > > Actually, as I read RFC 7901, the situation is even worse because there are > going to be valid non-RFC 7901 > implementing resolvers, and so the attacker -- who, recall, controls the > local network -- can just refuse > the discovery process described in S 5.1. > > The local network can only block the DoH HTTPS connection to your TRR, they > can't selectively block DNS queries within it. > > I agree with not using locally assigned DNS resolvers (via DHCP or ADD) for > anything if you value privacy. Obviously, DNSSEC > can
[TLS] TLS WG GH Repo Updates
Thanks to Yaroslav and Hannes for moving over the repo for the following repos: -ech-keylogfile: https://github.com/tlswg/draft-ietf-tls-ech-keylogfile -extended-key-update: https://github.com/tlswg/tls-key-update I also went ahead and update the weekly summary to include these and a lot of others I hadn’t added. Cheers, spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: TLS WG Virtual Interim on FATT Process
Thanks to all those who participated in the poll. Unfortunately, we couldn’t schedule a time where everybody could attend. The following time slot had the most people: > Begin forwarded message: > > From: IETF Meeting Session Request Tool > Subject: interim-2024-tls-02 interim approved > Date: October 1, 2024 at 20:09:13 EDT > To: , > > > An interim meeting for tls has been approved or does not require additional > approval. > A message has been sent to the secretariat requesting the interim be > announced. > > > - > Working Group Name: Transport Layer Security > Area Name: Security Area > Session Requester: Sean Turner > > Meeting Type: Virtual Meeting > > Session 1: > > Date: 2024-10-16 > Start Time: 14:00 America/New_York > Duration: 02:00 > Remote Participation Information: > https://meetings.conf.meetecho.com/interim/?group=7627d881-2175-4086-899f-657548e64b52 > Agenda Note: > > I will make sure to send reminders out prior to meeting. We will also record this session. And, we plan to have “the plan” out in advance (like a week) so that those that can’t make it in person can provide comments. Cheers, spt > On Sep 23, 2024, at 16:53, Sean Turner wrote: > > Hi! Thanks to all those who have already filled out the poll. I am hoping to > close this out by Friday so I will send daily reminders until then. > > Cheers, > spt > >> On Sep 23, 2024, at 12:05, Sean Turner wrote: >> >> The chairs would like to have an interim to review the FATT (Formal Analysis >> Triage Team) process. We are still working out the proposal, but we would >> like to get this meeting scheduled to review any feedback / comments once we >> do post the process. Please fill out the following with your available times >> if you are interested in attending: >> >> https://doodle.com/meeting/participate/id/aMoXAp1d >> >> Thanks, >> Deirdre, Joe, & Sean > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Reminders
Hi! Here’s a list of a select goings on: 1. TLS Virtual Interim concerning the Trust Tussle; see the following thread: https://mailarchive.ietf.org/arch/msg/tls/et9dCsZYHhmoXaAdybeXdq37PnE/ It’s today in under an hour from now. 2. Poll for TLS Virtual Interim concerning the FATT Process; see the following thread: https://mailarchive.ietf.org/arch/msg/tls/76yqBw5rOLlByPtPGXU8YJl6xO4/ Plan to close this poll out today! 3. Consensus Call for an early code point for draft-ietf-tls-key-share-prediction; see the following thread: https://mailarchive.ietf.org/arch/msg/tls/se4Lj79-6pTLGTQ6kleE9ZwTs4o/ Closes 8 October. 4. Consensus Call for an early code point for draft-ietf-tls-tlsflags; see the following thread: https://mailarchive.ietf.org/arch/msg/tls/0pCMGxpHxPSPnDPKGCFQmCE9b_I/ Closes 11 October. Cheers, spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] tls@ietf121: agenda requests
The TLS WG has requested a two hour session slot at IETF 121 [0]; we are not yet sure of the timing. For planning purposes, the chairs would like to solicit input from the WG for agenda topics. Please send your agenda topics request and an estimate for how much time you will need to tls-cha...@ietf.org. Please note that we will prioritize existing WG items. Please also review the guidance for TLS WG presenters that can be found at [1]. Cheers, Deirdre, Joe, and Sean [0] https://mailarchive.ietf.org/arch/msg/tls/KwzHh5wN7cNZ8VwbcC7qS6A7oVA/ [1 https://github.com/tlswg/tlswg-wiki/blob/master/FAQ.md ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: TLS Interim (was Re: interim-2024-tls-01 interim approved)
To add a little more context about the interim ... We are taking a step back to focus on the problem statement/space. As you can see from the agenda items, we are going to tease out whether we can agree on a problem statement and then wether we should try to solve that problem. As a result, I retitled the topic in the agenda to be “Trust Tussle” to better reflect what we are actually going to discuss. Feel free to read the I-Ds we discussed at IETF 120, draft-davidben-tls-trust-expr and draft-beck-tls-trust-anchor-ids, for background but we are not planning on discussing the I-Ds specifically. Cheers, spt > On Sep 27, 2024, at 13:37, Sean Turner wrote: > > HI! Just another reminder that we have an interim scheduled for Oct 1st @ 9am > Pacific time. I have uploaded the agenda:* > https://datatracker.ietf.org/doc/agenda-interim-2024-tls-01-tls-01/ > Here is a link to the remote meeting instructions (it’s MeetEcho): > https://meetings.conf.meetecho.com/interim/?group=f3d0d4f9-2480-4bdc-8a2d-4765d8aedd73 > > See you then! > > spt > > * Thanks Chris! > >> On Sep 17, 2024, at 12:18, Sean Turner wrote: >> >> Hi! Another reminder that we have a virtual interim scheduled for 2024-10-01 >> @ 9am Pacific time. We are still working out the details but the topic is >> Trust Expressions / Trust Anchor Transition. >> >> Cheers, >> spt >> >>> On Sep 10, 2024, at 13:33, Sean Turner wrote: >>> >>> Hi! We have scheduled a virtual interim to discuss Trust Expressions / >>> Trust Anchors Transition. We are in the process of defining some ground >>> rules for the meeting as well as setting some expected outcomes, but we >>> wanted to get the interim on the calendar. >>> >>> Cheers, >>> spt >>> >>>> On Sep 10, 2024, at 13:31, IETF Meeting Session Request Tool >>>> wrote: >>>> >>>> >>>> An interim meeting for tls has been approved or does not require >>>> additional approval. >>>> A message has been sent to the secretariat requesting the interim be >>>> announced. >>>> >>>> >>>> - >>>> Working Group Name: Transport Layer Security >>>> Area Name: Security Area >>>> Session Requester: Sean Turner >>>> >>>> Meeting Type: Virtual Meeting >>>> >>>> Session 1: >>>> >>>> Date: 2024-10-01 >>>> Start Time: 12:00 America/New_York >>>> Duration: 03:00 >>>> Remote Participation Information: >>>> https://meetings.conf.meetecho.com/interim/?group=f3d0d4f9-2480-4bdc-8a2d-4765d8aedd73 >>>> Agenda Note: >>>> >>>> - >>>> >>> >> > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: TLS Interim (was Re: interim-2024-tls-01 interim approved)
HI! Just another reminder that we have an interim scheduled for Oct 1st @ 9am Pacific time. I have uploaded the agenda:* https://datatracker.ietf.org/doc/agenda-interim-2024-tls-01-tls-01/ Here is a link to the remote meeting instructions (it’s MeetEcho): https://meetings.conf.meetecho.com/interim/?group=f3d0d4f9-2480-4bdc-8a2d-4765d8aedd73 See you then! spt * Thanks Chris! > On Sep 17, 2024, at 12:18, Sean Turner wrote: > > Hi! Another reminder that we have a virtual interim scheduled for 2024-10-01 > @ 9am Pacific time. We are still working out the details but the topic is > Trust Expressions / Trust Anchor Transition. > > Cheers, > spt > >> On Sep 10, 2024, at 13:33, Sean Turner wrote: >> >> Hi! We have scheduled a virtual interim to discuss Trust Expressions / Trust >> Anchors Transition. We are in the process of defining some ground rules for >> the meeting as well as setting some expected outcomes, but we wanted to get >> the interim on the calendar. >> >> Cheers, >> spt >> >>> On Sep 10, 2024, at 13:31, IETF Meeting Session Request Tool >>> wrote: >>> >>> >>> An interim meeting for tls has been approved or does not require additional >>> approval. >>> A message has been sent to the secretariat requesting the interim be >>> announced. >>> >>> >>> - >>> Working Group Name: Transport Layer Security >>> Area Name: Security Area >>> Session Requester: Sean Turner >>> >>> Meeting Type: Virtual Meeting >>> >>> Session 1: >>> >>> Date: 2024-10-01 >>> Start Time: 12:00 America/New_York >>> Duration: 03:00 >>> Remote Participation Information: >>> https://meetings.conf.meetecho.com/interim/?group=f3d0d4f9-2480-4bdc-8a2d-4765d8aedd73 >>> Agenda Note: >>> >>> - >>> >> > ___ 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-tlsflags
Hi! We paused progression of draft-ietf-tls-tlsflags until we had implementations. We (the chairs) have gotten requests for an early IANA code point; if you remember draft-ietf-tls-cross-sni-resumption, a WG I-D that is now expired, and draft-jhoyla-req-mtls-flag, a individual I-D, would both need this code point. Note that like draft-ietf-tls-dtls-rrc, draft-ietf-tls-tlsflags also creates a new sub-registry, but IANA cannot create a temporary registry and then manage it for us. We will do that in the WG/I-D; there is not much to manage because at this point it’s only two values. With that said …. We (the Chairs) would like to determine whether there is consensus to request an early code point request for "tls_flags” in the TLS ExtensionType Values registry registry; see Section 4 of the I-D [0]. The point of this consensus call is to determine whether you think this I-D is stable enough to request a code point from the DEs. Please let the list know by 11 October 2024 if you support this request. Cheers, spt (as TLS Co-Chair) [0] https://datatracker.ietf.org/doc/draft-ietf-tls-tlsflags/ ___ 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] 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] 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] Re: Publication has been requested for draft-ietf-tls-svcb-ech-05
> On Sep 23, 2024, at 16:50, Sean Turner via Datatracker > wrote: > > Sean Turner has requested publication of draft-ietf-tls-svcb-ech-05 as > Proposed Standard on behalf of the TLS working group. > > Please verify the document's state at > https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/ Hi! Please note that we have requested the IESG publish this I-D along with the ECH I-D. We are forwarding this I-D to the AD without sending it to through the FATT because ECH has already undergone formal analysis; see Joe’s msg to the list [1]. Cheers, spt [1] https://mailarchive.ietf.org/arch/msg/tls/NvePkO_eeWEmkw8gksqlZBRFSSI/ ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: TLS WG Virtual Interim on FATT Process
Hi! Thanks to all those who have already filled out the poll. I am hoping to close this out by Friday so I will send daily reminders until then. Cheers, spt > On Sep 23, 2024, at 12:05, Sean Turner wrote: > > The chairs would like to have an interim to review the FATT (Formal Analysis > Triage Team) process. We are still working out the proposal, but we would > like to get this meeting scheduled to review any feedback / comments once we > do post the process. Please fill out the following with your available times > if you are interested in attending: > > https://doodle.com/meeting/participate/id/aMoXAp1d > > Thanks, > Deirdre, Joe, & Sean ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Publication has been requested for draft-ietf-tls-svcb-ech-05
Sean Turner has requested publication of draft-ietf-tls-svcb-ech-05 as Proposed Standard on behalf of the TLS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/ ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Adoption call for Extended Key Update for TLS 1.3
Hi! There is consensus to adopt this draft as a working group item.* This might not be the exact form it ends up in, but there is sufficient interest to get the work started. I'll work with the authors to migrate to the official repository and submit an updated draft. spt * Apologies for taking so long. Some of the delay was a result of working on the FATT process. > On Jul 25, 2024, at 12:39, Sean Turner wrote: > > At the IETF 120 TLS session there was interest in adopting the Extended Key > Update for TLS 1.3 I-D > (https://datatracker.ietf.org/doc/draft-tschofenig-tls-extended-key-update/). > This message starts a two-week call for adoption. If you support adoption and > are willing to review and contribute text, please send a message to the list. > If you do not support adoption of this I-D, please send a message to the list > and indicate why. This call will close on 8 August 2024. > > Thanks, > Sean ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Adoption call for SSLKEYLOG Extension file for ECH
Hi! There is consensus to adopt this draft as a working group item.* I'll work with the authors to migrate to the official repository and submit an updated draft. spt * Apologies for taking so long. Some of the delay was a result of working on the FATT process. > On Jul 25, 2024, at 12:15, Sean Turner wrote: > > At the IETF 120 TLS session there was interest in adopting the SSLKEYLOG > Extension file for ECH I-D > (https://datatracker.ietf.org/doc/draft-rosomakho-tls-ech-keylogfile/). This > message starts a two-weekl call for adoption. If you support adoption and are > willing to review and contribute text, please send a message to the list. If > you do not support adoption of this I-D, please send a message to the list > and indicate why. This call will close on 8 August 2024. > > Thanks, > Sean ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] TLS WG Virtual Interim on FATT Process
The chairs would like to have an interim to review the FATT (Formal Analysis Triage Team) process. We are still working out the proposal, but we would like to get this meeting scheduled to review any feedback / comments once we do post the process. Please fill out the following with your available times if you are interested in attending: https://doodle.com/meeting/participate/id/aMoXAp1d Thanks, Deirdre, Joe, & Sean ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: TLS Interim (was Re: interim-2024-tls-01 interim approved)
Hi! Another reminder that we have a virtual interim scheduled for 2024-10-01 @ 9am Pacific time. We are still working out the details but the topic is Trust Expressions / Trust Anchor Transition. Cheers, spt > On Sep 10, 2024, at 13:33, Sean Turner wrote: > > Hi! We have scheduled a virtual interim to discuss Trust Expressions / Trust > Anchors Transition. We are in the process of defining some ground rules for > the meeting as well as setting some expected outcomes, but we wanted to get > the interim on the calendar. > > Cheers, > spt > >> On Sep 10, 2024, at 13:31, IETF Meeting Session Request Tool >> wrote: >> >> >> An interim meeting for tls has been approved or does not require additional >> approval. >> A message has been sent to the secretariat requesting the interim be >> announced. >> >> >> - >> Working Group Name: Transport Layer Security >> Area Name: Security Area >> Session Requester: Sean Turner >> >> Meeting Type: Virtual Meeting >> >> Session 1: >> >> Date: 2024-10-01 >> Start Time: 12:00 America/New_York >> Duration: 03:00 >> Remote Participation Information: >> https://meetings.conf.meetecho.com/interim/?group=f3d0d4f9-2480-4bdc-8a2d-4765d8aedd73 >> Agenda Note: >> >> - >> > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: I-D Action: draft-ietf-tls-rfc8446bis-11.txt
This version addresses all known issues. I will being work on the write-up, but I would expect it to be with our AD by next week. spt > On Sep 14, 2024, at 16:19, internet-dra...@ietf.org wrote: > > Internet-Draft draft-ietf-tls-rfc8446bis-11.txt is now available. It is a work > item of the Transport Layer Security (TLS) WG of the IETF. > > Title: The Transport Layer Security (TLS) Protocol Version 1.3 > Author: Eric Rescorla > Name:draft-ietf-tls-rfc8446bis-11.txt > Pages: 160 > Dates: 2024-09-14 > > Abstract: > > This document specifies version 1.3 of the Transport Layer Security > (TLS) protocol. TLS allows client/server applications to communicate > over the Internet in a way that is designed to prevent eavesdropping, > tampering, and message forgery. > > This document updates RFCs 5705, 6066, 7627, and 8422 and obsoletes > RFCs 5077, 5246, 6961, 8422, and 8446. This document also specifies > new requirements for TLS 1.2 implementations. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-tls-rfc8446bis-11.html > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-rfc8446bis-11 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > ___ > I-D-Announce mailing list -- i-d-annou...@ietf.org > To unsubscribe send an email to i-d-announce-le...@ietf.org ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] TLS Interim (was Re: interim-2024-tls-01 interim approved)
Hi! We have scheduled a virtual interim to discuss Trust Expressions / Trust Anchors Transition. We are in the process of defining some ground rules for the meeting as well as setting some expected outcomes, but we wanted to get the interim on the calendar. Cheers, spt > On Sep 10, 2024, at 13:31, IETF Meeting Session Request Tool > wrote: > > > An interim meeting for tls has been approved or does not require additional > approval. > A message has been sent to the secretariat requesting the interim be > announced. > > > - > Working Group Name: Transport Layer Security > Area Name: Security Area > Session Requester: Sean Turner > > Meeting Type: Virtual Meeting > > Session 1: > > Date: 2024-10-01 > Start Time: 12:00 America/New_York > Duration: 03:00 > Remote Participation Information: > https://meetings.conf.meetecho.com/interim/?group=f3d0d4f9-2480-4bdc-8a2d-4765d8aedd73 > Agenda Note: > > - > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Consensus Call: -rfc8446bis PRs #1360
Hi! Thanks to all who participated in this consensus call (and those who participated at IETF 120). Based on both the TLS WG sessions at IETF 120 and this thread, the consensus is to not merge the PR. ekr - please close the PR out and submit a new version of the I-D when you have time. spt > On Aug 26, 2024, at 09:23, Sean Turner wrote: > > Hi! Loganaden submitted a PR to add x25519 as an MTI in TLS 1.3 that > addresses an Issue submitted by Stephen; links to both follow: > Issue: https://github.com/tlswg/tls13-spec/issues/1359 > PR: https://github.com/tlswg/tls13-spec/pull/1360 > > As this has been suggested post WGLC, we need to ensure we have consensus to > merge this PR. We did spend some time on this (and other -rfc8446bis) PRs at > IETF 120. At the session, we did a poll to 1st determine whether it is > appropriate to make this change in this I-D, which > was supposed to be just for clarifications. The result of the poll was to not > make this change. To verify this, please review the PR in its entirety and > indicate whether you support not merging this PR by 9 September 23:59 UTC. > > Cheers, > spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Is there any interest in an RFC on how to do cross-organization mTLS?
Mark, Hi! I’d suggest writing the I-D [1] and then we (the royal we here) can figure out where it goes; could be ALLDISPATCH then TLS or UTA depending on ALLDISPATCH outcome. Additionally, discussing at the ALLDISPATCH session would get much a wider audience, which I think would help in general. spt [1] Submission deadline for IETF 121 is 21 October. > On Sep 9, 2024, at 14:42, Mark Robinson wrote: > > I've been doing a lot of work lately to support organizations that do mTLS > between each other. The problem I've found is that there is a huge amount of > ignorance on TLS in general and mTLS in particular. > > Would it be appropriate to write an RFC on how to make cross-organization > mTLS work reliably and at scale? Would this group/mailing list be the right > people to work with to make that happen? > > Mark > ___ > 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: [TLS]Re: [Editorial Errata Reported] RFC6347 (8089)
Since this is correctly marked as “Editorial” are there any objections to
changing the state to “Hold For Document Update”?
spt
> On Aug 23, 2024, at 18:18, Eric Rescorla wrote:
>
> I don't think this is an erratum. I agree it would be better, but I don't
> think that rises to "error".
>
> -Ekr
>
>
> On Fri, Aug 23, 2024 at 11:17 AM Rebecca VanRheenen
> wrote:
> Hi Paul,
>
> We are unable to verify this erratum that the submitter marked as editorial,
> so we changed the Type to “Technical”. As Stream Approver, please review and
> set the Status and Type accordingly (see the definitions at
> https://www.rfc-editor.org/errata-definitions/).
>
> Notes:
> * RFC 6347 has been obsoleted by RFC 9147. We see similar blocks of code in
> Section 5.2 and Appendix A.2 of RFC 9147.
> * For information about errata on obsolete RFCs, see #7 in the IESG Statement
> on "IESG Processing of RFC Errata for the IETF Stream”
> (https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/).
>
> You may review the report at:
> https://www.rfc-editor.org/errata/eid8089
>
> Information on how to verify errata reports can be found at:
> https://www.rfc-editor.org/how-to-verify/
>
> Further information on errata can be found at:
> https://www.rfc-editor.org/errata.php
>
> Best regards,
> RFC Editor/rv
>
>
> > On Aug 23, 2024, at 6:26 AM, RFC Errata System
> > wrote:
> >
> > The following errata report has been submitted for RFC6347,
> > "Datagram Transport Layer Security Version 1.2".
> >
> > --
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid8089
> >
> > --
> > Type: Editorial
> > Reported by: Kamil Milewski
> >
> > Section: 4.2.2
> >
> > Original Text
> > -
> > struct {
> > HandshakeType msg_type;
> > uint24 length;
> > uint16 message_seq; // New field
> > uint24 fragment_offset; // New field
> > uint24 fragment_length; // New field
> > select (HandshakeType) {
> > case hello_request: HelloRequest;
> > case client_hello: ClientHello;
> > case hello_verify_request: HelloVerifyRequest; // New type
> > case server_hello: ServerHello;
> > case certificate:Certificate;
> > case server_key_exchange: ServerKeyExchange;
> > case certificate_request: CertificateRequest;
> > case server_hello_done:ServerHelloDone;
> > case certificate_verify: CertificateVerify;
> > case client_key_exchange: ClientKeyExchange;
> > case finished: Finished;
> > } body;
> > } Handshake;
> >
> > Corrected Text
> > --
> > struct {
> > HandshakeType msg_type;
> > uint24 length;
> > uint16 message_seq; // New field
> > uint24 fragment_offset; // New field
> > uint24 fragment_length; // New field
> > select (HandshakeType) {
> > case hello_request: HelloRequest;
> > case client_hello: ClientHello;
> > case server_hello: ServerHello;
> > case hello_verify_request: HelloVerifyRequest; // New field
> > case certificate:Certificate;
> > case server_key_exchange: ServerKeyExchange;
> > case certificate_request: CertificateRequest;
> > case server_hello_done:ServerHelloDone;
> > case certificate_verify: CertificateVerify;
> > case client_key_exchange: ClientKeyExchange;
> > case finished: Finished;
> > } body; } Handshake;
> >
> > Notes
> > -
> > Change the order of cases inside select field to keep it:
> > 1. In ascending order
> > 2. Consistent with the structure in 4.3.2
> >
> > Instructions:
> > -
> > This erratum is currently posted as "Reported". (If it is spam, it
> > will be removed shortly by the RFC Production Center.) Please
> > use "Reply All" to discuss whether it should be verified or
> > rejected. When a decision is reached, the verifying party
> > will log in to change the status and edit the report, if necessary.
> >
> > --
> > RFC6347 (draft-ietf-tls-rfc4347-bis-06)
> > --
> > Title : Datagram Transport Layer Security Version 1.2
> > Publication Date: January 2012
> > Author(s) : E. Rescorla, N. Modadugu
> > Category: PROPOSED STANDARD
> > Source : Transport Layer Security
> > Stream : IETF
> > Verifying Party : IESG
> >
>
> ___
> 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: I-D Action: draft-ietf-tls-svcb-ech-05.txt
Thanks to the authors for updating the I-D to address the nits I noted while doing the Shepherd write-up. I will finish the Shepherd write-up and then this I-D can progress with the draft-ietf-tls-esni. spt > On Sep 3, 2024, at 19:19, internet-dra...@ietf.org wrote: > > Internet-Draft draft-ietf-tls-svcb-ech-05.txt is now available. It is a work > item of the Transport Layer Security (TLS) WG of the IETF. > > Title: Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings > Authors: Ben Schwartz >Mike Bishop >Erik Nygren > Name:draft-ietf-tls-svcb-ech-05.txt > Pages: 7 > Dates: 2024-09-03 > > Abstract: > > To use TLS Encrypted ClientHello (ECH) the client needs to learn the > ECH configuration for a server before it attempts a connection to the > server. This specification provides a mechanism for conveying the > ECH configuration information via DNS, using a SVCB or HTTPS record. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-tls-svcb-ech-05.html > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-svcb-ech-05 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > ___ > I-D-Announce mailing list -- i-d-annou...@ietf.org > To unsubscribe send an email to i-d-announce-le...@ietf.org ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Consensus Call: -rfc8446bis PRs #1360
Hi! Reminder that this consensus call is still ongoing. spt > On Aug 26, 2024, at 09:23, Sean Turner wrote: > > Hi! Loganaden submitted a PR to add x25519 as an MTI in TLS 1.3 that > addresses an Issue submitted by Stephen; links to both follow: > Issue: https://github.com/tlswg/tls13-spec/issues/1359 > PR: https://github.com/tlswg/tls13-spec/pull/1360 > > As this has been suggested post WGLC, we need to ensure we have consensus to > merge this PR. We did spend some time on this (and other -rfc8446bis) PRs at > IETF 120. At the session, we did a poll to 1st determine whether it is > appropriate to make this change in this I-D, which > was supposed to be just for clarifications. The result of the poll was to not > make this change. To verify this, please review the PR in its entirety and > indicate whether you support not merging this PR by 9 September 23:59 UTC. > > Cheers, > spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Consensus Call: -rfc8446bis PRs #1360
Hi! Loganaden submitted a PR to add x25519 as an MTI in TLS 1.3 that addresses an Issue submitted by Stephen; links to both follow: Issue: https://github.com/tlswg/tls13-spec/issues/1359 PR: https://github.com/tlswg/tls13-spec/pull/1360 As this has been suggested post WGLC, we need to ensure we have consensus to merge this PR. We did spend some time on this (and other -rfc8446bis) PRs at IETF 120. At the session, we did a poll to 1st determine whether it is appropriate to make this change in this I-D, which was supposed to be just for clarifications. The result of the poll was to not make this change. To verify this, please review the PR in its entirety and indicate whether you support not merging this PR by 9 September 23:59 UTC. Cheers, spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: I-D Action: draft-ietf-tls-svcb-ech-04.txt
Technically, this I-D has already been through WGLC and this version is to address the remaining WGLC. Any objection to progressing this while we debate in parallel whether to change the name? spt > On Aug 20, 2024, at 13:00, Salz, Rich > wrote: > > > I read the document [1]. I think it's ready for WGLC. I suggest one change. > I find the use of "bootstrapping" in the title misleading. I suggest > "Enabling TLS Encrypted ClientHello via DNS Service Bindings." > > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/ > > > ___ > 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: The TLS WG has placed draft-rosomakho-tls-ech-keylogfile in state "Call For Adoption By WG Issued"
> On Jul 25, 2024, at 09:37, Salz, Rich > wrote: > > Andrei's suggestion of informational is a good idea. Luckily, the authors pre-picked Informational! spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Adoption call for Extended Key Update for TLS 1.3
At the IETF 120 TLS session there was interest in adopting the Extended Key Update for TLS 1.3 I-D (https://datatracker.ietf.org/doc/draft-tschofenig-tls-extended-key-update/). This message starts a two-week call for adoption. If you support adoption and are willing to review and contribute text, please send a message to the list. If you do not support adoption of this I-D, please send a message to the list and indicate why. This call will close on 8 August 2024. Thanks, Sean ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Adoption call for SSLKEYLOG Extension file for ECH
At the IETF 120 TLS session there was interest in adopting the SSLKEYLOG Extension file for ECH I-D (https://datatracker.ietf.org/doc/draft-rosomakho-tls-ech-keylogfile/). This message starts a two-weekl call for adoption. If you support adoption and are willing to review and contribute text, please send a message to the list. If you do not support adoption of this I-D, please send a message to the list and indicate why. This call will close on 8 August 2024. Thanks, Sean ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]tls@ietf120: WG I-D status
Hi! We often review the WG I-Ds’ status during the chairs’ slides. I’d like to try an experiment to save us more time for the session by sending the update via email; it’s also in the chairs’ slides. If any I-D authors disagree with this very brief summary please let us know. The list is sorted based on datatracker order. - draft-ietf-tls-svcb-ech-03: Needs a -04 to address WGLC comments from Rich Salz and Chris Patton. - draft-ietf-tls-8773bis-02: Refer to Formal Analysis Triage Team (FATT) discussion in meeting. - draft-ietf-tls-wkech-05: See Stephen’s slides for IETF 120. - draft-ietf-tls-deprecate-obsolete-kex-04: Joe needs to do some minor word tweaking before moving it forward. - draft-ietf-tls-key-share-prediction-00: It’s new, needs WG review. - draft-ietf-tls-tls13-pkcs1-01: Through WGLC, will enter FATT process once 8773bis is resolved; technically behind -rrc. - draft-ietf-tls-rfc8447bis-09: Awaiting WGLC; Deirdre to run. - draft-ietf-tls-keylogfile-02: With RFC Editor. - draft-ietf-tls-ctls-10: Stalled, but Hannes said he will have more time late summer. - draft-ietf-tls-hybrid-design-10: See Deirdre’s slides for IETF 120. - draft-ietf-tls-tls12-frozen-00: See Rich’s slides for IETF 120. - draft-ietf-tls-dtls-rrc-11: Through WGLC, will enter FATT process once 8773bis is resolved. - draft-davidben-tls-key-share-prediction-01: WG review needed. - draft-ietf-tls-cert-abridge-01: Needs WG review. - draft-ietf-tls-tlsflags-13: Awaiting implementations; would move if draft-jhoyla-req-mtls-flag was adopted. - draft-ietf-tls-rfc8446bis-10: See Sean’s slides for IETF 120. Cheers, spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: I-D Action: draft-ietf-tls-svcb-ech-03.txt
Hey folks this version is just a keep alive version, i.e., the dates changed and that’s it. We had a couple of comments during WGLC that need to be addressed. Cheers, spt > On Jul 23, 2024, at 08:26, internet-dra...@ietf.org wrote: > > Internet-Draft draft-ietf-tls-svcb-ech-03.txt is now available. It is a work > item of the Transport Layer Security (TLS) WG of the IETF. > > Title: Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings > Authors: Ben Schwartz >Mike Bishop >Erik Nygren > Name:draft-ietf-tls-svcb-ech-03.txt > Pages: 6 > Dates: 2024-07-23 > > Abstract: > > To use TLS Encrypted ClientHello (ECH) the client needs to learn the > ECH configuration for a server before it attempts a connection to the > server. This specification provides a mechanism for conveying the > ECH configuration information via DNS, using a SVCB or HTTPS record. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-tls-svcb-ech-03.html > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-svcb-ech-03 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > ___ > I-D-Announce mailing list -- i-d-annou...@ietf.org > To unsubscribe send an email to i-d-announce-le...@ietf.org ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]tls@ietf120: agenda requests
The TLS WG is meeting at IETF 120 for 2 hours on Wednesday, July 24, 2024 from 1300-1500 (local time) [0] in the Regency E/F room [2]. The chairs would like to solicit input from the WG for agenda topics. Please send your agenda topics request and an estimate for how much time you will need to tls-cha...@ietf.org. Please note that we will prioritize existing WG items. Please also review the guidance for TLS WG presenters that can be found at [2]. Cheers, Deirdre, Joe, and Sean [0] https://datatracker.ietf.org/meeting/120/agenda [1] https://datatracker.ietf.org/meeting/120/floor-plan?room=regency-e-f [2] https://github.com/tlswg/tlswg-wiki/blob/master/FAQ.md ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Consensus Call: -rfc8446bis PR #1361
Hi! just a reminder this call is still on-going! Thanks for those who have contributed so far. spt > On Jun 21, 2024, at 07:15, Sean Turner wrote: > > Hi! David Benjamin submitted the following PR to unify some prose related to > certificate negotiation in TLS 1.3 (ClientHello/Certificate and > CertificateRequest/Certificate are now nice and symmetric): > https://github.com/tlswg/tls13-spec/pull/1361 > As this has been suggested post WGLC, we need to ensure we have consensus to > merge this PR, so please review the PR in its entirety and indicate whether > you support merging this PR by 5 July 23:59 UTC. > > Cheers, > spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Working Group Last Call for Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings
Mike, Thanks for this! When you think the issues are all resolved, please post a new version and I will get the Shepherd write-up draft for you and your co-authors to review. spt > On Jun 24, 2024, at 10:46, Mike Bishop wrote: > > I support publication, but I'm slightly biased since my name is on the doc. > > However, I noticed that the repo didn't have the Issue Tracker or Editor's > Copy enabled; I've enabled those, so if anyone has been holding WGLC feedback > for that reason, you can file your issues now. I created issues for the two > WGLC comments I've seen so far. > > -Original Message- > From: Sean Turner > Sent: Wednesday, June 12, 2024 2:11 PM > To: TLS List > Subject: [TLS]Working Group Last Call for Bootstrapping TLS Encrypted > ClientHello with DNS Service Bindings > > This email starts the working group last call for "Bootstrapping TLS > Encrypted ClientHello with DNS Service Bindings” I-D, located here: > > https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/ > > The WG Last Call will end 26 June 2024 @ 2359 UTC. > > Please review the I-D and submit issues and pull requests via the GitHub > repository that can be found at: > > https://github.com/tlswg/draft-ietf-tls-svcb-ech > > Alternatively, you can also send your comments to tls@ietf.org. > > Thanks, > spt > ___ > 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: -rfc8446bis PR #1361
Hi! David Benjamin submitted the following PR to unify some prose related to certificate negotiation in TLS 1.3 (ClientHello/Certificate and CertificateRequest/Certificate are now nice and symmetric): https://github.com/tlswg/tls13-spec/pull/1361 As this has been suggested post WGLC, we need to ensure we have consensus to merge this PR, so please review the PR in its entirety and indicate whether you support merging this PR by 5 July 23:59 UTC. Cheers, spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Working Group Last Call for Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings
Gentle reminder this WGLC is still ongoing. spt > On Jun 12, 2024, at 14:10, Sean Turner wrote: > > This email starts the working group last call for "Bootstrapping TLS > Encrypted ClientHello with DNS Service Bindings” I-D, located here: > > https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/ > > The WG Last Call will end 26 June 2024 @ 2359 UTC. > > Please review the I-D and submit issues and pull requests via the GitHub > repository that can be found at: > > https://github.com/tlswg/draft-ietf-tls-svcb-ech > > Alternatively, you can also send your comments to tls@ietf.org. > > Thanks, > spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Consensus Call: -rfc8446bis PRs #1343 & #1345
Hi! Thanks all to those who participated! We have consensus to land these two PRs; #1343 got tweaked during this call. ekr - merge when you get a chance. spt > On Jun 12, 2024, at 16:23, Sean Turner wrote: > > Hi! Just reminder to get any concerns about merging these in by 17 June 2024. > > spt > >> On Jun 3, 2024, at 11:38, Sean Turner wrote: >> >> Since draft-ietf-tls-rfc8446bis last completed WGLC, two PRs have been >> submitted (and discussed) that include changes to normative language: >> >> - #1343: Forbid the sender from sending redundant update_requested KeyUpdates >> https://github.com/tlswg/tls13-spec/pull/1343 >> >> - #1345: Forbid the sender from sending duplicate supported groups entries >> https://github.com/tlswg/tls13-spec/pull/1354 >> >> The discussion so far seems to support consensus to merge these PRs. If you >> object, please >> do so on the issue or in response to this message. Absent any pushback, we >> will direct the >> editors to incorporate them in two weeks' time. >> >> Cheers, >> spt > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Consensus Call: -rfc8446bis PRs #1357
> On Jun 13, 2024, at 18:42, Salz, Rich wrote: > > I looked at the diff in https://github.com/tlswg/tls13-spec/pull/1357/files > > The changes are fine with me and I prefer EKR's wording about close_notify. > Does that need to be added to section 1.2? Ah yes, we should note this (and the other post WGLC changes) in s1.2! Might get done as a separate PR though. spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Consensus Call: -rfc8446bis PRs #1357
Hi! At the last TLS WG session in Brisbane, I mentioned that we were waiting to process some RFC 8446 errata that might apply to the -rfc8446bis I-D. There is now a PR [0] for 5 of 19 errata that still apply to -rfc8446bis; the other 14 RFC 8446 errata we will close (the system uses the somewhat harsher term reject). Some of the proposed changes are editorial, but at least one change includes new 2119 language; see lines 4084-4088. EKR has also suggested some tweaks for this text, but it also includes 2119 language; see previous list discussion here [1]. As a result of the new 2119 language and that this change is post WGLC, we need to judge consensus to merge this PR. Please review the PR in its entirety and indicate whether you support merging this PR with the PR's proposed tweaks, with EKR’s proposed tweaks, or not (or propose something else) by 27 June 23:59 UTC. Cheers, spt [0] Thanks to Ben Smyth for puling this together. [1] https://mailarchive.ietf.org/arch/msg/tls/CoAEG9dGbKh4jUkfFtFfYjBkRSs/ ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Consensus Call: -rfc8446bis PRs #1343 & #1345
Hi! Just reminder to get any concerns about merging these in by 17 June 2024. spt > On Jun 3, 2024, at 11:38, Sean Turner wrote: > > Since draft-ietf-tls-rfc8446bis last completed WGLC, two PRs have been > submitted (and discussed) that include changes to normative language: > > - #1343: Forbid the sender from sending redundant update_requested KeyUpdates > https://github.com/tlswg/tls13-spec/pull/1343 > > - #1345: Forbid the sender from sending duplicate supported groups entries > https://github.com/tlswg/tls13-spec/pull/1354 > > The discussion so far seems to support consensus to merge these PRs. If you > object, please > do so on the issue or in response to this message. Absent any pushback, we > will direct the > editors to incorporate them in two weeks' time. > > Cheers, > spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Working Group Last Call for Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings
This email starts the working group last call for "Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings” I-D, located here: https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/ The WG Last Call will end 26 June 2024 @ 2359 UTC. Please review the I-D and submit issues and pull requests via the GitHub repository that can be found at: https://github.com/tlswg/draft-ietf-tls-svcb-ech Alternatively, you can also send your comments to tls@ietf.org. Thanks, spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Consensus Call: -rfc8446bis PRs #1343 & #1345
Gentle reminder about these two PRs. I should note there are now others. spt > On Jun 3, 2024, at 11:38, Sean Turner wrote: > > Since draft-ietf-tls-rfc8446bis last completed WGLC, two PRs have been > submitted (and discussed) that include changes to normative language: > > - #1343: Forbid the sender from sending redundant update_requested KeyUpdates > https://github.com/tlswg/tls13-spec/pull/1343 > > - #1345: Forbid the sender from sending duplicate supported groups entries > https://github.com/tlswg/tls13-spec/pull/1354 > > The discussion so far seems to support consensus to merge these PRs. If you > object, please > do so on the issue or in response to this message. Absent any pushback, we > will direct the > editors to incorporate them in two weeks' time. > > Cheers, > spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Working Group Last Call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3
WGLC closes out today. spt > On Jun 3, 2024, at 11:43, Sean Turner wrote: > > Hi! WGLC ends on Wednesday. I know this I-D is not all that exciting and > most of the “discussion" was about whether to adopt the I-D at all, but it > would be great if we had a couple of more people chime in. If you remember, > when we used the show of hands tool to help determine whether there was > consensus to adopt this draft there were 36 who wanted it adopted. > > spt > >> On May 28, 2024, at 09:44, Sean Turner wrote: >> >> Just a reminder that this WGLC is still ongoing. >> >> spt >> >>> On May 22, 2024, at 10:14, Sean Turner wrote: >>> >>> This email starts the working group last call for "Legacy RSASSA-PKCS1-v1_5 >>> codepoints for TLS 1.3” I-D, located here: >>> >>> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-pkcs1/ >>> >>> The WG Last Call will end 5 June 2024 @ 2359 UTC. >>> >>> Please review the I-D and submit issues and pull requests via the GitHub >>> repository that can be found at: >>> >>> https://github.com/tlswg/tls13-pkcs1 >>> >>> Alternatively, you can also send your comments to tls@ietf.org. >>> >>> Thanks, >>> spt >> > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]tls@ietf120: I-D submission deadline
Hi! Friendly reminder that the I-D submission deadline for IETF 120 is [1]: 2024-07-08 (Monday) Internet-Draft submission cut-off (for all Internet-Drafts, including -00) by UTC 23:59. Upload using the I-D Submission Tool [2] Cheers, spt [1] https://datatracker.ietf.org/meeting/important-dates/ [2] https://datatracker.ietf.org/submit/ ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Curve-popularity data?
Hi! I sent a similar message a couple of weeks ago, but I think thread warrants the same kind of message: Let’s clam it down some. A gentle reminder to keep it professional; see the IETF Guidelines for Conduct (RFC 7154). I would also like to note that discussion of various algorithms merits and usage is appropriate for this list. However, please keep the discussion focused on the technical issues and not stray into speculation on the personal motivation of statements made here or in other forums. spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Working Group Last Call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3
Hi! WGLC ends on Wednesday. I know this I-D is not all that exciting and most of the “discussion" was about whether to adopt the I-D at all, but it would be great if we had a couple of more people chime in. If you remember, when we used the show of hands tool to help determine whether there was consensus to adopt this draft there were 36 who wanted it adopted. spt > On May 28, 2024, at 09:44, Sean Turner wrote: > > Just a reminder that this WGLC is still ongoing. > > spt > >> On May 22, 2024, at 10:14, Sean Turner wrote: >> >> This email starts the working group last call for "Legacy RSASSA-PKCS1-v1_5 >> codepoints for TLS 1.3” I-D, located here: >> >> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-pkcs1/ >> >> The WG Last Call will end 5 June 2024 @ 2359 UTC. >> >> Please review the I-D and submit issues and pull requests via the GitHub >> repository that can be found at: >> >> https://github.com/tlswg/tls13-pkcs1 >> >> Alternatively, you can also send your comments to tls@ietf.org. >> >> Thanks, >> spt > ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Consensus Call: -rfc8446bis PRs #1343 & #1345
Since draft-ietf-tls-rfc8446bis last completed WGLC, two PRs have been submitted (and discussed) that include changes to normative language: - #1343: Forbid the sender from sending redundant update_requested KeyUpdates https://github.com/tlswg/tls13-spec/pull/1343 - #1345: Forbid the sender from sending duplicate supported groups entries https://github.com/tlswg/tls13-spec/pull/1354 The discussion so far seems to support consensus to merge these PRs. If you object, please do so on the issue or in response to this message. Absent any pushback, we will direct the editors to incorporate them in two weeks' time. Cheers, spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Fwd: Registration Open for IETF 120 Vancouver, 20-26 July 2024
In case you missed it, here is the meeting announcement for IETF 120. Early Bird registration is available until 03 June 2024 UTC 23:59. spt > Begin forwarded message: > > From: IETF Chair > Subject: Registration Open for IETF 120 Vancouver, 20-26 July 2024 > Date: April 17, 2024 at 12:20:06 EDT > To: , > Reply-To: admin-disc...@ietf.org > > IETF 120 Vancouver > 20-26 July, 2024 > Hosted by Huawei > > I am pleased to announce that registration is now open for IETF 120 > Vancouver, 20-26 July 2024: > >https://registration.ietf.org > > Register now at SUPER EARLY rates before 4 June: > > Onsite >Week Pass: $875 >One-day Pass: $470 >Full-time Student Week Pass: $150 > Remote >Week Pass: $250 >One-day Pass: $140 >Full-time Student Week Pass: $55 > >> From 4 June, EARLY rates will apply and from 9 July, STANDARD rates. Full >> details of all rates are on the registration site linked above. A special >> thanks to those people who choose to buy a STANDARD rate registration early >> to help fund the IETF. > > Please note: > * All fees are in USD and all dates in UTC > * Payment must be made in full by the listed date to take advantage of Super > Early or Early rates. > * It is still possible to register solely for the IETF Hackathon at no > charge. > * You must have an IETF Datatracker account to both register and participate > in this meeting. If you don’t already have one, you can create it during the > registration process. > > # Remote participation fee waivers > We understand that not everyone can afford the remote registration fee and so > we make an unlimited number of remote participation fee waivers available. > This operates on a trust basis with no checks on eligibility, and the list of > fee waiver recipients is kept confidential. If you wish to participate > remotely but cannot afford the registration fee then please take the fee > waiver option: > > https://www.ietf.org/meeting/registration-fee-waivers/ > > # Registration changes and cancellation > If you register for onsite participation and wish to change to an online > registration then you can cancel with a full refund and re-register. If you > wish to cancel your registration for any other reason please contact us at > supp...@ietf.org. Please request any cancellations and refunds by contacting > us at supp...@ietf.org before 15 July 2024 UTC. > > Further details about IETF Meeting registration, including terms and > conditions, are available at: > > https://www.ietf.org/meeting/terms-and-conditions/ > > # Meeting venue and hotel reservations > The meeting venue is the Hyatt Regency Vancouver, which is also the main IETF > hotel. In addition, we have rooms as available at the Sheraton Vancouver > Wall Center, while further options are being explored. Details can be found > on the IETF 120 Meeting Venue and Hotel page: > > https://www.ietf.org/meeting/120/hotel > > PLEASE NOTE: Room availability across Vancouver during this week is expected > to be very low as there are other large events happening over this time, > leading to very high guest room rates. We encourage you to book early for > IETF 120. To ensure that our room block is only used by IETF participants, > the link to register is only provided after registration and should not be > shared. > > # eTAs and Visas > Thanks to Telus, a Connectivity Sponsor for IETF 120, for generously > providing our IETF 120 letter of invitation (LOI). > > Please note that in order to enter Canada, you will be required to have a > valid passport and potentially either a visa or an Electronic Travel > Authorization (eTA). Additional information can be found by visiting the > Canadian Government Immigration website, linked below. If you need a visa to > travel to Canada, you can request a LOI from your attendee dashboard after > registering for the meeting. If you have issues regarding your LOI, please > contact us directly at supp...@ietf.org. > > Electronic Travel Authorization and Visa Information: > > https://ircc.canada.ca/english/visit/visas.asp > > # Agenda > A preliminary agenda will be published on 21 June. Full details about the > meeting are available at: > >https://www.ietf.org/meeting/120/ > > # Childcare > We will be offering onsite childcare free to participants for children ages > 0-12 from Saturday, 20 July through Friday, 26 July during the meeting day. > Registering your children early is suggested, as space will be limited. The > link to register your child(ren) will be available via your attendee > dashboard soon. If you have any questions then please contact us at > supp...@ietf.org. > > Jay > > ___ > Recentattendees mailing list > recentattend...@ietf.org > https://www.ietf.org/mailman/listinfo/recentattendees ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email t
[TLS]Re: Working Group Last Call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3
Just a reminder that this WGLC is still ongoing. spt > On May 22, 2024, at 10:14, Sean Turner wrote: > > This email starts the working group last call for "Legacy RSASSA-PKCS1-v1_5 > codepoints for TLS 1.3” I-D, located here: > > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-pkcs1/ > > The WG Last Call will end 5 June 2024 @ 2359 UTC. > > Please review the I-D and submit issues and pull requests via the GitHub > repository that can be found at: > > https://github.com/tlswg/tls13-pkcs1 > > Alternatively, you can also send your comments to tls@ietf.org. > > Thanks, > spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: I-D Action: draft-ietf-tls-tls13-pkcs1-01.txt
Hi! I asked the authors to spin a new version because the I-D would have expired during the WGLC. No substantive changes were introduced in this the -01 version. spt > On May 23, 2024, at 16:44, internet-dra...@ietf.org wrote: > > Internet-Draft draft-ietf-tls-tls13-pkcs1-01.txt is now available. It is a > work item of the Transport Layer Security (TLS) WG of the IETF. > > Title: Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3 > Authors: David Benjamin >Andrei Popov > Name:draft-ietf-tls-tls13-pkcs1-01.txt > Pages: 7 > Dates: 2024-05-23 > > Abstract: > > This document allocates code points for the use of RSASSA-PKCS1-v1_5 > with client certificates in TLS 1.3. This removes an obstacle for > some deployments to migrate to TLS 1.3. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-pkcs1/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-tls-tls13-pkcs1-01.html > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-tls13-pkcs1-01 > > 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]Re: WG Adoption for TLS Trust Expressions
Hi! Let’s clam it down some in this thread. Just a gentle reminder to keep it professional. Thanks, spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: progressing -rrc
> On May 22, 2024, at 10:09, Sean Turner wrote: > > Hi! If you recall we paused progressing -rrc [1] while we awaited > implementations. Well, we now have that; we have one server and two clients > (all DTLS 1.2) [2]. However, we now also have the formal analysis triage > panel so we need to run the I-D through them. Once we run the I-D through > that process we will revisit progressing the I-D. I [have noted / will note] > in the datatracker that the document is awaiting external review. > > Cheers, > spt > > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-rrc/ > [2] https://github.com/tlswg/dtls-rrc/issues/72 I should have added that we are sending this I-D to the formal analysis triage team because this I-D might be changing security assumptions in DTLS 1.3 or extending it and generally we want those sort of changes to TLS 1.3 evaluated. You’ll note we are not suggesting passing the Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3 I-D to them. Cheers, spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Working Group Last Call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3
> On May 22, 2024, at 10:28, David Benjamin wrote: > > On Wed, May 22, 2024 at 10:27 AM Salz, Rich > wrote: > > This email starts the working group last call for "Legacy RSASSA-PKCS1-v1_5 > > codepoints for TLS 1.3” I-D, located here: > > No comments, ship it. > > > The only comment/question I have about this I-D (and I hope this is not too > > much of a bikeshed) is whether the Recommended column should be “D” instead > > of “N”. > > I think that would be a mistake as it makes the vast deployment of existing > TPM machines nonconformant. In a few years, maybe. For now, not-recommended > is strong enough. > > (I don't have strong feelings on this and am happy to defer this to what > everyone else wants. Just briefly noting that "N" in the document isn't an > explicit preference here. "D" just didn't exist at the time the document was > written.) I figured this was the case. Part of the reason for raising this point now is to tell the IESG that we actually thought about it when somebody asks about whether we considered “D”. spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Re: Working Group Last Call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3
> On May 22, 2024, at 10:14, Sean Turner wrote: > > This email starts the working group last call for "Legacy RSASSA-PKCS1-v1_5 > codepoints for TLS 1.3” I-D, located here: > > https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-pkcs1/ > > The WG Last Call will end 5 June 2024 @ 2359 UTC. > > Please review the I-D and submit issues and pull requests via the GitHub > repository that can be found at: > > https://github.com/tlswg/tls13-pkcs1 > > Alternatively, you can also send your comments to tls@ietf.org. The only comment/question I have about this I-D (and I hope this is not too much of a bikeshed) is whether the Recommended column should be “D” instead of “N”. spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]Working Group Last Call for Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3
This email starts the working group last call for "Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3” I-D, located here: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-pkcs1/ The WG Last Call will end 5 June 2024 @ 2359 UTC. Please review the I-D and submit issues and pull requests via the GitHub repository that can be found at: https://github.com/tlswg/tls13-pkcs1 Alternatively, you can also send your comments to tls@ietf.org. Thanks, spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS]progressing -rrc
Hi! If you recall we paused progressing -rrc [1] while we awaited implementations. Well, we now have that; we have one server and two clients (all DTLS 1.2) [2]. However, we now also have the formal analysis triage panel so we need to run the I-D through them. Once we run the I-D through that process we will revisit progressing the I-D. I [have noted / will note] in the datatracker that the document is awaiting external review. Cheers, spt [1] https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-rrc/ [2] https://github.com/tlswg/dtls-rrc/issues/72 ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
Re: [TLS] [EXTERNAL] Re: WG Adoption for TLS Trust Expressions
Ekr (and others from off-list msgs), Don’t worry the chairs are paying attention. And, yeah we’ll need to start something formal, but this thread is doing its job for now. BTW since we’d talked to Devon and Co. a lot about this I-D, I took inclusion of that phrase as a slip of the tongue so to speak. But, going forward a “hey are you interested in my I-D” emails shouldn’t read “hey I’m kicking off a WG adoption call” ;) spt > On Apr 29, 2024, at 09:43, Eric Rescorla wrote: > > Hi folks, > > I haven't yet formed an opinion on this document yet, but I did want to > observe that calls for adoption are issued by the chairs, not by individual > participants. Of course, anyone can start a thread and comments in this > thread are information for the chairs, but if adoption does happen, it will > be via some separate process. > > -Ekr > > > On Sat, Apr 27, 2024 at 11:42 AM Brendan McMillion > wrote: > Hi Devon > > I support adoption > > On Fri, Apr 26, 2024 at 7:38 PM Andrei Popov > wrote: > I support adoption. > > Cheers, > > Andrei > > -Original Message- > From: TLS On Behalf Of Watson Ladd > Sent: Friday, April 26, 2024 7:13 PM > To: Devon O'Brien > Cc: tls@ietf.org; Bob Beck > Subject: [EXTERNAL] Re: [TLS] WG Adoption for TLS Trust Expressions > > On Tue, Apr 23, 2024 at 1:39 PM Devon O'Brien > wrote: > > > > After sharing our first draft of TLS Trust Expressions and several > > discussions across a couple IETFs, we’d like to proceed with a call for > > working group adoption of this draft. We are currently prototyping trust > > expressions in BoringSSL & Chromium and will share more details when > > implementation is complete. > > > > > > As we mentioned in our message to the mailing list from January, our > > primary goal is to produce a mechanism for supporting multiple subscriber > > certificates and efficiently negotiating which to serve on a given TLS > > connection, even if that ends up requiring significant changes to the draft > > in its current state. > > > > > > To that end, we’re interested in learning whether wg members support > > adoption of this deployment model and the currently-described certificate > > negotiation mechanism or if they oppose adoption (and why!). > > We absolutely need to solve the problem and the draft is a good starting > point. > > > > > > > Thanks! > > > > David, Devon, and Bob > > > > > > ___ > > TLS mailing list > > TLS@ietf.org > > https://www/. > > ietf.org%2Fmailman%2Flistinfo%2Ftls&data=05%7C02%7CAndrei.Popov%40micr > > osoft.com%7C6ca75aa932344f322d9f08dc665fa375%7C72f988bf86f141af91ab2d7 > > cd011db47%7C1%7C0%7C638497808164901299%7CUnknown%7CTWFpbGZsb3d8eyJWIjo > > iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C% > > 7C&sdata=2n8iljUXBtb4Jf%2FZTqN2Nl5j81WoatTYA64c5%2FRoH0A%3D&reserved=0 > > > > -- > Astra mortemque praestare gradatim > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] -rfc8447bis: s15 ambiguity
Hi! I submitted the following PR to address the point Rich and ekr discussed about an ambiguity in s15 of -rfc8447bis: https://github.com/tlswg/rfc8447bis/pull/56 Cheers, spt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] -draft8447bis: rename Support Group Elliptic curve groups space
To me, it looks like we have rough agreement to change the note as specified in the PR. spt > On Mar 28, 2024, at 10:52, Sean Turner wrote: > > > > **WARNING: Potential bikeshed** > > -connolly-tls-mlkem-key-agreement has suggested that code points for the NIST > PQ be registered in the TLS Supported Groups IANA registry [1]. Currently > [2], the registry is carved up into three blocks as follows: > > Range: 0-255, 512-65535 > Registration Procedures: Specification Required > Note: Elliptic curve groups > > Range 256-511 > Registration Procedures: Specification Required > Note: Finite Field Diffie-Hellman groups > > Assuming that the proposal in -connolly-tls-mlkem-key-agreement is the path > for PQ KEM algorithms (and maybe regardless of whether this is the path), we > should really replace the “Elliptic curve groups” note in the 0-255, > 512-65535 range row with something else. I am open to suggestions, but would > like to propose “unallocated”. I have submitted the following issue: > https://github.com/tlswg/rfc8447bis/issues/54 > and this PR: > https://github.com/tlswg/rfc8447bis/pull/55 > to address this. > > spt > > [1] > https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 > > [2] Originally, RFC 8442 defined the name of the registry as "EC Named Curve > Registry” and then RFC 7919 re-named it “Supported Groups” and carved out the > FFDH space. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Dnsdir early review of draft-ietf-tls-svcb-ech-01
Ted & ErikN, So it looks like ErikN submitted the following PR and ekr approved: https://github.com/tlswg/draft-ietf-tls-svcb-ech/pull/1 If we have resolved your comments, can I ask on of the authors to spin a new version and we can look to move this I-D. Also, could I kindly ask you to revise your review to change to “ready” and maybe refer to thread: https://mailarchive.ietf.org/arch/msg/tls/VQcqUuOXSE8sgcp4_CHa6Jlc394/ spt > On Mar 30, 2024, at 19:17, Eric Rescorla wrote: > > > > On Sat, Mar 30, 2024 at 11:09 AM Ted Lemon wrote: > Encrypted dns transport works if you can trust the provider you are talking > to. DNSSEC works even if you can’t. And if your provider is trustworthy, > DNSSEC validation of results acquired through this tunnel should work. So > it’s silly in this case to trust the tunnel—there’s no upside to doing so > other than avoiding a few signature verifications. > > I don't object to people doing DNSSEC validation of ECH records (though AFAIK > no major browser does so), but... > > 1. The resolver only gains a limited amount by forging the SVCB response > because the resolver already knows the domain name you are going to. This > does conceal (say) the ALPN, but that's usually less interesting than the SNI. > 2. If the authoritative domain is misconfigured, which is not unheard of, > then this can create resolution failures (this is true for A/, of > course). Probably not much of an issue for the big public recursives, but can > definitely be an issue if you are just talking to some locally-supplied > resolver. > > -Ekr > > > Op za 30 mrt 2024 om 14:02 schreef Rob Sayre > On Sat, Mar 30, 2024 at 10:47 AM Erik Nygren wrote: > > An attacker who can prevent SVCB resolution can deny clients any associated > security benefits. > > Yes. > > A hostile recursive resolver can always deny service to SVCB queries, but > network intermediaries can often prevent resolution as well, even when the > client and recursive resolver validate DNSSEC and use a secure transport. > These downgrade attacks can prevent a client from being aware that "ech" is > configured which would result in the client sending the ClientHello in > cleartext. > > I think s/would/could/ here. > > I don't know if we want to write it, but doesn't using encrypted transport > DNS to an IP address avoid this problem? Like using 1.1.1.1 or 8.8.8.8 etc. I > know that raises centralization issues, but it does help with this issue. > > thanks, > Rob > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Working Group Last Call for SSLKEYLOG File
Noted in the Shepherd write-up. spt > On Apr 2, 2024, at 20:30, Stephen Farrell wrote: > > > Hiya, > > This is basically for the record and not an objection to proceeding. > > On 02/04/2024 17:34, Sean Turner wrote: >> This WGLC has concluded. There is consensus to move this document forward. >> The material change was to add a security consideration about forward >> secrecy guarantees being negated if the key material is leaked: >> https://github.com/tlswg/sslkeylogfile/pull/7/files >> We will not be asking the formal analysis folks to weigh in on this I-D; we >> all know the file’s content are the keys to the kingdom. >> Martin: If you can spin a new version, I can get the Shepherd write-up >> drafted. > > I like the addition in -01 but would still have preferred if we > weren't so awfully oblique about the consequences of running a > production system with this logging enabled. > > Were it up to me (and it's not) I'd suggest an additional addition > along the lines of: > > "Systems that enable logging as described here are (while logging > is enabled) unlikely to be consistent with requirements to make use > of state-of-the-art protections, as e.g. is called-for by GDPR > article 32 [1]" > > I suppose one could also re-do the above suggested text to refer > to RFC6919, section 3:-) [2] > > Again, I'm not objecting to proceeding, just bemoaning what I see > as us being so oddly timid in calling out real issues. > > Cheers, > S. > > [1] https://gdpr-info.eu/art-32-gdpr/ > [2] https://datatracker.ietf.org/doc/html/rfc6919#section-3 > >> spt >>> On Mar 28, 2024, at 09:24, Sean Turner wrote: >>> >>> Just a reminder that this WGLC ends soon! >>> >>> spt >>> >>>> On Mar 12, 2024, at 10:57, Sean Turner wrote: >>>> >>>> This is the working group last call for the SSLKEYLOGFILE Format for TLS >>>> Internet-Draft [1]. Please indicate if you think the I-D is ready to >>>> progress to the IESG and send any comments to the list by 31 March 2024. >>>> >>>> The GH repo for the I-D can be found at [2]. >>>> >>>> Thanks, >>>> >>>> Joe, Deirdre, and Sean >>>> >>>> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ >>>> [2] https://github.com/tlswg/sslkeylogfile >>> >> ___ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Transfer of change control for SSLKEYLOGFILE format
Martin, Thanks for this. This was noted in the Shepherd write-up for the IESG to find during their deliberations. Cheers, spt > On Apr 3, 2024, at 23:14, Martin Thomson wrote: > > Hey, > > I'm writing this in my capacity as owner for NSS[1], not as a draft author. > > The chairs asked that I formally indicate that Mozilla and the NSS project > are willing to transfer ownership of the SSLKEYLOGFILE format[2]. Though it > might be obvious to some of us that submitting an Internet-Draft implies that > willingness, we might as well make it formal. > > Mozilla and the NSS project are happy to transfer ownership of the > SSLKEYLOGFILE format to the IETF. > > Thanks, > Martin > > [1] https://firefox-source-docs.mozilla.org/mots/index.html#core-security > [2] https://datatracker.ietf.org/doc/html/draft-ietf-tls-keylogfile > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Publication has been requested for draft-ietf-tls-keylogfile-01
Sean Turner has requested publication of draft-ietf-tls-keylogfile-01 as Informational on behalf of the TLS working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Adoption call for TLS Flag - Request mTLS
At the IETF 119 TLS session there was some interest in the mTLS Flag I-D (https://datatracker.ietf.org/doc/draft-jhoyla-req-mtls-flag/); also, see previous list discussions at [0]. This message is to judge consensus on whether there is sufficient support to adopt this I-D. If you support adoption and are willing to review and contribute text, please send a message to the list. If you do not support adoption of this I-D, please send a message to the list and indicate why. This call will close on 16 April 2024. Thanks, Deirdre, Joe, and Sean [0] https://mailarchive.ietf.org/arch/msg/tls/9e2S95H9YgtHp5HhqdlNqmQP0_w/ ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Working Group Last Call for ECH
Addressed via:
https://github.com/tlswg/draft-ietf-tls-esni/pull/613
spt
> On Apr 2, 2024, at 10:46, Russ Housley wrote:
>
> Signed PGP part
> Thanks.
>
> This URL gives access without a paywall:
> https://www.cs.ox.ac.uk/people/vincent.cheval/publis/BCW-ccs22.pdf
>
> Russ
>
>> On Apr 2, 2024, at 10:31 AM, Stephen Farrell
>> wrote:
>>
>>
>> Hiya,
>>
>> On 02/04/2024 15:17, Russ Housley wrote:
>>> Joe:
>>> The ECH Internet-Draft includes this reference:
>>>[ECH-Analysis]
>>> "A Symbolic Analysis of Privacy for TLS 1.3 with Encrypted
>>> Client Hello", November 2022.
>>
>> I'm guessing that'd be:
>>
>> @inproceedings{bhargavan2022symbolic,
>> title={A symbolic analysis of privacy for tls 1.3 with encrypted client
>> hello},
>> author={Bhargavan, Karthikeyan and Cheval, Vincent and Wood, Christopher},
>> booktitle={Proceedings of the 2022 ACM SIGSAC Conference on Computer and
>> Communications Security},
>> pages={365--379},
>> year={2022}
>> }
>>
>> Cheers,
>> S.
>>
>>> This reference does not provide enough information for anyone to locate the
>>> document. I think a reference that everyone can locate is needed here.
>>> Russ
>>>> On Apr 1, 2024, at 6:12 PM, Joseph Salowey wrote:
>>>>
>>>> This WGLC has concluded. There is consensus to move this document
>>>> forward. I think there are one or two minor changes proposed that should
>>>> be incorporated into the revision we forward to the IESG.
>>>>
>>>> Joe
>>>>
>>>> On Thu, Mar 28, 2024 at 6:23 AM Sean Turner >>> <mailto:s...@sn3rd.com>> wrote:
>>>>> Just a reminder that this WGLC ends soon!
>>>>>
>>>>> spt
>>>>>
>>>>>> On Mar 11, 2024, at 18:00, Joseph Salowey >>>>> <mailto:j...@salowey.net>> wrote:
>>>>>>
>>>>>> This is the working group last call for TLS Encrypted Client Hello [1].
>>>>>> Please indicate if you think the draft is ready to progress to the IESG
>>>>>> and send any comments to the list by 31 March 2024. The comments sent
>>>>>> by Watson Ladd to the list [2] on 17 February 2024 will be considered
>>>>>> last call comments.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Joe, Deirdre, and Sean
>>>>>>
>>>>>> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/
>>>>>> [2]
>>>>>> https://mailarchive.ietf.org/arch/msg/tls/XUCFuNBSQfSJclkhLW-14DZ0ETg/
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[TLS] review requests for -svcb-ech and -wkech
Hi! You might have seen the DNSDIR and ARTART Directorate reviews recently for -svcb-ech and -wkech, respectively. The chairs are asking for these now that the ECH I-D has completed WGLC. We have also requested DNSDIR/DNSOP and HTTPbis review. Ditto on the HTTPbis review for -svcb-ech. Threads can be followed here: DNSOP: https://mailarchive.ietf.org/arch/msg/dnsop/lbTdtFZqB3kHS1iU7U4cve7DgZ0/ HTTPbis: https://lists.w3.org/Archives/Public/ietf-http-wg/2024AprJun/.html Cheers, spt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Working Group Last Call for SSLKEYLOG File
This WGLC has concluded. There is consensus to move this document forward. The material change was to add a security consideration about forward secrecy guarantees being negated if the key material is leaked: https://github.com/tlswg/sslkeylogfile/pull/7/files We will not be asking the formal analysis folks to weigh in on this I-D; we all know the file’s content are the keys to the kingdom. Martin: If you can spin a new version, I can get the Shepherd write-up drafted. spt > On Mar 28, 2024, at 09:24, Sean Turner wrote: > > Just a reminder that this WGLC ends soon! > > spt > >> On Mar 12, 2024, at 10:57, Sean Turner wrote: >> >> This is the working group last call for the SSLKEYLOGFILE Format for TLS >> Internet-Draft [1]. Please indicate if you think the I-D is ready to >> progress to the IESG and send any comments to the list by 31 March 2024. >> >> The GH repo for the I-D can be found at [2]. >> >> Thanks, >> >> Joe, Deirdre, and Sean >> >> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ >> [2] https://github.com/tlswg/sslkeylogfile > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] I-D Action: draft-ietf-tls-svcb-ech-01.txt
Hi! I am going to kick off some early reviews from the DNS and HTTP directorates to see if we get anything back. spt > On Mar 27, 2024, at 16:37, internet-dra...@ietf.org wrote: > > Internet-Draft draft-ietf-tls-svcb-ech-01.txt is now available. It is a work > item of the Transport Layer Security (TLS) WG of the IETF. > > Title: Bootstrapping TLS Encrypted ClientHello with DNS Service Bindings > Authors: Ben Schwartz >Mike Bishop >Erik Nygren > Name:draft-ietf-tls-svcb-ech-01.txt > Pages: 6 > Dates: 2024-03-27 > > Abstract: > > To use TLS Encrypted ClientHello (ECH) the client needs to learn the > ECH configuration for a server before it attempts a connection to the > server. This specification provides a mechanism for conveying the > ECH configuration information via DNS, using a SVCB or HTTPS record. > > The IETF datatracker status page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-svcb-ech/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-tls-svcb-ech-01.html > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-svcb-ech-01 > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > ___ > I-D-Announce mailing list > i-d-annou...@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] -draft8447bis: rename Support Group Elliptic curve groups space
**WARNING: Potential bikeshed** -connolly-tls-mlkem-key-agreement has suggested that code points for the NIST PQ be registered in the TLS Supported Groups IANA registry [1]. Currently [2], the registry is carved up into three blocks as follows: Range: 0-255, 512-65535 Registration Procedures: Specification Required Note: Elliptic curve groups Range 256-511 Registration Procedures: Specification Required Note: Finite Field Diffie-Hellman groups Assuming that the proposal in -connolly-tls-mlkem-key-agreement is the path for PQ KEM algorithms (and maybe regardless of whether this is the path), we should really replace the “Elliptic curve groups” note in the 0-255, 512-65535 range row with something else. I am open to suggestions, but would like to propose “unallocated”. I have submitted the following issue: https://github.com/tlswg/rfc8447bis/issues/54 and this PR: https://github.com/tlswg/rfc8447bis/pull/55 to address this. spt [1] https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 [2] Originally, RFC 8442 defined the name of the registry as "EC Named Curve Registry” and then RFC 7919 re-named it “Supported Groups” and carved out the FFDH space. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Working Group Last Call for SSLKEYLOG File
Minor suggestion to refer to -rfc84446bis: https://github.com/tlswg/sslkeylogfile/pull/8 aka let’s make a cluster! spt > On Mar 12, 2024, at 10:57, Sean Turner wrote: > > This is the working group last call for the SSLKEYLOGFILE Format for TLS > Internet-Draft [1]. Please indicate if you think the I-D is ready to progress > to the IESG and send any comments to the list by 31 March 2024. > > The GH repo for the I-D can be found at [2]. > > Thanks, > > Joe, Deirdre, and Sean > > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ > [2] https://github.com/tlswg/sslkeylogfile ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Working Group Last Call for SSLKEYLOG File
Just a reminder that this WGLC ends soon! spt > On Mar 12, 2024, at 10:57, Sean Turner wrote: > > This is the working group last call for the SSLKEYLOGFILE Format for TLS > Internet-Draft [1]. Please indicate if you think the I-D is ready to progress > to the IESG and send any comments to the list by 31 March 2024. > > The GH repo for the I-D can be found at [2]. > > Thanks, > > Joe, Deirdre, and Sean > > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ > [2] https://github.com/tlswg/sslkeylogfile ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Working Group Last Call for ECH
Just a reminder that this WGLC ends soon! spt > On Mar 11, 2024, at 18:00, Joseph Salowey wrote: > > This is the working group last call for TLS Encrypted Client Hello [1]. > Please indicate if you think the draft is ready to progress to the IESG and > send any comments to the list by 31 March 2024. The comments sent by Watson > Ladd to the list [2] on 17 February 2024 will be considered last call > comments. > > Thanks, > > Joe, Deirdre, and Sean > > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ > [2] https://mailarchive.ietf.org/arch/msg/tls/XUCFuNBSQfSJclkhLW-14DZ0ETg/ > > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] dispatching DTLS 1.2 errata
Hi! We’ve got 8 reported errata on DTLS 1.2 (RFC 6347): https://www.rfc-editor.org/errata_search.php?rfc=6347&rec_status=15&presentation=records that we, the royal we where we is the WG, need to dispatch. By way of background, the IESG has the following statement about processing errata on the IETF stream: https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/ Based on the IESG statement, please let me know by 3 April if you disagree with the following proposed resolutions: 1. https://www.rfc-editor.org/errata/eid3917 Proposed dispatch: reject Rationale: RFC 9147 obsoletes RFC 6347 and extensions is added to the ClientHello struct (see s5.3). 2. https://www.rfc-editor.org/errata/eid4103 Proposed dispatch: reject Rationale: RFC 9147 obsoletes RFC 6347 and HelloVerifyRequest is no longer applicable to DTLS 1.3. 3. https://www.rfc-editor.org/errata/eid5186 Proposed dispatch: reject Rationale: RFC 9147 obsoletes RFC 6347 and the section in question was extensively revised; the offending text is removed or no longer applies. 4. https://www.rfc-editor.org/errata/eid4104 Proposed dispatch: reject Rationale: RFC 9147 obsoletes RFC 6347and the paragraph in questions was extensively revised; the offending text is removed. 5. https://www.rfc-editor.org/errata/eid4105 Proposed dispatch: reject Rationale: RFC 9147 obsoletes RFC 6347 and the two sections were merged into one. 6. https://www.rfc-editor.org/errata/eid4642 Proposed dispatch: reject Rationale: RFC 9147 obsoletes RFC 6347, the field has been renamed, and the field’s explanation updated. 7. https://www.rfc-editor.org/errata/eid5903 Proposed dispatch: reject Rationale: RFC 9147 obsoletes RFC 6347 and the paragraph in questions was extensively revised; the offending text is reworded. 8. https://www.rfc-editor.org/errata/eid5026 Proposed dispatch: reject Rationale: RFC 9147 obsoletes RFC 6347 and the 2119-language for the length is no longer in RFC 9147. Cheers, spt ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] TLSFlags ambiguity
I just threw in a couple of PRs to align this I-D with 8446bis & 8447bis, but forgot to add this issue. I have corrected this now so that we won’t forget again: https://github.com/tlswg/tls-flags/issues/36 spt > On Mar 17, 2024, at 13:53, David Benjamin wrote: > > Did this ever get resolved? I noticed that there was a draft-13 cut, but the > issue Jonathan pointed out was still there. > > Looking at Section 2 again, it's actually even goofier than the original > email suggests. Section 2 first says: > > > The FlagExtensions field contains 8 flags in each octet. The length of the > > extension is the minimal length that allows it to encode all of the present > > flags. Within each octet, the bits are packed such that the first bit is > > the least significant bit and the eighth bit is the most significant. > > This is LSB first. Then there's an example, which is also LSB first: > > > For example, if we want to encode only flag number zero, the FlagExtension > > field will be 1 octet long, that is encoded as follows: > > > >0001 > > So that's all consistent. But then the last paragraph of section 2 says: > > > Note that this document does not define any particular bits for this > > string. That is left to the protocol documents such as the ones in the > > examples from the previous section. Such documents will have to define > > which bit to set to show support, and the order of the bits within the bit > > string shall be enumerated in network order: bit zero is the high-order bit > > of the first octet as the flags field is transmitted. > > This says it's MSB first for some reason. But this is not only inconsistent, > but also redundant with the text at the start of section 2. It seems to me we > could simply delete the redundant text and move on: > > > Note that this document does not define any particular bits for this > > string. That is left to the protocol documents such as the ones in the > > examples from the previous section. Such documents will have to define > > which bit to set to show support. > > David > > On Wed, Sep 27, 2023, 17:50 David Benjamin wrote: > Nice catch! I agree those don't match. I think bit zero should be the > least-significant bit. That is, we should leave the examples as-is and then > fix the specification text. > > Ordering bits MSB first doesn't make much sense. Unlike bytes, there is no > inherent order to bits in memory, so the most natural order is the power of > two represented by the bit. Put another way, everyone accesses bit N by > ANDing with 1 << N and that's least-significant bits first. I can think of a > couple systems (DER, GCM) that chose to order bits most-significant first and > both have caused endless confusion and problems. (It's particularly bad for > GCM which is actually representing a polynomial, but then messed up the > order. Let's not repeat this blunder.) > > On Fri, Sep 15, 2023 at 1:37 PM Jonathan Hoyland > wrote: > Hi TLSWG, > > I'm working on implementing the TLS Flags extension, and I just wanted to > clarify a potential ambiguity in the spec. > > In Section 2 the spec says: > Such documents will have to define which bit to set to show support, and the > order of the bits within the bit string shall be enumerated in network order: > bit zero is the high-order bit of the first octet as the flags field is > transmitted. > > And also gives the example for encoding bit zero: > For example, if we want to encode only flag number zero, the FlagExtension > field will be 1 octet long, that is encoded as follows: >0001 > In which it seems that the low-order bit of the first octet represents zero. > > I have no preference either way, but when transmitted on the wire, should > flag 0 be transmitted as > 0x01 or 0x80? > > Regards, > > Jonathan > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Technical Errata Reported] RFC6066 (5658)
I suspect that this errata should be rejected. RFC 6125 was published months after RFC 6066 and that makes this addition feel “new" to me and as such it’s inappropriate to change through the errata process; see [1]. spt [1] https://datatracker.ietf.org/doc/statement-iesg-iesg-processing-of-rfc-errata-for-the-ietf-stream-20210507/ > On Mar 15, 2019, at 05:35, RFC Errata System > wrote: > > The following errata report has been submitted for RFC6066, > "Transport Layer Security (TLS) Extensions: Extension Definitions". > > -- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5658 > > -- > Type: Technical > Reported by: Owen Friel > > Section: 3 > > Original Text > - > > > Corrected Text > -- > When a client uses DNS SRV to discover and connect to a server, the > client SHOULD include the "source domain" in the "host_name" and SHOULD > NOT include the "derived domain", where "source domain" and "derived > domain" are defined in RFC6125. > > Notes > - > The original text is all fine, but it is missing some additional clarifying > text on use of SNI when a client users DNS SRV to discover the service it is > connecting to. > > Instructions: > - > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -- > RFC6066 (draft-ietf-tls-rfc4366-bis-12) > -- > Title : Transport Layer Security (TLS) Extensions: Extension > Definitions > Publication Date: January 2011 > Author(s) : D. Eastlake 3rd > Category: PROPOSED STANDARD > Source : Transport Layer Security > Area: Security > Stream : IETF > Verifying Party : IESG ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Editorial Errata Reported] RFC6176 (5536)
Paul, I think you can mark this one as verified. I don’t think anybody is really confused by not citing 2446 in the 1st sentence but the quoted sentence is in RFC 2446 so as suggested the sentence is still true. spt > On Oct 19, 2018, at 23:33, RFC Errata System > wrote: > > The following errata report has been submitted for RFC6176, > "Prohibiting Secure Sockets Layer (SSL) Version 2.0". > > -- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5536 > > -- > Type: Editorial > Reported by: Eugene Adell > > Section: 1 > > Original Text > - > RFC 4346 [TLS1.1], and later RFC 5246 [TLS1.2], explicitly warned > implementers that the "ability to send version 2.0 CLIENT-HELLO > messages will be phased out with all due haste". This document > accomplishes this by updating the backward compatibility sections > found in TLS [TLS1.0][TLS1.1][TLS1.2]. > > Corrected Text > -- > RFC 2246 [TLS1.0], and later RFC 4346 [TLS1.1], then RFC 5246 > [TLS1.2] explicitly warned implementers that the "ability to send > version 2.0 CLIENT-HELLO messages will be phased out with all due > haste". This document accomplishes this by updating the backward > compatibility sections found in TLS [TLS1.0][TLS1.1][TLS1.2]. > > Notes > - > The warning on the version 2.0 Client Hello is as old as the first TLS > version (RFC 2246 Appendix E). That's what the authors meant and wanted to > highlight by listing two of the three RFCs containing this warning. This is > confirmed by their last sentence. It looks like a small mistake without > concrete effects, I push this errata considering "IESG Processing of RFC > Errata for the IETF Stream rule 6" > > Instructions: > - > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -- > RFC6176 (draft-ietf-tls-ssl2-must-not-04) > -- > Title : Prohibiting Secure Sockets Layer (SSL) Version 2.0 > Publication Date: March 2011 > Author(s) : S. Turner, T. Polk > Category: PROPOSED STANDARD > Source : Transport Layer Security > Area: Security > Stream : IETF > Verifying Party : IESG ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Technical Errata Reported] RFC8448 (5645)
Hi! This has been lingering for a while, I tend to think we could mark it as HFDU (hold for document update). spt > On Feb 28, 2019, at 16:20, RFC Errata System > wrote: > > The following errata report has been submitted for RFC8448, > "Example Handshake Traces for TLS 1.3". > > -- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5645 > > -- > Type: Technical > Reported by: Anthony Mai > > Section: 2 > > Original Text > - > Ephemeral private keys are shown as they are generated in the traces. > > Corrected Text > -- > Ephemeral private keys are shown as they are generated in the traces. > Note that X25519 private keys are trimmed in accordance to [RFC 7748] > Section 5, before use. This is done by clearing bit 0 to 2 of the first > byte and bit 7 of the last byte. And then set bit 6 of the last byte. > > Notes > - > On page 3,5,16,20,29,43,44,55,57, there are ten X25519 ephemeral private > keys listed. None of these private key value, when used directly in X25519 > calculation, will yield the associated public key listed. These private key > values are not the actual values used. Instead up to 5 bits are modified as > recommended by RFC 7748 section 5. Some implementations may choose NOT to > do such trimming, and it does not affect the connectivity, as the private > keys are never sent over the wire and does not affect network behavior. > > Not clarifying how the X25519 private keys were modified before using could > cause serious confusion. I personally struggled for a day before figuring > out this little obscure detail. > > Instructions: > - > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -- > RFC8448 (draft-ietf-tls-tls13-vectors-07) > -- > Title : Example Handshake Traces for TLS 1.3 > Publication Date: January 2019 > Author(s) : M. Thomson > Category: INFORMATIONAL > Source : Transport Layer Security > Area: Security > Stream : IETF > Verifying Party : IESG ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Editorial Errata Reported] RFC8447 (6009)
Paul, You can go ahead and mark this one as Verified. The name of the 0 value is “X509”. spt > On Mar 7, 2020, at 13:08, RFC Errata System wrote: > > The following errata report has been submitted for RFC8447, > "IANA Registry Updates for TLS and DTLS". > > -- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6009 > > -- > Type: Editorial > Reported by: Benjamin Kaduk > > Section: 14 > > Original Text > - > o Added a "Recommended" column to the registry. X.509 and Raw > > > Corrected Text > -- > o Added a "Recommended" column to the registry. X509 and Raw > > > Notes > - > Update to match https://www.rfc-editor.org/errata/eid5976 > > Instructions: > - > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -- > RFC8447 (draft-ietf-tls-iana-registry-updates-05) > -- > Title : IANA Registry Updates for TLS and DTLS > Publication Date: August 2018 > Author(s) : J. Salowey, S. Turner > Category: PROPOSED STANDARD > Source : Transport Layer Security > Area: Security > Stream : IETF > Verifying Party : IESG ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Working Group Last Call for SSLKEYLOG File
This is the working group last call for the SSLKEYLOGFILE Format for TLS Internet-Draft [1]. Please indicate if you think the I-D is ready to progress to the IESG and send any comments to the list by 31 March 2024. The GH repo for the I-D can be found at [2]. Thanks, Joe, Deirdre, and Sean [1] https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ [2] https://github.com/tlswg/sslkeylogfile ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
