Re: [Uta] Updated drafts for MTA-STS & TLSRPT

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 <dmargolis@google.com>
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 <ietf-dane@dukhovni.org>
> wrote:
>
>>
>> > On Feb 23, 2017, at 4:04 PM, Daniel Margolis <dmargolis@google.com>
>> 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
>> Uta@ietf.org
>> https://www.ietf.org/mailman/listinfo/uta
>>
>
>
> _______________________________________________
> Uta mailing list
> Uta@ietf.org
> https://www.ietf.org/mailman/listinfo/uta
>
>