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

[Russ Housley <[e-mail]>]

Stephen:

Maybe.  ECH would need to be updated to use PQC algorithms to get that protection.

Ill add that point:

   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] with
   algorithms that a secure against a CRQC can mitigate this risk.

Russ

> On Dec 6, 2023, at 4:00 PM, Stephen Farrell <[e-mail]> wrote:
> 
> 
> 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
>>> <john.mattsson=[e-mail]> 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 <[e-mail] <mailto:[e-mail]>> on
>>> behalf of Dan Harkins <[e-mail]
>>> <mailto:[e-mail]>> Date: Wednesday, 6 December 2023 at
>>> 14:50 To: [e-mail] <mailto:[e-mail]> <[e-mail]
>>> <mailto:[e-mail]>> 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 [e-mail] <mailto:[e-mail]> 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 [e-mail] <mailto:[e-mail]> https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list [e-mail] <mailto:[e-mail]> https://www.ietf.org/mailman/listinfo/tls
>> _______________________________________________ TLS mailing list [e-mail] https://www.ietf.org/mailman/listinfo/tls
> <OpenPGP_0xE4D8E9F997A833DD.asc>