I'm working through the rest of the alterations.
--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast
-----Original Message-----
From: Uta [mailto:uta-boun...@ietf.org] On Behalf Of Jim Fenton
Sent: Thursday, August 03, 2017 5:11 PM
To: uta@ietf.org
Subject: Re: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06
In response to Leif's request for specific text for the larger issues:
On 7/31/17 4:02 PM, Jim Fenton wrote:
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.
I agree that the MTA-STS reference is informative. By my reading, the following
RFC references are also informative:
3207, 3501, 3864, 7435, 7469, 7489
But check me on those...
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 3, third bullet:
o In the case of "https", reports SHOULD be submitted via POST
([RFC2818]) to the specified URI. Report submitters MAY ignore certificate
verification errors when submitting reports via https.
Section 4.3.2.1, dnssec-invalid: In this case, would the TLSRPT policy
be found?
Maybe just note this situation; add the following text to this bullet:
Note that DNSSEC failures are likely to also affect the retrieval of the TLSRPT
record, so reports with this failure are likely to be rare in practice.
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.
I suggest eliminating this requirement.
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., repo...@example.org or reports+clie...@example.org
for a service provider) in order to distinguish reports from other traffic.
I suggest eliminating this requirement.
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.
6.6. _smtp-tlsrpt DNS Global Underscore Scoped Registry Entry
This document registers a new DNS name in the "DNS Global Underscore Scoped Entry
Registry" as follows:
Scoped Entry: _smtp-tlsrpt
Applicable protocol: SMTP
Status: standard
Author/Change controller: IETF
Specification document(s): This document
Note that this registry is created by the publication of
draft-ietf-dnsop-attrleaf. If this document precedes it in publication, the
entry is requested to be included in the registry at its creation.
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 4.1:
The report SHOULD cover a full day (24 hours). In order to avoid congestion
caused by synchronized transmission and receipt of reports, report senders
SHOULD choose an arbitrary time to send their reports, either individually or
as a group. The transmission time MAY be determined, for example, by hashing
the reporting domain name, taking the result modulo 1440, and sending reports
at that many minutes past midnight UTC each day.
In Section 7: (original text is OK here too if you prefer, but suggest including the
"More broadly" sentence)
Reports as DDoS: TLSRPT allows specifying destinations for reports that are
outside the authority of the Policy Domain, which allows domains to delegate
processing of reports to a partner organization. However, an attacker who
controls a Policy Domain DNS could also use this mechanism to direct the
reports to an unwitting victim, flooding that victim with excessive reports.
More broadly, the publication of a reporting email address or URI presents the
opportunity for the addresses to be harvested and used as the target of a DoS
or DDoS attack. DMARC [RFC7489] defines a solution for verifying delegation to
avoid such attacks, which is an effective countermeasure for innocent
third-party senders of reports, but TLSRPT has less need for a verification
mechanism because it would require the attacker to induce the innocent third
party to send mail to the attacker.
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?
Add to Section 7:
Deceptive reports: TLSRPT supports the processing of reports from arbitrary
sources. As such, the data in the reports may be incorrect or even
intentionally deceptive. Report recipients need to be aware of and prepared to
handle this situation.
Add to bullet 4 of Section 3:
Reports sent via SMTP MUST contain a valid DKIM [RFC6376] signature by the
reporting domain. Reports lacking such a signature MUST be ignored by the
recipient.
(add normative reference to RFC6376)
(note that we still have a problem authenticating https reports, unless
client-authenticated TLS is required, which would be an onerous requirement).
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
