Subject: [TLS] Issue 56: AES as MTI

From: Eric Rescorla <[email-masked]>
Date: Wed, 12 Sep 2007 16:11:50 -0700

Pasi suggests making AES the mandatory to implement encryption
algorithm in TLS 1.2. Thoughts?

-Ekr

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 12 Sep 2007 16:26:33 -0700

At Wed, 12 Sep 2007 19:27:17 -0400,
Yee, Peter wrote:
> 
> Just AES in general or a specific key size and mode?  I'd generally
> favor the move, although I recognize that AES will probably be slower
> than RC4 so there will be those who would resist the move.  Despite
> that, I'd be in favor of AES-GCM as MTI as it's a whole lot better
> than 3DES_EDE_CBC.

The current algorithm is 3DES_EDE_CBC. I would imagine we would use
AES_128_CBC. It's a much easier substitution than GCM and most
TLS stacks already support AES-CBC.

-Ekr

---

From: "Joseph Salowey \(jsalowey\)" <[email-masked]>
Date: Wed, 12 Sep 2007 16:43:57 -0700

I'm in favor of having AES as the MTI.  I'd have to think a bit more
about whether CBC or GCM is appropriate, but either should be fine.
Initially, I was thinking AES-CBC, because of the reason Eric mentioned.

Joe

> -----Original Message-----
> From: Eric Rescorla [mailto:[email-masked]] 
> Sent: Wednesday, September 12, 2007 4:27 PM
> To: Yee, Peter
> Cc: [email-masked]
> Subject: Re: [TLS] Issue 56: AES as MTI
> 
> The current algorithm is 3DES_EDE_CBC. I would imagine we 
> would use AES_128_CBC. It's a much easier substitution than 
> GCM and most TLS stacks already support AES-CBC.
> 
> -Ekr
>

---

From: Mike <[email-masked]>
Date: Wed, 12 Sep 2007 17:26:28 -0700

> TLS stacks already support AES-CBC.

I support AES-CBC in my implementation, but don't yet support GCM,
just as one more data point for your decision.

However, is 128-bit AES as strong as 192-bit 3DES?

Mike

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 13 Sep 2007 10:35:55 +0200

> just as one more data point for your decision.

The situation is the same for GnuTLS, FWIW.

> However, is 128-bit AES as strong as 192-bit 3DES?

The effective key size for 3DES is only 112 bits, see also:
http://en.wikipedia.org/wiki/Triple_DES

/Simon

---

From: Russ Housley <[email-masked]>
Date: Thu, 13 Sep 2007 10:31:23 -0400

I support this suggestion.  S/MIME just made the transition from 3DES 
to AES as the mandatory to implement encryption algorithm.  (3DES is 
still a SHOULD in S/MIME.)

I think the mandatory to implement mode should remain CBC.  This will 
be less of an interoperability concern.  Earlier versions of TLS 
offered support for AES-CBC, but the authenticated encryption modes 
like AES-GCM will not be available until TLS 1.2 is complete.  So, 
AES-CBC has a much better backward compatibility situation.

Russ

---

From: Chris Newman <[email-masked]>
Date: Fri, 14 Sep 2007 12:45:51 -0700

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.

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.

                - Chris

---

From: Nelson B Bolyard <[email-masked]>
Date: Fri, 14 Sep 2007 14:10:58 -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.

> 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

---

From: Mike <[email-masked]>
Date: Fri, 14 Sep 2007 14:17:20 -0700

> RC4.

Yes, I've noticed this in my testing.  Many servers will pick RC4_MD5
even though it is last in my cipher list.  Examples are apple.com,
ibm.com, amazon.com, verisign.com.  When confronted with only AES
ciphers, most will negotiate it, but, for example, Verisign won't
(they do support 3DES though).

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 14 Sep 2007 14:43:57 -0700

At Fri, 14 Sep 2007 14:10:58 -0700,
Nelson B Bolyard wrote:
> I think the RFC does not need a Mandatory Cipher Suite.

I don't believe that that's on the table. As I understand IESG
policy, it's that there must be a Mandatory To Implement cipher
suite. Tim? Sam?

-Ekr

---

From: Russ Housley <[email-masked]>
Date: Fri, 14 Sep 2007 19:34:33 -0400

This has always been the case.  It ensures that there is a 
ciphersuite that can be negotiated between all implementations 
(unless it is explicitly turned off by policy controls).

Russ

---

From: Chris Newman <[email-masked]>
Date: Fri, 14 Sep 2007 17:32:26 -0700

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

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

> 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

---

From: Nelson B Bolyard <[email-masked]>
Date: Fri, 14 Sep 2007 18:33:01 -0700

Russ Housley wrote:
> This has always been the case.  It ensures that there is a ciphersuite
> that can be negotiated between all implementations (unless it is
> explicitly turned off by policy controls).

And this is important why?

It is important that all implementations that must work in (say) US DOD
government installations (where AES is mandated exclusively) must all
use AES so that they can interoperate.  That market requires that they
interoperate.

It is important that in the field of eCommerce, where everyone uses RC4,
that implementations use RC4 so that they can interoperate for eCommerce.

An implementation that does RC4 and not AES will work fine in eCommerce
and not in the DOD.  An implementation that does AES only and not RC4
will not work with quite a few eCommerce servers out there.  So what?

Why do we need to impose interoperability requirements that the markets
themselves do not demand?

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 14 Sep 2007 21:07:35 -0500

> And this is important why?

I think we could certainly have a base protocol w/o MTIs and then
various profiles which specify MTIs.  If we had to, and if there were
truly distinct non-big-i internets using different subsets of TLS.

But as it is I just don't see why we couldn't have some MTIs period.

> use AES so that they can interoperate.  That market requires that they

The big-i Internet requires interop.  It's a very heterogeneous
environment, and there aren't any heads of IT for it.

And DOD wants AES not for interop but for security.  They want interop
too, of course.

> that implementations use RC4 so that they can interoperate for eCommerce.

Not that they use RC4 -- that they support RC4.

> will not work with quite a few eCommerce servers out there.  So what?

Who wants to write code that can only be sold to one part of the market
instead of to all of it?

Look, RC4 is aging fast.  We need to move on from RC4.  Everyone has an
AES implementation nowadays.  AES is what the market is moving to, and
it's what the U.S. govt demands.  What's the problem with making AES an
MTI?

> themselves do not demand?

What if the banks get serious about security (or the regulators force
them to) only then find that all the stupid browsers are stuck with RC4
because the spec said they didn't have to implement AES?  That wouldn't
be very good.

We have to be ahead of the market to some degree because it takes years
to upgrade software on the big-i Internet.  There's nothing
controversial about AES being a required to implement cipher in any
modern Internet security protocol.  IPsec, TLS, SSHv2, Kerberos V,
etcetera, all have or soon will have AES as a required to implement
cipher.

AES as a required to implement cipher is almost not negotiable at this
stage.  Certainly I would object to TLS 1.2 not requiring support for
AES.

Nico
--