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

From: Alexey Melnikov <[email-masked]>
Date: Tue, 1 Aug 2017 10:11:25 +0100

Jim,
I would like to disagree:

> On 1 Aug 2017, at 00:02, Jim Fenton <[email-masked]> wrote:
> 
> 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.

Do you mean that a general purpose library is unable to add arbitrary header fields? This doesn't seem to qualify as "general purpose".

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

This is already possible.

Best Regards,
Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 1 Aug 2017 10:12:50 +0100

> 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 think it is Informative.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 1 Aug 2017 10:14:06 +0100

> 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?

+1

---

From: Daniel Margolis <[email-masked]>
Date: Tue, 1 Aug 2017 14:21:32 -0400

Hey, Jim. Few points:

On Mon, Jul 31, 2017 at 7:02 PM, Jim Fenton <[email-masked]> wrote:

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

Heh. It's a good point. But a sender can of course choose not to validate
DNSSEC for the destination domain when looking up the TLSRPT record (and
potentially MX records used for TLSRPT delivery). It seems unlikely to be
the common case--misconfiguring your DS record or signing keys (as opposed
to your TLSA records) is quite likely to result in mail never being
delivered because MX records effectively fail to resolve--but it's
hypothetically possible for a sender to still send TLSRPT reports from a
client whose resolver does not validate, and we leave that possibility open
by having this error type.

> 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's certainly possible that merely running a mail service opens you up to
a DoS. But TLSRPT with mailto: endpoints doesn't (I would contend)
exacerbate the risk, in that we assume anyone running a mailto: endpoint
for TLSRPT is probably already running a mail service. The point of that
paragraph is really to explain why DMARC's misdirected-reports attack
doesn't apply; without that attack, the only concern is the generic case of
"you're running a mail server and might get unwanted mail." Which is true,
but isn't new attack surface induced by TLSRPT.

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

I think your point is that while it may make sense to send daily reports,
they should not necessarily be *synchronized*--i.e. the mail covering the
period 00:00 - 24:00 should not be sent at 24:00. That's a fair point and
maybe worth being called out, I agree.

> 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
>
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: Jim Fenton <[email-masked]>
Date: Tue, 1 Aug 2017 11:41:05 -0700

> Do you mean that a general purpose library is unable to add arbitrary header fields? This doesn't seem to qualify as "general purpose".

"General purpose" was the wrong phrase. My suspicion was that
higher-level libraries for easily sending an email message from a
program wouldn't necessarily support adding arbitrary email header
fields. But I did a bit more research, and the ones I have found do
allow addition of arbitrary header fields.

> This is already possible.

Yes, and for this reason the requirement to add new message header
fields seems gratuitous. I expect reports will be separated by
destination address rather than using IMAP filters, the latter being
given as the motivation for the new header fields.

-Jim

---

From: Leif Johansson <[email-masked]>
Date: Tue, 1 Aug 2017 21:36:01 +0200

> Hey, Jim. Few points:

Jim - if you can suggest text on any of your non-nit issues that might
make it easier to zero in on a final version of this.

	Cheers Leif

> 
> On Mon, Jul 31, 2017 at 7:02 PM, Jim Fenton <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
> 
> Heh. It's a good point. But a sender can of course choose not to
> validate DNSSEC for the destination domain when looking up the TLSRPT
> record (and potentially MX records used for TLSRPT delivery). It seems
> unlikely to be the common case--misconfiguring your DS record or signing
> keys (as opposed to your TLSA records) is quite likely to result in mail
> never being delivered because MX records effectively fail to
> resolve--but it's hypothetically possible for a sender to still send
> TLSRPT reports from a client whose resolver does not validate, and we
> leave that possibility open by having this error type.
>  
> 
> It's certainly possible that merely running a mail service opens you up
> to a DoS. But TLSRPT with mailto: endpoints doesn't (I would contend)
> doesn't apply; without that attack, the only concern is the generic case
> of "you're running a mail server and might get unwanted mail." Which is
> true, but isn't new attack surface induced by TLSRPT. 
>  
>  
> 
> I think your point is that while it may make sense to send daily
> reports, they should not necessarily be /synchronized/--i.e. the mail
> covering the period 00:00 - 24:00 should not be sent at 24:00. That's a
> fair point and maybe worth being called out, I agree. 
>  
> 
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/uta>
> 
> 
> 
>

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 1 Aug 2017 21:02:03 +0100

> given as the motivation for the new header fields.

Not really, abusing Subject to encode this information is a hack. So
these header fields are useful even only if one type of report goes to a
particular email mailbox, because it is easy to separate specific
reports by domains, etc. programmatically, for example using IMAP.

---

From: Jim Fenton <[email-masked]>
Date: Tue, 1 Aug 2017 13:08:04 -0700

> reports by domains, etc. programmatically, for example using IMAP.

I don't think I was suggesting anything involving Subject. There's
already some of this in Section 5.3, and I'm not crazy about doing that
either, especially since it's only a SHOULD (so the report recipient
can't really depend on it being formatted that way).

---

From: Leif Johansson <[email-masked]>
Date: Wed, 2 Aug 2017 07:17:33 +0200

> can't really depend on it being formatted that way).

On the contrary. A SHOULD basically means you follow the spec unless
you have a good reason not to do so.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 2 Aug 2017 21:43:03 +0100

On 20/07/2017 13:28, Chris Newman wrote:
>>   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.

I think this change would be a good idea.

---

From: Jim Fenton <[email-masked]>
Date: Wed, 2 Aug 2017 22:01:40 -0700

> you have a good reason not to do so.

In this case, you're depending on all of the domains that send TLS
reports not to have a good reason not to do so. Maybe I'm just
extra-careful, but I don't know what good reasons might come up (maybe
some agent rewriting the Subject header field?) so I would be inclined
to not depend on it. If this Subject header field formatting stands, is
there some requirement that the requirement isn't a MUST (like the
TLS-Report-* header fields)?

Even so, recipients need to be able to handle any Subject header field
that anyone throws at them, at least to discard those messages and not
otherwise fail. For that reason, I think it's a good idea to minimize
the number of things that require robust checking. Isn't this
information in the payload of the report anyway? I'm not a fan of
redundant information that can be inconsistent.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Thu, 3 Aug 2017 14:11:17 -0700

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

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

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.
> general-purpose libraries for sending email messages can't be used. A
> better approach IMO would be to suggest the use of separate email

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.
> addresses and just spam them. It might be good to acknowledge that
> possibility here. Also, the suggestion of sending the messages daily for

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.

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

---

From: Leif Johansson <[email-masked]>
Date: Fri, 4 Aug 2017 10:59:03 +0200

Thx!

Skickat från min iPhone

> 3 aug. 2017 kl. 23:11 skrev Jim Fenton <[email-masked]>:
>

---

From: "Brotman, Alexander" <[email-masked]>
Date: Wed, 9 Aug 2017 13:07:16 +0000

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:[email-masked]] On Behalf Of Jim Fenton
Sent: Thursday, August 03, 2017 5:11 PM
To: [email-masked]
Subject: Re: [Uta] WGLC on draft-ietf-uta-smtp-tlsrpt-06

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

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.

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

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

This document registers a new DNS name in the "DNS Global Underscore Scoped Entry Registry" as follows:

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

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.

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

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.

(note that we still have a problem authenticating https reports, unless client-authenticated TLS is required, which would be an onerous requirement).

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 9 Aug 2017 14:33:49 +0100

Hi,

(As a participant)

On 09/08/2017 14:07, Brotman, Alexander wrote:
> 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?
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 created?
(As Area Director)
Yes. Depending on which documents gets to IESG first, the last one 
should include the information.

Best Regards,
Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 9 Aug 2017 14:39:50 +0100

A few more comments on filenames:

> somewhere, you will need to define new header fields as well.

In IMAP filename Content-Disposition parameter is returned as a part of 
BODYSTRUCTURE. This means that it is easy to extract this information 
algorithmically in one round trip, without the need to downaload and 
parse the whole report message. I am not saying that filename is the 
best thing, but this is a nice property. If people think that this type 
of information should be easy to retrieve through IMAP, there are other 
ways that are IMAP-friendly. For example making this a new parameter to 
Content-Disposition header field would still work (it is also returned 
in BODYSTRUCTURE).

Best Regards,
Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 9 Aug 2017 14:47:16 +0100

Hi Jim,

On 03/08/2017 06:01, Jim Fenton wrote:

> otherwise fail.
This is true.

> For that reason, I think it's a good idea to minimize

Yes, this information is available in the JSON report itself, but it is 
hard to extract without downloading and parsing the whole report. If one 
writes an application which is mindful of bandwidth it is using (e.g. 
using IMAP) and such application wants to find all reports that have a 
particular property (e.g. all reports from or about a particular 
domain), it is more bandwidth and CPU efficient to extract this 
information from some header fields.

Best Regards,
Alexey

---

From: Jim Fenton <[email-masked]>
Date: Wed, 9 Aug 2017 10:02:16 -0700

On 8/9/17 6:33 AM, Alexey Melnikov 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?
> 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.
>
>

I'll leave it up to the rough consensus of the WG. But my expectation is
that the vast majority of TLSRPT mail will be directed to addresses only
used for that purpose, and then piped directly into an agent that does
something with them -- probably stuff the data into a database, which is
then used to generate composite reports for the domain. IMAP won't be
involved at all, and filtering will be done only by database lookups.

If the same information from the body of the report is also contained in
new header fields, message subject, or attachment filename, the
specification needs to be clear about what happens when they don't
agree: does the recipient discard reports that are inconsistent, and if
not, which values are used?

IMO, it's more straightforward to keep this simple and have the
information in only one place.
>
>>    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?
> (As Area Director)

+1. Or if attrleaf goes first, TLSRPT requests an entry in the registry
that attrleaf created.

-Jim