Re: [Uta] Updated TLSRPT (WGLC Comments)

["Brotman, Alexander" <[e-mail]>]

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:[e-mail]] 
Sent: Saturday, March 24, 2018 5:56 PM
To: Brotman, Alexander <[e-mail]>
Cc: [e-mail]
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:
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.

Ayke


2018-03-05 14:09 GMT+01:00 Brotman, Alexander <[e-mail]>:
> Updated draft in a short while.
>
> --
> Alex Brotman
> Sr. Engineer, Anti-Abuse
> Comcast
>
>
> -----Original Message-----
> From: Uta [mailto:[e-mail]] On Behalf Of Viktor Dukhovni
> Sent: Sunday, March 04, 2018 3:08 PM
> To: [e-mail]
> Subject: Re: [Uta] Updated TLSRPT (WGLC Comments)
>
>
>
>> On Mar 4, 2018, at 1:47 PM, Brotman, Alexander <[e-mail]> wrote:
>>
>> 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
>
> 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.
>
> _______________________________________________
> Uta mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta
>
> _______________________________________________
> Uta mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/uta