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

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.

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

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.

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"

Maybe add "Aggregate report URI (rua)" to the terminology section.

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