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 _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
