Subject: [Gen-art] Genart last call review of draft-ietf-uta-smtp-tlsrpt-17

From: Joel Halpern <[email-masked]>
Date: Thu, 08 Mar 2018 14:28:02 -0800

Reviewer: Joel Halpern
Review result: Almost Ready

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.

Document: draft-ietf-uta-smtp-tlsrpt-17
Reviewer: Joel Halpern
Review Date: 2018-03-08
IETF LC End Date: 2018-04-02
IESG Telechat date: Not scheduled for a telechat

Summary: This document is close to ready for publication as a Proposed Standard
RFC.

Major issues:
    Given that the format of the txt record allows for multiple URIs, the ntext
    needs to specify what the reader of the record is supposed to do when there
    are multiple (using the same or different formats).  I presume the intent
    is that the reader may use any of the URIs, and only needs to use 1.  But
    it needs to say so.

    The field names in section 4.2.1 do not match the field names in the schema
    "summary" section in 4.4.

    Reading the details of the "failed-session-count" in the "failure details"
    section in section 4.4, I infer that the intention is that "failure
    details" is to be repeated for each different kind of failure.  That is a
    sensible approach.  I can not find where the text actually states that to
    be the approach.  (yes, it is represented in the example.)

Minor issues:
    The introductory text on the relationship between StartTLS and
    Opportunistic Security is confusing.  Niether the term nor the RFC existed
    when Starttls was defined.  Maybe instead of  "The protocol design is based
    on "Opportunistic Security"..." it could read "The protocol design uses an
    approach that has come to be known as "Opportunistic Security"..."?

    Section 3, bullet 3, says that submitters using POST can ignore certificate
    validation errors when using https.  That seems to undermine the usage of
    https.  As such, I would expect to at least see some explanation of when
    and why ignoring such errors is appropriate.

    It is surprising in Section 3 Bullet 4 that reporting via email requires
    that the report submitted use DKIM.  Particularly while ignoring any
    security errors in communicating with the recipient domain.

    In the formal definition of the txt record, shouldn't the URI format also
    indicate that semicolon needs to be encoded?

    The reference in section 4.2.1 on treating the success count as a heartbeat
    suggests that the intention that these reports are to be filed even when
    everything has worked right all day.  If that is the intention, it should
    be stated explicitly.  If that is not the intent, then the reference to
    heartbeat in 4.2.1 should be removed.

    Section 5.1 defines a report filename.  This is probably a naive question,
    but what is that for?  If using HTTPS, the earlier text says that the POST
    operation goes to the target URI from the txt record.  When using email,
    there is no apparent need for a filename.

    Most of the security risks described in the Security section (7) do not
    seem to have any mitigation.  Should there not be some explanation why
    deployment is acceptable with these risks?

Nits/editorial comments:
    I presume that the use of DNS text records to convey policy has been
    reviewed and approved by the DNS Directorate.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 8 Mar 2018 18:33:12 -0500

> On Mar 8, 2018, at 5:28 PM, Joel Halpern <[email-masked]> wrote:
> 

Actually, this is not surprising.  The main security risk here is report spam,
that will drown the true signal in noise, making it impossible to notice real
validation failures or operate the service.

Therefore, the report origin domain must be authenticated via DKIM.  I'd
be tempted to go further and require a particular "selector" prefix that
is specifically chosen for "tlsrpt", so that with domains such as "gmail",
where anyone can get an email account, just being a user on the sending
system is not enough to be able to forge a DKIM authenticated report.
But that would create significant complications for the sender to make it
so, and so is probably not needed.

In summary, when sending reports the party that needs to be authenticated
is the sender domain, while the receiving domain is presumed operationally
compromised, and so should be exempt from any authentication requirements.

-- 
	Viktor.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 8 Mar 2018 18:46:42 -0500

A reasonable perspective.  Could that be added to the document?

Yours,
Joel

---

From: "Brotman, Alexander" <[email-masked]>
Date: Wed, 14 Mar 2018 11:21:21 +0000

I don't see any reason a specific DKIM selector wouldn't be possible.

We'll see if we can get some language added to address the clarifications you've requested.

--
Alex Brotman
Sr. Engineer, Anti-Abuse
Comcast

-----Original Message-----
From: Joel M. Halpern [mailto:[email-masked]] 
Sent: Thursday, March 08, 2018 6:47 PM
To: Viktor Dukhovni <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Uta] Genart last call review of draft-ietf-uta-smtp-tlsrpt-17

Yours,
Joel

On 3/8/18 6:33 PM, Viktor Dukhovni wrote:
> Actually, this is not surprising.  The main security risk here is 
> report spam, that will drown the true signal in noise, making it 
> impossible to notice real validation failures or operate the service.
> 
> Therefore, the report origin domain must be authenticated via DKIM.  
> I'd be tempted to go further and require a particular "selector" 
> prefix that is specifically chosen for "tlsrpt", so that with domains 
> such as "gmail", where anyone can get an email account, just being a 
> user on the sending system is not enough to be able to forge a DKIM authenticated report.
> But that would create significant complications for the sender to make 
> it so, and so is probably not needed.
> 
> In summary, when sending reports the party that needs to be 
> authenticated is the sender domain, while the receiving domain is 
> presumed operationally compromised, and so should be exempt from any authentication requirements.
>