> Benjamin Kaduk has entered the following ballot position for > draft-ietf-uta-mta-sts-17: No Objection
> When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-uta-mta-sts/ > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > Thanks for the well-written document! Other people have noted some things > already, > so I can only add small things. > Section 3.1 > Did you consider ABNF that would let new versions be defined without > having to redefine the ABNF? First, since the cost of "redefinition" is a single line of ABNF: sts-version =/ %s"v=STSv2" it's hardly high cost. As for the corresponding code, in my implementation it would correspond to a single line change. Again, hardly high cost. Second, this approach is used in numerous other specifications in the email space, so it is hardly obscure. What would be obscure is some other sort of extension mechansism. We've tried other mechanisms on several past occasions, including the original MIME specificaiton, and the results have been poor. Those experiences have led to the current approach. Third, the only reasons I can think of for a version change would be to change either some aspect of the syntax or some basic semantics of the record/object. Those changes are almost certainly going to be a lot more difficult than supporting an additional version number. > Section 7.2 > It's probably better to cite this as BCP 195 than RFC 7525 directly. Given the liklihood of BCP 195 being upgraded to TLS 1.3 at some point without full consideration of the impace on email infrastructure, I'm by no means sure that's the case. Or, to put this another way, if you want to reference a changing set of secure substrate best practices here, that in turn imposes a requirement on future versions of those best practices to give full consideration to email infrastructure realities. As the wise man once said, "Are you sure this is what you want?" > Section 8.1 > Recipients should also prefer to update the HTTPS policy body before > updating the TXT record; this ordering avoids the risk that senders, > seeing a new TXT record, mistakenly cache the old policy from HTTPS. > It seems like this risk would be mitigated if the "id" value from > the TXT record was required to also appear in the policy body as an > identifier. But presumably that would cause issues elsewhere, as it > is not the case in the current document. The problem with including the id in the policy is that now you have a gap no matter how you order the update. Ned _______________________________________________ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
