Subject: [Uta] Updated TLSRPT (WGLC Comments)

From: "Brotman, Alexander" <[email-masked]>
Date: Sun, 4 Mar 2018 18:47:05 +0000

Hello folks,

We used the feedback from folks during the WGLC and have submitted a new version.  This is mostly editorial changes or minor inconsistencies.  We did also remove any relation between the TLS-Report-Submitter and the filename.  If you have any comments, please let us know.  Thank you.

https://www.ietf.org/id/draft-ietf-uta-smtp-tlsrpt-16.txt

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 4 Mar 2018 15:07:48 -0500

> On Mar 4, 2018, at 1:47 PM, Brotman, Alexander <[email-masked]> wrote:
> 
> Hello folks,
> 

Almost there, but a couple of editorial nits:

        4.4

            o  "policy-string": A string representation of the policy,

Since it is no longer a "string representation" of the policy, but rather
an array of strings, at least the description should probably change to:
"An encoding of the policy as a JSON array of strings" or some such.  You
could also rename the element to "policy-array", but I don't feel strongly
about that.

 	4.5.  Policy Samples

 	   Part of the report body includes the policy that is applied when
 	   attemping relay to the destination.

 	   For DANE TLSA policies, a JSON array of strings each representing the
 	   RDATA of a single TLSA resource record as a space-separated list of
 	   its four TLSA fields; the fields are in presentation format (defined
 	   in RFC6698 Section 2.2) with no internal spaces or grouping
 	   parentheses:
 		
 	   ["3 0 1
 	   1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D747D1D085D",
 	   3 0 1
 	   12350A337E6DB9C6123522D136A475638CC43E1ED424F8EEC8513D747D1D1234"]

There's a missing open double-quote for the second "3 0 1".
 		
 	   For the MTA-STS policy, an array of JSON string will represent the

s/array of JSON string will represent/JSON array of strings that represents/
just as in the DANE paragraph above.

 	   policy that is declared by the receiving site, including any errors
 	   that may be present.  Note that if there are multiple MX records,
 	   they are not included as an array.
           
           [
           "version: STSv1",
           "mode: report",
           "mx: mx1.example.com",
           "mx: mx2.example.com",
           "mx: mx.backup-example.com",
           "max_age: 12345678"
           ]

I reformatted the JSON array with one element per line for clarity (putting the
square brackets on separate lines), I think you should do the same both here,
and in the DANE example:

           [
           "3 0 1 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D747D1D085D",
 	   "3 0 1 12350A337E6DB9C6123522D136A475638CC43E1ED424F8EEC8513D747D1D1234"
           ]

The comment about MX host patterns not being included as an array may be a
confusing.  It might be clearer to say:

  Note that where there are multiple "mx" values, they must be listed as separate
  "mx" elements in the policy array, rather as a single nested "mx" sub-array.

-- 
	Viktor.

---

From: "Brotman, Alexander" <[email-masked]>
Date: Mon, 5 Mar 2018 13:09:42 +0000

Updated draft in a short while.

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

-----Original Message-----
From: Uta [mailto:[email-masked]] On Behalf Of Viktor Dukhovni
Sent: Sunday, March 04, 2018 3:08 PM
To: [email-masked]
Subject: Re: [Uta] Updated TLSRPT (WGLC Comments)

        4.4

Since it is no longer a "string representation" of the policy, but rather an array of strings, at least the description should probably change to:
"An encoding of the policy as a JSON array of strings" or some such.  You could also rename the element to "policy-array", but I don't feel strongly about that.

 	4.5.  Policy Samples

 		
 	   ["3 0 1

s/array of JSON string will represent/JSON array of strings that represents/ just as in the DANE paragraph above.

           [
           "version: STSv1",
           "mode: report",
           "mx: mx1.example.com",
           "mx: mx2.example.com",

I reformatted the JSON array with one element per line for clarity (putting the square brackets on separate lines), I think you should do the same both here, and in the DANE example:

           [

The comment about MX host patterns not being included as an array may be a confusing.  It might be clearer to say:

-- 
	Viktor.

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

---

From: Ayke van Laethem <[email-masked]>
Date: Sat, 24 Mar 2018 23:03:02 +0100

Hi all,

Something that's been confusing to me is: if and how does the
SMTP-TLSRPT specification depend on the MTA-STS specification?
The "mode" field of the policy controls whether any report should be
generated (if there is a TLSRPT policy too), but the SMTP-TLSRPT
specification itself does not mention this dependency at all.
In fact, I wonder why the MTA-STS policy would affect report sending anyway.

Consider these cases:
1. There is a policy with mode=testing and no TLSRPT policy
    - obviously no report is generated, because there is no address to
      send it to
2. There is a policy with mode=none and a TLSRPT policy
    - according to the MTA-STS spec, no report should be sent, but the
      TLSRPT spec is silent on this
3. There is no STS policy at all, but there is a TLSRPT policy
    - I'm guessing reports have to be sent, even though there is no
      STS policy that says so, in case DANE is used

It would make most sense to me if report sending only depends on the
presence of the TLSRPT policy (the TXT record) and not at all on the
active MTA-STS policy mode.
There may be a special case to not send reports if there is a MTA-STS
policy mode=none *and* DANE is not in use (how do you determine
exactly DANE is not in use?), but IMHO this should be documented in
the TLSRPT spec.

> "An encoding of the policy as a JSON array of strings" or some such.  You could also rename the element to "policy-array", but I don't feel strongly about that.

+1

Ayke

---

From: "Brotman, Alexander" <[email-masked]>
Date: Tue, 27 Mar 2018 00:20:16 +0000

Ayke,

At one point, these two were a single draft, but there's more utility possible with having TLSRPT separate.  To answer your scenarios below:

1) The site may not be able to process reports, or may not want the information, but they could still want to move toward a policy  of ensuring mode=enforce or have a TLSA published.  The MTA-STS draft mentions that if the site also publishes TLSRPT, they could receive reports. 
2) The site could still have TLSA records or general TLS failures.  While the sending site would not validate the MTA-STS policy, there could be other items causing reports show failures.
3) I believe 2 and 3 are similar situations.

Does that answer some of your questions?

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

-----Original Message-----
From: Ayke van Laethem [mailto:[email-masked]] 
Sent: Saturday, March 24, 2018 5:56 PM
To: Brotman, Alexander <[email-masked]>
Cc: [email-masked]
Subject: Re: [Uta] Updated TLSRPT (WGLC Comments)

Hi all,

Something that's been confusing to me is: if and how does the SMTP-TLSRPT specification depend on the MTA-STS specification?
The "mode" field of the policy controls whether any report should be generated (if there is a TLSRPT policy too), but the SMTP-TLSRPT specification itself does not mention this dependency at all.
In fact, I wonder why the MTA-STS policy would affect report sending anyway.

Consider these cases:

It would make most sense to me if report sending only depends on the presence of the TLSRPT policy (the TXT record) and not at all on the active MTA-STS policy mode.
There may be a special case to not send reports if there is a MTA-STS policy mode=none *and* DANE is not in use (how do you determine exactly DANE is not in use?), but IMHO this should be documented in the TLSRPT spec.

Ayke