On Thu, Apr 14, 2016 at 10:38 PM, Jim Fenton <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. > Jim, TLS contains its own anti-downgrade measures. What's the reasoning for adding ones here? -Ekr > > > -Jim > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta > >
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
