> On May 20, 2019, at 8:25 PM, Geoffrey Keating <[email protected]> wrote:
>
> Joseph Salowey <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/tls
