> On 13 Apr 2016, at 10:04, Daniel Margolis <dmargo...@google.com > <mailto:dmargo...@google.com>> wrote: > > On Wed, Apr 13, 2016 at 10:40 AM, Neil Cook <neil.c...@noware.co.uk > <mailto:neil.c...@noware.co.uk>> wrote: > >> On 13 Apr 2016, at 08:48, Daniel Margolis <dmargo...@google.com >> <mailto: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. > > Yes, but if you have a self-signed cert, you aren't going to have an STS > policy, so that's a different scenario than what we're discussing, no? >
Well, both need to work independently as you say below. But I might still have an STS policy (using a different, CA-signed cert) where I have a self-signed cert for DANE, because I want to support clients who only support one or the other. Forcing clients to validate both doesn’t seem to be a good idea. > This is distinct from the first analogy that crossed my mind, which is Web > browsers who support DANE: in the web browser case, WebPKI is essentially the > default, so for DANE to work (with self-signed certs) we need to be clear > that DANE trumps WebPKI. But in the SMTP case the default is nothing, so if > someone explicitly requests STS or DANE, both policies must work > independently (or else they're going to be missing mail from senders who > validate only one or the other). Yes, but I might prefer that senders use one rather than the other. DANE is more flexible in terms of allowing things like self-signed certs, so from my point of view, if I’m running a mail server I want clients to use DANE if they support both. I don’t want the client to make that decision. Neil > > >> 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 <mailto:Uta@ietf.org> >> https://www.ietf.org/mailman/listinfo/uta >> <https://www.ietf.org/mailman/listinfo/uta> > > > _______________________________________________ > Uta mailing list > Uta@ietf.org <mailto: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
