Re: [TLS] Issue 56: AES as MTI

[Nelson B Bolyard <nelson at bolyard.com>]

Chris Newman wrote:
> As far as I can tell, the real-world MTI for SSL/TLS as deployed is
> RC4.  I dislike it when the real world MTI and the specified MTI differ
> and the specification fails to explain the difference.

I think the RFC does not need a Mandatory Cipher Suite.  There are
different marketplaces for TLS, and each one will define its own mandatory
cipher suite.  I see no need to say that all implementations must do one.
Each implementation is intended to operate in one or more marketplaces,
and market forces will ensure that all implementations in each market will
implement the cipher suite that is the de facto standard mandatory one.

TLS 1.0 defined TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA and the eCommerce
marketplace utterly ignored that.  Several implementations STILL do not
implement that cipher suite to this day, yet that has not resulted in a
lack of interoperability.  Interoperability for eCommerce has employed
the RSA+RC4 cipher suites, as Chris noted.

> It's my belief that AES-CBC is more likely to result in future alignment
> of the real-world MTI and the specified MTI than 3DES and thus I support
> a change from 3DES to AES as MTI.   I would also support a change from
> 3DES to RC4 as MTI despite some concerns about the cryptographic
> longevity of that cipher.

Going forward, it's clear that in some markets, AES will be mandated to
the exclusion of all else, but in others RC4 will still dominate.

I suggest that the RFC should call for the development of profiles of TLS,
selected subsets of cipher suites, hello extensions, and perhaps EC curves
that will form the basis for interoperability for implementations within
the marketplace of each profile.

/Nelson

_______________________________________________
TLS mailing list
TLS at lists.ietf.org
https://www1.ietf.org/mailman/listinfo/tls