(As a participant)

On 09/08/2017 14:07, Brotman, Alexander wrote:

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?
I don't think Jim made a convincing argument for removing new header fields. From my personal experience writing IMAP based applications that search for this information (e.g. to search and process "all reports from a particular domain") is easier with new header fields than doing a search on a Subject which has complicated structure. This has nothing to do with whether the same mailbox receives multiple types of email messages, this is still a useful functionality if a particular mailbox receives only TLSRPT reports.

As per my followup discussion with Jim libraries for generating messages need to be able to add new header fields anyway. If people have real world experience about whether this is problematic, I would like to hear it.

Regarding filenames - I am ambivalent. If you need this information somewhere, you will need to define new header fields as well.

   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 
(As Area Director)
Yes. Depending on which documents gets to IESG first, the last one should include the information.

Best Regards,
I'm working through the rest of the alterations.

Alex Brotman
Sr. Engineer, Anti-Abuse

-----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, 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
0000-2400 UTC (section 4.1) does not scale well, and may be a DDoS in
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 

(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 mailing list

Uta mailing list

Reply via email to