Re: [TLS] Options for negotiating hybrid key exchanges for postquantum

[Hubert Kario <[e-mail]>]

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