On Wed, Dec 07, 2016 at 08:09:28PM +0100, Daniel Margolis wrote: > Thanks very much for the feedback. I think the good news is that some of > these comments are addressed in the upcoming draft.
Thanks for the detailed replies, and happy to hear about the upcoming draft, look forward to reading it :) > On Sun, Dec 4, 2016 at 5:06 PM, Alberto Bertogli <[email protected]> > wrote: > > > - Requiring additional DNS records make it more difficult to set up. > > > > DNS seems to me the best way to cheaply discover both domain participation > and new-policy-presence. In any event, given that SPF, DKIM, and DMARC all > require similar TXT records, I would assume this isn't *that* hard, is it? I agree, but I think it's the combination of additional subdomain + record for it + policy ID embedded in DNS that adds up. I have a suggestion about this below. > > - Having to keep the IDs in sync between the DNS records and the HTTPS > > policy is, IMO, a significant operational burden, and makes it more > > difficult to “get it right" when making changes. > > > > We've removed this. But you're right. :) Great! > > - The above also carries a complexity overhead in the RFC itself and the > > software implementation, by having to consider the interactions > > between the two (such as the caching logic, multiple level domains, > > etc.). > > > > There are a few potential problems you are alluding to, I think. > > 1. The "don't use a new policy if it hasn't been successfully used before" > thing. We have gotten rid of this. :) > > 2. Deployment issues, e.g. publishing a policy on the HTTPS endpoint and > updating the TXT record may be problematic if the HTTPS is served via a CDN > with some unclear cache update time. Will people see the new TXT, update > the policy, and get the old policy? Fortunately I think this kind of issue > is fairly insignificant, since the DNS version ID is in fact unimportant. > You can publish a new policy via HTTPS and then rotate the TXT record as > many times as you like. So policy publishers who can't figure out their CDN > can either a) wait a while for the CDN to update before updating the TXT or > b) update the TXT today *and* tomorrow. But having the policy ID on TXT means that you eventually should keep them in sync. It's less harmful complexity, but it's still complexity. It also makes delegation more difficult, as you can't just set a record once pointing to someone else, and forget about it. What do you think of the following alternative: publish the policy contents on https://_smtp_policy.<domain>/.... - No TXT record, no ID on DNS. Being able to resolve A/AAAA/CNAME for _smtp_policy.<domain> is equivalent to seeing the valid TXT record for _mta-sts.<domain>. - Implementations can just use http client libraries, and avoid direct DNS lookups and parsing, simplifying the implementation. If the policy is not present, this fails just as fast as the _mta-sts subdomain not existing. - Delegation continues to be reasonably easy: point _smtp_policy to the email provider. The email provider will need to get a valid cert for _smtp_policy.<domain>, just like in the current draft. About the policy ID: remove it completely, and rely on standard HTTP caching instead. Recommend in the RFC that an ETag+Cache-Control should be used when replying to GET requests for the policy, and they indicate the clients for how long they can cache it, and provide an ID for quick checking. This mechanism is well deployed, most CDNs support it already, libraries to manipulate them well are readily available, and removes all the cache management complexity from the RFC itself. > > I was wondering if this you had any rationale about those decisions that > > would help me understand why the current draft chose to go in this > > direction, instead of potentially simpler approaches. > > > > Well, the generic answer is that we didn't see simpler approaches that > didn't have some other downside. But there may be them--nondiscovery is not > a proof of non-existence! > > Do you have a suggested change or set of changes? I think the above are the main ideas I had :) I may have a couple of suggestions for the policy contents, if it's ok with you I can send them next week, but (to me) they are less important, as they don't relate to deployment and just content and extensibility. > > I hope this doesn't come across the wrong way, I debated whether to send > > this or not, but seeing the invitation to comment on your git repository > > tipped the scale :) > > > > Oh, definitely not. I appreciate the thoughtful comments! Thanks a lot for your thoughtful response, and for working on this! Alberto _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
