> On 13 Apr 2016, at 08:48, Daniel Margolis <dmargo...@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? >
Checking both is not a good idea. DANE support scenarios like self-signed certs, which STS does not. > 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. > We’re only talking about what precedence to use for senders who support both, not saying that recipients must support both. If sender who supports both DANE/DNSSEC and STS encounters a TLSA record it MUST honour that, and not use STS. If a sender supporting both only sees one or the other, then it’s fine. Senders which only support one or the other are also fine. Neil > On Wed, Apr 13, 2016 at 3:43 AM, Viktor Dukhovni <ietf-d...@dukhovni.org > <mailto:ietf-d...@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 <mailto:Uta@ietf.org> > https://www.ietf.org/mailman/listinfo/uta > <https://www.ietf.org/mailman/listinfo/uta> > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
