Re: [TLS] Issue 56: AES as MTI

[Chris Newman <Chris.Newman at Sun.COM>]

Nelson B Bolyard wrote on 9/14/07 14:10 -0700:

> 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.

This was a mistake the IETF made in TLS 1.0 due to patent issues.  The RSA 
patent had not expired when TLS 1.0 was published so there was a desire for an 
interoperable patent-free mechanism.  The fact the marketplace cared a lot more 
about performance than patents/licensing is telling and should inform future 
IETF behavior when such situations arise.  Regardless I would like to see that 
mistake corrected honestly in the specification.

> > 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.

If that's the case, I would like the document to say something to that effect. 
Being silent about the dominance of RC4 makes the specification negligent about 
real world interoperability.

> 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.

I think the base TLS spec needs one or more mandatory to implement cipher 
suites that will be present in generic TLS stacks and will interoperate in 
emerging/experimental marketplaces that don't have a specific profile. 
Frankly, I don't trust spec writers to remember to always set a MITM 
appropriate for the protocol that uses TLS so I want to see an interoperable 
fallback in the base specifications.  However, I have no problem with 
marketplace-specific profiles replacing the mandatory-to-implement requirements 
with different ones and to the extent this better reflects reality, I'd like to 
see more of it in the IETF.

For example, RFC 3501 section 11.1 adjusts the MITM requirements for TLS when 
used with IMAP.  Our rules would seem to permit that.

               - Chris


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