Subject: [Uta] AD review of draft-ietf-uta-smtp-tlsrpt-06.txt

From: Alexey Melnikov <[email-masked]>
Date: Wed, 28 Jun 2017 11:03:19 +0100

You can treat these comments as WGLC comments:

4.4.  JSON Report Schema

    The JSON schema is derived from the HPKP JSON schema [RFC7469] (cf.
    Section 3)

          {
            "organization-name": organization-name,
            "date-range": {
              "start-datetime": date-time,
              "end-datetime": date-time
            },
            "contact-info": email-address,
            "report-id": report-id,
            "policy": {
              "policy-type": policy-type,
              "policy-string": policy-string,
              "policy-domain": domain,
              "mx-host": mx-host-pattern
            },
            "summary": {
              "success-aggregate": total-successful-session-count,
              "failure-aggregate:" total-failure-session-count
            }
            "failure-details": [
              {
                "result-type": result-type,
                "sending-mta-ip": ip-address,
                "receiving-mx-hostname": receiving-mx-hostname,
                "receiving-mx-helo": receiving-mx-helo,
                "session-count": failed-session-count,
                "additional-information": additional-info-uri,
                "failure-reason-code": "Text body"

I think you should replace "Text body" with failure-reason-code here.

              }
            ]
          }

                             JSON Report Format

    o  "organization-name": The name of the organization responsible for
       the report.  It is provided as a string.

    o  "date-time": The date-time indicates the start- and end-times for
       the report range.  It is provided as a string formatted according
       to Section 5.6, "Internet Date/Time Format", of [RFC3339]. The
       report should be for a full UTC day, 0000-2400.

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

    o  "report-id": A unique identifier for the report.  Report authors
       may use whatever scheme they prefer to generate a unique
       identifier.  It is provided as a string.

    o  "policy-type": The type of policy that was applied by the sending
       domain.  Presently, the only three valid choices are "tlsa",
       "sts", and the literal string "no-policy-found".  It is provided
       as a string.

Is this set possibly extensible?
If yes, you probably need a new IANA registry.
If not, you should say so.

    o  "policy-string": The JSON string serialization ([RFC7159] section
       7) of the policy, whether TLSA record ([RFC6698] section 2.3) or
       MTA-STS policy.

    o  "domain": The Policy Domain is the domain against which the MTA-
       STS or DANE policy is defined.

Need to make it clear that U-labels are not used here (unless they are!).
For example, add:

       In the case of Internationalized Domain Names
       ([RFC5891]), the domain is the Punycode-encoded A-label
       [RFC3492] and not the U-label.

    o  "mx-host-pattern": The pattern of MX hostnames from the applied
       policy.  It is provided as a string, and is interpreted in the
       same manner as the "Checking of Wildcard Certificates" rules in
       Section 6.4.3 of [RFC6125].

Similar comment about [non-]use of U-labels.

    o  "result-type": A value from Section 4.3, "Result Types", above.

    o  "ip-address": The IP address of the sending MTA that attempted the
       STARTTLS connection.  It is provided as a string representation of
       an IPv4 or IPv6 address in dot-decimal or colon-hexadecimal
       notation.

Need references: RFC 5952 for IPv6 notation and reference "IPv4address" 
ABNF non terminal for IPv4.

    o  "receiving-mx-hostname": The hostname of the receiving MTA MX
       record with which the sending MTA attempted to negotiate a
       STARTTLS connection.

    o  "receiving-mx-helo": (optional) The HELO or EHLO string from the
       banner announced during the reported session.

    o  "success-aggregate": The aggregate number (integer) of
       successfully negotiated TLS-enabled connections to the receiving
       site.

In all other cases you describe the right hand side (the data type).
So should you use "total-successful-session-count" here?

    o  "failure-aggregate": The aggregate number (integer) of failures to
       negotiate an TLS-enabled connection to the receiving site.

In all other cases you describe the right hand side (the data type).
So should you use "total-failure-session-count" here?

    o  "session-count": The number of (attempted) sessions that match the
       relevant "result-type" for this section.

In all other cases you describe the right hand side (the data type).
So should you use "failed-session-count" here?

    o  "additional-info-uri": An optional URI pointing to additional

Add a reference.

       information around the relevant "result-type".  For example, this
       URI might host the complete certificate chain presented during an
       attempted STARTTLS session.

Are any specific URI types mandatory to implement? E.g. "http" and "https"?

    o  "failure-reason-code": A text field to include an TLS-related
       error code or error message.

In Section 5.3:

5.3.  Email Transport

    The report MAY be delivered by email.  To make the reports machine-
    parsable for the receivers, we define a top-level media type
    "multipart/report" with a new parameter "report-type="tlsrpt"".
    Inside it, there are two parts: The first part is human readable,
    typically "text/plain", and the second part is machine readable with
    a new media type defined called "application/tlsrpt+json".  If
    compressed, the report should use the media type "application/
    tlsrpt+gzip".

    In addition, the following two new top level message header fields
    are defined:

                     TLS-Report-Domain: Receiver-Domain
                     TLS-Report-Submitter: Sender-Domain

I would like to see a statement that these fields MUST be included.

    These message headers would allow for easy searching for all reports
    submitted by a report domain or a particular submitter, for example
    in IMAP:

Please add a reference to RFC 3501 for IMAP here.

    "s SEARCH HEADER "TLS-Report-Domain" "example.com""

6.1.  Message headers

    Below is the Internet Assigned Numbers Authority (IANA) Permanent
    Message Header Field registration information per [RFC3864].

              Header field name:           TLS-Report-Domain
              Applicable protocol:         smtp

Per 
<https://www.iana.org/assignments/message-headers/message-headers.xhtml#perm-headers> 
this should be "mail" instead of "smtp".

              Status:                      standard
              Author/Change controller:    IETF
              Specification document(s):   this one

              Header field name:           TLS-Report-Submitter
              Applicable protocol:         smtp

As above.

              Status:                      standard
              Author/Change controller:    IETF
              Specification document(s):   this one

In Section 6.3:

As you are registering 2 different MIME types, you need to have 2 
registration templates, because considerations for JSON and GZIP are 
slightly different.

In Section 6.4:

You need to specify IANA registration policy from choices listed in RFC 
5226. Most likely you want "Specification Required" or "Expert Review" 
(both imply expert review).

So you need to replace the last sentence of this section:

OLD:

    New result types can be added to this registry without the
    need to update this document.

NEW:

    New result types can be added to this registry using
    "Expert Review" IANA registration policy.

---

From: "Brotman, Alexander" <[email-masked]>
Date: Wed, 28 Jun 2017 11:56:22 +0000

Most of these seem reasonable, and we'll get to work sorting them out.  The only question I have is relating to:

--------------

-----------------

Sure, this set could be extended at some point in the future, but couldn't it be addressed by a minor edit to the draft?  I wouldn't think the number of possible values would be largely expanded, if ever. 

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

-----Original Message-----
From: Uta [mailto:[email-masked]] On Behalf Of Alexey Melnikov
Sent: Wednesday, June 28, 2017 6:03 AM
To: [email-masked]
Subject: [Uta] AD review of draft-ietf-uta-smtp-tlsrpt-06.txt

4.4.  JSON Report Schema

          {

              }
            ]
          }

                             JSON Report Format

Add a reference.

In Section 5.3:

5.3.  Email Transport

6.1.  Message headers

Per

              Status:                      standard

As above.

              Status:                      standard

In Section 6.3:

As you are registering 2 different MIME types, you need to have 2 registration templates, because considerations for JSON and GZIP are slightly different.

In Section 6.4:

You need to specify IANA registration policy from choices listed in RFC 5226. Most likely you want "Specification Required" or "Expert Review" 
(both imply expert review).

OLD:

NEW:

_______________________________________________
Uta mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/uta

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 28 Jun 2017 13:04:27 +0100

Hi Alex,

On 28/06/2017 12:56, Brotman, Alexander wrote:
> Sure, this set could be extended at some point in the future, but couldn't it be addressed by a minor edit to the draft?
Once this document is published as an RFC, you will need to do that in 
another draft. But yes, this would be fine.

>    I wouldn't think the number of possible values would be largely expanded, if ever.
>
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse
> Comcast
> x5364
>

---

From: Leif Johansson <[email-masked]>
Date: Wed, 28 Jun 2017 15:12:30 +0200

Does the authors feel this version is ready for WGLC?

	Cheers Leif

---

From: "Brotman, Alexander" <[email-masked]>
Date: Wed, 28 Jun 2017 18:17:52 +0000

We believe so.  We'd like to gather as many comments as possible to go with Alexey's and bundle those up, and hopefully finalize this.

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

-----Original Message-----
From: Uta [mailto:[email-masked]] On Behalf Of Leif Johansson
Sent: Wednesday, June 28, 2017 9:13 AM
To: [email-masked]
Subject: Re: [Uta] AD review of draft-ietf-uta-smtp-tlsrpt-06.txt

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Wed, 28 Jun 2017 23:31:11 +0200

> We believe so.  We'd like to gather as many comments as possible to go with Alexey's and bundle those up, and hopefully finalize this.

If you have more outstanding issues than Alexeis it might be worth while
to do another version and WGLC that one... if its just Alexeis stuff
right now we can deal with that in WGLC.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 29 Jun 2017 08:50:38 +0100

> On 28 Jun 2017, at 22:31, Leif Johansson <[email-masked]> wrote:
> 

I am Ok with treating my input as WGLC. Most of the things I reported are missing references or nits.