To reference the other message, we'll change that reference for DANE. I'll try to respond in-line for this one.
-- Alex Brotman Sr. Engineer, Anti-Abuse Comcast -----Original Message----- From: Uta [mailto:[email protected]] On Behalf Of Viktor Dukhovni Sent: Tuesday, December 05, 2017 11:14 PM To: [email protected] Subject: [Uta] TLSRPT further comments Section 4.3.2.1: "dnssec-invalid": This would indicate that no valid records were returned from the recursive resolver. The request returned with SERVFAIL for the requested TLSA record. It should be noted that if the reporter's systems are having problems resolving destination DNS records due to DNSSEC failures, it's possible they will also be unable to resolve the TLSRPT record, therefore these types of reports may be rare. Unfortunately, failure to resolve TLSA records is not yet always a result of a broader DNS outage. A small fraction of systems have nameservers that are either behind firewalls which implement misguided filtering of queries by RRtype (blocking TLSA and other "unusual" queries) or are buggy and mishandle authenticated denial of existence. Therefore, the "may be rare" sentence should I think be deleted. ---------- This seems to be a different type of operation issue. If an admin can never resolve a TLSA record from an external site, there may be larger issues going on. We can alter/remove the sentence, but I don't think it will change the frequency of those types reports. ---------- We could perhaps add a "dane-required" failure mode for cases where DANE is mandatory (by mutual agreement perhaps), but then the receiving domain's TLSA records (really the records for the underlying MX hosts) are unexpectedly removed, or become "insecure" if DNSSEC is disabled (DS records removed from parent zone). ------ I'd be inclined to say that this would appear in a "v2" of this draft. ------ Speaking of field names, a recent discussion on the ACME list concerned field names and whether to use "camelCase" or "kebab-case" (I hope the distinction is immediately apparent), and noted that "camelCase" is often a much better fit for programming language bindings because "camelCase" field names can be used directly as structure member field identifiers, enabling machine generation of encoding/decoding code from structure definitions. I think this is a reasonable argument for camels over kebabs, any thoughts on whether it is possible to revise the field names accordingly? ----- The draft has been like this since the inception, and I can't say I'm inclined to change it. If there's strong group consensus, we can do it. ----- Section 4.4: I notice that: "failure-details": [ { "result-type": result-type, "sending-mta-ip": ip-address, "receiving-mx-hostname": receiving-mx-hostname, "receiving-mx-helo": receiving-mx-helo, "failed-session-count": failed-session-count, "additional-information": additional-info-uri, "failure-reason-code": failure-reason-code } ] includes only the "receiving-mx-hostname" and not its IP address. Some sites have multiple hosts behind a single name, e.g. sometimes the IPv4 address for mail.example.com lands on a different machine than the IPv6 address for the same name (and indeed they present different certificate chains, ...). Leaving out the address might make it more difficult to identify the problem receiving machine. Perhaps the intention here is that receiving systems should make an effort to assign different "receiving-mx-helo" names in such to disambiguate these cases? If so, perhaps that should be mentioned in the text. ---------- We can add this, though, in the case of a front-end VIP, you're going to have the same target IP in many stanzas. I understand the rationale, just wonder how useful it will be in the end. --------- The format for DANE "policy-string" values is both under-specified, and needlessly complex: "policy-string": A string representation of the policy, whether TLSA record ([RFC6698] section 2.3) or MTA-STS policy. Examples: TLSA: ""_25._tcp.mx.example.com. IN TLSA ( 3 0 1 \ 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D7 47D1D085D )""... It should be more clear whether the "TLSA:" prefix is part of of the string (I believe it is not), and what the pair of consecutive double quotes is about, and how multiple TLSA records are represented. The JSON policy includes "\n" separators (which JSON maps to actual newlines), are TLSA records to be separated with similar logical newlines? More importantly, the form: _25._tcp.mx.example.com. IN TLSA ( 3 0 1 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D7 47D1D085D) carries much unnecessary syntax. It should instead be a simple quintuple (qname, usage, selector, mtype, data): _25._tcp.mx.example.com. 3 0 1 1F850A337E6DB9C609C522D136A475638CC43E1ED424F8EEC8513D747D1D085D with the implied "IN TLSA" and "(" ")" removed, and the hex data presented without any internal whitespace. With that simplified it remains only to specify clearly how present a complete TLSA RRset. ------------ The intent was to have the record and the result. Your changes are acceptable, and we can make the alterations. In the case of multiple record results, how would you like that to be displayed? Separated with a semicolon is sufficient I would think. We'll firm up the examples. ------------- Another nit: o "domain": The Policy Domain is the domain against which the MTA- STS or DANE policy is defined. In the case of Internationalized Domain Names ([RFC5891]), the domain is the Punycode-encoded A-label ([RFC3492]) and not the U-label. A domain name is not a "label" it consists of labels separated by "." characters. ---- I believe you're asking to replace "label" with "labels", and that's fine. ---- Also how are "policy-domain" and "mx-host" to be specified in the DANE case? DANE policy is per-MX, not per-domain, and mx-host seems redundant in both cases, since with STS the policy string surely contains the same data. What goes in these fields when no policy is obtained, they don't appear to be optional... ----- Perhaps I'm misinterpreting the statement. The policy domain is the recipient domain, while the mx-host is the MX that is attempted. Those do not need to align, and multiple recipient domains can point to a single MX. I'm not quite sure which policy you're referring to in the last portion of that paragraph. ----- Why in Section 5.1 is there a "report filename"? Surely the processing and storage of reports is entirely up to the receiving system, which should ignore filename hints from the sender. ----- This is the filename upon delivery. The receiver can rename the file to anything they'd like. ----- Why is the Content-Encoding (gzip or not) specified via a filename and not the standard header used for this purpose? ----- It's specified as both the attached filename and in the Content-Type header. In section 5.3 what are these "%s" prefixes in front of literal quoted strings? Is this a standard syntax? The [RFC5322].Subject field for report submissions SHOULD conform to the following ABNF: tlsrpt-subject = %s"Report" FWS ; "Report" %s"Domain:" FWS ; "Domain:" domain-name FWS ; per [RFC6376] %s"Submitter:" FWS ; "Submitter:" domain-name FWS ; per [RFC6376] %s"Report-ID:" FWS ; "Report-ID: "<" id-left "@" id-right ">" ; per [RFC5322] [CFWS] ; per [RFC5322] ; (as with FWS) ----- Yes, I believe Chris asked for that change. I'd have to check list history. ----- In section 5.4, why a separate GZIP-specific media type and not just a Content-Encoding? Surely the media type is just the JSON report format, and GZIP is an encoding layer... ---- I believe this was at the request of the WG Chairs. I'd have to go back through history to verify this. ----- In section 5.5 there's talk of a "logarithmic scale" for retries, but normally we speak of *exponential* backoff, not logarithmic! ------ Agreed ------ I can't make head nor tail of the verbiage in 5.6. Sounds like someone ran over a thesaurus while riding a lawn mower... :-) -------- If the filename/subject disagree with the report, then the report is the authoritative source. -------- Finally, I am concerned that TLSRPT appears to preclude timely reports, requiring each report to cover a full 24 hours. Might it not be reasonable, in some cases to send a timely report on first failure, to be followed by a summary end of day report later? Surely receiving systems might want to learn of problems more promptly. Or are do we want to leave that to a separate spec for in-band reporting (which I guess nobody has yet had the cycles to work on)? ------- In-band would be a better place I would think. The sender cannot guarantee that the receiving site will process reports in a timely fashion. ------- -- Viktor. _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta _______________________________________________ Uta mailing list [email protected] https://www.ietf.org/mailman/listinfo/uta
