Jim,

To be clear, you'd like to remove the headers (5.3) and filename (5.1) 
sections, and have all the filtering based solely on the subject that is 
specified in 5.3?  And relating to "draft-ietf-dnsop-attrleaf", could you 
clarify that a bit?  Are you asking me to request an alteration of the attrleaf 
document after TLSRPT has been created?

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

Reply via email to