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.
-Benjamin
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
