Re: [TLS] A la carte handshake negotiation

[Nico Williams <[e-mail]>]

On Fri, Jun 26, 2015 at 09:12:43PM +0000, David Benjamin wrote:
> On Fri, Jun 26, 2015 at 4:47 PM Nico Williams <[e-mail]> wrote:
> > This can be fixed by having signalling cipher suite assignments for
> > negotiating a cartesian product of them (in addition to any actual
> > cipher suites offered).  [...]
> 
> Hrm. I might not understanding you right, isn't that roughly the same as
> defining new values:
> 
>   [...]
> 
> and saying that TLS 1.3 uses those rather than either ECDHE_RSA or
> ECDHE_ECDSA, but they share a namespace with the pre-1.3 cipher suite list
> for convenience and avoiding a new extension? That seems reasonable to me
> actually. If we avoid weird pre-1.3 interactions, I don't have opinions on
> new extension vs camping out in the old namespace.

Yes, they'd share the same cipher suite number (and name) namespace.

Pre-1.3 implementations would ignore these "new" cipher suites, which is
why still sending some old ones is important for interop.

Using an extension loses the ability to express old vs. new cipher suite
relative priorities.  That might not be a problem (with 1.3<->1.3 using
only the new thing), and if no one cares, then I wouldn't either.

> Or is the goal that, by accepting both ECDHE_CERT and ECDHE_ECDSA, the
> common case can send a slightly shorter ClientHello? (For Chrome I think
> it'd be four bytes because we only do two AEADs.)

There's two different goals here:

1) "Compress" the ClientHello;
2) (maybe!) reduce the amount of bookkeeping to do in the cipher suite
   registry.

(2) is easier if we go with an extension instead of camping on the
cipher suite namespace.

We've failed to register useful cipher suites before.  We can probably
fix this anyways by writing tools for IANA to do the cartesian product
so that it's never again a manual process for RFC authors nor for IANA.

Elegance would also be a goal, except that it's too late for that.

Nico
--