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 <tls-boun...@ietf.org> on behalf of Dan Harkins <dhark...@lounge.org>
Date: Wednesday, 6 December 2023 at 14:50
To: TLS@ietf.org <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

Reply via email to