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. -Jim
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
