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.
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).
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?
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.
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.
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.
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...
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.
Why is the Content-Encoding (gzip or not) specified via a filename
and not the standard header used for this purpose?
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)
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...
In section 5.5 there's talk of a "logarithmic scale" for retries,
but normally we speak of *exponential* backoff, not logarithmic!
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... :-)
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)?
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
