[skex] Re: Updates

[Eric Rescorla <[e-mail]>]

On Tue, May 7, 2024 at 7:00 AM Tony Rosati <[e-mail]>
wrote:

> Hi guys,
>
>
>
> To clarify, in RFC 8446, TLS-PSK only offers no FS.
>

Unfortunately, the situation is slightly more complicated than this.

If you use a long-term PSK then knowledge of the PSK allows you to decrypt
traffic. However, one of the main uses of PSK is for resumption, in which
you establish a key in connection A using ECDHE and then use it in
connection B. In TLS 1.2, these keys were the same, but in TLS 1.3 they are
instead derived from the same original secret, but are otherwise
independent, with the key needed for B being called the "Resumption Main
(Master) Secret (RMS)". An attacker who learns the RMS is not able to
decrypt connection A but could decrypt connection B, so you have FS for A.
However, if the client and server delete the RMS after connection B is
complete, then an attacker who compromises the client or server will not be
able to decrypt B. So, in this case you do get FS for B.

However, many TLS implementations do not have a database of the PSK/RMS
pairs but instead have a single static key K_ticket, which they use to
encrypt the RMS to form the PSK label. I.e., PSK-label = E(K_ticket, RMS).
In this case, compromise of K_ticket leads to recovery of the RMS and so
you don't get FS for B (though you still do for A,)


 But there is a PSK with ECDHE mode that does provide FS, correct?
>

Yes, though any 0-RTT data has the properties I mentioned above.

-Ekr


>
>
> Thanks
>
> Tony
>
>
>
> *From: *skex <[e-mail]> on behalf of Eric Rescorla <
> [e-mail]>
> *Date: *Monday, May 6, 2024 at 10:23 AM
> *To: *Manfred von Willich <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>
> *Subject: *Re: [skex] Updates
>
>
>
>
>
> On Mon, May 6, 2024 at 6:07 AM Manfred von Willich <
> [e-mail]> wrote:
>
>
>
> On Mon, May 6, 2024 at 8:42 AM Eric Rescorla <[e-mail]> wrote:
>
>
>
> On Mon, May 6, 2024 at 5:34 AM Yanlei(Ray) <ray.yanlei=
> [e-mail]> wrote:
>
> 1. In the new version of use cases, the use cases are divided into "PSK
> for use in tandem with asymmetric key agreement" and "Standalone and other
> key establishment". TLS belongs to the first kind of use cases. However, I
> think TLS 1.3 also supports PSK-only key exchange mode and also belongs to
> the second category.
>
>
>
> TLS 1.3 does in fact support a PSK-only mode, though it is not in wide use
> because it does not provide PFS.
>
>
>
> Surely that is not quite true?  As I understand it, TLS PSK-only allows
> negotiation of which PSK to use with each session, providing PFS given a
> suitable key establishment.  Seen this way, the PFS limitation is not in
> the PSK-only version of TLS, but in the mindset of the implementer.
>
>
>
> Yes, under the hypothesis that the PSK itself was created with some
> mechanism that provides PFS, then TLS-PSK provides PFS.
>
>
>
> However, as a practical matter, TLS-PSK tends to get used in two modes:
>
>
>
> 1. A pre-arranged mostly static key.
>
> 2. TLS session resumption
>
>
>
> The first mode obviously doesn't offer PFS. The second mode has some
> somewhat complicated properties depending on exactly how the Resumption
> Main Secret is handled and whether you are using tickets or storing the
> PSKs in a database, how you delete them, etc. (see
> https://www.rfc-editor.org/rfc/rfc8446#section-8.1)
>
>
>
> As a practical matter, the implementor consensus seems to be to just use
> PSK with a public key exchange.
>
>
>
> -Ekr
>
>
>
>
>
> Thanks for the reminder.  I have now added the TLS PSK-only into my fork
> of the use cases repo (still not merged to original).
>
>
>
> Manfred
>
> --
> skex mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/skex
>
>