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

[Dave Garrett <[e-mail]>]

On Monday, March 09, 2015 05:52:21 pm Aaron Zauner wrote:
> Dave Garrett wrote:
> > 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
> 
> Thanks for clearing this up. This should be explained in case it ends up
> in the I-D.

Sorry for not being clear enough. The way I worded it initially was interpretable in multiple ways. (which I guess is apt for this discussion ;)

> > 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).
> 
> I'm fine with that.

The risks could be mitigated with some limit on when to bail entirely, though I don't know that could be specified in a way that won't cause interop problems. If we're confident that humans have finally figured out how to write cryptography in a way that won't have catastrophic failures anymore (stop laughing), then we'd just expect some minor interop breakage until implementations are updated after a deprecation/prohibition RFC for an MTD.

In my opinion, everyone is too afraid of breakage. We should just agree on how to break in unison in a way that maintains the best possible result.

> I think the crypto community is pretty confident in AES. That being
> said, different AEAD constructions would make sense in case there is new
> research suggesting security issues with one of both. Be it MTI or MTD.

Setting CBC aside, I agree. We're pretty much down to just AES-GCM being fully trusted, and that really needs to be fixed with more variants as well as new ciphers and new versions of old ciphers, like Camellia and GOST. Single points of failure are not a good thing.

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

For those that haven't checked the CFRG recently, they've agreed on Curve25519 & Ed448. How long it will take to agree on how to specify this is anyone's guess.


Dave