Re: [Uta] "webby" STS and DANE/DNSSEC co-existence

[Chris Newman <[e-mail]>]

 On April 14, 2016 at 22:38:23 , Jim Fenton ([e-mail](mailto:[e-mail])) wrote:
> On 4/13/16 10:43 AM, Chris Newman wrote:
> > DANE is merely one method of validating a certificate, there can also be SMTP policy orthogonal to DANE. Take for example, DEEP’s “tls11” and “tls12” directives. Those specify a minimum acceptable version of TLS for future connections. Although we haven’t debated yet whether to include those in SMTP relay policy, I think it would make sense to include those directives, particularly given the problems we’ve seen with old versions of TLS causing real security problems. And there may be future policy directives we want that are even more compelling. So the question is where to put SMTP relay security policy that is orthogonal to DANE. Seems like wherever we choose to put the policy for SMTP relay STS (whether in a DNSSEC-protected DNS record, HTTPS well-known or SMTP+STARTTLS), that’s where we should always look for SMTP relay policy.  
> >  
> When you're deciding whether to publish an encryption policy, it's important to consider whether there's a downgrade attack. Fundamentally, we're trying to deal with a situation where an intermediary can interfere with the negotiation of encryption, or whether an impostor server can claim not to support encryption in an effort to avoid a requirement to authenticate itself as would happen when TLS is negotiated.
>  
> I don't know the details of what TLS 1.2 fixes in TLS 1.1, but I would only include tls11 and tls12 directives if there is a downgrade attack where the attacker can claim to only support TLS 1.1 and not 1.2 and benefit from that. Unless there is something about certification verification that can be exploited, the impostor server attack isn't possible because the impostor would have to authenticate to negotiate TLS 1.1 as well. Similar situation for the intermediary/MITM.
>  
> Is there actually something in TLS 1.1 that can be exploited by these sorts of attackers? If not, I wouldn't include those directives.

In SSL 3.0 and TLS 1.0 there are things attackers can exploit and those protocols are still in the wild and still required by many old MUAs that are still widely used. TLS 1.1 it’s less clear at the moment that it’s exploitable, but that’s likely to change.

While the TLS “live at the moment” version negotiation is not vulnerable to MITM, I view policy as setting the baseline for future security rather than stopping immediate MITMs. We can also do a threat analysis. The most common attacks outside passive eavesdropping and DNS are breaking into servers. Breaking into servers tends to get noticed if there’s an outbound stream of data or things stop working. But what if I break into a server and change it to prefer SSL 3.0 and TLS 1.0 over later versions during the negotiations? Now I can do external attacks on that domain that may not be detectable by the domain’s intrusion detection system. Meanwhile end-users are assured they’re secure by the “lock”.

So while Viktor made a compelling case that the TLS version directive is not appropriate for SMTP relay, I think it is appropriate for the MUA STS scenario where it’s simpler to implement, where very old MUAs are in wide use requiring permissive servers, and I’d really like to be sure my client is using the stronger versions of TLS as long as I don’t have to manually configure it.

Does this make sense?

Another reason I like the TLS version directive is I can give example code of how to implement it which helps explain the concepts. The other directives are too complicated for that.

		- Chris