Re: Ciphersuites (was Re: Mandatory to implement cipher suites)

On Thu, Jul 17, 2014 at 1:07 PM, Martin Thomson
<martin.thomson@gmail.com> wrote:
> On 17 July 2014 11:40, Yoav Nir <ynir.ietf@gmail.com> wrote:
>> I fail to see why we need both a DHE and ECDHE ciphersuite. I prefer that we have only the ECDHE.
>>
>> DHE depends on the server sending down secure parameters, which the client has no way to verify. It’s also slower. If we’re not including AES-CBC+HMAC-SHA1 we might as well drop DHE as well.
>>
>> Having said that, I would have preferred to not have this requirement at all, and leave it to a TLS standard to have mandatory-to-implement ciphersuites. There is nothing special about HTTP(S) that makes some ciphersuite appropriate here while being less appropriate for SMTP. But if we’ve made up our minds to specify an MTI ciphersuite, I suggest we specify only one, and make that TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.
>
> I'm afraid we can't really do that without a risk of interoperability
> failure.  TLS mandates something that we prohibit the use of.

Martin, I'm not sure what you are referring to with the pronouns in
those two sentences. What can't we really do without the risk of
interoperability failure? What is TLS mandating that we prohibit the
use of?

> I'm amenable to your suggestion of just ECDHE.  One being better than
> two when it comes to MTI.  I'll note that this is probably something
> we should continue in the TLS WG; as we've done so far.

I agree with Yoav that it is better for the HTTP specification to
*NOT* specify a mandatory-to-implement cipher suite. The other
TLS-related recommendations that the HTTP specification makes all seem
good and likely to stand the test of time. However, the current set of
cipher suites that are currently considered reasonable are still
problematic for various reasons. For example, nobody has demonstrated
an AES-GCM implementation that is both correct (free from side-channel
attacks) and efficient on common ARM processors. That should
automatically disqualify AES-GCM cipher suites from being made
mandatory. So far, we have not yet standardized cipher suites that are
both efficient and able to be implemented correctly everywhere, but
that might happen soon with the ChaCha20+Poly1305 or similar cipher
suites. Even if/when such cipher suites are standardized, I think
there would be too many objections to making them mandatory to
implement for HTTP right away. Conversely, I don't think the lack of a
specified mandatory-to-implement cipher suite hurts HTTP in a
practical way whatsoever. HTTP/1 did not have it and we figured out a
way to make things work regardless.

Besides my general objection, I object specifically to making any
TLS_DHE_* cipher suite mandatory to implement, for similar reasons to
Yoav. There are *draft* proposals being written to solve the serious
safety and interoperability issues with TLS_DHE_* cipher suites, but
they haven't been standardized, deployed, or tested yet. Also, I am
concerned that encouraging or mandating any TLS_DHE_* cipher suites
may cause complications for the 1-RTT and/or 0-RTT handshakes in TLS
1.3. In particular, I am concerned that it may be too inefficient to
presumptuously generate ephemeral DHE keypairs for use in the
ClientHello, especially in addition to one or more ECDHE keys that
will have to be presumptuously generated too. I understand that there
are some procedural issues to overcome regarding the use/requirement
of ECDHE in IETF protocols, but I don't think those procedural
concerns outweigh the practical benefits that ECDHE has over DHE.

Also, I'm surprised people from Mozilla are recommending that
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 considering that no Mozilla
products support that cipher suite and considering that Mozilla made a
conscious decision to specifically NOT support that cipher suite.

Cheers,
Brian

Received on Saturday, 19 July 2014 19:33:34 UTC