Re: [dane] Ben Campbell's Yes on draft-ietf-dane-smtp-with-dane-18: (with COMMENT)

["Ben Campbell" <[e-mail]>]

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.