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

[Mark Risher <[e-mail]>]

Hi, everyone:
Hope you all made it home safely.

I think we can do that by requiring that outbound MTAs
> that implement the "webby" approach MUST/SHOULD first test
> for, and process, TLSA records for the next MX in the path.
> In  other words the "webby" approach is tried 2nd.


I agree that's the right order of operations for sending MTAs that *can* do
both, and I agree we don't want one approach to preclude the other. So it
actually sounds like MUST to me, in that if a sender does not have the
plumbing in place (yet) to validate TLSA records, then the SHOULD still
won't have any effect (you'd basically be saying that you SHOULD implement
DANE/DNSSEC, which I think we all agree with). Would that clarification be
better in the STS specification (because it will be published later), or in
a meta BCP that explains operational guidelines for people who can support
both?

>
>  The risk is that the sender won't find the policy at all if the web
> address lookup fails. But can we agree that the long MTU approach
> described in the current draft isn't an effective mitigation to that
> problem? Several people pointed out in the meeting that caches don't
> typically hold things for very long times; the MTU specifies how long
> records MAY be cached, not how long they SHOULD be cached.


Yes, we have a known issue that, if you can never successfully retrieve a
policy, then you can never do better than status quo. The value of the long
MTU only kicks in once you've bootstrapped. The bootstrapping problem
against a persistent adversary could potentially be addressed with
preloading, e.g. the way that certain web browsers ship with pinned
certificates already in place.

Side update for the mailing list/working group: Based on feedback from the
in-person meeting, the authors are working on separating reporting and
clearing up the DNSSEC/policy issues as discussed, and hope to have a new
draft shortly. Thank you for all of your feedback and comments, both on
email and at the meeting.

Take care,
/m






--
Mark E. Risher |  Group Product Manager |  [e-mail] |  650-253-3123

On Mon, Apr 11, 2016 at 6:21 PM, Viktor Dukhovni <[e-mail]>
wrote:

> On Mon, Apr 11, 2016 at 09:45:06PM +0100, Stephen Farrell wrote:
>
> > With no hats, I'd like to argue that the WG should pursue
> > the "webby" STS proposal, but should also ensure that we
> > do not damage progress made by those who are deploying the
> > DANE/DNSSEC approach to securing MTA-MTA connections.
> >
> > I think we can do that by requiring that outbound MTAs
> > that implement the "webby" approach MUST/SHOULD first test
> > for, and process, TLSA records for the next MX in the path.
> > In  other words the "webby" approach is tried 2nd.
>
> [ By the way both DANE and STS are still opportunistic security as
>   defined in RFC 7435, the difference is that these are not just
>   unauthenticated encryption. DANE and STS are used on the fly
>   with peers that publish the relevant policy via some downgrade-
>   resistant mechanism. ]
>
> In Postfix, if and when we do implement client-side "webby" STS,
> I expect that STS wil be trumped by any DANE policy on MTAs that
> support both (when sending email to destinations that support both).
> One key reason is that DANE downgrade-resistance is stronger (works
> on first contact) and DANE is exposed to fewer trusted CAs.
>
> --
>         Viktor.
>
> _______________________________________________
> Uta mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta
>