Subject: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06

From: Leif Johansson <[email-masked]>
Date: Wed, 12 Jul 2017 12:11:15 +0200

This starts a 3 week working group last call (WGLC) on
draft-ietf-uta-smtp-tlsrpt-06. Please provide your comments to the list
by Wednesday
August 2nd.

	Best R
	Leif & Orit

---

From: "Chris Newman" <[email-masked]>
Date: Thu, 20 Jul 2017 14:28:19 +0200

>    The report is composed as a plain text file encoded in the JSON
>   format ([RFC7159]).

Can we use I-JSON format instead? RFC 7493. I'd prefer if the report is 
encoded in UTF-8 rather than an arbitrary Unicode encoding that the 
recipient has to dynamically detect.

>   o  "email-address": The contact information for a responsible party
>      of the report.  It is provided as a string formatted according to
>      Section 3.4.1, "Addr-Spec", of [RFC5322].

Can we format according to the "Mailbox" rule in section 4.1.2 of 
[RFC5321]? I'd prefer not to require receivers to strip out FWS & CFWS 
from the address.

>     tlsrpt-subject = %x52.65.70.6f.72.74 1*FWS       ; "Report"
>                      %x44.6f.6d.61.69.6e.3a 1*FWS    ; "Domain:"
>                      domain-name 1*FWS               ; from RFC 6376
>                      %x53.75.62.6d.69.74.74.65.72.3a ; "Submitter:"
>                      1*FWS domain-name 1*FWS
>                      %x52.65.70.6f.72.74.2d.49.44.3a ; "Report-ID:"
>                      msg-id                          ; from RFC 5322

Where is 'FWS' defined? If it's the FWS from RFC 5322, then you need to 
change "1*FWS" to "FWS" in all 5 places.

Can you please reference RFC 7405 to improve readability, so this can be 
rewritten as:

  tlsrpt-subject = %s"Report" FWS %s"Domain:" FWS domain-name
                   %s"Submitter:" FWS domain-name FWS
                   %s"Report-ID:" msg-id

Also, you might want to instead use:
    %s"Report-ID" FWS "<" id-left "@" id-right ">" [CFWS]

so there's no need to skip over comments (CFWS) to extract the report 
id.

		- Chris

---

From: Jim Fenton <[email-masked]>
Date: Mon, 31 Jul 2017 16:02:08 -0700

> draft-ietf-uta-smtp-tlsrpt-06. Please provide your comments to the list
General comments:

All of the references are listed as normative, which I strongly suspect
isn't really the case. Informative references need to be separated.

As the document notes, the reference for MTA-STS needs to be added. If
it is a normative reference, this document will be held up until that is
published.

Section 3, what happens in the case of HTTPS delivery of reports if
there is some problem with the certificate presented by the server? For
mailto:, it explicitly states that the message should be sent in the
clear if necessary, but that doesn't seem to be the case with https:.

Section 4.3.2.1, dnssec-invalid: In this case, would the TLSRPT policy
be found?

Section 5.1, I don't like the idea of associating semantics with the
filename of MIME parts. As it's written, use of the specified filename
format is optional, so the recipient can't depend on it anyway. DMARC
does this, and I didn't like it there either, but it's an informational
document so this may not have gotten all the scrutiny this should as a
standards-track document.

Section 5.3, I don't think it's a good idea to define and require new
message header fields for this. This means that some of the
general-purpose libraries for sending email messages can't be used. A
better approach IMO would be to suggest the use of separate email
addresses (e.g., [email-masked] or [email-masked] for
a service provider) in order to distinguish reports from other traffic.

IANA considerations: Consider adding a request to register _smtp-tlsrpt
in the registry being created by draft-ietf-dnsop-attrleaf if that
registry is created before this is published.

Section 7, Reports as DDoS: The discussion revolves around the fact
that, unlike DMARC, there isn't a third party involved in a DMARC report
so it isn't necessary to validate delegation. I'm not sure this
completely alleviates the DDoS risk, though: it's equally possible for
malicious second parties to overload the receiver with reports, or for
malicious parties to look around for TLSRPT policies with mailto:
addresses and just spam them. It might be good to acknowledge that
possibility here. Also, the suggestion of sending the messages daily for
0000-2400 UTC (section 4.1) does not scale well, and may be a DDoS in
itself.

Section 7, additional consideration: The "untrusted content"
consideration talks about malicious code, but attackers could also send
counterfeit reports that look real in an effort to confuse the report
recipient. Should valid DKIM signatures from the reporting domain be
required on TLSRPT messages?

Detailed comments and nits:

1.1 last bullet: initiating the delivery -> initiating the transmission

3. in tlsrpt-uri: [@!RFC3986] -> [RFC3986]
        What is the "numeric portion" that is referred to here?

4. bullet 2a "neither a TLSA nor MTA-STS policy" -> "neither a DANE nor
MTA-STS policy"

5.1 "The filename is typically constructed": Is that a MAY? SHOULD?
DMARC uses this wording, but it's informational.
        Following the ABNF, "json.gz": The IANA considerations section
lists this is .gz. And the MUST here is confusing, is this only if the
filename is 'typically constructed' or always?

5.3 The [RFC5322].Subject field for individual report submissions: There
isn't an "individual" report defined here. Looks like this is left over
from DMARC.

5.4 should use the media type -> SHOULD use the media type

5.5 should be on a logarithmic scale -> SHOULD be on a logarithmic scale
(do MTAs typically do this, or is it calling for something special?)

Sections 8 and 9 should be renumbered as appendices, and marked as
informative examples.

-Jim