SMTP MTA Strict Transport Security (MTA-STS)
RFC 8461

Note: This ballot was opened for revision 15 and is now closed.

(Ben Campbell) Yes

Comment (2018-05-09 for -17)
No email
send info
I'm balloting "Yes" because I want to see this work published. But I have a few concerns:

§3 seems to leave much of the interpretation of the TXT record as "implication". It should be explicit. I'd like to see the specific steps the sender is supposed to follow (perhaps the flow in §5.1 could be expanded to include the TXT query and interpretation?

For example, the idea that a non-existent record means no MTA-STS support is sort of buried in the description of multiple text records. Would it be reasonable to say that the sender SHOULD NOT query for policy if the id hasn't changed since a previous query?

- "When fetching a new policy or updating a policy, the HTTPS endpoint MUST present a X.509 certificate which is valid for the "mta-sts"
I find this confusing. Which endpoint is doing the fetching? Which one MUST present the cert. Are we talking about this in the context of TLS or something else?
- Why is checking for certificate revocation only a MAY?
- Does the term "sender" refer to the SMTP sender, or something else?

§4.1: Why is checking for certificate revocation only a MAY?

(Alexey Melnikov) Yes

Comment (2018-06-16)
No email
send info
Discussion of IANA registration of ".well-known/mta-sts.txt" with the Designated Expert is in progress.

(Adam Roach) (was Discuss) Yes

Comment (2018-05-24 for -19)
No email
send info
Thanks to the authors of draft-ietf-uta-smtp-tlsrpt for addressing the situation highlighted in my earlier DISCUSS.

(Ignas Bagdonas) No Objection

Deborah Brungard No Objection

Alissa Cooper No Objection

(Spencer Dawkins) No Objection

Benjamin Kaduk No Objection

Comment (2018-05-09 for -17)
No email
send info
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.

(Suresh Krishnan) No Objection

Warren Kumari (was Discuss) No Objection

Comment (2018-05-23 for -19)
No email
send info
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!

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

This would mean that the policy can be fetched from - 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.

(Mirja Kühlewind) No Objection

Comment (2018-05-07 for -17)
No email
send info
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"

(Terry Manderson) No Objection

(Eric Rescorla) (was Discuss) No Objection

Comment (2018-05-30 for -19)
No email
send info
Thank you for addressing my DISCUSS.

Alvaro Retana No Objection

Martin Vigoureux No Objection