Re: [TLS] A la carte handshake negotiation

[Ilari Liusvaara <[e-mail]>]

On Sun, Jun 28, 2015 at 12:06:09AM -0500, Nico Williams wrote:
> On Sat, Jun 27, 2015 at 11:09:28AM +0300, Ilari Liusvaara wrote:
> > > We could do even better: stop cartesian products altogether.
> > > 
> > >   TLS_SRV_AUTH_NONE (anon)
> > >   TLS_SRV_AUTH_PKIX (certs)
> > >   TLS_SRV_AUTH_PSK  (also authenticates the client)
> > > 
> > >   TLS_KEX_DH
> > >   TLS_KEX_ECDH
> > >   TLS_KEX_KEY_TRANSPORT (encryption to the server's RSA pubkey)
> > > 
> > >   TLS_ENC_AES_128_GCM_SHA256 (the hash is for the handshake, but has to
> > >                               match the symmetric encryption suite's
> > >                               strength)
> > >   TLS_ENC_AES_256_GCM_SHA512
> > >   ...
> > > 
> > > Key exchange, authentication, bulk+hash.
> > 
> > One can't really decouple authentication and key exchange cleanly,
> > especially because of PSK (KEX+Auth sets key exchange shape).
> 
> But I think it simplifies things if we separate them and note that some
> mechanisms of one kind have a "twin" of the other kind.
> 
> Imagine that TLS 1.3 clients offer / servers select mechanisms for key
> exchange and authentication separately but either may contribute to the
> other.  Thus to do PSK without PFS the client would offer PSK for key
> exchange, and PSK again for authentication.  If the client offers ECDH
> for key exchange and PSK for both (and no others), then the server can
> pick either PSK only, or PSK + ECDH; if the client offers ECDH for key
> exchange and PSK for authentication (and no others) then the server must
> do that (or fail).
> 
> Some combinations would be non-sensical, such as RSA key transport for
> key exchange but PSK for authentication.  The server must not pick them,
> but with the client only offering sets of mechanisms from which the
> server picks, that's fine.  If there's no sane combination that could be
> picked, then the client screwed up and the connection fails.

"Chinese menus" with coupled choices are classical source of interop
problems.

Also, out of 6 points for kex/aux (after unifying DH, adding PSK and
renaming PKIX to CERT), only 4 seem sane:

GDH+CERT
GDH+PSK
GDH+ANON
PSK+PSK

KEY_TRANSPORT doesn't lead to anything sane without greatly different
key exchange.

If new PAKE KEX would be added, it would add 2 combinations
fooPAKE+CERT and fooPAKE+ANON (6 for 7).

> > Also, DH and ECDH (and perhaps some other things) do unify to GDH.
> 
> Yes.  Preferably all DH-like key agreement protocols should be unified,
> especially when they can work with standard groups.

Things that I think might be able to unify are SIDH and RLWE (but I'm
not sure, especially of the latter). Which would be nice, given that
both are allegedly PQ, and together with PQ signatures would make
PQ protocol.

The requirements for unification are:
- Capability to work with fixed public parameters
- Only one message per side.
- The messages can be in either order (even if client always goes
  first).
- Message size <64kB for both.

> > Also, one way to do PRF-hash replacement would be to define sets of
> > PRF-hashes, and have the symmetric algorithm pick algorithm from
> > that set.
> 
> Sure.  I tend to think of the PRF as part of the handshake, so it's a
> bit strange to associate it with the bulk cipher, but since we want to
> match their strengths, it makes some sense.  We also have to match key
> exchange and authentication strengths, but we want to succeed with a
> mismatch provided we don't fall to realtime downgrade attacks -- the one
> thing we can always match is the hashed and the bulk ciphers.

The reason to have a plan for PRF replacement is that formally TLS 1.3
requires CR prf-hash (even if reality may be a lot less harsh). So if
SHA-2 ever breaks, there might be a lot of new ciphers....

(SHA-2 breaking would also cause problems with signatures, but that
is a separate matter and only partially solvable at TLS level).


-Ilari