I think I agree with where you've got to, but I do want to clarify that I think it's important that a shorter refresh period doesn't shorten the policy expiry - we want a 6 month policy to be cached and relied on for 6 months, even if, for most of that 6 months an attacker is blocking a more frequent DNS policy check.
On Fri, Feb 24, 2017 at 3:44 PM, Daniel Margolis <[email protected]> wrote: > Yes, I think we agree here. But presently the RFC doesn't really recommend > frequent updating of the policy, AFAIR, though of course doing so is indeed > cheap and a good idea. So we should recommend it! > > On Thu, Feb 23, 2017 at 10:21 PM, Viktor Dukhovni <[email protected]> > wrote: > >> >> > On Feb 23, 2017, at 4:04 PM, Daniel Margolis <[email protected]> >> wrote: >> > >> >> This applies whether or not the change is to the list of acceptable >> "mx" >> >> hosts, or to some other property. >> > >> > Yes, but my point was that we don't (to my recollection) actually >> require >> > senders to check for new policies on every mail send--they can >> legitimately >> > keep using an old, cached policy as long as it works. >> >> Poorly crafted implementations will err in many interesting ways, but with >> luck their users will clamour for fixes or switch to less broken systems. >> >> The DNS lookup is cheap and should happen frequently, and doing so on each >> SMTP connection should be recommended in the draft. >> >> > As you say below, there are many optional strategies for senders to >> refresh >> > policies in a reasonable way, so I am not of the opinion this is a >> fatal flaw. >> > On whether it would be better to say senders SHOULD take one of these >> policies, >> > though, I am open to feedback. >> >> I think recommending well thought-out approaches to these issues is >> useful: >> >> 1. It makes implementors think about the issues. >> 2. It gives them usable solutions that they can adopt or improve on. >> >> Nothing this proposed RFC can say will force compliance, the SMTP server >> is a passive actor in this space, and has no idea whether the client is >> using STS at all, let alone correctly. >> >> -- >> Viktor. >> >> _______________________________________________ >> Uta mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/uta >> > > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta > >
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
