Re: [TLS] Issue 56: AES as MTI

On Fri, Sep 14, 2007 at 06:33:01PM -0700, Nelson B Bolyard wrote:
> 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?

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.

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

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.

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

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

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

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?

> Why do we need to impose interoperability requirements that the markets
> 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
-- 

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