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

> On 11 Apr 2016, at 22:38, Mark Risher <risher@google.com> wrote:
> 
> 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?
> 

I’d rather see it specified in the STS specification (as a MUST), because there’s otherwise there’s a chance some implementors won’t read a separate meta BCP.

Neil

>  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 |	 risher@google.com <mailto:risher@google.com> |	 650-253-3123 <>
> On Mon, Apr 11, 2016 at 6:21 PM, Viktor Dukhovni <ietf-dane@dukhovni.org <mailto:ietf-dane@dukhovni.org>> 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
> 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