SMTP MTA Strict Transport Security (MTA-STS)
draft-ietf-uta-mta-sts-21

I still don't love this - it feels like it is still "reserving" a DNS label, but -18 text is close enough to having this as  a convention that I'm OK with it...

Thank you!
W

Previous DISCUSS position:
[ Edit: Could the format of the _mta-sts to be something like:
"_mta-sts.example.com.  TXT "v=STSv2; id=20180114T070707; label=foo"  ?

This would mean that the policy can be fetched from foo.example.com - the record *could* specify "label=mta-sts" if it wanted - this allows this to work without "reserving" a DNS label.  ]


I apologize, this DISCUSS written in a rush.

I'm uncomfortable with the DNS "reservations" happening in this document -- it basically reserves the (leftmost) DNS labels _mta-sts (as a TXT record) and mta-sts as a hard-coded name -- I think that this needs to be better documented / in the IANA considerations.

I apologize for the lack of detail/lack of actionable content - I couldn't decide between Deferring and balloting DISCUSS -- I decided on DISCUSS because  I think I need to think about this, and clearing a DISCUSS is simpler than having the document stuck for a full cycle.

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?


Section 3.2

   When fetching a policy, senders SHOULD validate that the media type
   is "text/plain" to guard against cases where webservers allow
   untrusted users to host non-text content (typically, HTML or images)
   at a user-defined path.  All parameters other charset=utf-8 or
   charset=us-ascii are ignored.

Nit: "other than"


Section 5

Should the "enforce" text also mention the STARTTLS requirement from
Section 4?


Section 7.2

It's probably better to cite this as BCP 195 than RFC 7525 directly.


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.

Thank you for addressing my DISCUSS.

Some questions on use of normative language:

1) sec 3.3.: Is there a reason that you not always use normative language for the recommendation regarding rate limiting? 
e.g. "...we suggest implementions may limit further attempts to a period of five minutes or longer..." or "A suggested timeout is one minute, and a suggested maximum policy size 64 kilobytes".
(also a nit here s/implementions/implementations/)

2) Also in sec 8.1. and 8.2 you maybe want to use normative language as well...?

3) And there also a few cases in section 10.2 where normative language could be appropriate/help:
"we strongly recommend implementers to prefer policy "max_age" values to be as long as is practical." and "we suggest implementers do not wait until a cached policy has expired before checking for an update" and "MTAs should alert administrators to repeated policy refresh failures long before cached policies expire"