SMTP TLS Reporting
RFC 8460

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

(Ben Campbell) (was Discuss) Yes

Comment (2018-04-19 for -18)
No email
send info
[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.

Alexey Melnikov Yes

Comment (2018-05-22 for -21)
No email
send info
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?

Adam Roach Yes

Comment (2018-04-18 for -18)
No email
send info
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.

Ignas Bagdonas No Objection

Deborah Brungard No Objection

Alissa Cooper No Objection

Comment (2018-04-18 for -18)
No email
send info
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).

(Spencer Dawkins) No Objection

Benjamin Kaduk No Objection

Comment (2018-04-16 for -18)
No email
send info
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.

Suresh Krishnan No Objection

Comment (2018-04-17 for -18)
No email
send info
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

Warren Kumari (was Discuss) No Objection

Comment (2018-04-16 for -18)
No email
send info
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.

Mirja Kühlewind No Objection

Comment (2018-04-18 for -18)
No email
send info
Maybe add "Aggregate report URI (rua)" to the terminology section.

(Terry Manderson) No Objection

(Eric Rescorla) No Objection

Comment (2018-04-15 for -18)
No email
send info
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"

Alvaro Retana No Objection

Martin Vigoureux No Objection