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

[Peter C]

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 several 
publicly computable public keys that are equivalent to it, i.e., they produce 
the same shared secrets".  Assuming the early secret doesn't change, this means 
equivalent public keys will produce the same handshake secrets and the same 
master secrets.  The transcript hash does give you different handshake traffic 
secrets and application traffic secrets, but I think that's too late in the key 
schedule for [DOWLING].

Do you think it's possible to re-use the DHKEM proof as it is using a similar 
extract-and-expand derivation there?  I'm not sure if there's anything else in 
[DOWLING] that would need to be adjusted or if that would be enough by itself.

Peter

> -Original Message-
> From: Douglas Stebila 
> Sent: Wednesday, July 24, 2024 9:58 PM
> To: Peter C 
> Cc: TLS List 
> Subject: Re: [TLS] I-D Action: draft-ietf-tls-hybrid-design-10.txt
>
> [You don't often get email from dsteb...@gmail.com. Learn why this is
> important at https://aka.ms/LearnAboutSenderIdentification ]
>
> Hi Peter,
>
> I agree that if you assume that the PQ KEM is broken, then [GIACON] and
> [BINDEL] don't apply since ECDH-as-a-KEM is not IND-CCA2 secure.  I don't
> fully follow your argument on why it's not possible to fall back on [DOWLING]
> -- in other words, just resort back to the original security proof of ECDH in 
> TLS
> 1.3.
>
> I did see your subsequent email about the tweaking that one can do for NIST
> P-256 and X25519 due to compressed formats leading to mathematically
> equivalent points.  If it was the case that this tweakability resulted in 
> hybrid
> key exchange having a problem (either a security problem or just a proof
> problem) when the PQ KEM is broken, then I think that would also imply that
> this tweakability leads to a problem in plain old ECDH key exchange in TLS 
> 1.3.
> In other words, I think your argument implies that the [DOWLING] proof
> doesn't apply to TLS 1.3 ECDH key exchange because the point encodings
> used for X25519 and NIST P-256 don't satisfy dual-snPRF-ODH.  Which may be
> true, but it would imply a bigger scope of concerns than just hybrid key
> exchange.
>
> Now, it is the case that the HKDF.Expand portions of the key schedule include
> the transcript hash and thus the ECDH public keys, so any of these tweaks
> would, at the HKDF.Expand point, lead to different hash values.  This suggests
> to me that if one needed to adapt the proof, I'd start by treating 
> HKDF.Extract
> and HKDF.Expand as a single monolithic operation involving the shared
> secrets and the transcripts.  In the random oracle model, this results in
> hashing everything in, which I guess would provide enough rigidity to prevent
> any such attacks, similar to the argument in X-Wing.
>
> So if I am correctly interpreting your argument about point formats leading to
> a proof doubt, I think the path forward would be to revisit the original
> [DOWLING] proof in light of groups that don't satisfy dual-snPRF-ODH due to
> tweakability of point formats, possibly addressing this by treating
> HKDF.Extract and HKDF.Expand monolithically, and try to cover both the
> original ECDH and the hybrid questions at the same time.
>
> Douglas
>
>
> > On Jul 24, 2024, at 09:39, Peter C  wrote:
> >
> > Douglas,
> >
> > The agenda for the TLS session is looking packed, and this is a very in-the-
> weeds comment, so I hope you don't mind me posting it to the list.  Happy to
> take any discussion off-list, if you'd prefer.
> >
> > The draft-ietf-tls-hybrid-design security considerations currently say:
> >
> >The shared secrets computed in the hybrid key exchange should be
> >computed in a way that achieves the "hybrid" property: the resulting
> >secret is secure as long as at least one of the component key
> >exchange algorithms is unbroken. See [GIACON] and [BINDEL] for an
> >investigation of these issues.
> >
> > If you assume the PQ KEM is IND-CCA2 secure, then I agree that [GIACON]
> and [BINDEL] imply that the derived traffic secrets will be indistinguishable
> from random and from each other.  The same is true if the KEM is only OW-
> CCA2 secure by Petcher-Campagna
> (https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fia.cr%25
> 2F2023%2F972&data=05%7C02%7CPeter.C%40ncsc.gov.uk%7C2bd705ee884e
> 4ad41b7608dcac2359c7%7C14aa5744ece1474ea2d734f46dda64a1%7C0%7C0
> %7C638574515034600724%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLj
> AwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%
> 7C&sdata=erDUiHV32UBLTruz22JbYXg9M7%2BKGyr%2FVc3thoS8DYw%3D&re
> served=0).
> >
> > If you assume the PQ KEM is broken, however, then [GIACON] and [BINDEL]
> do not apply since ECDH-as-a-KEM is not IND-CCA2 

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

[Joseph Salowey]

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 else.
>
> So, ditto
>
> *Arnaud Taddei*
> Global Security Strategist | Enterprise Security Group
>
> *mobile:* +41 79 506 1129
> Geneva, Switzerland
> arnaud.tad...@broadcom.com | broadcom.com
>
> On 24 Jul 2024, at 13:22, Stephen Farrell 
> wrote:
>
>
> Hiya,
>
> What's the status/plan for draft-ietf-tls-esni-18?
>
> Thanks,
> S.
>
> On 24/07/2024 20:57, Sean Turner wrote:
>
> [External Email] This email originated outside of Trinity College Dublin.
> Do not click links or open attachments unless you recognise the sender and
> know the content is safe.
> 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 mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
>
>
> This electronic communication and the information and any files
> transmitted with it, or attached to it, are confidential and are intended
> solely for the use of the individual or entity to whom it is addressed and
> may contain information that is confidential, legally privileged, protected
> by privacy laws, or otherwise restricted from disclosure to anyone else. If
> you are not the intended recipient or the person responsible for delivering
> the e-mail to the intended recipient, you are hereby notified that any use,
> copying, distributing, dissemination, forwarding, printing, or copying of
> this e-mail is strictly prohibited. If you received this e-mail in error,
> please return the e-mail to the sender, delete it from your computer, and
> destroy any printed copy of it.
> ___
> 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]The TLS WG has placed draft-rosomakho-tls-ech-keylogfile in state "Call For Adoption By WG Issued"

[IETF Secretariat]

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 verify
that on list.

___
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

[Sean Turner]

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]Re: [EXTERNAL] Adoption call for SSLKEYLOG Extension file for ECH

[Andrei Popov]

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 
less harmful.)

Cheers,

Andrei

-Original Message-
From: Sean Turner 
Sent: Thursday, July 25, 2024 9:16 AM
To: TLS List 
Subject: [EXTERNAL] [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 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"

[Salz, Rich]

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.

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[IETF Secretariat]

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 119, there was no
objection to starting a call for adoption.

___
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

[Sean Turner]

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 Extended Key Update for TLS 1.3

[Salz, Rich]

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]Re: [⚠️] Re: [EXTERNAL] Adoption call for SSLKEYLOG Extension file for ECH

[Yaroslav Rosomakho]

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 a production system". Happy to add
stronger wording if that helps.

The ultimate goal is to simplify adoption of ECH for both developers of TLS
software and implementers. Without a standard approach to troubleshooting
every developer has to build an individual set of bespoke troubleshooting
tools. Ability to inspect ECH negotiation in off the shelf tools such as
Wireshark during development or tests would significantly help adoption.


Best Regards,
Yaroslav

On Thu, Jul 25, 2024 at 9:31 AM 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.
>
> (As long as this remains on the Informational track, I believe it's
> somewhat less harmful.)
>
> Cheers,
>
> Andrei
>
> -Original Message-
> From: Sean Turner 
> Sent: Thursday, July 25, 2024 9:16 AM
> To: TLS List 
> Subject: [EXTERNAL] [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 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: [⚠️] Re: The TLS WG has placed draft-rosomakho-tls-ech-keylogfile in state "Call For Adoption By WG Issued"

[Yaroslav Rosomakho]

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 really be available only
in development builds and have stronger safeguards than just an environment
variable.

Best Regards,
Yaroslav

On Thu, Jul 25, 2024 at 9:37 AM Salz, Rich  wrote:

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

[Andrei Popov]

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 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 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"

[Sean Turner]

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

[Bob Beck]

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-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 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

[Marten Seemann]

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 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 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 Extended Key Update for TLS 1.3

[Jennifer Bowman (jenbowma)]

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]
Cisco Systems, Inc.
United States
[A cover of a book  Description automatically generated]
Order 
here
This email may contain confidential and privileged material for the sole use of 
the intended recipient. Any review, use, distribution or disclosure by others 
is strictly prohibited. If you are not the intended recipient (or authorized to 
receive for the recipient), please contact the sender by reply email and delete 
all copies of this message.
Update Profile - 
Unsubscribe - 
Privacy
Please click 
here
 for Company Registration


From: Bob Beck 
Sent: Thursday, July 25, 2024 1:35 PM
To: Sean Turner 
Cc: TLS List 
Subject: [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 
mailto:s...@sn3rd.com>> 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 mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Bob Beck]

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 applicability statement it is worded
> that "this mechanism MUST NOT be used in a production system". Happy to add
> stronger wording if that helps.
>

No matter what your opinion on standardizing SSLKEYLOGFILE,
https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ does not
contain this MUST NOT guidance as in this draft.

MUST NOT guidance for only this portion of SSLKEYLOGFILE functionality that
is not present for the rest of specification calls into question how an
application developer shipping SSLKEYLOGFILE functionality in an
application is supposed to follow this guidance. Is only this portion of
the functionality supposed to be removed in "production"

It seems to me like if this is what the IETF wants to advise, This advice
is being given in the wrong draft.

-Bob


>
> The ultimate goal is to simplify adoption of ECH for both developers of
> TLS software and implementers. Without a standard approach to
> troubleshooting every developer has to build an individual set of bespoke
> troubleshooting tools. Ability to inspect ECH negotiation in off the shelf
> tools such as Wireshark during development or tests would significantly
> help adoption.
>
>
> Best Regards,
> Yaroslav
>
> On Thu, Jul 25, 2024 at 9:31 AM Andrei Popov  40microsoft@dmarc.ietf.org> 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.
>>
>> (As long as this remains on the Informational track, I believe it's
>> somewhat less harmful.)
>>
>> Cheers,
>>
>> Andrei
>>
>> -Original Message-
>> From: Sean Turner 
>> Sent: Thursday, July 25, 2024 9:16 AM
>> To: TLS List 
>> Subject: [EXTERNAL] [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 mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
>>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Stephen Farrell]

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 this remains on the Informational track, I believe it's
somewhat less harmful.)


I don't think TLS should adopt regardless of the kind of RFC.

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: [⚠️] Re: [EXTERNAL] Adoption call for SSLKEYLOG Extension file for ECH

[Salz, Rich]

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: [⚠️] Re: [EXTERNAL] Adoption call for SSLKEYLOG Extension file for ECH

[Steven Valdez]

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. 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 a production system". Happy to add
>> stronger wording if that helps.
>>
>
> No matter what your opinion on standardizing SSLKEYLOGFILE,
> https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/ does not
> contain this MUST NOT guidance as in this draft.
>
> This guidance does appear to be included in the base draft under "1.1
Applicability Statement".


> MUST NOT guidance for only this portion of SSLKEYLOGFILE functionality
> that is not present for the rest of specification calls into question how
> an application developer shipping SSLKEYLOGFILE functionality in an
> application is supposed to follow this guidance. Is only this portion of
> the functionality supposed to be removed in "production"
>
> It seems to me like if this is what the IETF wants to advise, This advice
> is being given in the wrong draft.
>
> -Bob
>
>
>>
>> The ultimate goal is to simplify adoption of ECH for both developers of
>> TLS software and implementers. Without a standard approach to
>> troubleshooting every developer has to build an individual set of bespoke
>> troubleshooting tools. Ability to inspect ECH negotiation in off the shelf
>> tools such as Wireshark during development or tests would significantly
>> help adoption.
>>
>>
>> Best Regards,
>> Yaroslav
>>
>> On Thu, Jul 25, 2024 at 9:31 AM Andrei Popov > 40microsoft@dmarc.ietf.org> 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.
>>>
>>> (As long as this remains on the Informational track, I believe it's
>>> somewhat less harmful.)
>>>
>>> Cheers,
>>>
>>> Andrei
>>>
>>> -Original Message-
>>> From: Sean Turner 
>>> Sent: Thursday, July 25, 2024 9:16 AM
>>> To: TLS List 
>>> Subject: [EXTERNAL] [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 mailing list -- tls@ietf.org
>>> To unsubscribe send an email to tls-le...@ietf.org
>>>
>> ___
>> TLS mailing list -- tls@ietf.org
>> To unsubscribe send an email to tls-le...@ietf.org
>>
> ___
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-le...@ietf.org
>


-- 

 Steven Valdez |  Chrome Privacy Sandbox |  sval...@google.com |  Cambridge,
MA
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[Andrei Popov]

  *   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 tools.
The troubleshooting approach used in this I-D is more invasive than it needs to 
be. Troubleshooting can be accomplished in a number of ways, including 
logs/traces that do not disclose all TLS-protected data.


  *   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 a production system".
That’s nice, but in practice this does not prevent abuse of the feature. I 
would rather SSLKEYLOGFILE was documented by the SW vendors who choose to 
implement it, in a repository outside of the IETF. I understand I’m in the 
rough on this.

Cheers,

Andrei

From: Yaroslav Rosomakho 
Sent: Thursday, July 25, 2024 10:12 AM
To: Andrei Popov 
Cc: TLS List 
Subject: Re: [⚠️] [TLS]Re: [EXTERNAL] Adoption call for SSLKEYLOG Extension 
file for ECH

You don't often get email from 
yrosomakho=40zscaler@dmarc.ietf.org.
 Learn why this is important
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 a production system". Happy to add 
stronger wording if that helps.

The ultimate goal is to simplify adoption of ECH for both developers of TLS 
software and implementers. Without a standard approach to troubleshooting every 
developer has to build an individual set of bespoke troubleshooting tools. 
Ability to inspect ECH negotiation in off the shelf tools such as Wireshark 
during development or tests would significantly help adoption.


Best Regards,
Yaroslav

On Thu, Jul 25, 2024 at 9:31 AM Andrei Popov 
mailto:40microsoft@dmarc.ietf.org>>
 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.

(As long as this remains on the Informational track, I believe it's somewhat 
less harmful.)

Cheers,

Andrei

-Original Message-
From: Sean Turner mailto:s...@sn3rd.com>>
Sent: Thursday, July 25, 2024 9:16 AM
To: TLS List mailto:tls@ietf.org>>
Subject: [EXTERNAL] [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 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 Extended Key Update for TLS 1.3

[Russ Housley]

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 in the call for adoption 
process, will the FATT triage assessment be shared with the WG?

Russ

___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[The IESG]

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 Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-keylogfile/




Technical Summary

   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.

Working Group Summary


   The one thing that worried some people (including your responsible AD)
   was the fact that this could be used as pervasive monitoring tool if this
   file is offloaded/shared on production systems. Numerous warnings were
   added to the document to not do this. As the feature is already readily
   available (Firefox, Chrome, Wireshark, openssl, libcurl, etc.) those
   who are building such monitoring devices can already do so anyway.

Document Quality

  This is documenting a widely deployed feature that is used for development
  and debugging major crypto libraries and browsers (see above)

Personnel

   The Document Shepherd for this document is Sean Turner. The Responsible
   Area Director is Paul Wouters.


___
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

[Michael Tuexen]

> 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 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.
Dear all,

I do support adoption and I'm willing to work on it, in particular to make
sure that it works on the contexts of DTLS over SCTP, one of its use cases.

Best regards
Michael
> 
> Thanks,
> 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: I-D Action: draft-ietf-tls-hybrid-design-10.txt

[Douglas Stebila]

> 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 doesn't change, 
> this means equivalent public keys will produce the same handshake secrets and 
> the same master secrets.  The transcript hash does give you different 
> handshake traffic secrets and application traffic secrets, but I think that's 
> too late in the key schedule for [DOWLING].

The proof in [DOWLING] only aims to prove that the handshake traffic secrets 
and application traffic secrets are secure, not that the handshake secrets and 
master secrets are secure, so for that purpose it should be okay that the 
transcript hash is incorporated a little later in the key schedule.

> Do you think it's possible to re-use the DHKEM proof as it is using a similar 
> extract-and-expand derivation there?  I'm not sure if there's anything else 
> in [DOWLING] that would need to be adjusted or if that would be enough by 
> itself.

Probably.  Technically the [DOWLING] proof does not mention KEMs at all; it 
models the ephemeral key exchange strictly in terms of DH groups.  Intuitively, 
the PRF-ODH assumptions are largely doing the work of an IND-CCA assumption, 
and I think it should be the case that one could straightforwardly adapt the 
proof to be about KEM-based key exchange and rely on the IND-CCA or even just 
IND-1CCA assumption.  That's how we analyzed the ephemeral key exchange 
components in the KEMTLS proof, which is why I think it should translate over.  
But one ought to work through the details.

I've started an email thread with my [DOWLING] coauthors and we're talking 
through how to patch that proof to handle this case.

Douglas


> On Jul 25, 2024, at 7:05 AM, Peter C  wrote:
> 
> 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 
> several publicly computable public keys that are equivalent to it, i.e., they 
> produce the same shared secrets".  Assuming the early secret doesn't change, 
> this means equivalent public keys will produce the same handshake secrets and 
> the same master secrets.  The transcript hash does give you different 
> handshake traffic secrets and application traffic secrets, but I think that's 
> too late in the key schedule for [DOWLING].
> 
> Do you think it's possible to re-use the DHKEM proof as it is using a similar 
> extract-and-expand derivation there?  I'm not sure if there's anything else 
> in [DOWLING] that would need to be adjusted or if that would be enough by 
> itself.
> 
> Peter
> 
>> -Original Message-
>> From: Douglas Stebila 
>> Sent: Wednesday, July 24, 2024 9:58 PM
>> To: Peter C 
>> Cc: TLS List 
>> Subject: Re: [TLS] I-D Action: draft-ietf-tls-hybrid-design-10.txt
>> 
>> [You don't often get email from dsteb...@gmail.com. Learn why this is
>> important at https://aka.ms/LearnAboutSenderIdentification ]
>> 
>> Hi Peter,
>> 
>> I agree that if you assume that the PQ KEM is broken, then [GIACON] and
>> [BINDEL] don't apply since ECDH-as-a-KEM is not IND-CCA2 secure.  I don't
>> fully follow your argument on why it's not possible to fall back on [DOWLING]
>> -- in other words, just resort back to the original security proof of ECDH 
>> in TLS
>> 1.3.
>> 
>> I did see your subsequent email about the tweaking that one can do for NIST
>> P-256 and X25519 due to compressed formats leading to mathematically
>> equivalent points.  If it was the case that this tweakability resulted in 
>> hybrid
>> key exchange having a problem (either a security problem or just a proof
>> problem) when the PQ KEM is broken, then I think that would also imply that
>> this tweakability leads to a problem in plain old ECDH key exchange in TLS 
>> 1.3.
>> In other words, I think your argument implies that the [DOWLING] proof
>> doesn't apply to TLS 1.3 ECDH key exchange because the point encodings
>> used for X25519 and NIST P-256 don't satisfy dual-snPRF-ODH.  Which may be
>> true, but it would imply a bigger scope of concerns than just hybrid key
>> exchange.
>> 
>> Now, it is the case that the HKDF.Expand portions of the key schedule include
>> the transcript hash and thus the ECDH public keys, so any of these tweaks
>> would, at the HKDF.Expand point, lead to different hash values.  This 
>> suggests
>> to me that if one needed to adapt the proof, I'd start by treating 
>> HKDF.Extract
>> and HKDF.Expand as a single monolithic operation involving the shared
>> secrets and the transcripts.  In the random oracle model, this results in
>> hashing everything in, which I guess would provide enough rigidity to pre

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

[Peter C]

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".  Assuming the early secret doesn't change, this
> > means equivalent public keys will produce the same handshake secrets and
> > the same master secrets.  The transcript hash does give you different
> > handshake traffic secrets and application traffic secrets, but I think 
> > that's too
> > late in the key schedule for [DOWLING].

> The proof in [DOWLING] only aims to prove that the handshake traffic secrets
> and application traffic secrets are secure, not that the handshake secrets and
> master secrets are secure, so for that purpose it should be okay that the
> transcript hash is incorporated a little later in the key schedule.

Sorry, I only meant that in Theorem 5.2 the dual-snPRF-ODH assumption is used
in Game B.2 to replace the handshake secret with a uniformly random value which
then allows the handshake traffic secrets to be replaced with uniformly random
values in Game B.3 using the PRF assumption on HKDF.Expand and the fact that
the labels are distinct.  Equivalent public keys mean that the handshake secret
is not indistinguishable from random and the proof fails at Game B.2.  The 
distinct
labels in Game B.3 only imply that the handshake traffic secrets will be 
different,
not that they are indistinguishable.

Peter
___
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

[David Benjamin]

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 initiate an extended key update in
parallel. Messages don't get sent instantaneously, so we can't prevent this
scenario. We will then have two concurrent instances of this flow:

Client-initiated:
C->S: ExtendedKeyUpdateRequest1
S->C: ExtendedKeyUpdateResponse1
C->S: NewKeyUpdate1a; update C->S traffic secret
S->C: NewKeyUpdate1b; update S->C traffic secret

Server-initiated:
S->C: ExtendedKeyUpdateRequest2
C->S: ExtendedKeyUpdateResponse2
S->C: NewKeyUpdate2a <-- updates S->C traffic secret
C->S: NewKeyUpdate2b <-- updates C->S traffic secret

Now, the problem is that NewKeyUpdate1b and NewKeyUpdate2a are the same
message, sent in the same direction and may flow in parallel. Same for
NewKeyUpdate1a and NewKeyUpdate2b. That means you can get in a
situation where *both* flows are waiting for a NewKeyUpdate message and you
can't tell which one to progress. If the client and server disagree on the
order in which to apply the two secrets, the protocol will break.

One could fix this by making the two messages different, but that seems
unnecessary. I believe we only need three messages, not four.

C->S: ExtendedKeyUpdateRequest
S->C: ExtendedKeyUpdateResponse; update the S->C traffic secret
C->S: NewKeyUpdate; update the C->S traffic secret

I might suggest that NewKeyUpdate be called ExtendedKeyUpdateFinish in this
version. This avoids the ambiguity and is simpler.

(Not sure what the consequences of either design is on DTLS? I think I'd
need to spend time with pen and paper there. Perhaps it is sufficient to
just drive the update on ACKs, after apply the fixes described in
https://mailarchive.ietf.org/arch/msg/tls/_ku3-YDcroNmG_QKZsYTtqYzC0M/ )

But, as for adoption, I think solving this problem makes sense, and I think
this draft is still a reasonable starting point.

David

On Thu, Jul 25, 2024 at 1:48 PM Michael Tuexen <
michael.tue...@lurchi.franken.de> wrote:

> > 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 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.
> Dear all,
>
> I do support adoption and I'm willing to work on it, in particular to make
> sure that it works on the contexts of DTLS over SCTP, one of its use cases.
>
> Best regards
> Michael
> >
> > Thanks,
> > 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 mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[RFC Errata System]

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: Technical
Reported by: David Benjamin 

Section: 8

Original Text
-
   As with TLS 1.3, DTLS 1.3 implementations send a KeyUpdate message to
   indicate that they are updating their sending keys.  As with other
   handshake messages with no built-in response, KeyUpdates MUST be
   acknowledged.  In order to facilitate epoch reconstruction
   (Section 4.2.2), implementations MUST NOT send records with the new
   keys or send a new KeyUpdate until the previous KeyUpdate has been
   acknowledged (this avoids having too many epochs in active use).

Corrected Text
--
   As with TLS 1.3, DTLS 1.3 implementations send a KeyUpdate message to
   indicate that they are updating their sending keys. As with other
   handshake messages with no built-in response, KeyUpdates MUST be
   acknowledged. Acknowledgements are used to both control
   retransmission and transition to the next epoch. Implementations MUST
   NOT send records with the new keys until the KeyUpdate and all
   preceding messages have been acknowledged. This facilitates epoch
   reconstruction (Section 4.2.2) and avoids too many epochs in active
   use, by ensuring the peer has processed the KeyUpdate and started
   receiving at the new epoch.

   A KeyUpdate message terminates the post-handshake stream in an epoch.
   After sending KeyUpdate in an epoch, implementations MUST NOT send
   any new post-handshake messages in that epoch. Note that, if the
   implementation has sent KeyUpdate but is waiting for an ACK, the next
   epoch is not yet active. In this case, subsequent post-handshake
   messages may not be sent until receiving the ACK.

Notes
-
See https://mailarchive.ietf.org/arch/msg/tls/_ku3-YDcroNmG_QKZsYTtqYzC0M/ for 
discussion. This is option 7 from that discussion, as well as the fix for the 
other issue described at the top of 
https://mailarchive.ietf.org/arch/msg/tls/GYX_teYy5CTFiGCBgbQJQwv_Fj4/

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.

--
RFC9147 (draft-ietf-tls-dtls13-43)
--
Title   : The Datagram Transport Layer Security (DTLS) Protocol 
Version 1.3
Publication Date: April 2022
Author(s)   : E. Rescorla, H. Tschofenig, 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]Re: Issues with buffered, ACKed KeyUpdates in DTLS 1.3

[David Benjamin]

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
>> something else?
>>
>
> Errata at a minimum but this might be big enough for a small RFC
> describing the fix.
>
>>
>> On Wed, Apr 17, 2024 at 10:08 AM David Benjamin 
>> wrote:
>>
>>> > Sender implementations should already be able to retransmit messages
>>> with older epochs due to the "duplicated" post-auth state machine
>>>
>>> The nice thing about option 7 is that the older epochs retransmit
>>> problem becomes moot in updated senders, I think. If the sender doesn't
>>> activate epoch N+1 until KeyUpdate *and prior messages* are ACKed and if
>>> KeyUpdate is required to be the last handshake message in epoch N, then the
>>> previous epoch is guaranteed to be empty by the time you activate it.
>>>
>>> On Wed, Apr 17, 2024, 09:27 Marco Oliverio  wrote:
>>>
 Hi David,

 Thanks for pointing this out. I also favor solution 7 as it's the
 simpler approach and it doesn't require too much effort to add in current
 implementations.
 Sender implementations should already be able to retransmit messages
 with older epochs due to the "duplicated" post-auth state machine.

 Marco

 On Tue, Apr 16, 2024 at 3:48 PM David Benjamin 
 wrote:

> Thanks, Hannes!
>
> Since it was buried in there (my understanding of the issue evolved as
> I described it), I currently favor option 7. I.e. the sender-only fix to
> the KeyUpdate criteria.
>
> At first I thought we should also change the receiver to mitigate
> unfixed senders, but this situation should be pretty rare (most senders
> will send NewSessionTicket well before they KeyUpdate), DTLS 1.3 isn't 
> very
> widely deployed yet, and ultimately, it's on the sender implementation to
> make sure all states they can get into are coherent.
>
> If the sender crashed, that's unambiguously on the sender to fix. If
> the sender still correctly retransmits the missing messages, the 
> connection
> will perform suboptimally for a blip but still recover.
>
> David
>
>
> On Tue, Apr 16, 2024, 05:19 Tschofenig, Hannes <
> hannes.tschofe...@siemens.com> wrote:
>
>> Hi David,
>>
>>
>>
>> this is great feedback. Give me a few days to respond to this issue
>> with my suggestion for moving forward.
>>
>>
>>
>> Ciao
>>
>> Hannes
>>
>>
>>
>> *From:* TLS  *On Behalf Of *David Benjamin
>> *Sent:* Saturday, April 13, 2024 7:59 PM
>> *To:*  
>> *Cc:* Nick Harper 
>> *Subject:* Re: [TLS] Issues with buffered, ACKed KeyUpdates in DTLS
>> 1.3
>>
>>
>>
>> Another issues with DTLS 1.3's state machine duplication scheme:
>>
>>
>>
>> Section 8 says implementation must not send new KeyUpdate until the
>> KeyUpdate is ACKed, but it says nothing about other post-handshake
>> messages. Suppose KeyUpdate(5) in flight and the implementation decides 
>> to
>> send NewSessionTicket. (E.g. the application called some
>> "send NewSessionTicket" API.) The new epoch doesn't exist yet, so naively
>> one would start sending NewSessionTicket(6) in the current epoch. Now the
>> peer ACKs KeyUpdate(5), so we transition to the new epoch. But
>> retransmissions must retain their original epoch:
>>
>>
>>
>> > Implementations MUST send retransmissions of lost messages using
>> the same epoch and keying material as the original transmission.
>>
>> https://www.rfc-editor.org/rfc/rfc9147.html#section-4.2.1-3
>>
>>
>>
>> This means we must keep sending the NST at the old epoch. But the
>> peer may have no idea there's a message at that epoch due to packet loss!
>> Section 8 does ask the peer to keep the old epoch around for a spell, but
>> eventually the peer will discard the old epoch. If NST(6) didn't get
>> through before then, the entire post-handshake stream is now wedged!
>>
>>
>>
>> I think this means we need to amend Section 8 to forbid sending *any*
>> post-handshake message after KeyUpdate. That is, rather than saying you
>> cannot send a new KeyUpdate, a KeyUpdate terminates the post-handshake
>> stream at that epoch and all new post-handshake messages, be they 
>> KeyUpdate
>> or anything else, must be enqueued for the new epoch. This is a little
>> unfortunate because a TLS library which transparently KeyUpdates will 
>> then
>> inadvertently introduce hiccups where post-handshake messages triggered 
>> by
>> the application, like post-handshake auth, are blocked.
>>
>>
>>
>> That then suggests some more opti

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

[Martin Thomson]

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 server -- ECH_CONFIG might be 
included only once for each unique value that the server supports. This might 
be done with a special value for the ClientHello.random field (all zeros 
perhaps, or repeating the config ID 32 times).  That would save a lot of space 
in a server log.  Lookup would need to use the public name and config id, 
though I imagine that config id might be enough in many cases.

On Thu, Jul 25, 2024, at 09:15, IETF Secretariat wrote:
> 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 verify
> that on list.
>
> ___
> 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][Technical Errata Reported] RFC9147 (8048)

[RFC Errata System]

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: Technical
Reported by: David Benjamin 

Section: 5.2

Original Text
-
   The first message each side transmits in each association always has
   message_seq = 0.  Whenever a new message is generated, the
   message_seq value is incremented by one.  When a message is
   retransmitted, the old message_seq value is reused, i.e., not
   incremented.  From the perspective of the DTLS record layer, the
   retransmission is a new record.  This record will have a new
   DTLSPlaintext.sequence_number value.

Corrected Text
--
   The first message each side transmits in each association always has
   message_seq = 0.  Whenever a new message is generated, the
   message_seq value is incremented by one.  Implementations MUST NOT
   allow message_seq to wrap, but instead MUST establish a new
   association, terminating the old association.  When a message is
   retransmitted, the old message_seq value is reused, i.e., not
   incremented.  From the perspective of the DTLS record layer, the
   retransmission is a new record.  This record will have a new
   DTLSPlaintext.sequence_number value.

Notes
-
While pondering what to do about 
https://mailarchive.ietf.org/arch/msg/tls/6y8wTv8Q_IPM-PCcbCAmDOYg6bM/, I 
noticed that we don't say anything about message_seq wrapping. Since we don't 
reset that counter, it's not only possible for it to wrap, but for the peer to 
induce you to wrap it. This seems warrant some text. I borrowed the "MUST NOT 
allow ... to wrap, but instead ..." phrasing from Section 4.2.1.

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.

--
RFC9147 (draft-ietf-tls-dtls13-43)
--
Title   : The Datagram Transport Layer Security (DTLS) Protocol 
Version 1.3
Publication Date: April 2022
Author(s)   : E. Rescorla, H. Tschofenig, 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][Technical Errata Reported] RFC9147 (8050)

[RFC Errata System]

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: Technical
Reported by: David Benjamin 

Section: 8

Original Text
-
   With a 128-bit key as in AES-128, rekeying 2^64 times has a high
   probability of key reuse within a given connection.  Note that even
   if the key repeats, the IV is also independently generated.  In order
   to provide an extra margin of security, sending implementations MUST
   NOT allow the epoch to exceed 2^48-1.  In order to allow this value
   to be changed later, receiving implementations MUST NOT enforce this
   rule.  If a sending implementation receives a KeyUpdate with
   request_update set to "update_requested", it MUST NOT send its own
   KeyUpdate if that would cause it to exceed these limits and SHOULD
   instead ignore the "update_requested" flag.  Note: this overrides the
   requirement in TLS 1.3 to always send a KeyUpdate in response to
   "update_requested".

Corrected Text
--
   With a 128-bit key as in AES-128, rekeying 2^64 times has a high
   probability of key reuse within a given connection.  Note that even
   if the key repeats, the IV is also independently generated.  In order
   to provide an extra margin of security, sending implementations MUST
   NOT allow the epoch to exceed 2^48-1.  If a sending implementation
   receives a KeyUpdate with request_update set to "update_requested",
   it MUST NOT send its own KeyUpdate if that would cause it to exceed
   these limits and SHOULD instead ignore the "update_requested" flag.
   Note: this overrides the requirement in TLS 1.3 to always send a
   KeyUpdate in response to "update_requested".

   Exceeding the above limit is not possible with the key update
   mechanisms defined in this document.  After the handshake, each epoch
   change consumes a message_seq value, which is limited to 2^16-1. Both
   sending and receiving implementations MAY instead enforce an epoch
   limit of 2^16-1.  In this case, the implementation MUST check for
   this limit, if reached, terminate the association. In some cases, it
   is otherwise possible for the epoch number to reach 2^16+1.

Notes
-
See https://mailarchive.ietf.org/arch/msg/tls/6y8wTv8Q_IPM-PCcbCAmDOYg6bM/ for 
details. Strictly speaking, as noted in the corrected text, the maximum epoch 
value does not *quite* fit in 2^16. However, bumping the implementation's size 
just to accommodate two more epochs seems pointless.

The 2^16-1 value comes from the minimum number of messages in the sending side 
of a handshake, 2 (ClientHello + Finished as a client). Post-handshake, epochs 
begin at 3. From there, we can send at most 2^16-2 KeyUpdates, ending at epoch 
2^16-2+3 = 2^16+1.

In particular, I believe NSS stores the epoch as 16-bit in DTLS 1.3. We plan to 
do so in BoringSSL as well. It is a natural choice because epochs are 16-bit in 
DTLS 1.2. Without this erratum, I believe NSS, and any other implementation 
making this choice, is non-compliant because the spec says the receiver "MUST 
NOT enforce this rule".

To that end, I've deleted that sentence because we cannot *actually* change 
this value. DTLS 1.3 tried, but failed, to enable a larger epoch space. Maybe 
we can try again in DTLS 1.4, or decide we don't care and properly revert to 
16-bit.

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.

--
RFC9147 (draft-ietf-tls-dtls13-43)
--
Title   : The Datagram Transport Layer Security (DTLS) Protocol 
Version 1.3
Publication Date: April 2022
Author(s)   : E. Rescorla, H. Tschofenig, 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]Re: DTLS 1.3 epochs vs message_seq overflow

[David Benjamin]

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://www.rfc-editor.org/errata/eid8048
https://www.rfc-editor.org/errata/eid8050

David

On Tue, Apr 16, 2024 at 2:16 AM Tschofenig, Hannes <
hannes.tschofe...@siemens.com> wrote:

> Hi David,
>
>
>
> thanks for your reviews and the details comments.
>
>
>
> Let me search for the exchanges that lead to the increase in the epoch
> space. I recall that this was very late in the process based on feedback
> from John, who noticed that the smaller epoch space helps IoT communication
> but not the DTLS use in SCTP.
>
>
>
> Regarding your statement: “65K epochs should be enough for anybody,
> perhaps DTLS 1.4 should update the RecordNumber structure accordingly and
> save a few bytes in the ACKs“. Possibly correct. I am going to ask the
> SCTP community for feedback to find out whether that is also true for them.
>
>
>
> Ciao
>
> Hannes
>
>
>
> *From:* TLS  *On Behalf Of *David Benjamin
> *Sent:* Friday, April 12, 2024 1:16 AM
> *To:*  
> *Cc:* Nick Harper 
> *Subject:* Re: [TLS] DTLS 1.3 epochs vs message_seq overflow
>
>
>
> On Thu, Apr 11, 2024 at 7:12 PM David Benjamin 
> wrote:
>
> Hi all,
>
>
>
> In reviewing RFC 9147, I noticed something a bit funny. DTLS 1.3 changed
> the epoch number from 16 bits to 64 bits, though with a requirement that
> you not exceed 2^48-1. I assume this was so that you're able to rekey more
> than 65K times if you really wanted to.
>
>
>
> I'm not sure we actually achieved this. In order to change epochs, you
> need to do a KeyUpdate, which involves sending a handshake message. That
> means burning a handshake message sequence number. However, section 5.2
> says:
>
>
>
> > Note: In DTLS 1.2, the message_seq was reset to zero in case of a
> rehandshake (i.e., renegotiation). On the surface, a rehandshake in DTLS
> 1.2 shares similarities with a post-handshake message exchange in DTLS 1.3.
> However, in DTLS 1.3 the message_seq is not reset, to allow distinguishing
> a retransmission from a previously sent post-handshake message from a newly
> sent post-handshake message.
>
>
>
> This means that the message_seq space is never reset for the lifetime of
> the connection. But message_seq is a 16-bit field! So I think you would
> overflow message_seq before you manage to overflow a 16-bit epoch.
>
>
>
> Now, I think the change here was correct because DTLS 1.2's resetting on
> rehandshake was a mistake. In DTLS 1.2, the end of the previous handshake
> and the start of the next handshake happen in the same epoch, which meant
> that things were ambiguous and you needed knowledge of the handshake state
> machine to resolve things. However, given the wider epoch, perhaps we
> should have said that message_seq resets on each epoch or something. (Too
> late now, of course... DTLS 1.4 I suppose?)
>
>
>
> Alternatively, if we think 65K epochs should be enough for anybody,
> perhaps DTLS 1.4 should update the RecordNumber structure accordingly and
> save a few bytes in the ACKs. :-)
>
>
>
> Does all that check out, or did I miss something?
>
>
>
> David
>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

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

[RFC Errata System]

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: Editorial
Reported by: David Benjamin 

Section: 6.1

Original Text
-
   *  Epoch value (2) is used for messages protected using keys derived
  from [sender]_handshake_traffic_secret.  Messages transmitted
  during the initial handshake, such as EncryptedExtensions,
  CertificateRequest, Certificate, CertificateVerify, and Finished,
  belong to this category.  Note, however, that post-handshake
  messages are protected under the appropriate application traffic
  key and are not included in this category.

Corrected Text
--
   *  Epoch value (2) is used for messages protected using keys derived
  from [sender]_handshake_traffic_secret.  Messages transmitted
  during the handshake, such as EncryptedExtensions,
  CertificateRequest, Certificate, CertificateVerify, and Finished,
  belong to this category.  Note, however, that post-handshake
  messages are protected under the appropriate application traffic
  key and are not included in this category.

Notes
-
The discussion of "initial handshake" appears to be a remnant of DTLS 1.2, 
where a single connection may have multiple handshakes via renegotiation. In 
(D)TLS 1.3, there is only one handshake per connection.

Looking to RFC 8446, the only references to "initial handshake" refer to 
resumption, talking about the handshake in the initial connection, vs the 
handshake in resumption connections. This reference is not trying to 
distinguish initial vs resumption handshakes, so the use of "initial handshake" 
is a bit confusing. I believe plain "handshake" is the right terminology.

NB: There are two other references to "initial handshake", one in the diagram 
in Section 8, and another in Section 11. I believe they too should be switched 
to "handshake".

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.

--
RFC9147 (draft-ietf-tls-dtls13-43)
--
Title   : The Datagram Transport Layer Security (DTLS) Protocol 
Version 1.3
Publication Date: April 2022
Author(s)   : E. Rescorla, H. Tschofenig, 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]Re: DTLS 1.3 sequence number lengths and lack of ACKs

[David Benjamin]

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
mentioning the possibility of application-mediated ACK feedback? It seems
pretty unlikely to me that anyone would implement that.





On Tue, Apr 16, 2024 at 6:46 AM Tschofenig, Hannes <
hannes.tschofe...@siemens.com> wrote:

> Fair enough. I don’t have a strong preference as long as we document it
> somewhere.
>
>
>
> Ciao
> Hannes
>
>
>
> *From:* David Benjamin 
> *Sent:* Tuesday, April 16, 2024 3:18 PM
> *To:* Tschofenig, Hannes (T CST SEA-DE) 
> *Cc:*  ; Nick Harper 
> *Subject:* Re: [TLS] DTLS 1.3 sequence number lengths and lack of ACKs
>
>
>
> Regarding UTA or elsewhere, let's see how the buffered KeyUpdates issue
> pans out. If I haven't missed something, that one seems severe enough to
> warrants an rfc9147bis, or at least a slew of significant errata, in which
> case we may as well put the fixups into the main document where they'll be
> easier for an implementator to find.
>
>
>
> Certainly, as someone reading the document now to plan an implementation,
> I would have found it much, much less helpful to put crucial information
> like this in a separate UTA document instead of the main one, as these
> details influence how and whether to expose the 8- vs 16-bit choice to
> Applications Using TLS at all.
>
>
>
> David
>
>
>
>
>
>
>
> On Tue, Apr 16, 2024, 05:17 Tschofenig, Hannes <
> hannes.tschofe...@siemens.com> wrote:
>
> Hi David,
>
>
>
> thanks again for these comments.
>
>
>
> Speaking for myself, this exchange was not designed based on QUIC. I
> believe it pre-dated the corresponding work in QUIC.
>
>
>
> Anyway, there are different usage environments and, as you said, there is
> a difference in the amount of messages that may be lost. For some
> environments the loss 255 messages amounts to losing the message exchanges
> of several days, potentially weeks. As such, for those use cases the
> shorter sequence number space is perfectly fine. For other environments
> this is obviously an issue and you have to select the bigger sequence
> number space.
>
>
>
> More explanation about this aspect never hurts. Of course, nobody raised
> the need for such text so far and hence we didn’t add anything. As a way
> forward, we could add text to the UTA document. In the UTA document(s) we
> already talk about other configurable parameters, such as the timeout.
>
>
>
> Ciao
>
> Hannes
>
>
>
> *From:* TLS  *On Behalf Of *David Benjamin
> *Sent:* Friday, April 12, 2024 11:36 PM
> *To:*  
> *Cc:* Nick Harper 
> *Subject:* [TLS] DTLS 1.3 sequence number lengths and lack of ACKs
>
>
>
> Hi all,
>
>
>
> Here's another issue we noticed with RFC 9147: (There's going to be a few
> of these emails. :-) )
>
>
>
> DTLS 1.3 allows senders to pick an 8-bit or 16-bit sequence number. But,
> unless I missed it, there isn't any discussion or guidance on which to use.
> The draft simply says:
>
>
>
> > Implementations MAY mix sequence numbers of different lengths on the
> same connection
>
>
>
> I assume this was patterned after QUIC, but looking at QUIC suggests an
> issue with the DTLS 1.3 formulation. QUIC uses ACKs to pick the minimum
> number of bytes needed for the peer to recover the sequence number:
>
> https://www.rfc-editor.org/rfc/rfc9000.html#packet-encoding
>
>
>
> But the bulk of DTLS records, app data, are unreliable and not ACKed. DTLS
> leaves all that to application. This means a DTLS implementation does not
> have enough information to make this decision. It would need to be
> integrated into the application-protocol-specific reliability story, if the
> application protocol even maintains that information.
>
>
>
> Without ACK feedback, it is hard to size the sequence number safely.
> Suppose a DTLS 1.3 stack unconditionally picked the 1-byte sequence number
> because it's smaller, and the draft didn't say not to do it. That means
> after getting out of sync by 256 records, either via reordering or loss,
> the connection breaks. For example, if there was a blip in connectivity and
> you happened to lose 256 records, your connection is stuck and cannot
> recover. All future records will be at higher and higher sequence numbers.
> A burst of 256 lost packets seems within the range of situations one would
> expect an application to handle.
>
>
>
> (The 2-byte sequence number fails at 65K losses, which is hopefully high
> enough to be fine?  Though it's far far less than what QUIC's 1-4-byte
> sequence number can accommodate. It was also odd to see no discussion of
> this anywhere.)
>
>
>
> David
>
>
___
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org