> On 11 Apr 2016, at 22:38, Mark Risher <ris...@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 | ris...@google.com > <mailto:ris...@google.com> | 650-253-3123 <> > On Mon, Apr 11, 2016 at 6:21 PM, Viktor Dukhovni <ietf-d...@dukhovni.org > <mailto:ietf-d...@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
_______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
