On April 14, 2016 at 22:38:23 , Jim Fenton
(fen...@bluepopcorn.net(mailto:fen...@bluepopcorn.net)) 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
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
