On Sat, Dec 17, 2016 at 12:04 AM, Alberto Bertogli <[email protected] > wrote:
> But using HTTPS only has the same polling frequency. The MTA doesn't > need to trigger the probe any more often than with the current proposal. > I think you're basically right about polling frequency, but I believe there are two other reasons to keep the current design. First, DNS (leveraging the local resolver cache) avoids the need for a local read-write cache that remembers last-check-time. (We still need a local policy cache.) What I mean by that is that in the case where an MTA wants to check if a *new* policy exists--say, when the cached policy has failed to validate--the MTA may be doing so on every send. In a distributed environment (i.e. multiple MTAs in the same datacenter, but *sharing the same recursive resolver*), the check for "is there a new policy version?" is cached by the recursive resolver. In the HTTP-only model, however, each MTA must check-and-maybe-write the last-fetch-time (and whatever other sort of cache control data) upon fetch. I haven't thought deeply about this tradeoff, to be honest; given that there has to be some cache (preferably centralized anyway) of *discovered policies*, this may not be a big deal at all, but it's something to think about. We chose DNS for this because it was (fairly) easy to expect certain semantics from senders in terms of remembering when they last checked for a new policy; you can certainly do the same thing with HTTP cache semantics, but it may require slightly more explicit implementation on part of sending MTAs. (A well-behaved HTTP client library may at least honor the cache controls per-machine, so I'm not sure if the only risk here is that the cache is not distributed, which isn't likely *that* big a deal.) The second reason, potentially more compelling, is that the use of a magical TXT record makes it slightly harder for domains that allow untrusted content on user-chosen subdomains (like tumblr.com or dyndns.org) to have a malicious user serve a phony policy. I think this reason is a good bit more compelling (though there are, again, alternatives, like requiring a special EKU in the SSL certificate presented over HTTPS). Dan
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
