Ciphersuites (was Re: Mandatory to implement cipher suites)

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. Its also slower. If were 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 weve 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.

On Jul 17, 2014, at 3:01 AM, Martin Thomson <> wrote:

> In consultation with ekr, I've put together a proposal for addressing
> #498, listing mandatory to implement cipher suites.
> The text is short:
> + Implementations MUST support TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
> + <xref target="TLS12"/> and TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
> + <xref target="TLS-ECDHE"/> with P256 <xref target="FIPS186"/>.
> --
> The reason I'm posting is to confirm that adding what is called a
> "downref" is OK with this group.
> A "downref" is a normative reference to a non-standard document, in
> this case, an RFC that is in the Informational category [RFC5289].
> This is allowed in the IETF process, but it requires that the choice
> be made quite explicit.  Read RFC 3967 if you want all the gory
> details.
> Note that the TLS working group is currently debating whether or not
> to put the relevant ECC RFCs on the standards track, which could make
> this question moot.
> If you want to debate the merits of the particular choices, I'd
> request that you start another thread for that purpose.  I only want
> to track the procedural issue here.

Received on Thursday, 17 July 2014 18:40:43 UTC