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

[Russ Housley <[e-mail]>]

Geoffrey:
> 
> 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.

I am pleased to add text that will make it more clear, but you are the first one to ask.

Please see slides 5 and 6 of the presentation at IETF 104:
https://datatracker.ietf.org/meeting/104/materials/slides-104-tls-slides-ietf104-tls13-cert-with-extern-psk-00

> 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.

One (EC)DH exchange.

I agree that there is a fair amount of context in the draft.  That was an attempt to avoid the confusion that you claim in the previous paragraph.

> 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.

Hash functions are quantum-resistant.  Shor's algorithm means that you might want to use one that 2x longer than previously chosen.  The same is true for symmetric encryption algorithm keys.

I can add a paragraph to the security considerations that HKDF and the underlying hash function are assumed to be quantum-resistant.

> 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.

Thanks.

Russ