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

[Jim Fenton <[e-mail]>]

On 4/15/16 5:28 AM, Eric Rescorla wrote:
>
> On Thu, Apr 14, 2016 at 10:38 PM, 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.
>
>
> 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