On Tuesday, 30 July 2019 17:21:05 CEST Scott Fluhrer (sfluhrer) wrote: > During the physical meeting in Montreal, we had a discussion about > postquantum security, and in particular, on how one might want to negotiate > several different 'groups' simultaneously (because there might not be one > group that is entirely trusted, and I put 'groups' in scarequotes because > postquantum key exchanges are typically not formed from a Diffie-Hellman > group). > > At the meeting, there were two options presented: > > Option 1: as the supported group, we insert a 'hybrid marker' (and include > an extension that map lists which combination the hybrid marker stands for) > For example, the client might list in his supported groups hybrid_marker_0 > and hybrid_marker_1, and there would be a separate extension that lists > hybrid_marker_0 = X25519 + SIKEp434 and hybrid_marker_1 = X25519 + > NTRUPR653. The server would then look up the meanings of hybrid_marker_0 > and 1 in the extension, and then compare that against his security policy. > In this option, we would ask IANA to allocate code points for the various > individual postquantum key exchanges (in this example, SIKEp434 and > NTRUPR653), as well a range of code points for the various hybrid_markers. > > Option 2: we have code points for all the various combinations that we may > want to support; hence IANA might allocate a code point X25519_SIKEp434 and > another code point for X25519_NTRUPR653. With this option, the client > would list X25519_SIKEp434 and X25519_NTRUPR653 in their supported groups. > In this option, we would ask IANA to allocate code points for all the > various combinations that we want allow to be negotiated.
yes, option 1 sounds like a safer bet given the number of unknowns we have to work with (though the exact proposed mechanism is a bit clunky) both leave open the question how the secrets should be combined – some kind of concatenation scheme or another round of Derive-Secret → HKDF-Extract -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 115, 612 00 Brno, Czech Republic
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
