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 ([email protected]) 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 <[email protected]> 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
[email protected]
https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
