On 27 May 2015, at 18:56, Viktor Dukhovni wrote:
On Wed, May 27, 2015 at 11:14:20AM -0700, Ben Campbell wrote:
2.1.3, first paragraph:
The seems redundant to similar normative language in 2.1.1
Indeed this repeats language in 2.1.1, if restating the requirement
is frowned upon, this can be deleted.
It's not necessarily broken, but it's not optimal. It's no problem as
long as they agree, but it can be error prone for future updates, if any
ever happen.
2.1.3, last paragraph: "...it may need to issue a
separate query..."
I assume that means it also may _not_ need to do so. Is it worth
elaborating on that case?
The "may" is really a "will" conditional on the initial premise.
Perhaps one reason for the tentative tone, is that I was guessing
that some implementations would not go the extra mile to support
DANE with servers whose A/AAAA records are CNAME aliases into
"insecure" zones. That is:
; The TLSA record in this secure zone is likely to not get used,
; because the A record is insecure, and implementations are likely
; to not bother with the additional "IN CNAME" query that
distinguishes
; this from both zones being insecure.
;
smtp.example.com. IN CNAME smtp.example.net. ; secure zone
example.com
_25._tcp.smtp.example.com. IN TLSA 3 1 1 ... ; ditto
smtp.example.net. IN A 192.0.2.1 ; insecure zone example.net
Indeed while Postfix makes the extra CNAME query, IIRC Exim does
not. This is rather a corner case, because MX hostnames are in
any case not supposed to be CNAME aliases, and most email domains
have MX records, and MX hosts that are CNAME aliases are rare.
So I guess that this is an optional behaviour for MTAs that choose
to support DANE even in this corner case.
Does this need additional text in the document, or can we leave to
implementors to reach their own conclusions once they understand
that "insecure" CNAME responses for A/AAAA records can be returned
from "secure" zones when the CNAME target is an "insecure" zone.
(I might note that the same considerations apply to the DANE SRV
draft, but that document is much less detail oriented, and does
not discuss the issue at all).
Would it make sense to say something like "When this occurs, if a client
needs to determine the security status ... , it _needs_ to issue a
separate query..."
That is, drop the "may", but still leave it conditional?
Editorial:
2.3.3, first sentence: This is pretty convoluted. You might consider
breaking it into a few simpler sentences.
As there is no "2.3.3", I assume you mean "2.2.3", which is indeed
complex.
For a particular SMTP server, the associated TLSA base domain is
either the server hostname or, when that hostname is an alias (CNAME
or DNAME), possibly its fully alias-expanded name if every stage in
the alias expansion is "secure". This yields either one or two
candidate TLSA base domains for the SMTP server. When there are two
candidate TLSA base domains, the alias-expanded domain name has a
higher precedence (is tried first). The first of these to yield a
"secure" TLSA RRSet is the final TLSA base domain.
Each candidate TLSA base domain (alias-expanded or original) is in
turn prefixed with service labels of the form "_<port>._tcp". The
resulting domain name is used to issue a DNSSEC query with the query
type set to TLSA ([RFC6698] Section 7.1).
How about the following:
When the SMTP server's hostname is not a CNAME or DNAME alias,
the list of associated candidate TLSA base domains (see below)
consists of just the server hostname.
When hostname is an alias with a "secure" (at every stage) full
expansion, the list of candidate TLSA base domains (see below)
is a pair of domains: the fully expanded server hostname first
and the unexpanded server hostname second.
Each candidate TLSA base domain (alias-expanded or original) is in
turn prefixed with service labels of the form "_<port>._tcp". The
resulting domain name is used to issue a DNSSEC query with the query
type set to TLSA ([RFC6698] Section 7.1).
The first of these candidate domains to yield a "secure" TLSA
RRSet becomes the actual TLSA base domain.
Is that better?
Much, than you.
Thanks!
Ben.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
