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

[Stephen Farrell <[e-mail]>]

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.

Cheers,
S.



> 
> Russ
> 
> 
>> On Dec 6, 2023, at 4:21 PM, Stephen Farrell
>> <[e-mail]> wrote:
>> 
>> 
>> Hiya,
>> 
>> On 06/12/2023 21:06, Russ Housley wrote:
>>> 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.
>> 
>> That'd be a fairly giant outer client hello though if you include 
>> real PSK stuff in the inner CH, more or less any PQ hybrid scheme 
>> and the phoney/GREASE PSK stuff in the outer CH. I dunno if it'd be
>> feasible to use in practice, which would seem telling in terms of
>> promotion from experimental. I think someone would need to check 
>> the numbers and/or maybe figure out if the phoney/GREASE outer PSK 
>> stuff can be safely omitted in this context, and then write down 
>> how to do that.
>> 
>> I suspect that could end up with something that'd work ok, but
>> it'd need some work, and that's in addition to saying how to do the
>> PQ thing for ECH, which'd involve a number of design decisions I
>> think, and might in itself be a bit of an experiment.
>> 
>> So I don't think a quick bit of text about ECH solves the problem 
>> John raised in this context, or, at least, it'd be a non-trivial 
>> solution, and maybe more that you'd want if starting with with the 
>> goal in the subject line? (Not trying to be negative, just not at 
>> all sure.)
>> 
>> Cheers, S.
>> 
>>> 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>
>> <OpenPGP_0xE4D8E9F997A833DD.asc>
>