Re: [Uta] draft-ietf-uta-smtp-tlsrpt second WGLC
On 3/2/18 4:06 AM, Valery Smyslov wrote: > 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]: 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 ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] draft-ietf-uta-smtp-tlsrpt second WGLC
> On Mar 2, 2018, at 7:06 AM, Valery Smyslov wrote: > > 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? 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. ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] draft-ietf-uta-smtp-tlsrpt second WGLC
> On Feb 28, 2018, at 7:09 AM, Valery Smyslov 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. ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] draft-ietf-uta-smtp-tlsrpt second WGLC
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. ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] draft-ietf-uta-smtp-tlsrpt second WGLC
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 > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] draft-ietf-uta-smtp-tlsrpt second WGLC
Hi, a few comments. 1. IANA Considerations section is not properly aligned with the draft text: In particular, the STARTTLS Validation Result Types initial entries in Section 6.5 don't include the " certificate-not-trusted" and the "dane-required" reasons listed in Section 4.3.2. 2. Section 4.4. For DANE TLSA policies, a JSON array array of strings each representing the RDATA of a single TLSA resource record as a space- separated list of its four TLSA fields (in RFC6698 Section 2.2) presentation form with no internal spaces or grouping parentheses: ["3 0 1 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D747D1D085D", 3 0 1 12350A337E6DB9C6123522D136A475638CC43E1ED424F8EEC8513D747D1D1234"] MTA-STS (array of JSON strings): ["version: STSv1","mode: report","mx: mx1.example.com","mx: mx2.example.com","mx: mx.backup-example.com","max_age: 12345678"] It seems to me that the description of MTA-STS policy example is too brief comparing to the description of DANE policy example. Is it possible to expand it a bit? And I also think that a reference to MTA-STS policy definition from [I-D.ietf-uta-mta-sts] is appropriate here (or in the bullet text above). 3. In Appendix B: Figure: Example JSON report for a messages from Company-X to Company- Y, where 100 sessions were attempted to Company Y servers with an expired certificate and 200 sessions were attempted to Company Y servers that did not successfully respond to the "STARTTLS" command. "Figure:" looks strange here, since the example above has no any title. I suggest to s/Figure/Above. Even better would be to move this para to the beginning of the section (Appendix B), so that first it is described what is this example about and then the example follows. In this case s/Figure:/Below is. And one more thing in this para: "a messages" - is it a typo? And on Viktor's comment: > A small editorial comment: > > Old: > >For DANE TLSA policies, a JSON array array of strings each >representing the RDATA of a single TLSA resource record as a space- >separated list of its four TLSA fields (in RFC6698 Section 2.2) >presentation form with no internal spaces or grouping parentheses: > > New: > >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 in (RFC6698 Section 2.2) >presentation form with no internal spaces or grouping parentheses: > > That is, drop the duplication of "array" and > > s/fields (in /fields in (/ 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). Regards, Valery. ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta
Re: [Uta] draft-ietf-uta-smtp-tlsrpt second WGLC
On 2/20/18 10:13 PM, Valery Smyslov wrote: > 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. > I read the draft again and did a review pretty much from scratch. Apologies in advance if some of my comments are redundant or have already been discussed. Section 1 paragraph 4: "failures in routing" -- suggest also including DNS failures (spoofing, etc.) Section 1 paragraph 5: While this document derived from the MTA-STS effort, it seems like it's as much a companion for RFC 7672. Also wonder whether RFC 7672 should be a normative rather than informative reference. (same comment in section 2) Section 1.1 bullet 2: Perhaps also mention RFC 7672 since this is the SMTP policy piece of DANE policy Section 1.1 bullet 5: delivery -> relay Section 3.1: Redundant with Appendix A. Sections 3.1.2 and A.2 : I'm concerned that the trailing \ within quotes might be interpreted as a literal CRLF which would not be allowed by the ABNF. Section 4 bullet 2c: The MX host. Apparently separate reports are generated per MX host, which totally makes sense. But this seems like it could have been introduced better. Section 4 bullet 2d: An identifier for the policy (where applicable) -- This is mentioned nowhere else in the specification, so where would this identifier come from? Suggest it be deleted. 4.3.1 bullet 2: MX -> MX hostname 4.3.1 bullets 4 and 5: failure-reason -> failure-reason-codeĀ (also might be good to have a forward reference because these are the first mentions of it.) Section 4.4 below "policy-string": The examples are poorly delimited here; putting them in the middle of the bulleted list breaks the continuity of the list. Suggest a reference to examples located elsewhere. 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). Section 5.3.1 last paragraph "...sending MTAs MUST NOT honor...": This bit of normative text is easy to miss, tacked onto an example. It also seems like it may be very hard to implement: you can't just drop a report into the mail stream (at least not in the absence of "REQUIRETLS NO"). Have the authors considered suggesting that the reports be sent to another domain instead (a domain that does not have MTA-STS policy)? -Jim ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/uta