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

[Stephen Farrell <[e-mail]>]

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