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

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.

		- Chris
On April 12, 2016 at 17:48:25 , Daniel Margolis (dmargolis@google.com) wrote:

What's the complexity you're worried about? Is it mainly that there's another switch to flip incorrectly (i.e. inadvertent misconfiguration, at a greater risk due to the presence of more configurations) or the risk of malicious DoS? 

I think Stephen laid out the trade-offs fairly well. I can see the argument for telling recipients that if they already publish a DANE record they're probably fine and shouldn't really need an STS policy as well. But a "must" seems less helpful to me here; senders who have some external limitation that prevents them from implementing DNSSEC then must not implement STS? I'd be worried that some larger deployments might have trouble with that. 

On Wed, Apr 13, 2016 at 3:43 AM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
On Tue, Apr 12, 2016 at 06:52:31PM +0200, Daniel Margolis wrote:

> I'm not sure if I'm being stupid here, but what does it mean for STS to be
> "trumped" by DANE (or the reverse)? Do you mean that if the recipient
> domain/MX has both STS and DANE you will *only* validate the DANE policy?

Correct.  Trying to enforce both is too complex, and needlessly
increases the risk of delivery problems.

> If we instead said that senders who validate STS must honor STS and senders
> who validate DANE must honor DANE, is there a conflict?

That language is either tautological, or unreasonable, if intended
to imply that systems capable of both must be willing to apply both
concurrently.

> I would presume that if there is either a DANE failure or an STS failure
> senders who validate both will treat it as a failure. Introducing a concept
> of priority strikes me as unnecessary. What am I missing?

I have no plans to support concurrent evaluation of potentially
conflicting policies.  DANE is more robust than STS, given a DANE
policy I see no reason to also consider STS policy.

Of course an administrator will be able to choose which policy
applies to a given nexthop, but not enforcement of both.

--
        Viktor.

_______________________________________________
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  