On 4/15/16 5:28 AM, Eric Rescorla wrote: > > On Thu, Apr 14, 2016 at 10:38 PM, 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. > > > Jim, > > TLS contains its own anti-downgrade measures. What's the reasoning for > adding ones here? > > -Ekr > That's exactly my point: I wouldn't include these directives.
-Jim
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
