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

[Neil Cook <[e-mail]>]

> On 13 Apr 2016, at 10:04, Daniel Margolis <[e-mail] <mailto:[e-mail]>> wrote:
> 
> On Wed, Apr 13, 2016 at 10:40 AM, Neil Cook <[e-mail] <mailto:[e-mail]>> wrote:
> 
>> On 13 Apr 2016, at 08:48, Daniel Margolis <[e-mail] <mailto:[e-mail]>> 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 <[e-mail] <mailto:[e-mail]>> 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
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/uta <https://www.ietf.org/mailman/listinfo/uta>
>> 
>> _______________________________________________
>> Uta mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/uta <https://www.ietf.org/mailman/listinfo/uta>
> 
> 
> _______________________________________________
> Uta mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/uta