SMTP TLS Reporting
draft-ietf-uta-smtp-tlsrpt-23

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)

[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?

[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

[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.

[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.

[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).

[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.

[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

[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.

[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.

[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.

[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.

[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.

[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.

[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"

[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.

(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

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.

(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.

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.