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

Ah, in that case, I totally misunderstood. Sorry about that.

I don't have a big problem with saying that *if* you support both you
should do DANE first. But I must admit, I still don't really understand the
value in specifying this explicitly: recipients still have to assume a
misconfiguration in either policy may result in dropped mail, so this isn't
a great mitigation for misconfigurations or deliberate DoS. My view (in
previous discussions of the same question) was that we would simply not
specify this--which infrastructure to trust seems like it's something that
the sender determines on their own; it's (obviously) impossible for the
recipient to dictate this ("Let me give you my CA-signed proof that I want
you to always trust CAs."), so a sender can reasonably say that they would
prefer DNSSEC to WebPKI or vice versa (or fail if either fails). But this
isn't a big point to me, so I'm flexible about it.

On Wed, Apr 13, 2016 at 10:40 AM, Neil Cook <neil.cook@noware.co.uk> wrote:

>
> On 13 Apr 2016, at 08:48, Daniel Margolis <dmargolis@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?

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).

>
> 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-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
>>
>
> _______________________________________________
> Uta mailing list
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta
>
>
>