Re: [TLS] MTI policy & practice (Was: Re: Comments on various things on agenda)

[Dave Garrett <[e-mail]>]

On Monday, March 09, 2015 05:12:12 pm Aaron Zauner wrote:
> I get why some implementers (e.g. embedded people) would only want to
> have to implement one ciphersuite. My concern is also for deployment. I
> do believe (possibly naively) that most implementers will know what
> their users need. But then again -- maybe I'm just confused by the term
> (which should be defined in more detail, in case) -- but doesn't
> mandatory to deploy also mandate that implementations do support the
> specified ciphersuites in practice?

It's the difference between an implementation supporting the cipher and the deployment enabling the cipher. A connection proposing a cipher list without the MTI is still considered valid. One proposing without an MTD is essentially a protocol error.

We have three decision sets in TLS:

1) IETF TLS WG RFC -> The Specification
2) Software implementing #1 -> The Implementation
3) Administrators configuring #2 on their servers -> The Deployment

Unless it gets through all three, it doesn't actually end up on the Internet. The notion of MTI only covers us to #2. The notion of MTD gets to #3. Essentially, it's #1 telling #2 that they may not even provide an option to #3 to override the MTD decision by #1 (short of rewriting #2).

The HTTP/2 spec process also had discussions about being specific when referring to implementations vs. deployments, or being more general.

> I don't think that just because something has been 'convention' for some
> time it's always the best option (see postel's law).

Very much so.

> Again; are there serious concerns why there should not be more than one
> MTI ciphersuite in the TLS 1.3 spec.?

What I'm proposing is essentially two MTI, with one that implementations are not allowed to disable. If you want to be really strict, endpoints could reject connections that do not propose the MTD, regardless of what's negotiated (but that has risks if the MTD needs revoking).

> > MTI: ECDHE AES-GCM (possibly both ECDSA and RSA auth)
> 
> That would be again more than one ciphersuite. So why not have more than
> one but with different AEAD constructions?

Not a bad idea. However, the more that is proposed, the higher risk of some implementation deciding to ignore something. (though, this assumption may not be true anymore)

> BTW: I'm not convinced ECDSA is the best path to take [0]. AFAIK from
> deployments most commercial CAs do not issue ECDSA certificates either,
> unless that has changed significantly over the last year or so.

If it's not used enough, then yeah, RSA only there. I only suggest it as an option.

> I don't believe it'd be a good idea for TLS-WG to specify a curve
> before there is consensus within CFRG.

I think finalizing the TLS 1.3 spec prior to finalized CFRG specifications would be a bad idea. Hopefully they're almost done arguing.


Dave