Re: [TLS] Ala Carte Cipher suites

Yes. My expectation here is that "good" constructs are composable. "Composable with caveats" are not good, and shouldn't be included in a-la carte selection. 

--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street, Lexington, MA 02420-9185       

Web:  http://www.ll.mit.edu/CST/
MIT LL Root CA:  <https://www.ll.mit.edu/labcertificateauthority.html>

----- Original Message -----
From: Yoav Nir [mailto:ynir.ietf@gmail.com]
Sent: Monday, April 13, 2015 05:57 PM
To: Geoffrey Keating <geoffk@geoffk.org>
Cc: <tls@ietf.org> <tls@ietf.org>
Subject: Re: [TLS] Ala Carte Cipher suites - was: DSA should die

> On Apr 14, 2015, at 12:09 AM, Geoffrey Keating <geoffk@geoffk.org> wrote:
> 
> Martin Thomson <martin.thomson@gmail.com> writes:
> 
>> On 3 April 2015 at 17:05, Brian Smith <brian@briansmith.org> wrote:
>>> I don't think the current mechanism is problematic
>>> enough (at all, really) to justify that effort.
>> 
>> I think that I've the same view.
>> 
>> Then you have to consider interaction problems where some
>> implementations have hardware for certain things, and software for
>> others.  Not only does that produce strong preferences for some things
>> over others, it also can lead to holes in support tables, making a la
>> carte selection tricky.
>> 
>> That was always the clincher for me.
> 
> I agree.  In particular I don't think we've simplified anything if
> implementations have to have a list of invalid combinations, or have
> to know that certain ciphers are to be used only with matching key
> exchange algorithms (for example, use the GOST key exchange with the
> GOST symmetric cipher).

Why?  There’s nothing invalid about using Curve25519 key exchange with an RSA certificate and GOST symmetric ciphers, so TLS should not provide this. Requiring all three things to be GOST is a policy decision that can and should be part of server (and perhaps client) configuration.

If some standard in Russia demands that GOST algorithms be used for all three, that should be configurable on the server. If OTOH the Russian authorities decide that they are fine with ECDHE for key exchange, but demand the GOST symmetric ciphers and authentication, that is also easy to get working with a la carte, but now it’s impossible until someone specifies such ciphersuites in a new document.

Unless some combination creates an insecurity when each of its components is secure when combined with other components, I don’t think we have an issue. 

Yoav
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls