Re: [TLS] Ala Carte Cipher suites - was: DSA should die

[Yoav Nir <[e-mail]>]

> On Apr 14, 2015, at 6:02 AM, Daniel Kahn Gillmor <[e-mail]> wrote:
> 
> On Mon 2015-04-13 20:36:58 -0400, Viktor Dukhovni wrote:
>> So a key question is whether policies that rule out various corners
>> of the product space are legitimately required???
> 
> Here's one (granted, contrived) policy:
> 
> * i'm willing to talk to US Government peers (they all want Suite B)
>   and Russian Government peers (they all want GOST).  so my policy is
>   that I want either an all-GOST collection or an all-suite-B
>   collection.  a la carte would suggest that i'd be OK with GOST key
>   agreement combined with suite B symmetric crypto, though i would not
>   consider that OK.
> 

IKE has a complex structure of multiple “proposals”, each a collection of several “transforms”, where a “transform” is one algorithm and you can have more than one algorithm of the same type in a single proposal, so you could have for example:

 - proposal #1: GOST signature, GOST DH group, GOST encryption, GOST MAC
 - proposal #2: AES-128-CGC, AES-GCM-128, HMAC-SHA-1, HMAC-SHA-256, 2048-bit DH group, P-256, RSA certificates.

I haven’t found this construct to be particularly useful, and my implementation only ever emits one proposal (but can be configured with multiple algorithms).

Back to TLS: Your contrived policy can be implemented in the server. Your server (or Rich’s hosting) can be programmed to select only certain combinations depending on SNI, and that does not require any special support in the protocol.

For a client it is more difficult. Do we have a use case where a client connects to some site, and is fine with either GOST certificates and GOST encryption, or with AES-GCM and ECDSA, but not a mix?  If we accept that such policies should be enforced by servers, I think the problem goes away.

Yoav