Re: [Uta] Ben Campbell's Yes on draft-ietf-uta-mta-sts-17: (with COMMENT)

[Daniel Margolis <[e-mail]>]

No, it's just a rushed edit on my part. My intent was t say that you should
check the cached version against the version in HTTPS.

One *could* argue (as you speculated) that as long as the TXT is there, one
can bump the max-age parameter in the cache and not bother to do the HTTPS
fetch (since it should be a foregone conclusion). I don't see a problem
with that, really.

(In the problematic example you give, a sender can still only cache the old
version for as long as the TXT is unchanged, which is allowed in the
specification!)

In short, I think your interpretation (which was not my intent) works
perfectly fine, though I don't know that we would desire people do that. We
may want to simply not specify this--what we *do* want is for senders to
periodically and in advance of expiration refresh their cached policies;
technically this does not really require HTTPS I don't think, but it
doesn't hurt to do the fetch.

WDYT?

On Thu, May 10, 2018 at 6:44 PM Viktor Dukhovni <[e-mail]>
wrote:

>
>
> > On May 10, 2018, at 12:16 PM, Daniel Margolis <[e-mail]>
> wrote:
> >
> > Yes, you're right. I take back my comment, though I'm glad I made it
> since it clarified this whole thing. ;)
> >
> > I've rewritten this to
> >
> > Because this attack is also possible upon refresh of a cached policy, we
> suggest
> > implementers do not wait until a cached policy has expired before
> checking for
> > an update; if senders attempt to refresh the cache regularly (for
> example, by
> > checking their cached version string against the live policy in a
> background
> > task that runs daily or weekly and updating their cache's "max age"
> > accordingly), an attacker would have to foil policy discovery consistent
>
> I don't understand what is meant by "checking their cached version string"
> in:
>
>   (for example, by checking their cached version string against the
>   live policy in a background task that runs daily or weekly and
>   updating their cache's "max age" accordingly)
>
> Can you elaborate.  Are you saying that it is enough to check that
> the TXT record has not changed to extend the policy max_age?  Without
> connecting to the HTTPS site?
>
> Does that mean that a site that removes its "mta-sts" HTTPS service
> endpoint but keeps a stable TXT record in place will be able to
> indefinitely support policies at senders who originally obtained
> the policy?
>
> I am ambivalent about this approach.  For example, if a site does
> the DNS and HTTPS updates out of order, a sender might never learn
> the right (most recent) policy...
>
> Or am I misreading the new text?
>
> --
>         Viktor.
>
> _______________________________________________
> Uta mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta
>