Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Rob Sayre]

Stephen Farrell  wrote:
> That'd be a fairly giant outer client hello

Well, is there a latency histogram?

The reality I've seen ignored in these discussions is that these large
handshake messages are in fact very slow or broken on older
implementations, but that it might not matter.

The very slow tail in the trailing 5-10% area will never be updated anyway,
so it makes no sense to consider them in PQ discussions. For example, we
also have folks claiming we must accommodate very old TLS 1.2
implementations.

thanks,
Rob
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Bas Westerbaan]

sgtm

On Wed, Dec 13, 2023 at 4:36 PM Russ Housley  wrote:

> Bas:
>
> Thanks.  I've adjusted the proposed text to address your comments:
>
>Implementations must use a ciphersuite that includes a symmetric
>encryption algorithm with sufficiently large keys.  For protection
>against the future invention of a CRQC, the symmetric key needs to be
>at least 128 bits.  While Grover’s algorithm (described in
>Section 7.1 of [I-D.ietf-pquip-pqc-engineers]) allows a quantum
>computer to perform a brute force key search using quadratically
>fewer steps than would be required with classical computers, there
>are a number of mitigating factors suggesting that Grover’s algorithm
>will not speed up brute force symmetric key search as dramatically as
>one might suspect.  First, quantum computing hardware will likely be
>more expensive to build and use than classical hardware.  Second, to
>obtain the full quadratic speedup, all the steps of Grover’s
>algorithm must be performed in series.  However, attacks on
>cryptography use massively parallel processing, the advantage of
>Grover’s algorithm will be smaller.
>
>Implementations must use sufficiently large external PSKs.  For
>protection against the future invention of a CRQC, the external PSK
>needs to be at least 128 bits.
>
> Russ
>
>
> On Dec 13, 2023, at 8:18 AM, Bas Westerbaan  wrote:
>
> I think there is a companion point to be made.  I suggest:
>>
>>Implementations must use a ciphersuite that includes a symmetric
>>encryption algorithm with sufficiently large keys.  For protection
>>against the future invention of a CRQC, the symmetric key needs to be
>>at least 256 bits.
>>
>
> Not true.128 bit symmetric keys are fine for PQ.
>
> Right, I think that means that ECH as-is can be used, but in the face
>> of a CRQC, ECH as-is won't protect against the leakage about which
>> John was concerned.
>
>
> Not true. ECH, as-is, can be configured to use a PQ KEM. (Whether it's
> deployable, and whether its performance is acceptable, is something we
> should figure out.)
>
>  Best,
>
>  Bas
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Bas Westerbaan]

> By contrast the PQ version "just" has key size issues to worry about
> with the DNS advertising bits and maybe some structures that get
> tight.
>

I have the same intuition. Instead of guessing, we should plop Kyber in ECH
and see if it works.

If not then there are still other paths besides PSK — for instance using
BAT [1].

Best,

 Bas

[1] https://eprint.iacr.org/2022/031
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Watson Ladd]

On Wed, Dec 13, 2023 at 10:29 AM Christian Huitema  wrote:

>
> Doing a PQ version of ECH would be hard. On the other hand, doing an
> 8773-like enhancement to ECH should not be all that hard. It would
> require that the outer CH contains a PSK shared between the client and
> the fronting server, and then combining that PSK and a classic public
> key to derive the key encrypting the inner CH.

Managing shared symmetric keys between clients and servers at scale is
very much a "sufficient thrust" situation. An actually deployable
version of this, without huge latency would be very tricky: would have
to use tickets, have a way to hand them out, etc.  ECH is of limited
utility without this kind of scale.

By contrast the PQ version "just" has key size issues to worry about
with the DNS advertising bits and maybe some structures that get
tight.

Sincerely,
Watson

-- 
Astra mortemque praestare gradatim

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Christian Huitema]

On 12/12/2023 2:50 PM, Stephen Farrell wrote:


Hiya,

On 12/12/2023 17:08, Russ Housley wrote:

Stephen:

I've been thinking about your point.  Some people want to use RFC
8773 to protect data that is transmitted today and recorded from the
future invention of a quantum computer.  To do this, the handshake
includes the identifier for the external PSK, and an observer can get
tracking data by watching which clients and servers have the same
external PSK.  This tracking data does not need the same long-term
protection as the TLS protected content.  So, the high-level guidance
in the proposed text seems appropriate.  That is, rotation of the
external PSK identity or the use of the Encrypted Client Hello
extension.  I think you are correct, the "with algorithms that a
secure against a CRQC" should be dropped.


Right, I think that means that ECH as-is can be used, but in the face
of a CRQC, ECH as-is won't protect against the leakage about which
John was concerned.

If one is worried about a future CRQC, then using ECH as-is should be
fine and protects for now against that leakage. (One might even add a
bit of text recommending that this extension only be present in the
inner CH whenever ECH is in use?)

Using some future PQ version of ECH can't be done yet, and figuring
out how a PQ-version of ECH would work and not involve too-large a CH
is another day's work.


Doing a PQ version of ECH would be hard. On the other hand, doing an 
8773-like enhancement to ECH should not be all that hard. It would 
require that the outer CH contains a PSK shared between the client and 
the fronting server, and then combining that PSK and a classic public 
key to derive the key encrypting the inner CH.


To get quantum reliance we would need two PSK -- one with the fronting 
server, one with the protected server. The outer PSK would be used to 
harden the ECH encryption key. The inner PSK would be used to harden the 
session key.


Actually, if the fronting server can pass a secret to the protected 
server, this secret could be used instead of the "inner PSK" to harden 
the session key.


Still another day's work, but seems doable -- and keeping with spirit of 
8773, using only old tech like PSK and ECDH instead of relying on 
post-quantum algorithms.


-- Christian Huitema

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Russ Housley]

Bas:

Thanks.  I've adjusted the proposed text to address your comments:

   Implementations must use a ciphersuite that includes a symmetric
   encryption algorithm with sufficiently large keys.  For protection
   against the future invention of a CRQC, the symmetric key needs to be
   at least 128 bits.  While Grover’s algorithm (described in
   Section 7.1 of [I-D.ietf-pquip-pqc-engineers]) allows a quantum
   computer to perform a brute force key search using quadratically
   fewer steps than would be required with classical computers, there
   are a number of mitigating factors suggesting that Grover’s algorithm
   will not speed up brute force symmetric key search as dramatically as
   one might suspect.  First, quantum computing hardware will likely be
   more expensive to build and use than classical hardware.  Second, to
   obtain the full quadratic speedup, all the steps of Grover’s
   algorithm must be performed in series.  However, attacks on
   cryptography use massively parallel processing, the advantage of
   Grover’s algorithm will be smaller.

   Implementations must use sufficiently large external PSKs.  For
   protection against the future invention of a CRQC, the external PSK
   needs to be at least 128 bits.

Russ


> On Dec 13, 2023, at 8:18 AM, Bas Westerbaan  wrote:
> 
>> I think there is a companion point to be made.  I suggest:
>> 
>>Implementations must use a ciphersuite that includes a symmetric
>>encryption algorithm with sufficiently large keys.  For protection
>>against the future invention of a CRQC, the symmetric key needs to be
>>at least 256 bits.
> 
> Not true.128 bit symmetric keys are fine for PQ.
> 
>> Right, I think that means that ECH as-is can be used, but in the face
>> of a CRQC, ECH as-is won't protect against the leakage about which
>> John was concerned.
> 
> Not true. ECH, as-is, can be configured to use a PQ KEM. (Whether it's 
> deployable, and whether its performance is acceptable, is something we should 
> figure out.) 
> 
>  Best,
> 
>  Bas

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Bas Westerbaan]

>
> PS: I do not want us to hold up producing the ECH RFC while
> we figure that out - we should get the current thing out the
> door first!
>

Completely agree.

 Bas
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Stephen Farrell]

Hiya,

On 13/12/2023 13:18, Bas Westerbaan wrote:

Not true. ECH, as-is, can be configured to use a PQ KEM. (Whether it's
deployable, and whether its performance is acceptable, is something we
should figure out.)


I guess we're just interpreting "as-is" differently. What I
meant by "as-is" was an implementation of the current draft.
I agree that we can figure out how to use a PQ KEM with ECH
but that's work still to be done, and hence wasn't included
in what I meant by "ECH as-is."

Cheers,
S.

PS: I do not want us to hold up producing the ECH RFC while
we figure that out - we should get the current thing out the
door first!


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Bas Westerbaan]

>
> I think there is a companion point to be made.  I suggest:
>
>Implementations must use a ciphersuite that includes a symmetric
>encryption algorithm with sufficiently large keys.  For protection
>against the future invention of a CRQC, the symmetric key needs to be
>at least 256 bits.
>

Not true.128 bit symmetric keys are fine for PQ.

Right, I think that means that ECH as-is can be used, but in the face
> of a CRQC, ECH as-is won't protect against the leakage about which
> John was concerned.


Not true. ECH, as-is, can be configured to use a PQ KEM. (Whether it's
deployable, and whether its performance is acceptable, is something we
should figure out.)

 Best,

 Bas
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Russ Housley]

Stephen:
> 
>> I've been thinking about your point.  Some people want to use RFC
>> 8773 to protect data that is transmitted today and recorded from the
>> future invention of a quantum computer.  To do this, the handshake
>> includes the identifier for the external PSK, and an observer can get
>> tracking data by watching which clients and servers have the same
>> external PSK.  This tracking data does not need the same long-term
>> protection as the TLS protected content.  So, the high-level guidance
>> in the proposed text seems appropriate.  That is, rotation of the
>> external PSK identity or the use of the Encrypted Client Hello
>> extension.  I think you are correct, the "with algorithms that a
>> secure against a CRQC" should be dropped.
> 
> Right, I think that means that ECH as-is can be used, but in the face
> of a CRQC, ECH as-is won't protect against the leakage about which
> John was concerned.
> 
> If one is worried about a future CRQC, then using ECH as-is should be
> fine and protects for now against that leakage. (One might even add a
> bit of text recommending that this extension only be present in the
> inner CH whenever ECH is in use?)
> 
> Using some future PQ version of ECH can't be done yet, and figuring
> out how a PQ-version of ECH would work and not involve too-large a CH
> is another day's work.

I think that is correct, one a CRQC comes along, the attacker will be able to 
decrypt the identifiers for the external PSK and gain tracking information, but 
not the payload content.

In the future, when the TLS WG tackles a quantum-resistant ECH, then this 
concern will be resolved.

Russ



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Stephen Farrell]

tract only talks
about PSK authentication. The key exchange is likely more
important to make quantum-resistant than the
authentication. I think the title and abstract should talk
about PSK key exchange. - I think the paywalled references
should be removed. I think paywalled references are both a
cybersecurity risk and a democracy problem [1]. I don’t
think they belong in RFCs unless absolutely necessary. RFC
8446bis recently removed all paywalled references. - The 
document should refer to section C.4 of RFC8446bis that

now includes a short discussion on that reuse of an PSK
identifier enables tracking. I think RFC8773bis should have
a warning early that the privacy properties are much worse
than the normal certificate-based authentication. This
could be completely solved by mandating ECH. Alternatively,
it could be solved by sending the PSK identifier after
flight #1 when things are encrypted. 3GPP specified the use
of server certificate authentication combined with PSK
authentication and key exchange for TLS 1.2. As that mode
was not available in RFC 8446, 3GPP does not specify this 
mode for TLS 1.3 but there have recently been discussions

in 3GPP about adding RFC 8773. I think the really bad
privacy properties of PSK in TLS 1.3 is a significant
problem for 3GPP. The bad privacy properties of TLS 1.3
with PSK have also been discussed several times in EMU WG.
I think a mode that sends the PSK identifier encrypted
would make a lot more sense for standard track. I am not
supportive of standard track unless the tracking problem is
solved. If the privacy problems are solved, I am however
very supportive. Adding an extra roundtrip is a small price
to pay for privacy. Adding a field (psk identifier) that
can be used for tracking to current certificate-based TLS
is making privacy worse. I don’t think that is a good idea
or worthy of standards track. Cheers, John Preuß Mattsson 
[1] 
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/W2VOzy0wz_E/m/6pgf5tFaAAAJ





From: TLS mailto:tls-boun...@ietf.org>> on
behalf of Dan Harkins <mailto:dhark...@lounge.org>> Date: Wednesday, 6 December

2023 at 14:50 To: TLS@ietf.org <mailto:TLS@ietf.org>
mailto:tls@ietf.org>> Subject: Re: [TLS]
Call to Move RFC 8773 from Experimental to Standards Track 
Hi, I approve of this transition to standards track and I

am implementing this as well. regards, Dan. On 11/29/23
7:51 AM, Joseph Salowey wrote:

RFC 8773 (TLS 1.3 Extension for Certificate-Based
Authentication with an External Pre-Shared Key) was
originally published as experimental due to lack of
implementations. As part of implementation work for the
EMU workitem draft-ietf-emu-bootstrapped-tls which uses
RFC 8773 there is ongoing implementation work. Since the
implementation status of RFC 8773 is changing, this is a
consensus call to move RFC 8773 to standards track as
reflected in
[RFC8773bis](https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis).






This will also help avoid downref for the EMU draft.  Please indicate

if you approve of or object to this transition to
standards track status by December 15, 2023. Thanks, Joe,
Sean, and Deirdre 
___ TLS

mailing list TLS@ietf.org <mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls

-- "The object of life is not to be on the side of the
majority, but to escape finding oneself in the ranks of the
insane." -- Marcus Aurelius 
___ TLS mailing

list TLS@ietf.org <mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
___ TLS mailing
list TLS@ietf.org <mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls

___ TLS mailing
list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls








OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Russ Housley]

Christian:

>>> 
>>> Thanks. I am not 100% sure that we actually have an attack against the 
>>> [EC]DH+PSK combination, but I am confident than if the PSK secret is weak, 
>>> the attacker can get to the early data. If only for that, it is prudent to 
>>> use long enough PSK.
>> As stated in draft-ietf-tls-8773bis, some people are interested in using the 
>> external PSK with a certificate to protect against the future invention of a 
>> Cryptographically Relevant Quantum Computer (CRQC).  Others want to use of a 
>> public key with a factory-provisioned secret value for the initial 
>> enrollment of a device in an enterprise network (for example 
>> draft-ietf-emu-bootstrapped-tls).
>> For the security consideration, I suggest an additional paragraph:
>> Implementations must use sufficiently large external PSKs.  For 
>> protection
>> against the future invention of a CRQC, the external PSK needs to be 
>> at
>> least 256 bits.
>> Does that resolve your concern?
> 
> Yes.


I think there is a companion point to be made.  I suggest:

   Implementations must use a ciphersuite that includes a symmetric
   encryption algorithm with sufficiently large keys.  For protection
   against the future invention of a CRQC, the symmetric key needs to be
   at least 256 bits.

   Implementations must use sufficiently large external PSKs.  For
   protection against the future invention of a CRQC, the external PSK
   needs to be at least 256 bits.

Russ

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Russ Housley]

f both the client and the
>>>>> server. I don’t think that such a field enabling tracking belongs
>>>>> in modern TLS, but reuse of a PSK identifier is already in RFC 8446
>>>>> so this document does theoretically not make the worst-case worse.
>>>>> If RFC 8773 is updated. I think the following things should be
>>>>> updated: - The title and abstract only talks about PSK
>>>>> authentication. The key exchange is likely more important to make
>>>>> quantum-resistant than the authentication. I think the title and
>>>>> abstract should talk about PSK key exchange. - I think the
>>>>> paywalled references should be removed. I think paywalled
>>>>> references are both a cybersecurity risk and a democracy problem
>>>>> [1]. I don’t think they belong in RFCs unless absolutely necessary.
>>>>> RFC 8446bis recently removed all paywalled references. - The
>>>>> document should refer to section C.4 of RFC8446bis that now
>>>>> includes a short discussion on that reuse of an PSK identifier
>>>>> enables tracking. I think RFC8773bis should have a warning early
>>>>> that the privacy properties are much worse than the normal
>>>>> certificate-based authentication. This could be completely solved
>>>>> by mandating ECH. Alternatively, it could be solved by sending the
>>>>> PSK identifier after flight #1 when things are encrypted.
>>>>> 3GPP specified the use of server certificate authentication
>>>>> combined with PSK authentication and key exchange for TLS 1.2. As
>>>>> that mode was not available in RFC 8446, 3GPP does not specify this
>>>>> mode for TLS 1.3 but there have recently been discussions in 3GPP
>>>>> about adding RFC 8773. I think the really bad privacy properties of
>>>>> PSK in TLS 1.3 is a significant problem for 3GPP. The bad privacy
>>>>> properties of TLS 1.3 with PSK have also been discussed several
>>>>> times in EMU WG. I think a mode that sends the PSK identifier
>>>>> encrypted would make a lot more sense for standard track.
>>>>> I am not supportive of standard track unless the tracking problem
>>>>> is solved. If the privacy problems are solved, I am however very
>>>>> supportive. Adding an extra roundtrip is a small price to pay for
>>>>> privacy. Adding a field (psk identifier) that can be used for
>>>>> tracking to current certificate-based TLS is making privacy worse.
>>>>> I don’t think that is a good idea or worthy of standards track.
>>>>> Cheers, John Preuß Mattsson
>>>>> [1]
>>>>> https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/W2VOzy0wz_E/m/6pgf5tFaAAAJ
>>>>> 
>>>>> From: TLS mailto:tls-boun...@ietf.org>> on
>>>>> behalf of Dan Harkins >>>> <mailto:dhark...@lounge.org>> Date: Wednesday, 6 December 2023 at
>>>>> 14:50 To: TLS@ietf.org <mailto:TLS@ietf.org> >>>> <mailto:tls@ietf.org>> Subject: Re: [TLS] Call to Move RFC 8773
>>>>> from Experimental to Standards Track
>>>>> Hi,
>>>>> I approve of this transition to standards track and I am
>>>>> implementing this as well.
>>>>> regards,
>>>>> Dan.
>>>>> On 11/29/23 7:51 AM, Joseph Salowey wrote:
>>>>>> RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication
>>>>>> with an External Pre-Shared Key) was originally published as
>>>>>> experimental due to lack of implementations. As part of
>>>>>> implementation work for the EMU workitem
>>>>>> draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there is
>>>>>> ongoing implementation work. Since the implementation status of
>>>>>> RFC 8773 is changing, this is a consensus call to move RFC 8773
>>>>>> to standards track as reflected in 
>>>>>> [RFC8773bis](https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis).
>>>>>> 
>>> This will also help avoid downref for the EMU draft.  Please indicate
>>>>>> if you approve of or object to this transition to standards
>>>>>> track status by December 15, 2023.
>>>>>> Thanks,
>>>>>> Joe, Sean, and Deirdre
>>>>>> ___ TLS mailing list 
>>>>>> TLS@ietf.org <mailto:TLS@ietf.org> 
>>>>>> https://www.ietf.org/mailman/listinfo/tls
>>>>> -- "The object of life is not to be on the side of the majority,
>>>>> but to escape finding oneself in the ranks of the insane." --
>>>>> Marcus Aurelius
>>>>> ___ TLS mailing list 
>>>>> TLS@ietf.org <mailto:TLS@ietf.org> 
>>>>> https://www.ietf.org/mailman/listinfo/tls 
>>>>> ___ TLS mailing list 
>>>>> TLS@ietf.org <mailto:TLS@ietf.org> 
>>>>> https://www.ietf.org/mailman/listinfo/tls
>>>> ___ TLS mailing list 
>>>> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
>>> 
> 



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Russ Housley]

John:
> 
> But now when I look at TS 33.222 personally, I see that Section 5.3 actually 
> uses HTTP Digest for the Shared key-based client authentication, not TLS PSK 
> authentication.

Thanks for getting back to me on this.

Russ___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[John Mattsson]

Hi Russ,

Seem like good suggested updates.

Russ Housley wrote:
>Can you point me to the 3GPP document that makes use of RFC 8773?  It should 
>probably be referenced in Section 3.1 >as another example along with 
>[I-D.ietf-emu-bootstrapped-tls].

Hi, Section 5.3 of TS 33.222 specifies "Shared key-based UE authentication with 
certificate-based NAF authentication". Other sections specified “Shared 
key-based mutual authentication” and “Certificate based mutual”. It was 
recently discussed in 3GPP if 5.3 should be updated to refer to RFC 8773.

But now when I look at TS 33.222 personally, I see that Section 5.3 actually 
uses HTTP Digest for the Shared key-based client authentication, not TLS PSK 
authentication. Must have been some misunderstanding. 3GPP does not use RFC 
8773.

Cheers,
John Preuß Mattsson

From: Russ Housley 
Date: Friday, 8 December 2023 at 20:08
To: John Mattsson 
Cc: IETF TLS 
Subject: Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track
John:

Thanks for you thoughtful review.

Russ Housley wrote:
>   Appendix E.6 of [RFC8446] discusses identity-exposure attacks on
>   PSKs.  Also, Appendix C.4 of [I-D.ietf-tls-rfc8446bis] discusses
>   tracking prevention.  The guidance in these sections remain relevant.
>
>   If an external PSK identity is used for multiple connections, then an
>   observer will generally be able track clients and/or servers across
>   connections.  The rotation of the external PSK identity or the use of
>   the Encrypted Client Hello extension [I-D.ietf-tls-esni] can mitigate
>   this risk.

That seems like a good start. I think it would be good the TLS WG came up with 
additional guidelines/mechanisms/requirements for doing External PSK in a 
secure way that does not enable tracking. Using the same External PSK 
identifier for a long time should be discouraged. Maybe ECH is the solution. 
That would however be outside the scope of RFC 8773.

Some additional comments on RFC8773(bis):

- I think the abstact and introduction should talk about client authentication 
as well. Right now it only talks about server authentication. The external PSK 
provides both client and server authentication. The 3GPP use case for RFC 8773 
is to use certificates for the server authentication and PSK for the client 
authentication.

Can you point me to the 3GPP document that makes use of RFC 8773?  It should 
probably be referenced in Section 3.1 as another example along with 
[I-D.ietf-emu-bootstrapped-tls].

Suggested Abstract update:

   This document specifies a TLS 1.3 extension that allows TLS clients
   and servers to authenticate with a combination of a certificate and
   an external pre-shared key (PSK).

Suggested Introduction update:

   The TLS 1.3 [RFC8446] handshake protocol provides two mutually
   exclusive forms of server authentication.  First, the server can be
   authenticated by providing a signature certificate and creating a
   valid digital signature to demonstrate that it possesses the
   corresponding private key.  Second, the server can be authenticated
   by demonstrating that it possesses a pre-shared key (PSK) that was
   established by a previous handshake.  A PSK that is established in
   this fashion is called a resumption PSK.  A PSK that is established
   by any other means is called an external PSK.

   A TLS 1.3 server that is authenticating with a certificate may
   optionally request a certificate from the TLS 1.3 client for
   authentication as described in Section 4.3.2 of [RFC8446].

   This document specifies a TLS 1.3 extension permitting certificate-
   based authentication to be combined with an external PSK as an input
   to the TLS 1.3 key schedule.


- When RFC 8773 was published, we did not have ML-KEM and ML-DSA, now we do. I 
think RFC8773bis should explain how and why the solution with External PSK is 
needed now that we have ML-KEM and ML-DSA. Is it needed when we get standard 
track ML-KEM and ML-DSA? CNSA 2.0 seems to indicate that ML-KEM and ML-DSA is 
enough for TOP SECRET, but I know that some european governments like to always 
combine External PSK with asymmetric crypto just to be on the safe side and to 
always get PFS.

I suggest an additional paragraph in Section 3.1:

   Quantum-resistant public-key cryptographic algorithms are becoming
   standards, but it will take many years for TLS 1.3 ciphersuites that
   use these algorithms to be developed and deployed.  In some
   environments, deployment of a strong external PSK provides protection
   until these quantum-resistant algorithms are deployed.

Russ



Cheers,
John Preuß Mattsson

From: Russ Housley mailto:hous...@vigilsec.com>>
Date: Wednesday, 6 December 2023 at 21:51
To: John Mattsson 
mailto:john.matts...@ericsson.com>>
Cc: IETF TLS mailto:tls@ietf.org>>
Subject: Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track
John:

I respond to your three suggested ch

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Dennis Jackson]

RFC 8773 S3:

> In the near term, this document describes a TLS 1.3 extension to 
protect today's communications from the future invention of a 
large-scale quantum computer by providing a strong external PSK as an 
input to the TLS 1.3 key schedule while preserving the authentication 
provided by the existing certificate and digital signature mechanisms.


I don't see anything specifically alarming about the design, but I'm 
very uncomfortable about any standards-track document making a strong 
security claim like this  if its not backed by some kind of formal 
analysis.


The document could also be a bit more explicit on the security 
properties it achieves and when e.g. that it breaks down once a 
large-scale QC is actually available, that clients & servers need to 
reject connections which do not negotiate the extension to actually 
benefit from its protection.


On the issue of tracking via external PSKs - it's easy to imagine a 
scheme where client and server divide time into epochs and derive 
per-epoch keys to prevent tracking between epochs. I'm sure there must 
be some prior art that could be referenced as a recommendation?


Best,
Dennis

On 29/11/2023 15:51, Joseph Salowey wrote:
RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with 
an External Pre-Shared Key) was originally published as experimental 
due to lack of implementations. As part of implementation work for the 
EMU workitem draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there 
is ongoing implementation work. Since the implementation status of RFC 
8773 is changing, this is a consensus call to move RFC 8773 to 
standards track as reflected in 
[RFC8773bis](https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis). 
This will also help avoid downref for the EMU draft.  Please indicate 
if you approve of or object to this transition to standards track 
status by December 15, 2023.


Thanks,

Joe, Sean, and Deirdre

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Russ Housley]

John:

Thanks for you thoughtful review.

> Russ Housley wrote:
> >   Appendix E.6 of [RFC8446] discusses identity-exposure attacks on
> >   PSKs.  Also, Appendix C.4 of [I-D.ietf-tls-rfc8446bis] discusses
> >   tracking prevention.  The guidance in these sections remain relevant.
> > 
> >   If an external PSK identity is used for multiple connections, then an
> >   observer will generally be able track clients and/or servers across
> >   connections.  The rotation of the external PSK identity or the use of
> >   the Encrypted Client Hello extension [I-D.ietf-tls-esni] can mitigate
> >   this risk.
>  
> That seems like a good start. I think it would be good the TLS WG came up 
> with additional guidelines/mechanisms/requirements for doing External PSK in 
> a secure way that does not enable tracking. Using the same External PSK 
> identifier for a long time should be discouraged. Maybe ECH is the solution. 
> That would however be outside the scope of RFC 8773.
>  
> Some additional comments on RFC8773(bis):
>  
> - I think the abstact and introduction should talk about client 
> authentication as well. Right now it only talks about server authentication. 
> The external PSK provides both client and server authentication. The 3GPP use 
> case for RFC 8773 is to use certificates for the server authentication and 
> PSK for the client authentication.

Can you point me to the 3GPP document that makes use of RFC 8773?  It should 
probably be referenced in Section 3.1 as another example along with 
[I-D.ietf-emu-bootstrapped-tls].

Suggested Abstract update:

   This document specifies a TLS 1.3 extension that allows TLS clients
   and servers to authenticate with a combination of a certificate and
   an external pre-shared key (PSK).

Suggested Introduction update:

   The TLS 1.3 [RFC8446] handshake protocol provides two mutually
   exclusive forms of server authentication.  First, the server can be
   authenticated by providing a signature certificate and creating a
   valid digital signature to demonstrate that it possesses the
   corresponding private key.  Second, the server can be authenticated
   by demonstrating that it possesses a pre-shared key (PSK) that was
   established by a previous handshake.  A PSK that is established in
   this fashion is called a resumption PSK.  A PSK that is established
   by any other means is called an external PSK.

   A TLS 1.3 server that is authenticating with a certificate may
   optionally request a certificate from the TLS 1.3 client for
   authentication as described in Section 4.3.2 of [RFC8446].

   This document specifies a TLS 1.3 extension permitting certificate-
   based authentication to be combined with an external PSK as an input
   to the TLS 1.3 key schedule.

> - When RFC 8773 was published, we did not have ML-KEM and ML-DSA, now we do. 
> I think RFC8773bis should explain how and why the solution with External PSK 
> is needed now that we have ML-KEM and ML-DSA. Is it needed when we get 
> standard track ML-KEM and ML-DSA? CNSA 2.0 seems to indicate that ML-KEM and 
> ML-DSA is enough for TOP SECRET, but I know that some european governments 
> like to always combine External PSK with asymmetric crypto just to be on the 
> safe side and to always get PFS.

I suggest an additional paragraph in Section 3.1:

   Quantum-resistant public-key cryptographic algorithms are becoming
   standards, but it will take many years for TLS 1.3 ciphersuites that
   use these algorithms to be developed and deployed.  In some
   environments, deployment of a strong external PSK provides protection
   until these quantum-resistant algorithms are deployed.

Russ

>  
> Cheers,
> John Preuß Mattsson
>  
> From: Russ Housley mailto:hous...@vigilsec.com>>
> Date: Wednesday, 6 December 2023 at 21:51
> To: John Mattsson  <mailto:john.matts...@ericsson.com>>
> Cc: IETF TLS mailto:tls@ietf.org>>
> Subject: Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track
> 
> John:
>  
> I respond to your three suggested changes below:
>  
> (1) How about a title of "TLS 1.3 Extension for Using Certificates with an 
> External Pre-Shared Key"
>  
> (2) None of the normative references are paywalled.  Two references are not 
> RFCs or RFC errata or I-Ds or IANA web pages:
>  
> [GGM1986] is free access at https://dl.acm.org/doi/10.1145/6490.6503 
> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-aef859da111c15a9=1=8b806035-f71c-4c87-ae4f-a3492b6bc616=https%3A%2F%2Fdl.acm.org%2Fdoi%2F10.1145%2F6490.6503>
>  
> [K2016] I found the same paper at https://eprint.iacr.org/2016/711.  I'll 
> point here. 
> <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-6e0c9e24a3cecc9b=1=8b806

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[John Mattsson]

Hi Russ,

Russ Housley wrote:
>   Appendix E.6 of [RFC8446] discusses identity-exposure attacks on
>   PSKs.  Also, Appendix C.4 of [I-D.ietf-tls-rfc8446bis] discusses
>   tracking prevention.  The guidance in these sections remain relevant.
>
>   If an external PSK identity is used for multiple connections, then an
>   observer will generally be able track clients and/or servers across
>   connections.  The rotation of the external PSK identity or the use of
>   the Encrypted Client Hello extension [I-D.ietf-tls-esni] can mitigate
>   this risk.

That seems like a good start. I think it would be good the TLS WG came up with 
additional guidelines/mechanisms/requirements for doing External PSK in a 
secure way that does not enable tracking. Using the same External PSK 
identifier for a long time should be discouraged. Maybe ECH is the solution. 
That would however be outside the scope of RFC 8773.

Some additional comments on RFC8773(bis):

- I think the abstact and introduction should talk about client authentication 
as well. Right now it only talks about server authentication. The external PSK 
provides both client and server authentication. The 3GPP use case for RFC 8773 
is to use certificates for the server authentication and PSK for the client 
authentication.

- When RFC 8773 was published, we did not have ML-KEM and ML-DSA, now we do. I 
think RFC8773bis should explain how and why the solution with External PSK is 
needed now that we have ML-KEM and ML-DSA. Is it needed when we get standard 
track ML-KEM and ML-DSA? CNSA 2.0 seems to indicate that ML-KEM and ML-DSA is 
enough for TOP SECRET, but I know that some european governments like to always 
combine External PSK with asymmetric crypto just to be on the safe side and to 
always get PFS.

Cheers,
John Preuß Mattsson

From: Russ Housley 
Date: Wednesday, 6 December 2023 at 21:51
To: John Mattsson 
Cc: IETF TLS 
Subject: Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track
John:

I respond to your three suggested changes below:

(1) How about a title of "TLS 1.3 Extension for Using Certificates with an 
External Pre-Shared Key"

(2) None of the normative references are paywalled.  Two references are not 
RFCs or RFC errata or I-Ds or IANA web pages:

[GGM1986] is free access at 
https://dl.acm.org/doi/10.1145/6490.6503<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-aef859da111c15a9=1=8b806035-f71c-4c87-ae4f-a3492b6bc616=https%3A%2F%2Fdl.acm.org%2Fdoi%2F10.1145%2F6490.6503>

[K2016] I found the same paper at https://eprint.iacr.org/2016/711.  I'll point 
here.<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-6e0c9e24a3cecc9b=1=8b806035-f71c-4c87-ae4f-a3492b6bc616=https%3A%2F%2Feprint.iacr.org%2F2016%2F711>

(3) The privacy considerations already talk about Appendix E.6 of [RFC8446].  I 
am please to add a pointer to ECH, but I do not think that ECH use should not 
be mandated.

I suggest:

   Appendix E.6 of [RFC8446] discusses identity-exposure attacks on
   PSKs.  Also, Appendix C.4 of [I-D.ietf-tls-rfc8446bis] discusses
   tracking prevention.  The guidance in these sections remain relevant.

   If an external PSK identity is used for multiple connections, then an
   observer will generally be able track clients and/or servers across
   connections.  The rotation of the external PSK identity or the use of
   the Encrypted Client Hello extension [I-D.ietf-tls-esni] can mitigate
   this risk.

Russ



On Dec 6, 2023, at 11:51 AM, John Mattsson 
 wrote:

Hi,

I am quite convinced that the security properties are not worse than a mixture 
of PSK authentication, PSK key exchange, (EC)DHE key exchange, and signature 
authentication.

In some cases, this is very good. You get the quantum-resistance of the PSK 
together with the PFS of ECDHE, and the entity authentication and security 
policies of certificates. In other cases, it is not so good as the reuse of a 
PSK identifier enables tracking and potentially identification of both the 
client and the server. I don’t think that such a field enabling tracking 
belongs in modern TLS, but reuse of a PSK identifier is already in RFC 8446 so 
this document does theoretically not make the worst-case worse.

If RFC 8773 is updated. I think the following things should be updated:
- The title and abstract only talks about PSK authentication. The key exchange 
is likely more important to make quantum-resistant than the authentication. I 
think the title and abstract should talk about PSK key exchange.
- I think the paywalled references should be removed. I think paywalled 
references are both a cybersecurity risk and a democracy problem [1]. I don’t 
think they belong in RFCs unless absolutely necessary. RFC 8446bis recently 
removed all paywalled references.
- The document should refer to section C.4 of RFC8446bis that now includes a 
short discussion on that reuse of an PSK identi

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Stephen Farrell]

 that sends the PSK identifier
encrypted would make a lot more sense for standard track.
I am not supportive of standard track unless the tracking problem
is solved. If the privacy problems are solved, I am however very
supportive. Adding an extra roundtrip is a small price to pay for
privacy. Adding a field (psk identifier) that can be used for
tracking to current certificate-based TLS is making privacy worse.
I don’t think that is a good idea or worthy of standards track.
Cheers, John Preuß Mattsson
[1]
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/W2VOzy0wz_E/m/6pgf5tFaAAAJ

From: TLS mailto:tls-boun...@ietf.org>> on
behalf of Dan Harkins mailto:dhark...@lounge.org>> Date: Wednesday, 6 December 2023 at
14:50 To: TLS@ietf.org <mailto:TLS@ietf.org> mailto:tls@ietf.org>> Subject: Re: [TLS] Call to Move RFC 8773
from Experimental to Standards Track
Hi,
I approve of this transition to standards track and I am
implementing this as well.
regards,
Dan.
On 11/29/23 7:51 AM, Joseph Salowey wrote:

RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication
with an External Pre-Shared Key) was originally published as
experimental due to lack of implementations. As part of
implementation work for the EMU workitem
draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there is
ongoing implementation work. Since the implementation status of
RFC 8773 is changing, this is a consensus call to move RFC 8773
to standards track as reflected in 
[RFC8773bis](https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis).


This will also help avoid downref for the EMU draft.  Please indicate

if you approve of or object to this transition to standards
track status by December 15, 2023.
Thanks,
Joe, Sean, and Deirdre
___ TLS mailing list TLS@ietf.org 
<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls

-- "The object of life is not to be on the side of the majority,
but to escape finding oneself in the ranks of the insane." --
Marcus Aurelius
___ TLS mailing list TLS@ietf.org 
<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls 
___ TLS mailing list TLS@ietf.org 
<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls

___ TLS mailing list TLS@ietf.org 
https://www.ietf.org/mailman/listinfo/tls






OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Russ Housley]

n be used for
>>> tracking to current certificate-based TLS is making privacy worse.
>>> I don’t think that is a good idea or worthy of standards track.
>>> Cheers, John Preuß Mattsson
>>> [1]
>>> https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/W2VOzy0wz_E/m/6pgf5tFaAAAJ
>>> 
>>> From: TLS mailto:tls-boun...@ietf.org>> on
>>> behalf of Dan Harkins >> <mailto:dhark...@lounge.org>> Date: Wednesday, 6 December 2023 at
>>> 14:50 To: TLS@ietf.org <mailto:TLS@ietf.org> >> <mailto:tls@ietf.org>> Subject: Re: [TLS] Call to Move RFC 8773
>>> from Experimental to Standards Track
>>> Hi,
>>> I approve of this transition to standards track and I am
>>> implementing this as well.
>>> regards,
>>> Dan.
>>> On 11/29/23 7:51 AM, Joseph Salowey wrote:
>>>> RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication
>>>> with an External Pre-Shared Key) was originally published as
>>>> experimental due to lack of implementations. As part of
>>>> implementation work for the EMU workitem
>>>> draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there is
>>>> ongoing implementation work. Since the implementation status of
>>>> RFC 8773 is changing, this is a consensus call to move RFC 8773
>>>> to standards track as reflected in 
>>>> [RFC8773bis](https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis).
>>>> 
> This will also help avoid downref for the EMU draft.  Please indicate
>>>> if you approve of or object to this transition to standards
>>>> track status by December 15, 2023.
>>>> Thanks,
>>>> Joe, Sean, and Deirdre
>>>> ___ TLS mailing list 
>>>> TLS@ietf.org <mailto:TLS@ietf.org> 
>>>> https://www.ietf.org/mailman/listinfo/tls
>>> -- "The object of life is not to be on the side of the majority,
>>> but to escape finding oneself in the ranks of the insane." --
>>> Marcus Aurelius
>>> ___ TLS mailing list 
>>> TLS@ietf.org <mailto:TLS@ietf.org> 
>>> https://www.ietf.org/mailman/listinfo/tls 
>>> ___ TLS mailing list 
>>> TLS@ietf.org <mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
>> ___ TLS mailing list 
>> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
> 



signature.asc
Description: Message signed with OpenPGP
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Christian Huitema]

On 12/6/2023 10:59 AM, Russ Housley wrote:

Christian:


Thanks. I am not 100% sure that we actually have an attack against the 
[EC]DH+PSK combination, but I am confident than if the PSK secret is weak, the 
attacker can get to the early data. If only for that, it is prudent to use long 
enough PSK.


As stated in draft-ietf-tls-8773bis, some people are interested in using the 
external PSK with a certificate to protect against the future invention of a 
Cryptographically Relevant Quantum Computer (CRQC).  Others want to use of a 
public key with a factory-provisioned secret value for the initial enrollment 
of a device in an enterprise network (for example 
draft-ietf-emu-bootstrapped-tls).

For the security consideration, I suggest an additional paragraph:

 Implementations must use sufficiently large external PSKs.  For 
protection
 against the future invention of a CRQC, the external PSK needs to be at
 least 256 bits.

Does that resolve your concern?


Yes.

-- Christian Huitema

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Stephen Farrell]

Hiya,


(3) The privacy considerations already talk about Appendix E.6 of
[RFC8446].  I am please to add a pointer to ECH, but I do not think
that ECH use should not be mandated.


While I'm a fan of ECH, does it actually do the trick here?
If the adversary has a CRQC then we'd need an updated ECH
that's not vulnerable in that scenario, and we don't have
that now. (And it might be hard to get to, given MTU sizes.)

Cheers,
S.



I suggest:

Appendix E.6 of [RFC8446] discusses identity-exposure attacks on 
PSKs.  Also, Appendix C.4 of [I-D.ietf-tls-rfc8446bis] discusses 
tracking prevention.  The guidance in these sections remain

relevant.

If an external PSK identity is used for multiple connections, then
an observer will generally be able track clients and/or servers
across connections.  The rotation of the external PSK identity or the
use of the Encrypted Client Hello extension [I-D.ietf-tls-esni] can
mitigate this risk.

Russ



On Dec 6, 2023, at 11:51 AM, John Mattsson
 wrote:

Hi,

I am quite convinced that the security properties are not worse
than a mixture of PSK authentication, PSK key exchange, (EC)DHE key
exchange, and signature authentication.

In some cases, this is very good. You get the quantum-resistance of
the PSK together with the PFS of ECDHE, and the entity
authentication and security policies of certificates. In other
cases, it is not so good as the reuse of a PSK identifier enables
tracking and potentially identification of both the client and the
server. I don’t think that such a field enabling tracking belongs
in modern TLS, but reuse of a PSK identifier is already in RFC 8446
so this document does theoretically not make the worst-case worse.

If RFC 8773 is updated. I think the following things should be
updated: - The title and abstract only talks about PSK
authentication. The key exchange is likely more important to make
quantum-resistant than the authentication. I think the title and
abstract should talk about PSK key exchange. - I think the
paywalled references should be removed. I think paywalled
references are both a cybersecurity risk and a democracy problem
[1]. I don’t think they belong in RFCs unless absolutely necessary.
RFC 8446bis recently removed all paywalled references. - The
document should refer to section C.4 of RFC8446bis that now
includes a short discussion on that reuse of an PSK identifier
enables tracking. I think RFC8773bis should have a warning early
that the privacy properties are much worse than the normal
certificate-based authentication. This could be completely solved
by mandating ECH. Alternatively, it could be solved by sending the
PSK identifier after flight #1 when things are encrypted.

3GPP specified the use of server certificate authentication
combined with PSK authentication and key exchange for TLS 1.2. As
that mode was not available in RFC 8446, 3GPP does not specify this
mode for TLS 1.3 but there have recently been discussions in 3GPP
about adding RFC 8773. I think the really bad privacy properties of
PSK in TLS 1.3 is a significant problem for 3GPP. The bad privacy
properties of TLS 1.3 with PSK have also been discussed several
times in EMU WG. I think a mode that sends the PSK identifier
encrypted would make a lot more sense for standard track.

I am not supportive of standard track unless the tracking problem
is solved. If the privacy problems are solved, I am however very
supportive. Adding an extra roundtrip is a small price to pay for
privacy. Adding a field (psk identifier) that can be used for
tracking to current certificate-based TLS is making privacy worse.
I don’t think that is a good idea or worthy of standards track.

Cheers, John Preuß Mattsson

[1]
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/W2VOzy0wz_E/m/6pgf5tFaAAAJ

 From: TLS mailto:tls-boun...@ietf.org>> on
behalf of Dan Harkins mailto:dhark...@lounge.org>> Date: Wednesday, 6 December 2023 at
14:50 To: TLS@ietf.org <mailto:TLS@ietf.org> mailto:tls@ietf.org>> Subject: Re: [TLS] Call to Move RFC 8773
from Experimental to Standards Track


Hi,

I approve of this transition to standards track and I am
implementing this as well.

regards,

Dan.

On 11/29/23 7:51 AM, Joseph Salowey wrote:

RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication
with an External Pre-Shared Key) was originally published as
experimental due to lack of implementations. As part of
implementation work for the EMU workitem
draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there is
ongoing implementation work. Since the implementation status of
RFC 8773 is changing, this is a consensus call to move RFC 8773
to standards track as reflected in 
[RFC8773bis](https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis).




This will also help avoid downref for the EMU draft.  Please indicate

if you approve of or object to this transition to standards
track status by December 15, 2023.

Thanks,

Joe, Sean, and Deirdre

___

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Russ Housley]

John:

I respond to your three suggested changes below:

(1) How about a title of "TLS 1.3 Extension for Using Certificates with an 
External Pre-Shared Key"

(2) None of the normative references are paywalled.  Two references are not 
RFCs or RFC errata or I-Ds or IANA web pages:

[GGM1986] is free access at https://dl.acm.org/doi/10.1145/6490.6503

[K2016] I found the same paper at https://eprint.iacr.org/2016/711.  
I'll point here.

(3) The privacy considerations already talk about Appendix E.6 of [RFC8446].  I 
am please to add a pointer to ECH, but I do not think that ECH use should not 
be mandated.

I suggest:

   Appendix E.6 of [RFC8446] discusses identity-exposure attacks on
   PSKs.  Also, Appendix C.4 of [I-D.ietf-tls-rfc8446bis] discusses
   tracking prevention.  The guidance in these sections remain relevant.

   If an external PSK identity is used for multiple connections, then an
   observer will generally be able track clients and/or servers across
   connections.  The rotation of the external PSK identity or the use of
   the Encrypted Client Hello extension [I-D.ietf-tls-esni] can mitigate
   this risk.

Russ


> On Dec 6, 2023, at 11:51 AM, John Mattsson 
>  wrote:
> 
> Hi,
>  
> I am quite convinced that the security properties are not worse than a 
> mixture of PSK authentication, PSK key exchange, (EC)DHE key exchange, and 
> signature authentication.
>  
> In some cases, this is very good. You get the quantum-resistance of the PSK 
> together with the PFS of ECDHE, and the entity authentication and security 
> policies of certificates. In other cases, it is not so good as the reuse of a 
> PSK identifier enables tracking and potentially identification of both the 
> client and the server. I don’t think that such a field enabling tracking 
> belongs in modern TLS, but reuse of a PSK identifier is already in RFC 8446 
> so this document does theoretically not make the worst-case worse.
>  
> If RFC 8773 is updated. I think the following things should be updated:
> - The title and abstract only talks about PSK authentication. The key 
> exchange is likely more important to make quantum-resistant than the 
> authentication. I think the title and abstract should talk about PSK key 
> exchange.
> - I think the paywalled references should be removed. I think paywalled 
> references are both a cybersecurity risk and a democracy problem [1]. I don’t 
> think they belong in RFCs unless absolutely necessary. RFC 8446bis recently 
> removed all paywalled references.
> - The document should refer to section C.4 of RFC8446bis that now includes a 
> short discussion on that reuse of an PSK identifier enables tracking. I think 
> RFC8773bis should have a warning early that the privacy properties are much 
> worse than the normal certificate-based authentication. This could be 
> completely solved by mandating ECH. Alternatively, it could be solved by 
> sending the PSK identifier after flight #1 when things are encrypted.
>  
> 3GPP specified the use of server certificate authentication combined with PSK 
> authentication and key exchange for TLS 1.2. As that mode was not available 
> in RFC 8446, 3GPP does not specify this mode for TLS 1.3 but there have 
> recently been discussions in 3GPP about adding RFC 8773. I think the really 
> bad privacy properties of PSK in TLS 1.3 is a significant problem for 3GPP. 
> The bad privacy properties of TLS 1.3 with PSK have also been discussed 
> several times in EMU WG. I think a mode that sends the PSK identifier 
> encrypted would make a lot more sense for standard track.
>  
> I am not supportive of standard track unless the tracking problem is solved. 
> If the privacy problems are solved, I am however very supportive. Adding an 
> extra roundtrip is a small price to pay for privacy. Adding a field (psk 
> identifier) that can be used for tracking to current certificate-based TLS is 
> making privacy worse. I don’t think that is a good idea or worthy of 
> standards track.
>  
> Cheers,
> John Preuß Mattsson
>  
> [1] 
> https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/W2VOzy0wz_E/m/6pgf5tFaAAAJ
>  
> From: TLS mailto:tls-boun...@ietf.org>> on behalf of 
> Dan Harkins mailto:dhark...@lounge.org>>
> Date: Wednesday, 6 December 2023 at 14:50
> To: TLS@ietf.org <mailto:TLS@ietf.org> mailto:tls@ietf.org>>
> Subject: Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track
> 
> 
>Hi,
> 
>I approve of this transition to standards track and I am implementing
> this as well.
> 
>regards,
> 
>Dan.
> 
> On 11/29/23 7:51 AM, Joseph Salowey wrote:
> > RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with 
> > an External Pre-Shared Key)

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Russ Housley]

Christian:
> 
> Thanks. I am not 100% sure that we actually have an attack against the 
> [EC]DH+PSK combination, but I am confident than if the PSK secret is weak, 
> the attacker can get to the early data. If only for that, it is prudent to 
> use long enough PSK.

As stated in draft-ietf-tls-8773bis, some people are interested in using the 
external PSK with a certificate to protect against the future invention of a 
Cryptographically Relevant Quantum Computer (CRQC).  Others want to use of a 
public key with a factory-provisioned secret value for the initial enrollment 
of a device in an enterprise network (for example 
draft-ietf-emu-bootstrapped-tls).

For the security consideration, I suggest an additional paragraph:

Implementations must use sufficiently large external PSKs.  For 
protection
against the future invention of a CRQC, the external PSK needs to be at
least 256 bits.

Does that resolve your concern?

Russ


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[John Mattsson]

Hi,

I am quite convinced that the security properties are not worse than a mixture 
of PSK authentication, PSK key exchange, (EC)DHE key exchange, and signature 
authentication.

In some cases, this is very good. You get the quantum-resistance of the PSK 
together with the PFS of ECDHE, and the entity authentication and security 
policies of certificates. In other cases, it is not so good as the reuse of a 
PSK identifier enables tracking and potentially identification of both the 
client and the server. I don’t think that such a field enabling tracking 
belongs in modern TLS, but reuse of a PSK identifier is already in RFC 8446 so 
this document does theoretically not make the worst-case worse.

If RFC 8773 is updated. I think the following things should be updated:
- The title and abstract only talks about PSK authentication. The key exchange 
is likely more important to make quantum-resistant than the authentication. I 
think the title and abstract should talk about PSK key exchange.
- I think the paywalled references should be removed. I think paywalled 
references are both a cybersecurity risk and a democracy problem [1]. I don’t 
think they belong in RFCs unless absolutely necessary. RFC 8446bis recently 
removed all paywalled references.
- The document should refer to section C.4 of RFC8446bis that now includes a 
short discussion on that reuse of an PSK identifier enables tracking. I think 
RFC8773bis should have a warning early that the privacy properties are much 
worse than the normal certificate-based authentication. This could be 
completely solved by mandating ECH. Alternatively, it could be solved by 
sending the PSK identifier after flight #1 when things are encrypted.

3GPP specified the use of server certificate authentication combined with PSK 
authentication and key exchange for TLS 1.2. As that mode was not available in 
RFC 8446, 3GPP does not specify this mode for TLS 1.3 but there have recently 
been discussions in 3GPP about adding RFC 8773. I think the really bad privacy 
properties of PSK in TLS 1.3 is a significant problem for 3GPP. The bad privacy 
properties of TLS 1.3 with PSK have also been discussed several times in EMU 
WG. I think a mode that sends the PSK identifier encrypted would make a lot 
more sense for standard track.

I am not supportive of standard track unless the tracking problem is solved. If 
the privacy problems are solved, I am however very supportive. Adding an extra 
roundtrip is a small price to pay for privacy. Adding a field (psk identifier) 
that can be used for tracking to current certificate-based TLS is making 
privacy worse. I don’t think that is a good idea or worthy of standards track.

Cheers,
John Preuß Mattsson

[1] 
https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/W2VOzy0wz_E/m/6pgf5tFaAAAJ

From: TLS  on behalf of Dan Harkins 
Date: Wednesday, 6 December 2023 at 14:50
To: TLS@ietf.org 
Subject: Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

   Hi,

   I approve of this transition to standards track and I am implementing
this as well.

   regards,

   Dan.

On 11/29/23 7:51 AM, Joseph Salowey wrote:
> RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with
> an External Pre-Shared Key) was originally published as experimental
> due to lack of implementations. As part of implementation work for the
> EMU workitem draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there
> is ongoing implementation work. Since the implementation status of RFC
> 8773 is changing, this is a consensus call to move RFC 8773 to
> standards track as reflected in
> [RFC8773bis](https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis).
> This will also help avoid downref for the EMU draft.  Please indicate
> if you approve of or object to this transition to standards track
> status by December 15, 2023.
>
> Thanks,
>
> Joe, Sean, and Deirdre
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Dan Harkins]

  Hi,

  I approve of this transition to standards track and I am implementing
this as well.

  regards,

  Dan.

On 11/29/23 7:51 AM, Joseph Salowey wrote:
RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with 
an External Pre-Shared Key) was originally published as experimental 
due to lack of implementations. As part of implementation work for the 
EMU workitem draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there 
is ongoing implementation work. Since the implementation status of RFC 
8773 is changing, this is a consensus call to move RFC 8773 to 
standards track as reflected in 
[RFC8773bis](https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis). 
This will also help avoid downref for the EMU draft.  Please indicate 
if you approve of or object to this transition to standards track 
status by December 15, 2023.


Thanks,

Joe, Sean, and Deirdre

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Ilari Liusvaara]

On Tue, Dec 05, 2023 at 06:24:33PM -0800, Christian Huitema wrote:
> 
> Yes. Both are used to compute the "early secret" -- external PSK for the
> initial handshake, resumption PSK in subsequent handshakes. If the secrets
> are "short" and the attacker can use early data as some kind of oracle, then
> the attacker can probably crack the PSK for the initial handshake, or the
> resumption PSK in subsequent handshakes. If the PSK is cracked, it probably
> does not add much effective entropy to the key computed via the [EC]DH + PSK
> combination.

AFAICT, If the PSK is too weak, then the attacker can crack it using the
binder, no need for any early data.




-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Christian Huitema]

On 12/5/2023 10:56 AM, Russ Housley wrote:




On Dec 5, 2023, at 12:01 PM, Christian Huitema  wrote:

On 12/5/2023 8:13 AM, Russ Housley wrote:

At IETF 104, I presented a slide with informal reasoning about TLS 1.3 Security.
Authentication:
The certificate processing is exactly the same. It is not better or worse.
Key Schedule computation of Early Secret:
– Initial Handshake
Without extension: HKDF-Extract(0, 0)
With extension: HKDF-Extract(ExternalPSK, 0)
– Subsequent Handshake No changes.
Conclusion: Any entropy contributed by the External PSK can only make the Early 
Secret better; the External PSK cannot make it worse.


That's true, but that's not the only point. Your introduction section argues 
that adding entropy will enable resistance to quantum attacks.
We assume that quantum attacks can break symmetric encryption using meet in the middle 
algorithm, which means the "safe" size for a quantum resistant symmetric key is 
probably 256 bits, not the commonly used 128.


Agreed.


If the PSK is also used to encrypt early data, and if that PSK is not strong 
enough, the quantum attacker will do a two steps: use the early data as an 
oracle to break the PSK, then use the now discovered PSK to break the [EC]DH + 
PSK combination.


The external PSK is inserted in the key schedule in the initial handshake.  The 
resumption PSK is used in subsequent handshakes.  So, I am missing something in 
your concern.


Yes. Both are used to compute the "early secret" -- external PSK for the 
initial handshake, resumption PSK in subsequent handshakes. If the 
secrets are "short" and the attacker can use early data as some kind of 
oracle, then the attacker can probably crack the PSK for the initial 
handshake, or the resumption PSK in subsequent handshakes. If the PSK is 
cracked, it probably does not add much effective entropy to the key 
computed via the [EC]DH + PSK combination.





At a minimum, this kind of consideration should be added to the security 
section if we move this RFC to standards track.


I am pleased to add some text about the size of the external PSK.


Thanks. I am not 100% sure that we actually have an attack against the 
[EC]DH+PSK combination, but I am confident than if the PSK secret is 
weak, the attacker can get to the early data. If only for that, it is 
prudent to use long enough PSK.


-- Christian Huitema



Russ




-- Christian Huitema



I will be glad to work with someone that already has things set up for TLS 1.3 
without this extension to do a more formal analysis.
Russ

On Dec 3, 2023, at 5:00 PM, Eric Rescorla  wrote:

To respond directly to the call: I think we should require some level of formal 
analysis for this kind of extension.

If there is some, I think the WG should look at it to determine whether it's 
sufficient. If there isn't I think this should remain at experimental. Not 
having a normative downref is not a good reason; those are trivial to manage.

-Ekr


On Sun, Dec 3, 2023 at 12:28 PM Deirdre Connolly mailto:durumcrustu...@gmail.com>> wrote:

Whoops wrong one, strike that

On Sun, Dec 3, 2023, 3:28 PM Deirdre Connolly mailto:durumcrustu...@gmail.com>> wrote:

At least one bit of work:
https://dl.acm.org/doi/abs/10.1145/3548606.3559360

On Sun, Dec 3, 2023, 3:23 PM Eric Rescorla mailto:e...@rtfm.com>> wrote:

What do we have in terms of formal analysis for this extension?

-Ekr


On Fri, Dec 1, 2023 at 11:40 AM Russ Housley mailto:hous...@vigilsec.com>> wrote:

I think this should move forward.  I am encouraged that at least two people 
have spoken to me about their implementations.

Russ


On Nov 29, 2023, at 10:51 AM, Joseph Salowey mailto:j...@salowey.net>> wrote:

RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with an 
External Pre-Shared Key) was originally published as experimental due to lack 
of implementations. As part of implementation work for the EMU workitem 
draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there is ongoing 
implementation work. Since the implementation status of RFC 8773 is changing, 
this is a consensus call to move RFC 8773 to standards track as reflected in 
[RFC8773bis](https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis). This 
will also help avoid downref for the EMU draft.  Please indicate if you approve 
of or object to this transition to standards track status by December 15, 2023.

Thanks,

Joe, Sean, and Deirdre


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls




___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Russ Housley]

> On Dec 5, 2023, at 12:01 PM, Christian Huitema  wrote:
> 
> On 12/5/2023 8:13 AM, Russ Housley wrote:
>> At IETF 104, I presented a slide with informal reasoning about TLS 1.3 
>> Security.
>> Authentication:
>> The certificate processing is exactly the same. It is not better or worse.
>> Key Schedule computation of Early Secret:
>> – Initial Handshake
>>  Without extension: HKDF-Extract(0, 0)
>>  With extension: HKDF-Extract(ExternalPSK, 0)
>> – Subsequent Handshake No changes.
>> Conclusion: Any entropy contributed by the External PSK can only make the 
>> Early Secret better; the External PSK cannot make it worse.
> 
> That's true, but that's not the only point. Your introduction section argues 
> that adding entropy will enable resistance to quantum attacks.
> We assume that quantum attacks can break symmetric encryption using meet in 
> the middle algorithm, which means the "safe" size for a quantum resistant 
> symmetric key is probably 256 bits, not the commonly used 128.

Agreed.

> If the PSK is also used to encrypt early data, and if that PSK is not strong 
> enough, the quantum attacker will do a two steps: use the early data as an 
> oracle to break the PSK, then use the now discovered PSK to break the [EC]DH 
> + PSK combination.

The external PSK is inserted in the key schedule in the initial handshake.  The 
resumption PSK is used in subsequent handshakes.  So, I am missing something in 
your concern.

> At a minimum, this kind of consideration should be added to the security 
> section if we move this RFC to standards track.

I am pleased to add some text about the size of the external PSK.

Russ


> 
> -- Christian Huitema
> 
> 
>> I will be glad to work with someone that already has things set up for TLS 
>> 1.3 without this extension to do a more formal analysis.
>> Russ
>>> On Dec 3, 2023, at 5:00 PM, Eric Rescorla  wrote:
>>> 
>>> To respond directly to the call: I think we should require some level of 
>>> formal analysis for this kind of extension.
>>> 
>>> If there is some, I think the WG should look at it to determine whether 
>>> it's sufficient. If there isn't I think this should remain at experimental. 
>>> Not having a normative downref is not a good reason; those are trivial to 
>>> manage.
>>> 
>>> -Ekr
>>> 
>>> 
>>> On Sun, Dec 3, 2023 at 12:28 PM Deirdre Connolly >> > wrote:
 Whoops wrong one, strike that
 
 On Sun, Dec 3, 2023, 3:28 PM Deirdre Connolly >>> > wrote:
> At least one bit of work:
> https://dl.acm.org/doi/abs/10.1145/3548606.3559360
> 
> On Sun, Dec 3, 2023, 3:23 PM Eric Rescorla  > wrote:
>> What do we have in terms of formal analysis for this extension?
>> 
>> -Ekr
>> 
>> 
>> On Fri, Dec 1, 2023 at 11:40 AM Russ Housley > > wrote:
>>> I think this should move forward.  I am encouraged that at least two 
>>> people have spoken to me about their implementations.
>>> 
>>> Russ
>>> 
 On Nov 29, 2023, at 10:51 AM, Joseph Salowey >>> > wrote:
 
 RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with 
 an External Pre-Shared Key) was originally published as experimental 
 due to lack of implementations. As part of implementation work for the 
 EMU workitem draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there 
 is ongoing implementation work. Since the implementation status of RFC 
 8773 is changing, this is a consensus call to move RFC 8773 to 
 standards track as reflected in 
 [RFC8773bis](https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis). 
 This will also help avoid downref for the EMU draft.  Please indicate 
 if you approve of or object to this transition to standards track 
 status by December 15, 2023.
 
 Thanks,
 
 Joe, Sean, and Deirdre
 
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Eric Rescorla]

Thanks. This is interesting, but I think we should have a higher standard
than informal reasoning.

We know that there have been challenges around the composition of PSK and
certificates in the past (see Appendix E.1 of RFC 8446), so I think that's
especially true in this case.

-Ekr


On Tue, Dec 5, 2023 at 8:13 AM Russ Housley  wrote:

> At IETF 104, I presented a slide with informal reasoning about TLS 1.3
> Security.
>
> Authentication:
> The certificate processing is exactly the same. It is not better or worse.
>
> Key Schedule computation of Early Secret:
>
> – Initial Handshake
> Without extension: HKDF-Extract(0, 0)
> With extension: HKDF-Extract(ExternalPSK, 0)
>
> – Subsequent Handshake No changes.
>
> Conclusion: Any entropy contributed by the External PSK can only make the
> Early Secret better; the External PSK cannot make it worse.
>
> I will be glad to work with someone that already has things set up for TLS
> 1.3 without this extension to do a more formal analysis.
>
> Russ
>
>
> On Dec 3, 2023, at 5:00 PM, Eric Rescorla  wrote:
>
> To respond directly to the call: I think we should require some level of
> formal analysis for this kind of extension.
>
> If there is some, I think the WG should look at it to determine whether
> it's sufficient. If there isn't I think this should remain at experimental.
> Not having a normative downref is not a good reason; those are trivial to
> manage.
>
> -Ekr
>
>
> On Sun, Dec 3, 2023 at 12:28 PM Deirdre Connolly 
> wrote:
>
>> Whoops wrong one, strike that
>>
>> On Sun, Dec 3, 2023, 3:28 PM Deirdre Connolly 
>> wrote:
>>
>>> At least one bit of work:
>>> https://dl.acm.org/doi/abs/10.1145/3548606.3559360
>>>
>>> On Sun, Dec 3, 2023, 3:23 PM Eric Rescorla  wrote:
>>>
 What do we have in terms of formal analysis for this extension?

 -Ekr


 On Fri, Dec 1, 2023 at 11:40 AM Russ Housley 
 wrote:

> I think this should move forward.  I am encouraged that at least two
> people have spoken to me about their implementations.
>
> Russ
>
> On Nov 29, 2023, at 10:51 AM, Joseph Salowey  wrote:
>
> RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with
> an External Pre-Shared Key) was originally published as experimental due 
> to
> lack of implementations. As part of implementation work for the EMU
> workitem draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there is
> ongoing implementation work. Since the implementation status of RFC 8773 
> is
> changing, this is a consensus call to move RFC 8773 to standards track as
> reflected in [RFC8773bis](
> https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis). This will
> also help avoid downref for the EMU draft.  Please indicate if you approve
> of or object to this transition to standards track status by December 15,
> 2023.
>
> Thanks,
>
> Joe, Sean, and Deirdre
>
>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Christian Huitema]

On 12/5/2023 8:13 AM, Russ Housley wrote:

At IETF 104, I presented a slide with informal reasoning about TLS 1.3 Security.

Authentication:
The certificate processing is exactly the same. It is not better or worse.

Key Schedule computation of Early Secret:

– Initial Handshake
Without extension: HKDF-Extract(0, 0)
With extension: HKDF-Extract(ExternalPSK, 0)

– Subsequent Handshake No changes.

Conclusion: Any entropy contributed by the External PSK can only make the Early 
Secret better; the External PSK cannot make it worse.


That's true, but that's not the only point. Your introduction section 
argues that adding entropy will enable resistance to quantum attacks.
We assume that quantum attacks can break symmetric encryption using meet 
in the middle algorithm, which means the "safe" size for a quantum 
resistant symmetric key is probably 256 bits, not the commonly used 128.


If the PSK is also used to encrypt early data, and if that PSK is not 
strong enough, the quantum attacker will do a two steps: use the early 
data as an oracle to break the PSK, then use the now discovered PSK to 
break the [EC]DH + PSK combination.


At a minimum, this kind of consideration should be added to the security 
section if we move this RFC to standards track.


-- Christian Huitema




I will be glad to work with someone that already has things set up for TLS 1.3 
without this extension to do a more formal analysis.

Russ



On Dec 3, 2023, at 5:00 PM, Eric Rescorla  wrote:

To respond directly to the call: I think we should require some level of formal 
analysis for this kind of extension.

If there is some, I think the WG should look at it to determine whether it's 
sufficient. If there isn't I think this should remain at experimental. Not 
having a normative downref is not a good reason; those are trivial to manage.

-Ekr


On Sun, Dec 3, 2023 at 12:28 PM Deirdre Connolly mailto:durumcrustu...@gmail.com>> wrote:

Whoops wrong one, strike that

On Sun, Dec 3, 2023, 3:28 PM Deirdre Connolly mailto:durumcrustu...@gmail.com>> wrote:

At least one bit of work:
https://dl.acm.org/doi/abs/10.1145/3548606.3559360

On Sun, Dec 3, 2023, 3:23 PM Eric Rescorla mailto:e...@rtfm.com>> wrote:

What do we have in terms of formal analysis for this extension?

-Ekr


On Fri, Dec 1, 2023 at 11:40 AM Russ Housley mailto:hous...@vigilsec.com>> wrote:

I think this should move forward.  I am encouraged that at least two people 
have spoken to me about their implementations.

Russ


On Nov 29, 2023, at 10:51 AM, Joseph Salowey mailto:j...@salowey.net>> wrote:

RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with an 
External Pre-Shared Key) was originally published as experimental due to lack 
of implementations. As part of implementation work for the EMU workitem 
draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there is ongoing 
implementation work. Since the implementation status of RFC 8773 is changing, 
this is a consensus call to move RFC 8773 to standards track as reflected in 
[RFC8773bis](https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis). This 
will also help avoid downref for the EMU draft.  Please indicate if you approve 
of or object to this transition to standards track status by December 15, 2023.

Thanks,

Joe, Sean, and Deirdre





___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Russ Housley]

At IETF 104, I presented a slide with informal reasoning about TLS 1.3 Security.

Authentication:
The certificate processing is exactly the same. It is not better or worse.

Key Schedule computation of Early Secret:

– Initial Handshake
Without extension: HKDF-Extract(0, 0)
With extension: HKDF-Extract(ExternalPSK, 0)

– Subsequent Handshake No changes.

Conclusion: Any entropy contributed by the External PSK can only make the Early 
Secret better; the External PSK cannot make it worse.

I will be glad to work with someone that already has things set up for TLS 1.3 
without this extension to do a more formal analysis.

Russ


> On Dec 3, 2023, at 5:00 PM, Eric Rescorla  wrote:
> 
> To respond directly to the call: I think we should require some level of 
> formal analysis for this kind of extension.
> 
> If there is some, I think the WG should look at it to determine whether it's 
> sufficient. If there isn't I think this should remain at experimental. Not 
> having a normative downref is not a good reason; those are trivial to manage.
> 
> -Ekr
> 
> 
> On Sun, Dec 3, 2023 at 12:28 PM Deirdre Connolly  > wrote:
>> Whoops wrong one, strike that
>> 
>> On Sun, Dec 3, 2023, 3:28 PM Deirdre Connolly > > wrote:
>>> At least one bit of work:
>>> https://dl.acm.org/doi/abs/10.1145/3548606.3559360
>>> 
>>> On Sun, Dec 3, 2023, 3:23 PM Eric Rescorla >> > wrote:
 What do we have in terms of formal analysis for this extension?
 
 -Ekr
 
 
 On Fri, Dec 1, 2023 at 11:40 AM Russ Housley >>> > wrote:
> I think this should move forward.  I am encouraged that at least two 
> people have spoken to me about their implementations.
> 
> Russ
> 
>> On Nov 29, 2023, at 10:51 AM, Joseph Salowey > > wrote:
>> 
>> RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with an 
>> External Pre-Shared Key) was originally published as experimental due to 
>> lack of implementations. As part of implementation work for the EMU 
>> workitem draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there is 
>> ongoing implementation work. Since the implementation status of RFC 8773 
>> is changing, this is a consensus call to move RFC 8773 to standards 
>> track as reflected in 
>> [RFC8773bis](https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis). 
>> This will also help avoid downref for the EMU draft.  Please indicate if 
>> you approve of or object to this transition to standards track status by 
>> December 15, 2023. 
>> 
>> Thanks,
>> 
>> Joe, Sean, and Deirdre
>> 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Christian Huitema]

+1

Reading RFC 8773, I feel at least a tension and maybe a contradiction 
between the stated motivation, resisting to quantum analysis by 
combining an [EC]DH derived secret and a PSK, and the use of the PSK 
alone to derive the early secret. If the early secret is used for 0-RTT, 
then the adversary have some information that only depend on the PSK. 
That information might be used to facilitate the attack on [EC]DH+PSK, 
especially if the PSK is not strong enough to resist quantum analysis.


At this point, this consideration is only a gut feeling. A formal 
analysis would either dispel my weak guess, or confirm it and result in 
specific recommendations such as not using the early secret. Plus, the 
formal analysis might also find other issues, behind this one.


-- Christian Huitema

On 12/3/2023 2:00 PM, Eric Rescorla wrote:

To respond directly to the call: I think we should require some level of
formal analysis for this kind of extension.

If there is some, I think the WG should look at it to determine whether
it's sufficient. If there isn't I think this should remain at experimental.
Not having a normative downref is not a good reason; those are trivial to
manage.

-Ekr


On Sun, Dec 3, 2023 at 12:28 PM Deirdre Connolly 
wrote:


Whoops wrong one, strike that

On Sun, Dec 3, 2023, 3:28 PM Deirdre Connolly 
wrote:


At least one bit of work:
https://dl.acm.org/doi/abs/10.1145/3548606.3559360

On Sun, Dec 3, 2023, 3:23 PM Eric Rescorla  wrote:


What do we have in terms of formal analysis for this extension?

-Ekr


On Fri, Dec 1, 2023 at 11:40 AM Russ Housley 
wrote:


I think this should move forward.  I am encouraged that at least two
people have spoken to me about their implementations.

Russ

On Nov 29, 2023, at 10:51 AM, Joseph Salowey  wrote:

RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with
an External Pre-Shared Key) was originally published as experimental due to
lack of implementations. As part of implementation work for the EMU
workitem draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there is
ongoing implementation work. Since the implementation status of RFC 8773 is
changing, this is a consensus call to move RFC 8773 to standards track as
reflected in [RFC8773bis](
https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis). This will
also help avoid downref for the EMU draft.  Please indicate if you approve
of or object to this transition to standards track status by December 15,
2023.

Thanks,

Joe, Sean, and Deirdre
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls






___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Eric Rescorla]

To respond directly to the call: I think we should require some level of
formal analysis for this kind of extension.

If there is some, I think the WG should look at it to determine whether
it's sufficient. If there isn't I think this should remain at experimental.
Not having a normative downref is not a good reason; those are trivial to
manage.

-Ekr


On Sun, Dec 3, 2023 at 12:28 PM Deirdre Connolly 
wrote:

> Whoops wrong one, strike that
>
> On Sun, Dec 3, 2023, 3:28 PM Deirdre Connolly 
> wrote:
>
>> At least one bit of work:
>> https://dl.acm.org/doi/abs/10.1145/3548606.3559360
>>
>> On Sun, Dec 3, 2023, 3:23 PM Eric Rescorla  wrote:
>>
>>> What do we have in terms of formal analysis for this extension?
>>>
>>> -Ekr
>>>
>>>
>>> On Fri, Dec 1, 2023 at 11:40 AM Russ Housley 
>>> wrote:
>>>
 I think this should move forward.  I am encouraged that at least two
 people have spoken to me about their implementations.

 Russ

 On Nov 29, 2023, at 10:51 AM, Joseph Salowey  wrote:

 RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with
 an External Pre-Shared Key) was originally published as experimental due to
 lack of implementations. As part of implementation work for the EMU
 workitem draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there is
 ongoing implementation work. Since the implementation status of RFC 8773 is
 changing, this is a consensus call to move RFC 8773 to standards track as
 reflected in [RFC8773bis](
 https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis). This will
 also help avoid downref for the EMU draft.  Please indicate if you approve
 of or object to this transition to standards track status by December 15,
 2023.

 Thanks,

 Joe, Sean, and Deirdre
 ___
 TLS mailing list
 TLS@ietf.org
 https://www.ietf.org/mailman/listinfo/tls


 ___
 TLS mailing list
 TLS@ietf.org
 https://www.ietf.org/mailman/listinfo/tls

>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Deirdre Connolly]

Whoops wrong one, strike that

On Sun, Dec 3, 2023, 3:28 PM Deirdre Connolly 
wrote:

> At least one bit of work:
> https://dl.acm.org/doi/abs/10.1145/3548606.3559360
>
> On Sun, Dec 3, 2023, 3:23 PM Eric Rescorla  wrote:
>
>> What do we have in terms of formal analysis for this extension?
>>
>> -Ekr
>>
>>
>> On Fri, Dec 1, 2023 at 11:40 AM Russ Housley 
>> wrote:
>>
>>> I think this should move forward.  I am encouraged that at least two
>>> people have spoken to me about their implementations.
>>>
>>> Russ
>>>
>>> On Nov 29, 2023, at 10:51 AM, Joseph Salowey  wrote:
>>>
>>> RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with an
>>> External Pre-Shared Key) was originally published as experimental due to
>>> lack of implementations. As part of implementation work for the EMU
>>> workitem draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there is
>>> ongoing implementation work. Since the implementation status of RFC 8773 is
>>> changing, this is a consensus call to move RFC 8773 to standards track as
>>> reflected in [RFC8773bis](
>>> https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis). This will
>>> also help avoid downref for the EMU draft.  Please indicate if you approve
>>> of or object to this transition to standards track status by December 15,
>>> 2023.
>>>
>>> Thanks,
>>>
>>> Joe, Sean, and Deirdre
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>>>
>>> ___
>>> TLS mailing list
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Deirdre Connolly]

At least one bit of work:
https://dl.acm.org/doi/abs/10.1145/3548606.3559360

On Sun, Dec 3, 2023, 3:23 PM Eric Rescorla  wrote:

> What do we have in terms of formal analysis for this extension?
>
> -Ekr
>
>
> On Fri, Dec 1, 2023 at 11:40 AM Russ Housley  wrote:
>
>> I think this should move forward.  I am encouraged that at least two
>> people have spoken to me about their implementations.
>>
>> Russ
>>
>> On Nov 29, 2023, at 10:51 AM, Joseph Salowey  wrote:
>>
>> RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with an
>> External Pre-Shared Key) was originally published as experimental due to
>> lack of implementations. As part of implementation work for the EMU
>> workitem draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there is
>> ongoing implementation work. Since the implementation status of RFC 8773 is
>> changing, this is a consensus call to move RFC 8773 to standards track as
>> reflected in [RFC8773bis](
>> https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis). This will also
>> help avoid downref for the EMU draft.  Please indicate if you approve of or
>> object to this transition to standards track status by December 15, 2023.
>>
>> Thanks,
>>
>> Joe, Sean, and Deirdre
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Eric Rescorla]

What do we have in terms of formal analysis for this extension?

-Ekr


On Fri, Dec 1, 2023 at 11:40 AM Russ Housley  wrote:

> I think this should move forward.  I am encouraged that at least two
> people have spoken to me about their implementations.
>
> Russ
>
> On Nov 29, 2023, at 10:51 AM, Joseph Salowey  wrote:
>
> RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with an
> External Pre-Shared Key) was originally published as experimental due to
> lack of implementations. As part of implementation work for the EMU
> workitem draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there is
> ongoing implementation work. Since the implementation status of RFC 8773 is
> changing, this is a consensus call to move RFC 8773 to standards track as
> reflected in [RFC8773bis](
> https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis). This will also
> help avoid downref for the EMU draft.  Please indicate if you approve of or
> object to this transition to standards track status by December 15, 2023.
>
> Thanks,
>
> Joe, Sean, and Deirdre
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Russ Housley]

I think this should move forward.  I am encouraged that at least two people 
have spoken to me about their implementations.

Russ

> On Nov 29, 2023, at 10:51 AM, Joseph Salowey  wrote:
> 
> RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with an 
> External Pre-Shared Key) was originally published as experimental due to lack 
> of implementations. As part of implementation work for the EMU workitem 
> draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there is ongoing 
> implementation work. Since the implementation status of RFC 8773 is changing, 
> this is a consensus call to move RFC 8773 to standards track as reflected in 
> [RFC8773bis](https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis). This 
> will also help avoid downref for the EMU draft.  Please indicate if you 
> approve of or object to this transition to standards track status by December 
> 15, 2023. 
> 
> Thanks,
> 
> Joe, Sean, and Deirdre
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Salz, Rich]

  *   RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with an 
External Pre-Shared Key) was originally published as experimental due to lack 
of implementations…  Please indicate if you approve of or object to this 
transition to standards track status by December 15, 2023.

I support this.

You should’a let the new kid handle the call :)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Call to Move RFC 8773 from Experimental to Standards Track

[Ira McDonald]

Hi,

Approve.

Cheers,
- Ira



On Wed, Nov 29, 2023 at 10:51 AM Joseph Salowey  wrote:

> RFC 8773 (TLS 1.3 Extension for Certificate-Based Authentication with an
> External Pre-Shared Key) was originally published as experimental due to
> lack of implementations. As part of implementation work for the EMU
> workitem draft-ietf-emu-bootstrapped-tls which uses RFC 8773 there is
> ongoing implementation work. Since the implementation status of RFC 8773 is
> changing, this is a consensus call to move RFC 8773 to standards track as
> reflected in [RFC8773bis](
> https://datatracker.ietf.org/doc/draft-ietf-tls-8773bis). This will also
> help avoid downref for the EMU draft.  Please indicate if you approve of or
> object to this transition to standards track status by December 15, 2023.
>
> Thanks,
>
> Joe, Sean, and Deirdre
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls