[TLS]Re: DTLS 1.3 sequence number lengths and lack of ACKs

Circling back here, what do we wish to do here? I went to file an erratum, but it wasn't clear to me what to put in here. Perhaps an extra paragraph in Section 4? Not sure what we should advise... certainly we should tell implementers about what happens if they pick an 8-bit one. Is it worth mentio

[TLS][Editorial Errata Reported] RFC9147 (8051)

The following errata report has been submitted for RFC9147, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid8051 -- Type: Ed

[TLS]Re: DTLS 1.3 epochs vs message_seq overflow

Circling back to this thread, I think the best thing to do is to just concede we failed to actually increase the epoch space and permit implementations to keep it 16-bit. We can try again in DTLS 1.4, or just fully revert to a 16-bit epoch space. I've filed the following errata to do this: https:/

[TLS][Technical Errata Reported] RFC9147 (8050)

The following errata report has been submitted for RFC9147, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid8050 -- Type: Te

[TLS][Technical Errata Reported] RFC9147 (8048)

The following errata report has been submitted for RFC9147, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid8048 -- Type: Te

[TLS]Re: The TLS WG has placed draft-rosomakho-tls-ech-keylogfile in state "Call For Adoption By WG Issued"

We should do this. It's good work and it completes the work we've already done here. The status is correct. I don't think that we need new security considerations about compiling this in or any of that. What is in the draft is pretty good. My only real suggestion is that perhaps -- for a ser

[TLS]Re: Issues with buffered, ACKed KeyUpdates in DTLS 1.3

To follow up here, I've filed https://www.rfc-editor.org/errata/eid8047 with "option 7" from the thread. On Sat, Apr 27, 2024 at 8:11 AM Watson Ladd wrote: > > > On Sat, Apr 27, 2024, 8:03 AM David Benjamin > wrote: > >> What should the next steps be here? Is this a bunch of errata, or >> somet

[TLS][Technical Errata Reported] RFC9147 (8047)

The following errata report has been submitted for RFC9147, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3". -- You may review the report below and at: https://www.rfc-editor.org/errata/eid8047 -- Type: Te

[TLS]Re: Adoption call for Extended Key Update for TLS 1.3

I support adoption of the draft to solve this problem, but I suspect the construction will need some changes. I'm not sure the construction in the draft actually works. A single extended key update flow in the draft sends NewKeyUpdate in *both* directions. Now, imagine if both client and server in

[TLS]Re: I-D Action: draft-ietf-tls-hybrid-design-10.txt

Douglas, > > It's not exactly due to the point formats, at least for X25519. The RFC > > 7748 > > security considerations highlight that "for each public key, there are > > several > > publicly computable public keys that are equivalent to it, i.e., they > > produce > > the same shared secrets

[TLS]Re: I-D Action: draft-ietf-tls-hybrid-design-10.txt

> It's not exactly due to the point formats, at least for X25519. The RFC 7748 > security considerations highlight that "for each public key, there are > several publicly computable public keys that are equivalent to it, i.e., they > produce the same shared secrets". Assuming the early secret

[TLS]Re: Adoption call for Extended Key Update for TLS 1.3

> On 25. Jul 2024, at 09: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 su

[TLS]Document Action: 'The SSLKEYLOGFILE Format for TLS' to Informational RFC (draft-ietf-tls-keylogfile-02.txt)

The IESG has approved the following document: - 'The SSLKEYLOGFILE Format for TLS' (draft-ietf-tls-keylogfile-02.txt) as Informational RFC This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Paul Wouters and Deb Cooley. A URL of this Interne

[TLS]Re: Adoption call for Extended Key Update for TLS 1.3

The FATT-related slides that were presented yesterday said: ~~~ Mechanism: triage, then maybe analyze At document/change adoption call, chairs email the triage panel, bring summarized analysis to the WG as part of the adoption discussion. ~~~ I now realize that this is ambiguous. At what point

[TLS]Re: [⚠️] Re: [EXTERNAL] Adoption call for SSLKEYLOG Extension file for ECH

* The ultimate goal is to simplify adoption of ECH for both developers of TLS software and implementers Understood; I do not question the goals of the authors. * Without a standard approach to troubleshooting every developer has to build an individual set of bespoke troubleshooting tool

[TLS]Re: [⚠️] Re: [EXTERNAL] Adoption call for SSLKEYLOG Extension file for ECH

On Fri, Jul 26, 2024 at 3:25 AM Bob Beck wrote: > > > On Thu, Jul 25, 2024 at 10:15 AM Yaroslav Rosomakho 40zscaler@dmarc.ietf.org> wrote: > >> Thank you for the feedback, Andrei. >> >> Yes, it is intended to stay on the informational track as an extension >> to draft-ietf-tls-keylogfile-02.

[TLS]Re: [⚠️] Re: [EXTERNAL] Adoption call for SSLKEYLOG Extension file for ECH

It seems to me like if this is what the IETF wants to advise, This advice is being given in the wrong draft. Yes. The drafts should be merged. ___ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org

[TLS]Re: [EXTERNAL] Adoption call for SSLKEYLOG Extension file for ECH

Hiya, On 25/07/2024 17:30, Andrei Popov wrote: I do not support adoption, because I believe the IETF should not standardize tools and techniques for decrypting TLS-protected data. It is harder for a TLS implementer to reject requests for IETF- blessed functionality. Same here. (As long as

[TLS]Re: [⚠️] Re: [EXTERNAL] Adoption call for SSLKEYLOG Extension file for ECH

On Thu, Jul 25, 2024 at 10:15 AM Yaroslav Rosomakho wrote: > Thank you for the feedback, Andrei. > > Yes, it is intended to stay on the informational track as an extension > to draft-ietf-tls-keylogfile-02. We tried to keep wording in line with the > keylogfile draft - for instance in the applica

[TLS]Re: Adoption call for Extended Key Update for TLS 1.3

I support adoption. Thanks, Jenn [cid:image001.png@01DADE98.CAEA5100] Jennifer Bowman Sr. Solution Architect jenbo...@cisco.com WebEx Go: +1 434 818 2000 CCDE – 2018::16 CCIE – 51241 (Sec/RS) DevNet Professional [cid:image002.png@01DADE98.CAEA5100]

[TLS]Re: Adoption call for Extended Key Update for TLS 1.3

I support adoption. On Thu, 25 Jul 2024 at 10:37, Bob Beck wrote: > I support adoption, and would be willing to review drafts and would work > to have it implemented. > > On Thu, Jul 25, 2024 at 9:44 AM Sean Turner wrote: > >> At the IETF 120 TLS session there was interest in adopting the Exten

[TLS]Re: Adoption call for Extended Key Update for TLS 1.3

I support adoption, and would be willing to review drafts and would work to have it implemented. On Thu, Jul 25, 2024 at 9:44 AM 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-ts

[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]Re: [EXTERNAL] Adoption call for Extended Key Update for TLS 1.3

I support adoption. Cheers, Andrei -Original Message- From: Sean Turner Sent: Thursday, July 25, 2024 9:39 AM To: TLS List Subject: [EXTERNAL] [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]Re: [⚠️] Re: The TLS WG has placed draft-rosomakho-tls-ech-keylogfile in state "Call For Adoption By WG Issued"

Thank you, Rich. That's a great idea. I personally believe that the current practice adopted by many pieces of _production_ software to take an environment variable and silently dump sslkeylog in a clear text file is rather reckless and should be strongly discouraged. This functionality must reall

[TLS]Re: [⚠️] Re: [EXTERNAL] Adoption call for SSLKEYLOG Extension file for ECH

Thank you for the feedback, Andrei. Yes, it is intended to stay on the informational track as an extension to draft-ietf-tls-keylogfile-02. We tried to keep wording in line with the keylogfile draft - for instance in the applicability statement it is worded that "this mechanism MUST NOT be used in

[TLS]Re: Adoption call for Extended Key Update for TLS 1.3

I support adoption. I will review the drafts and work to get it implemented ___ 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 tex

[TLS]The TLS WG has placed draft-tschofenig-tls-extended-key-update in state "Call For Adoption By WG Issued"

The TLS WG has placed draft-tschofenig-tls-extended-key-update in state Call For Adoption By WG Issued (entered by Sean Turner) The document is available at https://datatracker.ietf.org/doc/draft-tschofenig-tls-extended-key-update/ Comment: After revising the comments based on input after IETF 1

[TLS]Re: The TLS WG has placed draft-rosomakho-tls-ech-keylogfile in state "Call For Adoption By WG Issued"

I support adoption. I want the security considerations to recommend that this SHOULD be controlled by compile-time options, if possible, and definitely not enabled in general production use. Andrei's suggestion of informational is a good idea. ___ TL

[TLS]Re: [EXTERNAL] Adoption call for SSLKEYLOG Extension file for ECH

I do not support adoption, because I believe the IETF should not standardize tools and techniques for decrypting TLS-protected data. It is harder for a TLS implementer to reject requests for IETF-blessed functionality. (As long as this remains on the Informational track, I believe it's somewhat

[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, p

[TLS]The TLS WG has placed draft-rosomakho-tls-ech-keylogfile in state "Call For Adoption By WG Issued"

The TLS WG has placed draft-rosomakho-tls-ech-keylogfile in state Call For Adoption By WG Issued (entered by Sean Turner) The document is available at https://datatracker.ietf.org/doc/draft-rosomakho-tls-ech-keylogfile/ Comment: At IETF 120 there was support in the room to adopt, but we need to

[TLS]Re: tls@ietf120: WG I-D status

For ECH we are waiting on the resolution of of two issues in github by the authors and then I think we are ready to move forward. I expect this to be resolved over the next few weeks. On Wed, Jul 24, 2024 at 1:29 PM Arnaud Taddei wrote: > Funny I had the SAME question earlier too with someone e

[TLS]Re: I-D Action: draft-ietf-tls-hybrid-design-10.txt

Douglas, I was approaching this from the hybrid TLS side of things, but I agree that it's potentially an issue for TLS with traditional ECDH. It's not exactly due to the point formats, at least for X25519. The RFC 7748 security considerations highlight that "for each public key, there are seve