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

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 2 Mar 2018 09:13:58 +0300

Hi,

so, the second WGLC is over. Thanks to Jim for detailed review.
Authors, please publish a new version that addresses all the received
comments (I believe all of them are editorial).

Once the new version is published, I'll submit it to the IESG.

Regards,
Valery.

> Hi,
> 
> this is the second working group last call (WGLC) for the "SMTP TLS Reporting"
> (https://datatracker.ietf.org/doc/draft-ietf-uta-smtp-tlsrpt/).
> The WGLC will be short and will last for one week till March the 1st. The document has received substantial
> changes recently, so
> please review
> the latest version of the draft (-15) to make sure that these changes didn't break WG consensus.
> 
> Regards,
> Leif & Valery.
> 
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 2 Mar 2018 15:06:28 +0300

Hi Jim,

just one comment:

> Section 5.3 paragraph 3: "MUST match the value found in the filename"
> but the value in the filename is only a recommendation (section 5.1). I
> continue to lean toward not depending on values in other than the
> message body (single source of truth).

I believe that this section describes how the "TLS-Report-Submitter" is filled in
by sender, not how it is checked by the receiver. Section 5.6. already states
that the report body is the only authoritative source for receiver. 
I agree that the current wording is a confusing and can be improved. For example:

   When constructed the "TLS-Report-Submitter" value MUST match the value in the
   filename (if it is present there) and the [RFC5321] domain from the "contact-info" from the
   report body.  These message headers MUST be included and should allow
   for easy searching for all reports submitted by a report domain or a
   particular submitter, for example in IMAP [RFC3501]:

Daniel, Alex, is this interpretation correct?

> -Jim

Regards,
Valery.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 2 Mar 2018 10:57:16 -0500

> On Feb 28, 2018, at 7:09 AM, Valery Smyslov <[email-masked]> wrote:
> 
> It seems to me that the new sentence is still too long and a bit hard to parse.
> Is it possible to rephrase it? Something along the lines:
> 
>    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:
> 
> (hope this doesn't change its meaning).

Works for me.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 2 Mar 2018 11:05:11 -0500

> On Mar 2, 2018, at 7:06 AM, Valery Smyslov <[email-masked]> wrote:
> 

It would be simpler to say that the filename is an opaque string, and that
any structuring of the filename is merely intended to make the default
name under which a reader might save the report distinct for distinct
reports, and to make to easier to identify a particular report via its
(suggested) filename.  A user (human or email processing bot) is of course
entirely free to ignore the filename and store the report however they
see fit, or not store it as a file at all, and process its records on the
fly into a database.

-- 
	Viktor.

---

From: Jim Fenton <[email-masked]>
Date: Fri, 2 Mar 2018 10:45:00 -0800

>    particular submitter, for example in IMAP [RFC3501]:

My opinion is that since section 5.6 effectively says the filename (and
therefore the TLS-Report-Submitter) doesn't matter because only the body
is authoritative, the MUST requirements are excessive. I do see the
value of the TLS-Report-Submitter header field as a convenience feature
for the IMAP search usage that was mentioned, so I would say that it
SHOULD match the body.

I agree with Viktor's comment that the filename should be treated as an
opaque string. Setting specific requirements for it only makes the
protocol more brittle, and as he points out, how and whether the
filename is used is implementation-dependent anyway.

-Jim