On Thu, May 10, 2018 at 12:38 AM Benjamin Kaduk <[email protected]> wrote:
> On Wed, May 09, 2018 at 11:43:50AM -0700, Ned Freed wrote: > > > 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: > [...] > > ("Yes" would have sufficed.) > > > > 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?" > > It seems rather inherent that when one is using the phrase > "infrastructure realities" in this sort of context, it will be in > conflict with "best current practice", because if there was no > conflict, it wouldn't be worth talking about. So if this is simply > a matter of giving a more direct pointer to the conflict between > deployed reality and (ideal) best practices, yes, I'm fine with > that. > > I also expect that a hypothetical rev of BCP 195 to include TLS 1.3 > will take into account all consumers of TLS, and not limit itself to > just the Web ecosystem, since TLS is a general-purpose protocol. > > > > 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. > > Right. > Yes, but an alternate approach is to have the "id" in the TXT become a part of the policy URI--e.g. ..well-known/mta-sts-$id.txt We chose not to do this because it seemed like greater complexity with little benefit; in general, it's not hard advice to tell people to publish the policy body first, and fixed paths seem a bit more coherent to me. But I thought I'd call that out for interest's sake. > > -Benjamin > > _______________________________________________ > Uta mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/uta >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
