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

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
>