Re: [TLS] WGLC for draft-ietf-tls-tls13-cert-with-extern-psk

[Hugo Krawczyk <[e-mail]>]

A clarification on the text suggest below by Russ.

The way I see it, the external PSK as used in
draft-ietf-tls-tls13-cert-with-extern-psk is not intended as a means of
authentication but as a way of regaining forward secrecy in case the
(EC)DHE mechanism is ever broken (e.g., by cryptanalysis or by a quantum
computer). Indeed, as long as the future attacker does not learn the PSK
and the key derivation remains unbroken (e.g., HMAC is still a secure PRF
(*)), that attacker cannot derive the session secrets even if it can
compute the (EC)DHE value. When looking at the mechanism in this way,
questions like whether this is a PSK-with-ECDHE mechanism with added
signatures or a regular 1.5 RTT with added PSK authentication are easily
answered. It is a regular 1.5 RTT where a PSK has been added to the key
derivation for the sake of quantum-resistant forward secrecy. In this case,
one should see authentication as fully relying on certificate-based
signatures. So, even if parties other than the communicating client and
server know the PSK, this endangers the secrecy of PSK and its forward
security effect, but not the authenticity of the handshake.

The above is my interpretation of the draft based on a superficial reading.
I have not studied it carefully enough to validate the design or understand
the full implication to TLS 1.3. Yet, it seems that the above conceptual
approach may help understanding the goal of the draft and analyzing its
security.

(*) The design of HKDF has as an explicit goal to support the case of
secret salt in HKDF-Extract in which case the security of HKDF relies
solely on HMAC being a secure PRF (which is the most studied aspect of
HMAC). Using the PSK as input to the KDF achieves this property.

Hugo

On Tue, May 21, 2019 at 3:46 PM Russ Housley <[e-mail]> wrote:

>
>
> > On May 20, 2019, at 8:25 PM, Geoffrey Keating <[e-mail]> wrote:
> >
> > Joseph Salowey <[e-mail]> writes:
> >
> >> The last call has come and gone without any comment.  Please indicate if
> >> you have reviewed the draft even if you do not have issues to raise so
> the
> >> chairs can see who has reviewed it.  Also indicate if you have any
> plans to
> >> implement the draft.
> >
> > I looked at the draft.
> >
> > My understanding of the draft (and I think it would have helped if it
> > contained a diagram showing the resulting TLS handshake) is that it's
> > specifying the existing psk_dhe_ke flow, to which it adds a
> > certificate-based signature over the handshake, which it doesn't
> > specify but works the same way as in RFC 8446 when there is no PSK.
> >
> > This is somewhat confusing because the draft is written as if it
> > starts with a certificate-based TLS flow and somehow adds a PSK; it
> > repeats all the RFC 8446 PSK machinery, but doesn't explain how the
> > certificate interacts with it, and raises questions like "are there
> > two DH operations or just one?".  I think the draft could have been a
> > lot shorter.
> >
> > Conversely, one area where the draft could have been longer would be to
> > explain how exactly this produces quantum-resistance in the presence
> > of a secret shared key.  It appears that it relies on the HKDF-Expand
> > function being quantum-resistant.  That seems like an important thing
> > to document, given that we don't have fully functional quantum
> > cryptanalysis yet and so don't know exactly what might be
> > quantum-resistant or not.
> >
> > However, once you're past that, the resulting protocol seems quite
> > simple (as an addition to psk_dhe_ke) and I have no objections to it.
>
> I think that the necessary property is that HKDF reman a PRF.
>
> I suggest the following additions to the Security Considerations:
>
>   If the external PSK is known to any party other than the client and
>   the server, then the external PSK MUST NOT be the sole basis for
>   authentication.  The reasoning is explained in [K2016] (see
>   Section 4.2).  When this extension is used, authentication is based
>   on certificates, not the external PSK.
>
>   In this extension, the external PSK regains the forward secrecy if the
>   (EC)DH key agreement is ever broken by cryptanalysis or the future
>   invention of a large-scale quantum computer.  As long as the attacker
>   does not know the PSK and the key derivation algorithm remains
>   unbroken, the attacker cannot derive the session secrets even if they
>   are able to compute the (EC)DH shared secret.
>
>   TLS 1.3 key derivation makes use of the HKDF algorithm, which depends
>   upon the HMAC construction and a hash function.  This extension
>   provides the desired protection for the session secrets as long as
>   HMAC with the selected hash function is a pseudorandom function (PRF)
>   [GGM1986].
>
>
>   [GGM1986]  Goldreich, O., Goldwasser, S., and S. Micali, "How to
>              construct random functions", J. ACM 1986 (33), pp.
>              792-807, 1986.
>
>   [K2016]    Krawczyk, H., "A Unilateral-to-Mutual Authentication
>              Compiler for Key Exchange (with Applications to Client
>              Authentication in TLS 1.3)", IACR ePrint 2016/711, August
>              2016.
>
> Russ
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>