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

[Aaron Zauner <[e-mail]>]

Hi Dave, et al.,

Dave Garrett wrote:
> Honestly, I don't believe the existing policy is unreasonable. If implementers could actually be compelled to implement both, great, but RFCs can get ignored and in practice you could end up with only one... and no interop.

I don't see why having only one MTI ciphersuites would change that
outcome? If the RFC gets ignored anything could happen. A TLS
implementation that is unable to speak to other implementations is
pretty useless; that would probably also be the observation by the
implementers.

> A bigger problem is that just specifying MTI isn't enough in practice. It would be better to have an MTI and a separate MTD (MTI + mandatory to deploy). For example, with RC4 being phased out I've actually got a report from someone who has a host that uses TLS 1.2 but with their MTI suite (AES-CBC) disabled, and only RC4 and Camellia supported. This shouldn't be a thing we have to worry about. If we picked an MTD and an MTI, that would be far more reliable. Both would of course be subject to revision in a future RFC, and it should probably state that up front. (instead of pretending that everything will be fine forever)
> 

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?

I don't think that just because something has been 'convention' for some
time it's always the best option (see postel's law). It might make sense
to reevaluate as others have also stated in this thread.

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

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

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.

> 
> Also specifying MTI curves is probably a good idea at this point.
> 

AFAICT it'll take CFRG some more time until a recommendation can be
made. I don't believe it'd be a good idea for TLS-WG to specify a curve
before there is consensus within CFRG.

Thanks,
Aaron

[0] djb explains this in more detail over here:
    http://blog.cr.yp.to/20140323-ecdsa.html