[TLS] Re: Publication has been requested for draft-ietf-tls-keylogfile-03
> On Apr 9, 2025, at 8:00 PM, Stephen Farrell wrote: > On 03/04/2025 14:42, Stephen Farrell wrote: >> On 03/04/2025 14:35, Sean Turner via Datatracker wrote: >>> Sean Turner has requested publication of draft-ietf-tls- >>> keylogfile-03 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/ >> Hang on - where was the outcome of the WGLC declared or >> summarised by the chairs? Where are the minutes for the >> IETF-122 meeting? >> I think you're skipping process steps here in a way that >> ought not be done, esp when there have been objections to >> this draft. (And I think I already asked that the poll at >> the meeting not be used as a declaration of consensus.) >> Please correct. I object to decisions not being made on >> the list when there is contention. > > I got no response from chairs or AD on or off list to the > above. Seems like bad form to me but maybe people were too > busy. > > I note that despite my request/objection, the IETF LC for > this has now been issued. I've objected there too. [1]. I > see that SM also had process comments on this too. [2] > > I do plan to appeal should this document not be sent back > to the WG to confirm whether or not there is WG consensus > to publish. (And publishing as-is is wrong of course:-) > > Cheers, > S. > > [1] > https://mailarchive.ietf.org/arch/msg/last-call/KFXyZbe_hi-0OjCtvORwyJm_wpo/ > [2] > https://mailarchive.ietf.org/arch/msg/last-call/fLGvbWNGBhux9c6crFJ1ZioKmLg/ Stephen, The minutes have now been posted; see [0]. Joe posted them for internal review, and I got my wires crossed that the minutes were not also published to the datatracker. I have updated the Shepherd Write-Up and brought your (and others) continued objections to progressing this draft. Likewise, I have discussed this with our AD at length. The points I believe you have made align the way (beyond don’t publish, this is a bad idea) are: 1. Strong Caveats/Warnings: When draft-thomson-tls-keylogfile was up for adoption, you were okay adopting it as long as there were sufficient warnings. The Security Considerations section includes much more text and an Applicability Statement section was added, which in particular notes this mechanism “MUST NOT” be used in production systems. When -ech-keylogfile, I believe there were more objections, but not a lot of support for more text. Now the drafts are combined, the text in the Security Considerations has been expanded to also include ECH and the Applicability Statement remains. Likewise, a PR has been landed and will appear when -04 is published that adds words specifically about the compilation issue [1]. As both drafts completed WGLC independently and now the draft is a combo, this point seems settled. 2. -ech-keylogfile is not needed because ECH is new. There were people who implemented ECH at scale who spoke in support of -ech-keylogfile. Also, -ech-keylogfile made it through WGLC; the only new comment beyond “make the warnings stronger and bigger” was to merge the draft together because it was odd that -ech-keylogfile was creating a registry for a draft so newly in the RFC editor’s queue. 3. Merging: During -ech-keylogfile, Rich suggested we merge it. I noted that that was going to happen when I closed out that WGLC. There were no objections. I noted that that merge had completed when -tls-keylogfile-03 was published; again, no objections to the initial note. 4. Specification Required vs IETF Review: This WG published RFC 8447 and -rfc8447bis is nearing completion. As you know, these documents set the registration requirements for almost all of the registries to Specification Required, which also implies expert review. This is true for the Cipher Suite & Support Groups. If the concern is about something slipping by the DEs, then we have bigger problems. The registration list is public [2], the DEs are known (Yoav, Rich, and Nick), and the DEs can raise registrations with the WG and have previously reported on registrations [3]. As you note I did not close out that WGLC; I should have, I will send a message in response to the WGLC thread referring to this message. While I know you would prefer to not use the informal poll we took at the IETF 122 session because it does not support your position it is nonetheless telling. But because I forgot about the change to add more compilation constraints in the Applicability Statement and we should confirm the discussions at IETF on list, we will get a new version posted and re-run the confirmation about progressing the draft call noting that there was strong consensus with some vocal opposition. Stay tuned. I have replied to S. Moonesmay. Cheers, spt [0] https://datatracker.ietf.org/doc/minutes-122-tls-202503200230/ [1] https://author-tools.ietf.org/api/iddiff?doc_1=draft-ietf-tls-keylogfile&url_2=https://tlswg.github.io/sslkeylogfil
[TLS] Re: 2nd Working Group Last Call for The SSLKEYLOGFILE Format for TLS
I was remiss in not closing this out. More discussion has gone over here: https://mailarchive.ietf.org/arch/msg/tls/GXE38LHQVJk219HPq5goi_HO81M/ spt > On Feb 7, 2025, at 10:52 AM, Sean Turner wrote: > > This email starts the 2nd working group last call for "The SSLKEYLOGFILE > Format for TLS” I-D, located here: > > https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ > > The WG Last Call will end 21 February 2025 @ 2359 UTC. > > Please review the I-D, which now incorporates draft-ietf-tls-ech-keylogfile, > and submit issues and pull requests via the GitHub repository that can be > found at: > > https://github.com/tlswg/sslkeylogfile > > 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] Confirming Consensus to Progress The SSLKEYLOGFILE Format for TLS
Hi! At IETF 122, the chairs took a sense of the room about whether to progress draft-ietf-tls-keylogfile. There was consensus to do so [0]. We need to confirm that on-list. If you disagree with the consensus please let us know, and why. We close this call at 1159 UTC on 29 April 2025. Cheers, spt [0] see minutes: https://datatracker.ietf.org/doc/minutes-122-tls-202503200230/ ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Confirming Consensus to Progress The SSLKEYLOGFILE Format for TLS
Hiya, On 11/04/2025 16:43, Sean Turner wrote: Hi! At IETF 122, the chairs took a sense of the room about whether to progress draft-ietf-tls-keylogfile. There was consensus to do so [0]. We need to confirm that on-list. If you disagree with the consensus please let us know, and why. We close this call at 1159 UTC on 29 April 2025. You can probably make a wild guess as to my position:-) From [0]: " Do you object to moving forward with the publication of the SSLKEYLOG draft? yes: 4 no: 22 no opinion: 18 " I was one of the 4. I think I've explained why on the list already so won't repeat myself. Cheers, S. Cheers, spt [0] see minutes: https://datatracker.ietf.org/doc/minutes-122- tls-202503200230/ ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls- le...@ietf.org OpenPGP_signature.asc Description: OpenPGP digital signature ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Publication has been requested for draft-ietf-tls-keylogfile-03
Hiya, On 11/04/2025 16:40, Sean Turner wrote: On Apr 9, 2025, at 8:00 PM, Stephen Farrell wrote: On 03/04/2025 14:42, Stephen Farrell wrote: On 03/04/2025 14:35, Sean Turner via Datatracker wrote: Sean Turner has requested publication of draft-ietf-tls- keylogfile-03 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/ Hang on - where was the outcome of the WGLC declared or summarised by the chairs? Where are the minutes for the IETF-122 meeting? I think you're skipping process steps here in a way that ought not be done, esp when there have been objections to this draft. (And I think I already asked that the poll at the meeting not be used as a declaration of consensus.) Please correct. I object to decisions not being made on the list when there is contention. I got no response from chairs or AD on or off list to the above. Seems like bad form to me but maybe people were too busy. I note that despite my request/objection, the IETF LC for this has now been issued. I've objected there too. [1]. I see that SM also had process comments on this too. [2] I do plan to appeal should this document not be sent back to the WG to confirm whether or not there is WG consensus to publish. (And publishing as-is is wrong of course:-) Cheers, S. [1] https://mailarchive.ietf.org/arch/msg/last-call/ KFXyZbe_hi-0OjCtvORwyJm_wpo/ [2] https://mailarchive.ietf.org/arch/ msg/last-call/fLGvbWNGBhux9c6crFJ1ZioKmLg/ Stephen, The minutes have now been posted; see [0]. Joe posted them for internal review, and I got my wires crossed that the minutes were not also published to the datatracker. Ack. I have updated the Shepherd Write-Up and brought your (and others) continued objections to progressing this draft. Likewise, I have discussed this with our AD at length. The points I believe you have made align the way (beyond don’t publish, this is a bad idea) are: 1. Strong Caveats/Warnings: When draft-thomson-tls-keylogfile was up for adoption, you were okay adopting it as long as there were sufficient warnings. The Security Considerations section includes much more text and an Applicability Statement section was added, which in particular notes this mechanism “MUST NOT” be used in production systems. When -ech-keylogfile, I believe there were more objections, but not a lot of support for more text. Now the drafts are combined, the text in the Security Considerations has been expanded to also include ECH and the Applicability Statement remains. Likewise, a PR has been landed and will appear when -04 is published that adds words specifically about the compilation issue [1]. As both drafts completed WGLC independently and now the draft is a combo, this point seems settled. 2. -ech-keylogfile is not needed because ECH is new. There were people who implemented ECH at scale who spoke in support of -ech- keylogfile. Also, -ech-keylogfile made it through WGLC; the only new comment beyond “make the warnings stronger and bigger” was to merge the draft together because it was odd that -ech-keylogfile was creating a registry for a draft so newly in the RFC editor’s queue. 3. Merging: During -ech-keylogfile, Rich suggested we merge it. I noted that that was going to happen when I closed out that WGLC. There were no objections. I noted that that merge had completed when -tls-keylogfile-03 was published; again, no objections to the initial note. 4. Specification Required vs IETF Review: This WG published RFC 8447 and -rfc8447bis is nearing completion. As you know, these documents set the registration requirements for almost all of the registries to Specification Required, which also implies expert review. This is true for the Cipher Suite & Support Groups. If the concern is about something slipping by the DEs, then we have bigger problems. The registration list is public [2], the DEs are known (Yoav, Rich, and Nick), and the DEs can raise registrations with the WG and have previously reported on registrations [3]. The above is a pretty fair summary, but not quite 100% (which is natural enough) - IMO item #4 is by far the worst aspect of publishing as-is; this does differ from other registries as every new thing added to this one is a new way to exfiltrate (a bad thing when done outside debugging which we know will happen), whereas with other registries adding a bad thing is very much the exception (e.g. NULL ciphers are very rare). I think we would be far better off with IETF review if we do have to hold our noses and create this registry. As you note I did not close out that WGLC; I should have, I will send a message in response to the WGLC thread referring to this message. While I know you would prefer to not use the informal poll we took at the IETF 122 session because it does not support your position it is nonetheless telling. But because I forgot about the change to add more compilation constraints in the Applic
[TLS] Re: Publication has been requested for draft-ietf-tls-keylogfile-03
> On Apr 11, 2025, at 11:50 AM, Stephen Farrell > wrote: > > > Hiya, > > On 11/04/2025 16:40, Sean Turner wrote: >>> On Apr 9, 2025, at 8:00 PM, Stephen Farrell >>> wrote: On 03/04/2025 14:42, Stephen >>> Farrell wrote: On 03/04/2025 14:35, Sean Turner via Datatracker wrote: > Sean Turner has requested publication of draft-ietf-tls- keylogfile-03 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/ Hang on - where was the outcome of the WGLC declared or summarised by the chairs? Where are the minutes for the IETF-122 meeting? I think you're skipping process steps here in a way that ought not be done, esp when there have been objections to this draft. (And I think I already asked that the poll at the meeting not be used as a declaration of consensus.) Please correct. I object to decisions not being made on the list when there is contention. >>> I got no response from chairs or AD on or off list to the above. >>> Seems like bad form to me but maybe people were too busy. >>> I note that despite my request/objection, the IETF LC for this has >>> now been issued. I've objected there too. [1]. I see that SM also >>> had process comments on this too. [2] >>> I do plan to appeal should this document not be sent back to the >>> WG to confirm whether or not there is WG consensus to publish. >>> (And publishing as-is is wrong of course:-) >>> Cheers, S. >>> [1] https://mailarchive.ietf.org/arch/msg/last-call/ >>> KFXyZbe_hi-0OjCtvORwyJm_wpo/ [2] https://mailarchive.ietf.org/arch/ >>> msg/last-call/fLGvbWNGBhux9c6crFJ1ZioKmLg/ >> Stephen, >> The minutes have now been posted; see [0]. Joe posted them for >> internal review, and I got my wires crossed that the minutes were >> not also published to the datatracker. > > Ack. > >> I have updated the Shepherd Write-Up and brought your (and others) >> continued objections to progressing this draft. Likewise, I have >> discussed this with our AD at length. The points I believe you have >> made align the way (beyond don’t publish, this is a bad idea) are: >> 1. Strong Caveats/Warnings: When draft-thomson-tls-keylogfile was up >> for adoption, you were okay adopting it as long as there were >> sufficient warnings. The Security Considerations section includes >> much more text and an Applicability Statement section was added, >> which in particular notes this mechanism “MUST NOT” be used in >> production systems. When -ech-keylogfile, I believe there were more >> objections, but not a lot of support for more text. Now the drafts >> are combined, the text in the Security Considerations has been >> expanded to also include ECH and the Applicability Statement >> remains. Likewise, a PR has been landed and will appear when -04 is >> published that adds words specifically about the compilation issue >> [1]. As both drafts completed WGLC independently and now the draft >> is a combo, this point seems settled. >> 2. -ech-keylogfile is not needed because ECH is new. There were >> people who implemented ECH at scale who spoke in support of -ech- >> keylogfile. Also, -ech-keylogfile made it through WGLC; the only new >> comment beyond “make the warnings stronger and bigger” was to merge >> the draft together because it was odd that -ech-keylogfile was >> creating a registry for a draft so newly in the RFC editor’s queue. >> 3. Merging: During -ech-keylogfile, Rich suggested we merge it. I >> noted that that was going to happen when I closed out that WGLC. >> There were no objections. I noted that that merge had completed when >> -tls-keylogfile-03 was published; again, no objections to the >> initial note. >> 4. Specification Required vs IETF Review: This WG published RFC 8447 >> and -rfc8447bis is nearing completion. As you know, these documents >> set the registration requirements for almost all of the registries >> to Specification Required, which also implies expert review. This is >> true for the Cipher Suite & Support Groups. If the concern is about >> something slipping by the DEs, then we have bigger problems. The >> registration list is public [2], the DEs are known (Yoav, Rich, and >> Nick), and the DEs can raise registrations with the WG and have >> previously reported on registrations [3]. > > The above is a pretty fair summary, but not quite 100% (which is > natural enough) - IMO item #4 is by far the worst aspect of > publishing as-is; this does differ from other registries as every > new thing added to this one is a new way to exfiltrate (a bad > thing when done outside debugging which we know will happen), > whereas with other registries adding a bad thing is very much > the exception (e.g. NULL ciphers are very rare). I think we would > be far better off with IETF review if we do have to hold our > noses and create this registry. > >> As you note I did not close out that WGLC; I should
[TLS] Re: Opsdir ietf last call review of draft-ietf-tls-svcb-ech-07
From: Linda Dunbar via Datatracker Sent: Wednesday, April 9, 2025 3:58 PM To: ops-...@ietf.org Cc: draft-ietf-tls-svcb-ech@ietf.org ; last-c...@ietf.org ; tls@ietf.org Subject: Opsdir ietf last call review of draft-ietf-tls-svcb-ech-07 ... > Mixed SVCB RRSets with and without the “ech” parameter are vulnerable to > downgrade attacks, yet may occur in multi-provider environments or during > staged rollouts. Clear operational guidance is needed to mitigate these risks, > such as prioritizing ECH-capable endpoints using SvcPriority. Deployments > involving CDNs or multi-CDN setups add complexity around coordination of ECH > keys and consistent DNS records, and would benefit from best practice > recommendations. This situation is addressed in detail already in the Security Considerations: https://www.ietf.org/archive/id/draft-ietf-tls-svcb-ech-07.html#section-8-1. I don't believe we have any further recommendations. > Additionally, diagnosing ECH failures can be difficult due to the lack of > fallback and visibility. The draft should recommend logging and monitoring > strategies to help operators detect misconfigurations. I don't believe we have any relevant recommendations for logging or monitoring. Any such logging would likely not be related to the DNS records, so those recommendations would be in draft-ietf-tls-esni or a later draft. > Key rotation, TTL > management, and rollback procedures are also important but not addressed. draft-ietf-tls-esni does already discuss these topics: Key rotation: https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni#name-maintain-forward-secrecy Rollback: https://datatracker.ietf.org/doc/html/draft-ietf-tls-esni#name-misconfiguration-and-deploy ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Opsdir last call review of draft-ietf-tls-rfc8447bis-11
> On Apr 3, 2025, at 10:54 AM, Giuseppe Fioccola via Datatracker > wrote: > > Reviewer: Giuseppe Fioccola > Review result: Has Nits > > This document updates the changes in RFC 8447 and requests IANA to make > changes > to a number of TLS and DTLS registries. In particular, it updates the > "Recommended" column in TLS registries by defining a third value "D" for items > that are discouraged and adds a "Comment" column to the registries that do not > already have it. This document updates several RFCs: RFC 3749, RFC 5077, RFC > 4680, RFC 5246, RFC 5705, RFC 5878, RFC 6520, RFC 7301, and RFC 8447. > > I think that the document has a well defined scope and is quite clear. > However, > I have few suggestions: > > - In the Abstract, I suggest to replace 'adds a Comments column to all active > registries' with 'adds a Comment column to all the registries that do not > already have it'. Done via: https://github.com/tlswg/rfc8447bis/pull/76 > - In section 3, I suggest to replace 'The permitted values are' with 'The > permitted values of the Recommended column are', just to avoid any confusion. Done via: https://github.com/tlswg/rfc8447bis/pull/76 > - In the sections from 4 to 14, I suggest to add some explanation on why > specific registries are changed to discouraged. Some insight would help the > reader. We had other comments along these lines. I went through and looked at whether there were links to the drafts that gave info on why D; see https://github.com/tlswg/rfc8447bis/pull/74. Mostly, we added a ref back to this document which includes the info. > - I would also add some observations on the operational and interoperability > impacts, if any, of the changes proposed in the document. > > - Currently, the section on "IANA Considerations" simply says that the > document > is entirely about changes to TLS-related IANA registries, as per RFC 8447. > Instead, I would put all the relevant sections on IANA requests (i.e. sections > from 4 to 14) under an "IANA Considerations" section. In this way you can > avoid > the IANA section with no content. On these, two we’ll take them under advisement. On the ops and inerop impacts, I am not sure there is much more to say beyond hey make sure your implementation is updatable and configurable. On the last point, we could do that, but this draft has been in this format for 4 years and RFC 8447 before it has the same format. Cheers, spt ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] I-D Action: draft-ietf-tls-rfc8447bis-12.txt
Internet-Draft draft-ietf-tls-rfc8447bis-12.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-12.txt Pages: 19 Dates: 2025-04-11 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 that do not already have a "Comments" column. 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-12.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-rfc8447bis-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] I-D Action: draft-ietf-tls-keylogfile-04.txt
Internet-Draft draft-ietf-tls-keylogfile-04.txt is now available. It is a work item of the Transport Layer Security (TLS) WG of the IETF. Title: The SSLKEYLOGFILE Format for TLS Authors: Martin Thomson Yaroslav Rosomakho Hannes Tschofenig Name:draft-ietf-tls-keylogfile-04.txt Pages: 15 Dates: 2025-04-11 Abstract: A format that supports the logging information about the secrets used in a TLS connection is described. Recording secrets to a file in SSLKEYLOGFILE format allows diagnostic and logging tools that use this file to decrypt messages exchanged by TLS endpoints. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-tls-keylogfile-04.html A diff from the previous version is available at: https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-keylogfile-04 Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: I-D Action: draft-ietf-tls-rfc8447bis-12.txt
HI! This version addresses the Directorate comments received to date. spt > On Apr 11, 2025, at 12:21 PM, internet-dra...@ietf.org wrote: > > Internet-Draft draft-ietf-tls-rfc8447bis-12.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-12.txt > Pages: 19 > Dates: 2025-04-11 > > 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 that do not already have a > "Comments" column. > > 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-12.html > > A diff from the previous version is available at: > https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-rfc8447bis-12 > > 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: Confirming Consensus to Progress The SSLKEYLOGFILE Format for TLS
> On Apr 11, 2025, at 11:43 AM, Sean Turner wrote: > > Hi! At IETF 122, the chairs took a sense of the room about whether to > progress draft-ietf-tls-keylogfile. There was consensus to do so [0]. We need > to confirm that on-list. If you disagree with the consensus please let us > know, and why. We close this call at 1159 UTC on 29 April 2025. > > Cheers, > spt > > [0] see minutes: > https://datatracker.ietf.org/doc/minutes-122-tls-202503200230/ Here’s a link to the latest version: https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ spt___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Confirming Consensus to Progress The SSLKEYLOGFILE Format for TLS
Hiya, On 11/04/2025 17:29, Sean Turner wrote: Here’s a link to the latest version: https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ I had a look at the diff, and at the latest openssl code, just released this week as openssl 3.5, and it looks to me like the labels in the draft's IANA registry do not in fact match that code very well at all. That seems like another basis (not previously raised) on which to say this is not ready to be published - seems like this is not only undesirable, but inaccurate. Cheers, S. OpenPGP_signature.asc Description: OpenPGP digital signature ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] Re: Confirming Consensus to Progress The SSLKEYLOGFILE Format for TLS
Hi list, > seems like this is not only undesirable, but inaccurate. maybe I'm wrong, but in couple of cases we have seen, that implementations done before a RFC has been release differs from that. Sometimes even natural, because the RFC has evolved and not all implementations are able to follow that in short term. Therefore these are strong words for something which I would consider as an iterative process of improvements. br Achim Am 12.04.25 um 02:33 schrieb Stephen Farrell: Hiya, On 11/04/2025 17:29, Sean Turner wrote: Here’s a link to the latest version: https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ I had a look at the diff, and at the latest openssl code, just released this week as openssl 3.5, and it looks to me like the labels in the draft's IANA registry do not in fact match that code very well at all. That seems like another basis (not previously raised) on which to say this is not ready to be published - seems like this is not only undesirable, but inaccurate. Cheers, S. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
[TLS] [IANA #1413503] expert review for draft-ietf-tls-esni (tls-extensiontype-values)
Dear Yoav Nir (cc: tls WG, tls-reg-review mailing list), Following up on this; as a designated expert for the TLS ExtensionType Values registry, can you review the proposed registration in draft-ietf-tls-esni-23 for us? Please note that Nick Sullivan is a co-author for this draft and that Rich has already approved. Please see: https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ The due date was March 18. If this is OK, when the IESG approves the document for publication, we'll make the registration at: https://www.iana.org/assignments/tls-extensiontype-values/ We'll act after both experts approve the registration. With thanks, David Dong IANA Services Sr. Specialist On Thu Apr 03 00:23:12 2025, david.dong wrote: > Dear Yoav Nir (cc: tls WG, tls-reg-review mailing list), > > Following up on this; as a designated expert for the TLS ExtensionType > Values registry, can you review the proposed registration in draft- > ietf-tls-esni-23 for us? Please note that Nick Sullivan is a co-author > for this draft and that Rich had already approved. > > Please see: > > https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ > > The due date was March 18. > > If this is OK, when the IESG approves the document for publication, > we'll make the registration at: > > https://www.iana.org/assignments/tls-extensiontype-values/ > > We'll act after both experts approve the registration. > > With thanks, > > David Dong > IANA Services Sr. Specialist > > On Mon Mar 24 22:04:42 2025, david.dong wrote: > > Dear Yoav Nir (cc: tls WG, tls-reg-review mailing list), > > > > Following up on this; as a designated expert for the TLS > > ExtensionType > > Values registry, can you review the proposed registration in draft- > > ietf-tls-esni-23 for us? Please note that Nick Sullivan is a co- > > author > > for this draft and that Rich had already approved. > > > > Please see: > > > > https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ > > > > The due date was March 18. > > > > If this is OK, when the IESG approves the document for publication, > > we'll make the registration at: > > > > https://www.iana.org/assignments/tls-extensiontype-values/ > > > > We'll act after both experts approve the registration. > > > > With thanks, > > > > David Dong > > IANA Services Sr. Specialist > > > > > > On Sat Mar 15 01:27:51 2025, david.dong wrote: > > > Dear Yoav Nir (cc: tls WG, tls-reg-review mailing list), > > > > > > Following up on this; as a designated expert for the TLS > > > ExtensionType > > > Values registry, can you review the proposed registration in draft- > > > ietf-tls-esni-23 for us? Please note that Nick Sullivan is a co- > > > author > > > for this draft and that Rich had already approved. > > > > > > Please see: > > > > > > https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ > > > > > > The due date is March 18. > > > > > > If this is OK, when the IESG approves the document for publication, > > > we'll make the registration at: > > > > > > https://www.iana.org/assignments/tls-extensiontype-values/ > > > > > > We'll act after both experts approve the registration. > > > > > > With thanks, > > > > > > David Dong > > > IANA Services Sr. Specialist > > > > > > > > > On Thu Mar 06 21:31:55 2025, david.dong wrote: > > > > Dear Yoav Nir (cc: tls WG, tls-reg-review mailing list), > > > > > > > > As a designated expert for the TLS ExtensionType Values registry, > > > > can > > > > you review the proposed registration in draft-ietf-tls-esni-23 > > > > for > > > > us? > > > > Please note that Nick Sullivan is a co-author for this draft and > > > > that > > > > Rich had already approved. > > > > > > > > Please see: > > > > > > > > https://datatracker.ietf.org/doc/draft-ietf-tls-esni/ > > > > > > > > The due date is March 18. > > > > > > > > If this is OK, when the IESG approves the document for > > > > publication, > > > > we'll make the registration at: > > > > > > > > https://www.iana.org/assignments/tls-extensiontype-values/ > > > > > > > > We'll act after both experts approve the registration. > > > > > > > > With thanks, > > > > > > > > David Dong > > > > IANA Services Sr. Specialist > > > > > > > > On Wed Feb 26 18:26:30 2025, david.dong wrote: > > > > > Hi Nick, > > > > > > > > > > Yes, that's correct; this review request is for the two new > > > > > registrations in section 11.1 in the TLS ExtensionType Values > > > > > registry, which has the registration procedure of Specification > > > > > Required. > > > > > > > > > > Thank you. > > > > > > > > > > Best regards, > > > > > > > > > > David Dong > > > > > IANA Services Sr. Specialist > > > > > > > > > > On Wed Feb 26 08:10:28 2025, nicholas.sulli...@gmail.com wrote: > > > > > > I’m conflicted out as mentioned, but I want to clarify: this > > > > > > request > > > > > > is for > > > > > > the code points in the existing extension (section 11.1), not > > > > > > the > > > > > > request > > > > > > for the alert code point (11.2) or the new extension registry > >
