Skip to main content

SMTP TLS Reporting
RFC 8460

Revision differences

Document history

Date Rev. By Action
2019-11-01
23 (System) Received changes through RFC Editor sync (added Errata tag)
2018-09-28
23 (System) IANA registries were updated to include RFC8460
2018-09-26
23 (System)
Received changes through RFC Editor sync (created alias RFC 8460, changed abstract to 'A number of protocols exist for establishing encrypted channels between SMTP …
Received changes through RFC Editor sync (created alias RFC 8460, changed abstract to 'A number of protocols exist for establishing encrypted channels between SMTP Mail Transfer Agents (MTAs), including STARTTLS, DNS- Based Authentication of Named Entities (DANE) TLSA, and MTA Strict Transport Security (MTA-STS).  These protocols can fail due to misconfiguration or active attack, leading to undelivered messages or delivery over unencrypted or unauthenticated channels.  This document describes a reporting mechanism and format by which sending systems can share statistics and specific information about potential failures with recipient domains.  Recipient domains can then use this information to both detect potential attacks and diagnose unintentional misconfigurations.', changed pages to 34, changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2018-09-26, changed IESG state to RFC Published)
2018-09-26
23 (System) RFC published
2018-09-25
23 (System) RFC Editor state changed to AUTH48-DONE from AUTH48
2018-09-08
23 (System) RFC Editor state changed to AUTH48 from RFC-EDITOR
2018-08-20
23 (System) RFC Editor state changed to RFC-EDITOR from REF
2018-08-09
23 (System) RFC Editor state changed to REF from EDIT
2018-06-18
23 (System) RFC Editor state changed to EDIT from MISSREF
2018-06-15
23 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2018-06-15
23 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2018-06-15
23 (System) IANA Action state changed to In Progress from Waiting on Authors
2018-06-15
23 (System) IANA Action state changed to Waiting on Authors from In Progress
2018-06-15
23 (System) IANA Action state changed to In Progress from Waiting on Authors
2018-06-14
23 (System) IANA Action state changed to Waiting on Authors from In Progress
2018-06-14
23 (System) IANA Action state changed to In Progress from On Hold
2018-06-14
23 Alex Brotman New version available: draft-ietf-uta-smtp-tlsrpt-23.txt
2018-06-14
23 (System) New version approved
2018-06-14
23 (System) Request for posting confirmation emailed to previous authors: Janet Jones , Alexander Brotman , Mark Risher , Daniel Margolis , Binu Ramakrishnan
2018-06-14
23 Alex Brotman Uploaded new revision
2018-05-25
22 (System) IANA Action state changed to On Hold from Waiting on Authors
2018-05-25
22 (System) IANA Action state changed to Waiting on Authors from In Progress
2018-05-23
22 (System) IANA Action state changed to In Progress
2018-05-23
22 (System) RFC Editor state changed to MISSREF
2018-05-23
22 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2018-05-23
22 (System) Announcement was received by RFC Editor
2018-05-23
22 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2018-05-23
22 Cindy Morgan IESG has approved the document
2018-05-23
22 Cindy Morgan Closed "Approve" ballot
2018-05-23
22 Cindy Morgan Ballot approval text was generated
2018-05-23
22 Alexey Melnikov There is one RFC Editor note.
2018-05-23
22 Alexey Melnikov IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2018-05-23
22 Alexey Melnikov RFC Editor Note was changed
2018-05-23
22 Alex Brotman New version available: draft-ietf-uta-smtp-tlsrpt-22.txt
2018-05-23
22 (System) New version approved
2018-05-23
22 (System) Request for posting confirmation emailed to previous authors: Janet Jones , Alexander Brotman , Mark Risher , Daniel Margolis , Binu Ramakrishnan
2018-05-23
22 Alex Brotman Uploaded new revision
2018-05-23
21 Alexey Melnikov RFC Editor Note was changed
2018-05-22
21 Alexey Melnikov
[Ballot comment]
Note that there is one action from me pending in regards to this document:

1) See the RFC Editor note I've added that …
[Ballot comment]
Note that there is one action from me pending in regards to this document:

1) See the RFC Editor note I've added that registers DNS label. This addresses PHB's SecDir comment.


Also, the following issues from IESG were partially addressed:

From Adam:

§6.5:

>  This document creates a new registry, "STARTTLS Validation Result
>  Types".  The initial entries in the registry are:

This table omits a column for the defining document and/or party to contact,
which is usually present for "Expert Review" registries. Is that intentional?
2018-05-22
21 Alexey Melnikov Ballot comment text updated for Alexey Melnikov
2018-05-21
21 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-05-21
21 Alex Brotman New version available: draft-ietf-uta-smtp-tlsrpt-21.txt
2018-05-21
21 (System) New version approved
2018-05-21
21 (System) Request for posting confirmation emailed to previous authors: Janet Jones , Alexander Brotman , Mark Risher , Daniel Margolis , Binu Ramakrishnan
2018-05-21
21 Alex Brotman Uploaded new revision
2018-05-09
20 Alexey Melnikov IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent::AD Followup
2018-05-07
20 Gunter Van de Velde Closed request for Last Call review by OPSDIR with state 'No Response'
2018-05-02
20 Alexey Melnikov RFC Editor Note was changed
2018-05-02
20 Alexey Melnikov RFC Editor Note was changed
2018-05-02
20 Alexey Melnikov
[Ballot comment]
Note that there are two actions from me pending in regards to this document:

1) See the RFC Editor note I've added that …
[Ballot comment]
Note that there are two actions from me pending in regards to this document:

1) See the RFC Editor note I've added that registers DNS label. This addresses PHB's SecDir comment.

2) IANA is right that there is no registry for the information supplied in Section 6.2. Either the section should be deleted or we should create a new registry for multipart/report report-types.

3) The following issues from IESG were not addressed (or were possibly partially addressed):

From Adam:

§5.4:

>  Alternately, if a receiving system offers "Accept-Encoding" value of
>  "gzip"...

Offers it where?

Alexey: the whole section was removed, I would like it back!

§6.5:

>  This document creates a new registry, "STARTTLS Validation Result
>  Types".  The initial entries in the registry are:

This table omits a column for the defining document and/or party to contact,
which is usually present for "Expert Review" registries. Is that intentional?


From Benjamin:

I wonder if this document could benefit from a Privacy Considerations
section.  While it is true that the intent is to transmit aggregate
statistics from MTA to MTA, and MTAs are inherently at well-known
public locations, if any given data point in the report has only a
small number of occurrences, that could potentially reveal
information about an individual or small group of individuals.  On
the other hand, if an outlier data point indicates an attack, then
it should not be suppressed from the report!  So while there may not
be much guidance to give to implementors, it would be reassuring to
know that the topic has been given some thought.


From Eric:

IMPORTANT
>  4.1.  Report Time-frame

>      The report SHOULD cover a full day, from 0000-2400 UTC.  This should
>      allow for easier correlation of failure events.  To avoid a Denial of
>      Service against the system processing the reports, the reports should
>      be delivered after some delay, perhaps several hours.

IMPORTANT: I think what you're trying to do is avoid people sending
everything at midnight, If so, you should specify a random delay
algorithm. Otherwise, a popular implementation might specify a fixed
delay, which produces the same problem. I am not marking this DISCUSS
because the number of senders seems likely to be too small for this to
cause a major problem, but I still believe you should fix it
2018-05-02
20 Alexey Melnikov Ballot comment text updated for Alexey Melnikov
2018-05-02
20 Alex Brotman New version available: draft-ietf-uta-smtp-tlsrpt-20.txt
2018-05-02
20 (System) New version approved
2018-05-02
20 (System) Request for posting confirmation emailed to previous authors: Janet Jones , Alexander Brotman , Mark Risher , Daniel Margolis , Binu Ramakrishnan
2018-05-02
20 Alex Brotman Uploaded new revision
2018-05-02
19 Alexey Melnikov RFC Editor Note was changed
2018-05-02
19 (System) Sub state has been changed to AD Followup from Revised ID Needed
2018-05-02
19 Alex Brotman New version available: draft-ietf-uta-smtp-tlsrpt-19.txt
2018-05-02
19 (System) New version approved
2018-05-02
19 (System) Request for posting confirmation emailed to previous authors: Janet Jones , Alexander Brotman , Mark Risher , Daniel Margolis , Binu Ramakrishnan
2018-05-02
19 Alex Brotman Uploaded new revision
2018-04-19
18 Cindy Morgan IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation
2018-04-19
18 Ignas Bagdonas [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas
2018-04-19
18 Ben Campbell
[Ballot comment]
[Thank you for responding to my DISCUSS points via email. I have cleared, but I do how to see more explicit discussion in …
[Ballot comment]
[Thank you for responding to my DISCUSS points via email. I have cleared, but I do how to see more explicit discussion in the security considerations.]

Substantive:

§1.1: There are at least a few lower case instances of 2119 keywords. Please consider using the boilerplate from RFC 8174 instead of 2119.

§5.3, first paragraph: The paragraph claims that this document defines "multipart/report". In fact, it does not.

§5.4, 2nd paragraph: " A reporting entity HOULD expect a "successful" response from the accepting HTTPS server...": I'm not sure how to interpret a normative requirement to expect success. What is the real intent here?

Editorial and Nits:

§1, paragraph 1, 2nd sentence: The sentence is convoluted. Can it be broken into multiple simpler sentences?

§1.1, Policy Domain: The definition is partially circular. Please define what is meant by "domain". I assume that means domain in the DNS sense, but the word "domain" is commonly uses in other senses as well. Please be explicit.
2018-04-19
18 Ben Campbell [Ballot Position Update] Position for Ben Campbell has been changed to Yes from Discuss
2018-04-18
18 Adam Roach
[Ballot comment]
Thanks to everyone who worked on this document. The mechanism seems useful, and
I hope it aids in the deployment of TLS-secured email …
[Ballot comment]
Thanks to everyone who worked on this document. The mechanism seems useful, and
I hope it aids in the deployment of TLS-secured email transfer. I have a mix of
editoral and substantive comments.

---------------------------------------------------------------------------

§1.1:

This document also uses lowercase forms of these words. Consider using the
boilerplate from RFC 8174.

---------------------------------------------------------------------------

§3:

>  If the reporter does not support one
>  of the report mechanisms, then it SHOULD NOT attempt delivery to
>  those rua destinations.

This seems tautological. If this is intended to restrict some action that is not
impossible by its own nature, then it needs rephrasing. Otherwise, it should
probably just be removed.

---------------------------------------------------------------------------

§4.4:

>  o  "total-successful-session-count": The aggregate number (integer)
>    of successfully negotiated TLS-enabled connections to the
>    receiving site.
>
>  o  "total-failure-session-count": The aggregate number (integer) of
>    failures to negotiate a TLS-enabled connection to the receiving
>    site.
>
>  o  "failed-session-count": The number of (attempted) sessions that
>    match the relevant "result-type" for this section.

Although these use the word "number," its use seems to be colloquial rather
than technical. It is probably worthwhile, for avoidance of doubt (and to
prevent errant string encodings), to add ", encoded as a JSON number" to the
end of each of these.

---------------------------------------------------------------------------

§4.4:

>  dec-octet = DIGIT ; 0-9 / %x31-39 DIGIT ; 10-99 / "1" 2DIGIT ;
>  100-199 / "2" %x30-34 DIGIT ; 200-249 / "25" %x30-35 ; 250-255

Presumably, this is ANBF? Please indicate that. Also, in ABNF, comments start
with a semicolon and continue to the end of the line, which makes this
production syntactically invalid.

I beleive you want the following instead:

  dec-octet = DIGIT              ; 0-9
              / %x31-39 DIGIT    ; 10-99
              / "1" 2DIGIT        ; 100-199
              / "2" %x30-34 DIGIT ; 200-249
              / "25" %x30-35      ; 250-255


---------------------------------------------------------------------------

§4.5:

>  For the MTA-STS policy, an array of JSON strings that represents the
>  policy that is declared by the receiving site, including any errors
>  that may be present.

This isn't a sentence. Perhaps insert "this is" before "an array"?

---------------------------------------------------------------------------

§5.2:

>  The report SHOULD be subjected to GZIP compression for both email and
>  HTTPS transport.

This "SHOULD" makes it necessary to include GZIP as a normative reference. I
believe the correct reference here is RFC 1952. While it is Informational, it is
already in the downref registry, which saves us a lot of headache.

---------------------------------------------------------------------------

§5.4:

>  Alternately, if a receiving system offers "Accept-Encoding" value of
>  "gzip"...

Offers it where?

---------------------------------------------------------------------------

§6.4:

>  Security considerations: Security considerations relating to SMTP TLS
>  Reporting are discussed in Section 7.

Please also cite RFC 6713 Section 4.

>                    Magic number(s):  n/a

Please replace "n/a" with "first two bytes are 0x1f, 0x8b."

---------------------------------------------------------------------------

§6.5:

>  This document creates a new registry, "STARTTLS Validation Result
>  Types".  The initial entries in the registry are:

This table omits a column for the defining document and/or party to contact,
which is usually present for "Expert Review" registries. Is that intentional?

---------------------------------------------------------------------------

Appendix B:

Please use IPv6 or a mix of IPv4 and IPv6 in your example. See
https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ for further guidance.

Please select addresses from the ranges reserved by RFC 3849 (and RFC 5737, if
necessary), rather than the allocated addresses (owned by Yahoo, Alisoft, and
Windstream) and private-use addresses currently in the example.
2018-04-18
18 Adam Roach [Ballot Position Update] New position, Yes, has been recorded for Adam Roach
2018-04-18
18 Alissa Cooper
[Ballot comment]
I would support adding clarifying text to address Ben's DISCUSS, which makes a point that the Gen-ART reviewer also raised.

The Gen-ART reviewer …
[Ballot comment]
I would support adding clarifying text to address Ben's DISCUSS, which makes a point that the Gen-ART reviewer also raised.

The Gen-ART reviewer made a number of other points that are also worth taking a look at (I saw a response only to the one about ignoring certificate validation errors).
2018-04-18
18 Alissa Cooper [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper
2018-04-18
18 Deborah Brungard [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard
2018-04-18
18 Alexey Melnikov
[Ballot comment]
Note that there are two actions from me pending in regards to this document:

1) See the RFC Editor note I've added that …
[Ballot comment]
Note that there are two actions from me pending in regards to this document:

1) See the RFC Editor note I've added that registers DNS label. This addresses PHB's SecDir comment.

2) Please see the RFC Editor note with +gzip Media Type suffix registration.

3) IANA is right that there is no registry for the information supplied in Section 6.2. Either the section should be deleted or we should create a new registry for multipart/report report-types.
2018-04-18
18 Alexey Melnikov Ballot comment text updated for Alexey Melnikov
2018-04-18
18 Mirja Kühlewind [Ballot comment]
Maybe add "Aggregate report URI (rua)" to the terminology section.
2018-04-18
18 Mirja Kühlewind [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind
2018-04-18
18 Martin Vigoureux [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux
2018-04-18
18 Terry Manderson [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson
2018-04-17
18 Suresh Krishnan
[Ballot comment]
The report in Appendix B seems to be using non-example IP addresses (e.g. 98.136.216.25 seems to be a Yahoo address). Please change these …
[Ballot comment]
The report in Appendix B seems to be using non-example IP addresses (e.g. 98.136.216.25 seems to be a Yahoo address). Please change these to use example addresses from one of the documentation blocks from RFC6890
2018-04-17
18 Suresh Krishnan Ballot comment text updated for Suresh Krishnan
2018-04-17
18 Suresh Krishnan [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan
2018-04-17
18 Alvaro Retana [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana
2018-04-16
18 (System) IANA Review state changed to IANA - Not OK from Version Changed - Review Needed
2018-04-16
18 Warren Kumari
[Ballot comment]
Old DISCUSS position for hysterical raisins:

I'm guessing that I'm simply misunderstanding / not understanding (reformatted for clarity):
1: If multiple TXT records …
[Ballot comment]
Old DISCUSS position for hysterical raisins:

I'm guessing that I'm simply misunderstanding / not understanding (reformatted for clarity):
1: If multiple TXT records for "_smtp._tls" are returned by the resolver, records which do not begin with "v=TLSRPTv1;" are discarded.
2: If the number of resulting records is not one, senders MUST assume the recipient domain does not implement TLSRPT.
3: If the resulting TXT record contains multiple strings, then the record MUST be treated as if those strings are concatenated together without adding spaces.

So, if I query for '_smtp._tls.example.com' and get back:
"v=TLSRPTv1;rua=mailto:foo@example.com"
"v=TLSRPTv3;rua=mailto:bar@example.com"

I throw away the one that contains 'bar', fair enough, got it. What I don't understand is what a record would look like which is a single record (#2), but that contains multiple strings (#3).
Can you provide an example of a TXT record with multiple strings? I don't *think* that this is just me being dense, and so I think that the document needs to better explain this / include the example.
2018-04-16
18 Warren Kumari [Ballot Position Update] Position for Warren Kumari has been changed to No Objection from Discuss
2018-04-16
18 Warren Kumari
[Ballot discuss]
I'm guessing that I'm simply misunderstanding / not understanding (reformatted for clarity):
1: If multiple TXT records for "_smtp._tls" are returned by the …
[Ballot discuss]
I'm guessing that I'm simply misunderstanding / not understanding (reformatted for clarity):
1: If multiple TXT records for "_smtp._tls" are returned by the resolver, records which do not begin with "v=TLSRPTv1;" are discarded.
2: If the number of resulting records is not one, senders MUST assume the recipient domain does not implement TLSRPT.
3: If the resulting TXT record contains multiple strings, then the record MUST be treated as if those strings are concatenated together without adding spaces.

So, if I query for '_smtp._tls.example.com' and get back:
"v=TLSRPTv1;rua=mailto:foo@example.com"
"v=TLSRPTv3;rua=mailto:bar@example.com"

I throw away the one that contains 'bar', fair enough, got it. What I don't understand is what a record would look like which is a single record (#2), but that contains multiple strings (#3).
Can you provide an example of a TXT record with multiple strings? I don't *think* that this is just me being dense, and so I think that the document needs to better explain this / include the example.
2018-04-16
18 Warren Kumari [Ballot Position Update] New position, Discuss, has been recorded for Warren Kumari
2018-04-16
18 Benjamin Kaduk
[Ballot comment]
Thanks to Alexey et al for following up on the secdir review thread.

Some other notes:

In the Abstract: Is it "potential attackers" …
[Ballot comment]
Thanks to Alexey et al for following up on the secdir review thread.

Some other notes:

In the Abstract: Is it "potential attackers" or "potential attacks" that
can be detected?

Section 1.1

  o  MTA-STS Policy: A definition of the expected TLS availability,
      behavior, and desired actions for a given domain when a sending
      MTA encounters problems in negotiating a secure channel.

This description of the policy doesn't make it seem like a
definition of those elements, rather a statement or listing of them.


Section 3

  o  "v": This value MUST be equal to "TLSRPTv1".

How about something like "This document defines version 1; other
versions may be defined in later documents"?  Additionally, text
later in this section aboud discarding records that do not begin
with "v=TLSRPTv1;" and the pruned list not having exactly one
element is not friendly to future version negotiation.

On a more meta level, do we really need both versioning and extensions?

SMTP deliveries can go in the clear, but what about https reports?
What do we do if the TLS handshake fails for a
non-certificate-validation reason?

Section 4

  [...] Reporters may report multiple
  applied policies (for example, an MTA-STS policy and a DANE TLSA
  record for the same domain and MX); even in the case where only a
  single policy was applied, the "policies" field of the report body
  MUST be an array and not a singular value.

The confusion caused by misreading the semicolon as a comma is
pretty large; maybe start a new sentence with "Because of this
possibility, even in the case [...]"?


Section 4.4

Is the ABNF for IPv4address really supposed to be line-wrapped like
that?


Section 7

I'm not sure I correctly understand the reasoning for the statement
about using a large TTL for the TLSRPT TXT records -- it seems like
the idea is that if the consumer has already received the record
once, a large TTL will reduce the frequency at which the consumer
seeks to refresh their view of the record, so there are numerically
fewer DNS requests that could be intercepted by an attacker?  But it
seems like if the attacker can intercept the first request and
insert their spoofed response, the large TTL doesn't help at all
(and in fact could use their own large TTL to preserve the bogus
record for a long time).  So it's not really clear that there's much
of a difference, on first glance.  Also, this seems somewhat related
to Ben's DISCUSS.

I wonder if this document could benefit from a Privacy Considerations
section.  While it is true that the intent is to transmit aggregate
statistics from MTA to MTA, and MTAs are inherently at well-known
public locations, if any given data point in the report has only a
small number of occurrences, that could potentially reveal
information about an individual or small group of individuals.  On
the other hand, if an outlier data point indicates an attack, then
it should not be suppressed from the report!  So while there may not
be much guidance to give to implementors, it would be reassuring to
know that the topic has been given some thought.
2018-04-16
18 Benjamin Kaduk [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk
2018-04-16
18 Alexey Melnikov
[Ballot comment]
Note that there are two actions from me pending in regards to this document:

1) See the RFC Editor note I've added that …
[Ballot comment]
Note that there are two actions from me pending in regards to this document:

1) See the RFC Editor note I've added that registers DNS label. This addresses PHB's SecDir comment.

2) Please see the RFC Editor note with +gzip Media Type suffix registration.
2018-04-16
18 Alexey Melnikov Ballot comment text updated for Alexey Melnikov
2018-04-16
18 Alexey Melnikov RFC Editor Note was changed
2018-04-16
18 Alexey Melnikov RFC Editor Note for ballot was generated
2018-04-16
18 Alexey Melnikov RFC Editor Note for ballot was generated
2018-04-15
18 Ben Campbell
[Ballot discuss]
I plan to ballot "Yes" for this, but there is an issue I think needs discussion first. Hopefully this will be easy to …
[Ballot discuss]
I plan to ballot "Yes" for this, but there is an issue I think needs discussion first. Hopefully this will be easy to address:

§3 says "Report submitters MAY ignore certificate validation errors when submitting reports via https." Yet the security considerations mention how an attacker than can subvert SMTP security might also be able to subvert the TLSRTP TXT records. It seems like one potential result of that could be to redirect the reports to a hostile destination, or at least away from the intended destination. Ignoring certificate validation errors  removes a check against that sort of thing.

I'm sure there are good reasons to allow that; I can even guess at a few. But I think allowing that sort of behavior needs explicit motivation, and I failed to find text that did that.
2018-04-15
18 Ben Campbell
[Ballot comment]
Substantive:

§1.1: There are at least a few lower case instances of 2119 keywords. Please consider using the boilerplate from RFC 8174 instead …
[Ballot comment]
Substantive:

§1.1: There are at least a few lower case instances of 2119 keywords. Please consider using the boilerplate from RFC 8174 instead of 2119.

§5.3, first paragraph: The paragraph claims that this document defines "multipart/report". In fact, it does not.

§5.4, 2nd paragraph: " A reporting entity HOULD expect a "successful" response from the accepting HTTPS server...": I'm not sure how to interpret a normative requirement to expect success. What is the real intent here?

Editorial and Nits:

§1, paragraph 1, 2nd sentence: The sentence is convoluted. Can it be broken into multiple simpler sentences?

§1.1, Policy Domain: The definition is partially circular. Please define what is meant by "domain". I assume that means domain in the DNS sense, but the word "domain" is commonly uses in other senses as well. Please be explicit.
2018-04-15
18 Ben Campbell [Ballot Position Update] New position, Discuss, has been recorded for Ben Campbell
2018-04-15
18 Spencer Dawkins [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins
2018-04-15
18 Eric Rescorla
[Ballot comment]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4524

Please address the secdir review comments about IANA registration.








IMPORTANT
>  4.1.  Report Time-frame

>  …
[Ballot comment]
Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D4524

Please address the secdir review comments about IANA registration.








IMPORTANT
>  4.1.  Report Time-frame

>      The report SHOULD cover a full day, from 0000-2400 UTC.  This should
>      allow for easier correlation of failure events.  To avoid a Denial of
>      Service against the system processing the reports, the reports should
>      be delivered after some delay, perhaps several hours.

IMPORTANT: I think what you're trying to do is avoid people sending
everything at midnight, If so, you should specify a random delay
algorithm. Otherwise, a popular implementation might specify a fixed
delay, which produces the same problem. I am not marking this DISCUSS
because the number of senders seems likely to be too small for this to
cause a major problem, but I still believe you should fix it

COMMENTS

>  1.1.  Terminology

>      The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>      document are to be interpreted as described in [RFC2119].

I notice that you repeatedly use "should" in contexts that suggests it
should be interpreted as normative but in lower case. Is this an
error? Are you planning to adopt 8174 boilerplate?


>      each of the supported rua destinations.  A receiver MAY opt to only
>      attempt delivery to one of the endpoints, however the report SHOULD
>      NOT be considered successfully delivered until one of the endpoints
>      accepts delivery of the report.  If the reporter does not support one
>      of the report mechanisms, then it SHOULD NOT attempt delivery to
>      those rua destinations.

Nit: this text probably should say, "it SHOULD not attempt deliver to
the destinations which use that method"
2018-04-15
18 Eric Rescorla [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla
2018-04-15
18 Alexey Melnikov
[Ballot comment]
Note that there are two actions from me pending in regards to this document:

1) Provide text about new DNS label registration as …
[Ballot comment]
Note that there are two actions from me pending in regards to this document:

1) Provide text about new DNS label registration as an RFC Editor note. This will address PHB's SecDir comment.

2) Provide text for +gzip Media Type suffix registration. The text is written, just need to be reviewed by the IANA expert.
2018-04-15
18 Alexey Melnikov Ballot comment text updated for Alexey Melnikov
2018-04-15
18 Alexey Melnikov Ballot has been issued
2018-04-15
18 Alexey Melnikov [Ballot Position Update] New position, Yes, has been recorded for Alexey Melnikov
2018-04-15
18 Alexey Melnikov Created "Approve" ballot
2018-04-15
18 Alexey Melnikov Ballot writeup was changed
2018-04-14
18 Alexey Melnikov IESG state changed to IESG Evaluation from Waiting for Writeup
2018-04-05
18 Joel Halpern Request for Telechat review by GENART Completed: Ready. Reviewer: Joel Halpern. Sent review to list.
2018-04-05
18 Jean Mahoney Request for Telechat review by GENART is assigned to Joel Halpern
2018-04-05
18 Jean Mahoney Request for Telechat review by GENART is assigned to Joel Halpern
2018-04-04
18 (System) IANA Review state changed to Version Changed - Review Needed from IANA - Not OK
2018-04-04
18 Alex Brotman New version available: draft-ietf-uta-smtp-tlsrpt-18.txt
2018-04-04
18 (System) New version approved
2018-04-04
18 (System) Request for posting confirmation emailed to previous authors: Janet Jones , Alexander Brotman , Mark Risher , Daniel Margolis , Binu Ramakrishnan
2018-04-04
18 Alex Brotman Uploaded new revision
2018-04-02
17 (System) IESG state changed to Waiting for Writeup from In Last Call
2018-03-30
17 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2018-03-30
17 Sabrina Tanamal
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-uta-smtp-tlsrpt-17. If any part of this review is inaccurate, please let …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-uta-smtp-tlsrpt-17. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that, upon approval of this document, there are five actions which we must complete.

First, in the Permanent Message Header Field Names registry on the Message Headers registry page located at:

https://www.iana.org/assignments/message-headers/

two new registrations will be made as follows:

Header Field Name: TLS-Report-Domain
Template:
Protocol: mail
Status: standard
Reference: [ RFC-to-be ]

Header Field Name: TLS-Report-Submitter
Template:
Protocol: mail
Status: standard
Reference: [ RFC-to-be ]

As this document requests registrations in an Expert Review (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC.

IANA Question --> Is the Template field for these registrations to be blank (i.e. no template)?

Second, section 6.2 of the current document makes this request:

"This document registers a new parameter "report-type="tlsrpt"" under "multipart/report" top-level media type for use with [RFC6522]. The media type suitable for use as a report-type is defined in the following section."

IANA Question --> In what registry should this registration be made? In the MIME Media Type Sub-Parameter Registries there is no sub-parameter registry for multipart/report media type. And, IANA has made no new registrations as a result of RFC 6522.

Third, in the application registry on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

the following registration will be made:

Name: tlsrpt+json
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Fourth, also in the application registry on the Media Types registry page located at:

https://www.iana.org/assignments/media-types/

the following registration will be made:

Name: tlsrpt+gzip
Template: [ TBD-at-Registration ]
Reference: [ RFC-to-be ]

Fourth, a new registry is to be created called the STARTTLS Validation Result Types. The new registry will be managed via Expert Review as defined in RFC 8126.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

There are initial registrations in the new registry as follows:

+-------------------------------+---------------+
| Result Type | Reference |
+-------------------------------+---------------+
| "starttls-not-supported" | [ RFC-to-be ] |
| "certificate-host-mismatch" | [ RFC-to-be ] |
| "certificate-expired" | [ RFC-to-be ] |
| "tlsa-invalid" | [ RFC-to-be ] |
| "dnssec-invalid" | [ RFC-to-be ] |
| "dane-required" | [ RFC-to-be ] |
| "certificate-not-trusted" | [ RFC-to-be ] |
| "sts-policy-invalid" | [ RFC-to-be ] |
| "sts-webpki-invalid" | [ RFC-to-be ] |
| "validation-failure" | [ RFC-to-be ] |
+-------------------------------+---------------+

IANA Question --> are the quotation marks to remain around each text string in the Result Type field?

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist
2018-03-12
17 Alexey Melnikov Placed on agenda for telechat - 2018-04-19
2018-03-08
17 Joel Halpern Request for Last Call review by GENART Completed: Almost Ready. Reviewer: Joel Halpern. Sent review to list.
2018-03-08
17 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2018-03-08
17 Jean Mahoney Request for Last Call review by GENART is assigned to Joel Halpern
2018-03-08
17 Phillip Hallam-Baker Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Phillip Hallam-Baker. Sent review to list.
2018-03-08
17 Tero Kivinen Request for Last Call review by SECDIR is assigned to Phillip Hallam-Baker
2018-03-08
17 Tero Kivinen Request for Last Call review by SECDIR is assigned to Phillip Hallam-Baker
2018-03-07
17 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Carlos Martinez
2018-03-07
17 Gunter Van de Velde Request for Last Call review by OPSDIR is assigned to Carlos Martinez
2018-03-05
17 Amy Vezza IANA Review state changed to IANA - Review Needed
2018-03-05
17 Amy Vezza
The following Last Call announcement was sent out (ends 2018-04-02):

From: The IESG
To: IETF-Announce
CC: uta-chairs@ietf.org, draft-ietf-uta-smtp-tlsrpt@ietf.org, uta@ietf.org, Leif Johansson , …
The following Last Call announcement was sent out (ends 2018-04-02):

From: The IESG
To: IETF-Announce
CC: uta-chairs@ietf.org, draft-ietf-uta-smtp-tlsrpt@ietf.org, uta@ietf.org, Leif Johansson , valery@smyslov.net, Valery Smyslov , alexey.melnikov@isode.com
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (SMTP TLS Reporting) to Proposed Standard


The IESG has received a request from the Using TLS in Applications WG (uta)
to consider the following document: - 'SMTP TLS Reporting'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-04-02. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  A number of protocols exist for establishing encrypted channels
  between SMTP Mail Transfer Agents, including STARTTLS, DANE TLSA, and
  MTA-STS.  These protocols can fail due to misconfiguration or active
  attack, leading to undelivered messages or delivery over unencrypted
  or unauthenticated channels.  This document describes a reporting
  mechanism and format by which sending systems can share statistics
  and specific information about potential failures with recipient
  domains.  Recipient domains can then use this information to both
  detect potential attackers and diagnose unintentional
  misconfigurations.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-tlsrpt/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-tlsrpt/ballot/


No IPR declarations have been submitted directly on this I-D.




2018-03-05
17 Amy Vezza IESG state changed to In Last Call from Last Call Requested
2018-03-05
17 Amy Vezza Last call announcement was changed
2018-03-05
17 Alexey Melnikov Last call was requested
2018-03-05
17 Alexey Melnikov Last call announcement was generated
2018-03-05
17 Alexey Melnikov Ballot approval text was generated
2018-03-05
17 Alexey Melnikov Ballot writeup was generated
2018-03-05
17 Alexey Melnikov Dear Secretariat, please initiate 4 weeks IETF LC to cover for IETF in London.
2018-03-05
17 Alexey Melnikov IESG state changed to Last Call Requested from AD Evaluation
2018-03-05
17 Alexey Melnikov IESG state changed to AD Evaluation from Publication Requested
2018-03-05
17 Valery Smyslov
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  …
(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  Proposed Standard as indicated on the title page header and in the
  datatracker.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  A number of protocols exist for establishing encrypted channels
  between SMTP Mail Transfer Agents, including STARTTLS, DANE TLSA, and
  MTA-STS.  These protocols can fail due to misconfiguration or active
  attack, leading to undelivered messages or delivery over unencrypted
  or unauthenticated channels.  This document describes a reporting
  mechanism and format by which sending systems can share statistics
  and specific information about potential failures with recipient
  domains.  Recipient domains can then use this information to both
  detect potential attackers and diagnose unintentional
  misconfigurations.


Working Group Summary

  The WG consensus for adoption this draft was strong and the core of
  the draft remained stable from the first version. Most discussions in the WG
  were concerned with clarifications and with supporting of additional
  features like automated parsing of MIME headers. The MIME encoding
  of TLS report was discussed a lot with WG members changing their opinions.
  The draft has passed through two WGLCs and I think that overall it has
  received enough scrutiny from reviewers.

Document Quality

  To my knowledge there are no implementations of this draft to date.
  However all the authors expressed a desire to implement it
  and some implementations are under way.

Personnel

  Who is the Document Shepherd? Who is the Responsible Area
  Director?

  Valery Smyslov (shepherd)
  Alexey Melnikov (AD)

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  I have reviewed the document and found it ready.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  No. The document was a subject of several detailed reviews
  from implementers and other WG members.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  No but an expert ABNF review would be useful.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  None.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No IPR disclosure has been filed that reference this document.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  The WG consensus is solid.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  There are two lines in the draft that are too long (in policy samples),
  this can be handled by RFC Editor. There is also one usage of domain name
  that doesn't follow RFC 2606 recommendations ("mx.backup-example.com").

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  None are applicable as far as I can see but an ABNF review
  would be useful.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  A new registry is created - "STARTTLS Validation Result Types".
  The registry is created using the expert review policy
  and is consistent with the document and clearly defined.
  Two new items are registered in the "Permanent Message Header Field" registry.
  Two new media types are registered. In addition a new parameter is registered
  under "multipart/report" top level media type. The requirements
  for the registries are fulfilled.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  The "STARTTLS Validation Result Types" registry.
  Pick experts that have a solid history and knowledge in TLS, DANE and email
  deployment. One possible name is Viktor Dukhovni .

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  Bill Fenners ABNF checker shows no errors on the ABNF definitions included in the draft.

2018-03-05
17 Valery Smyslov Responsible AD changed to Alexey Melnikov
2018-03-05
17 Valery Smyslov IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2018-03-05
17 Valery Smyslov IESG state changed to Publication Requested
2018-03-05
17 Valery Smyslov IESG process started in state Publication Requested
2018-03-05
17 Valery Smyslov Tag Revised I-D Needed - Issue raised by WGLC cleared.
2018-03-05
17 Valery Smyslov Changed document writeup
2018-03-05
17 Alex Brotman New version available: draft-ietf-uta-smtp-tlsrpt-17.txt
2018-03-05
17 (System) New version approved
2018-03-05
17 (System) Request for posting confirmation emailed to previous authors: Janet Jones , Alexander Brotman , Mark Risher , Daniel Margolis , Binu Ramakrishnan
2018-03-05
17 Alex Brotman Uploaded new revision
2018-03-04
16 Alex Brotman New version available: draft-ietf-uta-smtp-tlsrpt-16.txt
2018-03-04
16 (System) New version approved
2018-03-04
16 (System) Request for posting confirmation emailed to previous authors: Janet Jones , Alexander Brotman , Mark Risher , Daniel Margolis , Binu Ramakrishnan
2018-03-04
16 Alex Brotman Uploaded new revision
2018-03-01
15 Valery Smyslov Tag Revised I-D Needed - Issue raised by WGLC set. Tag Other - see Comment Log cleared.
2018-03-01
15 Valery Smyslov IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2018-02-21
15 Valery Smyslov Second WGLC.
2018-02-21
15 Valery Smyslov Tag Other - see Comment Log set.
2018-02-21
15 Valery Smyslov IETF WG state changed to In WG Last Call from WG Consensus: Waiting for Write-Up
2018-02-19
15 Alex Brotman New version available: draft-ietf-uta-smtp-tlsrpt-15.txt
2018-02-19
15 (System) New version approved
2018-02-19
15 (System) Request for posting confirmation emailed to previous authors: Janet Jones , Alexander Brotman , Mark Risher , Daniel Margolis , Binu Ramakrishnan
2018-02-19
15 Alex Brotman Uploaded new revision
2018-01-28
14 Valery Smyslov Notification list changed to Leif Johansson <leifj@sunet.se>, Valery Smyslov <valery@smyslov.net> from Leif Johansson <leifj@sunet.se>
2018-01-28
14 Valery Smyslov Document shepherd changed to Valery Smyslov
2018-01-26
14 Alex Brotman New version available: draft-ietf-uta-smtp-tlsrpt-14.txt
2018-01-26
14 (System) New version approved
2018-01-26
14 (System) Request for posting confirmation emailed to previous authors: uta-chairs@ietf.org, Binu Ramakrishnan , Alexander Brotman , Mark Risher , Janet Jones , Daniel Margolis
2018-01-26
14 Alex Brotman Uploaded new revision
2017-12-04
13 Daniel Margolis New version available: draft-ietf-uta-smtp-tlsrpt-13.txt
2017-12-04
13 (System) New version approved
2017-12-04
13 (System) Request for posting confirmation emailed to previous authors: uta-chairs@ietf.org, Binu Ramakrishnan , Alexander Brotman , Mark Risher , Janet Jones , Daniel Margolis
2017-12-04
13 Daniel Margolis Uploaded new revision
2017-12-04
12 Daniel Margolis New version available: draft-ietf-uta-smtp-tlsrpt-12.txt
2017-12-04
12 (System) New version approved
2017-12-04
12 (System) Request for posting confirmation emailed to previous authors: uta-chairs@ietf.org, Binu Ramakrishnan , Alexander Brotman , Mark Risher , Janet Jones , Daniel Margolis
2017-12-04
12 Daniel Margolis Uploaded new revision
2017-11-16
11 Leif Johansson Changed consensus to Yes from Unknown
2017-11-16
11 Leif Johansson Intended Status changed to Proposed Standard from None
2017-11-16
11 Leif Johansson Notification list changed to Leif Johansson <leifj@sunet.se>
2017-11-16
11 Leif Johansson Document shepherd changed to Leif Johansson
2017-11-09
11 Cindy Morgan New version available: draft-ietf-uta-smtp-tlsrpt-11.txt
2017-11-09
11 (System) Secretariat manually posting. Approvals already received
2017-11-09
11 Cindy Morgan Uploaded new revision
2017-09-28
10 Alex Brotman New version available: draft-ietf-uta-smtp-tlsrpt-10.txt
2017-09-28
10 (System) New version approved
2017-09-28
10 (System) Request for posting confirmation emailed to previous authors: Alexander Brotman , Binu Ramakrishnan , Mark Risher , uta-chairs@ietf.org, Janet Jones , Daniel Margolis
2017-09-28
10 Alex Brotman Uploaded new revision
2017-09-28
09 Leif Johansson IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2017-09-05
09 Alex Brotman New version available: draft-ietf-uta-smtp-tlsrpt-09.txt
2017-09-05
09 (System) New version approved
2017-09-05
09 (System) Request for posting confirmation emailed to previous authors: Alexander Brotman , Binu Ramakrishnan , Mark Risher , uta-chairs@ietf.org, Janet Jones , Daniel Margolis
2017-09-05
09 Alex Brotman Uploaded new revision
2017-08-15
08 Alex Brotman New version available: draft-ietf-uta-smtp-tlsrpt-08.txt
2017-08-15
08 (System) New version approved
2017-08-15
08 (System) Request for posting confirmation emailed to previous authors: Alexander Brotman , Binu Ramakrishnan , Mark Risher , uta-chairs@ietf.org, Janet Jones , Daniel Margolis
2017-08-15
08 Alex Brotman Uploaded new revision
2017-07-31
07 Alex Brotman New version available: draft-ietf-uta-smtp-tlsrpt-07.txt
2017-07-31
07 (System) New version approved
2017-07-31
07 (System) Request for posting confirmation emailed to previous authors: Alexander Brotman , Daniel Margolis
2017-07-31
07 Alex Brotman Uploaded new revision
2017-07-12
06 Leif Johansson IETF WG state changed to In WG Last Call from WG Document
2017-05-31
06 Alex Brotman New version available: draft-ietf-uta-smtp-tlsrpt-06.txt
2017-05-31
06 (System) New version approved
2017-05-31
06 (System) Request for posting confirmation emailed to previous authors: Alexander Brotman , Daniel Margolis , uta-chairs@ietf.org
2017-05-31
06 Alex Brotman Uploaded new revision
2017-05-04
05 Alexey Melnikov
Updated review for -05:

In Section 1:

  Specifically, this document defines a reporting schema that covers
  failures in routing, STARTTLS negotiation, and both …
Updated review for -05:

In Section 1:

  Specifically, this document defines a reporting schema that covers
  failures in routing, STARTTLS negotiation, and both DANE [RFC6698]
  and MTA-STS (TODO: Add ref) policy validation errors, and a standard

Such references should be fixed. Which format are you using for editing the document?

  TXT record that recipient domains can use to indicate where reports
  in this format should be sent.

  This document is intended as a companion to the specification for
  SMTP MTA Strict Transport Security (MTA-STS, TODO: Add ref).

In 1.1:

TLS needs a reference.


In Section 2:

I think I liked your earlier text about DMARC a bit better.
You list related technologies, but don't mention how they relate to this document or why you need a new format. Can you add a sentence or two on this? After reading this section my initial reaction is "why on Earth you are not using/extending one of existing mechanisms?".

In Section 3:

HTTPS needs to be updated to point to [one of] the latest HTTP/1.1 RFC.

mailto: URI needs a Normative Reference to RFC 6068.



In Section 4.3

Is the list of result types extensible? If yes, you should create a new IANA registry, so that people can add new values, without the need to update this document.


4.3.3.  General Failures

  When a negotiation failure can not be categorized into one of the
  "Negotiation Failures" stated above, the reporter SHOULD use the
  "validation-failure" category.  As TLS grows and becomes more
  complex, new mechanisms may not be easily categorized.  This allows
  for a generic feedback category.  When this category is used, the
  reporter SHOULD also use the "failure-reason-code" to give some
  feedback to the receiving entity.  This is intended to be a short
  text field, and the contents of the field should be an error code or
  error text, such as "X509_V_ERR_UNHANDLED_CRITICAL_CRL_EXTENSION".

Is this field human readable? If yes, then it would be good to add an option language tag for it.


In Section 5.3:

Why not define new email header fields? Encoding everything in Subject looks rather hackish.

Also, why not define new JSON-based MIME type for reports (e.g. application/tlsrpt+json and a similar one for gzip)? This will make it easier to process reports of different type addressed to the same email recipient.

You should also consider using multipart/report container with the second part being application/tlsrpt+json (or gzip variant) and no 3rd body part.


Section 9:

As this section is pretty much the most important section in the document, I am surprised that it is marked as Appendix. As a general comment, I think this section would benefit from more clarity about various syntaxes used. Some specific comments:

  o  "policy-type": The type of policy that was applied by the sending
      domain.  Presently, the only three valid choices are "tlsa",
      "sts", and the literal string "no-policy-found".  It is provided
      as a string.

Is this field case sensitive? If yes, it would be good to say so.

  o  "policy-string": The JSON string serialization ([RFC7159] section
      7) of the policy, whether TLSA record ([RFC6698] section 2.3) or
      MTA-STS policy.

This is underspecified. Need to have at least an example of TLSA record and MTA-STS policy.
(TLSA record has multiple fields, so it is important to know which ones are included.)

  o  "domain": The Policy Domain upon which the policy was applied.
      For messages sent to "user at example.com" this field would contain
      "example.com".  It is provided as a string.

Again, need references here. Are IDN domains (in UTF-8) allowed here?

  o  "ip-address": The IP address of the sending MTA that attempted the
      STARTTLS connection.  It is provided as a string representation of
      an IPv4 or IPv6 address in dot-decimal or colon-hexadecimal
      notation.

Need references for string representations of both types of IP addresses.
2017-05-04
05 Alexey Melnikov My early AD review on -04:

https://www.ietf.org/mail-archive/web/uta/current/msg01969.html
2017-05-04
05 Alex Brotman New version available: draft-ietf-uta-smtp-tlsrpt-05.txt
2017-05-04
05 (System) New version approved
2017-05-04
05 (System) Request for posting confirmation emailed to previous authors: Alexander Brotman , Daniel Margolis , uta-chairs@ietf.org
2017-05-04
05 Alex Brotman Uploaded new revision
2017-04-05
04 Alex Brotman New version available: draft-ietf-uta-smtp-tlsrpt-04.txt
2017-04-05
04 (System) New version approved
2017-04-05
04 (System) Request for posting confirmation emailed to previous authors: Alexander Brotman , Daniel Margolis , uta-chairs@ietf.org
2017-04-05
04 Alex Brotman Uploaded new revision
2017-02-15
03 Alex Brotman New version available: draft-ietf-uta-smtp-tlsrpt-03.txt
2017-02-15
03 (System) New version approved
2017-02-15
03 (System) Request for posting confirmation emailed to previous authors: "Daniel Margolis" , "Alexander Brotman" , uta-chairs@ietf.org
2017-02-15
03 Alex Brotman Uploaded new revision
2016-12-15
02 Alex Brotman New version available: draft-ietf-uta-smtp-tlsrpt-02.txt
2016-12-15
02 (System) New version approved
2016-12-15
02 (System) Request for posting confirmation emailed to previous authors: uta-chairs@ietf.org, "Janet Jones" , "Binu Ramakrishnan" , "Alexander Brotman" , "Daniel Margolis" , "Mark Risher"
2016-12-15
02 Alex Brotman Uploaded new revision
2016-07-18
01 Orit Levin Added to session: IETF-96: uta  Tue-1620
2016-07-09
01 Mark Risher New version available: draft-ietf-uta-smtp-tlsrpt-01.txt
2016-05-14
00 Orit Levin This document now replaces draft-brotman-smtp-tlsrpt instead of None
2016-05-14
00 Alex Brotman New version available: draft-ietf-uta-smtp-tlsrpt-00.txt