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

[Aaron Zauner <[e-mail]>]

Hi Dave,

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.

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

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

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.

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

:)

Aaron