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
> <[email protected]> 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 <[email protected] <mailto:[email protected]>> on behalf of
> Dan Harkins <[email protected] <mailto:[email protected]>>
> Date: Wednesday, 6 December 2023 at 14:50
> To: [email protected] <mailto:[email protected]> <[email protected] <mailto:[email protected]>>
> 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
> > [email protected] <mailto:[email protected]>
> > 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
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/tls
> _______________________________________________
> TLS mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
