On Sat, Dec 10, 2016 at 03:04:02PM +0100, Daniel Margolis wrote:
> Thanks again.
>
> The primary suggestion you make is very similar to some early discussions
> we had. The reason we stuck with DNS version signalling is to ensure that
> senders can cheaply check for new policies (e.g. in the case of a delivery
> failure) without worrying too much about availability of the HTTPS policy
> host; I agree that you can probably do the same with HTTP cache control,
> but it still means the HTTPS endpoint has to be able to serve every
> request, whereas DNS naturally provides caching at the recursive resolver.
>
> This allows us, I believe, to more easily require that senders MUST check
> for a new policy before permanently failing a delivery, which provides an
> important safety hatch for long-lived policy caching. (In error conditions,
> the "is there a new policy?" check is essentially as frequent as failed
> delivery attempts, whereas in normal conditions it's far lower, so there's
> some fear of cascading errors where a failure to resolve a new policy--and
> a failing cached policy--results in a DoS that prevents fetching the new
> policy.)
>
> That said, is it worth the complexity to deployments? As you say, it means
> that rolling out a new policy requires some DNS change on part of the
> mail-to domain, even if they are delegating all other aspects of their
> delivery. However, I believe a new policy should be required no more
> frequently than new MX records themselves, since all the policy specifies
> is the trusted MX records--and changing the MX records requires the
> customer to make a change to their DNS already.
>
> I do think the concern you raise is far greater if we were to move to e.g.
> public key pinning in policies; in that case, policy updates could be far
> more frequent than DNS changes, and the result is a real deployment
> complexity. So if in a later version we wanted to make such more specific
> policies, I believe we'd have to think about better methods of policy
> deployment.
>
> So in short, I believe in the current version the deployment complexity is
> not that big a concern because the DNS changes should be no more frequent
> than any existing DNS changes. But I do think you make a good observation,
> and the complexity/risk tradeoff is a hard one to really measure.
>
> Does it make sense?
It does, thanks for the detailed and thoughtful response.
In particular, I think the tradeoff you're characterizing (HTTPS serving
requirements vs. deployment complexity) is spot on; and that the
assumption that changing the policy is very infrequent carries a
significant weight in favour of the DNS approach.
However, within this context, I'd like to challenge that assumption a
little, if you don't mind :)
To me, one of the main benefits of the current proposal is
extensibility: it opens the door for using the policy definition file in
very useful ways, even if the current draft does not include them.
Key pinning is a great example that you mention in your email. It could
also be used to include SPF, DKIM and DMARC information; and who knows
what else people will come up in the future (list capabilities? signal
support for new protocols?).
Going with the assumption that the information in the policy changes
very infrequently can be quite limiting to future expansions. It won't
make them impossible to deploy, of course, but just much harder, which
will, in turn, likely hurt their adoption.
It also makes delegation more difficult, or limits the policies to a
coordinated change between the email handler and the domain owner, which
is hard to do specially at scale.
I fully agree that the HTTPS-only option puts a burden on reliably
running an HTTPS service. But I think these days that is a quite well
understood problem, and there are lots of options and general expertise
for doing it right.
Client-side caching can also serve as short-term unavailability
mitigation: HTTP Cache-Control's max-age and max-stale can be used by
policy servers to suggest clients how to cache the data and handle
expirations. The complexity of this is not very high, and will be
included in SMTP software, so the cost is on people implementing the
standard (few) and not using it (hopefully lots :).
As I see it, going HTTPS-only now in the interest of increasing adoption
and aiming at making it easier to extend the policy in the future is a
better tradeoff than going with DNS now and having to tweak/change it
later when expansions appear.
Does this make sense to you?
In any case, thanks again for taking the time to consider all this and
replying to thoughtfully, I really appreciate it.
> Happy to read other comments you have on the policy contents as well.
I have a suggestion to split the contents in "incoming email" and
"outgoing mail", for example, by url (mta-sts-in.json and
mta-sts-out.json), to make it easier to understand by having a clearer
scope.
Reflecting on it now, I still like it but I don't think is particularly
important, as entries can still be unambiguously defined and be
reasonably readable anyway :)
Thanks a lot!
Alberto
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
