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

From: "Ben Campbell" <[email-masked]>
Date: Wed, 27 May 2015 11:14:20 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-dane-smtp-with-dane-18: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dane-smtp-with-dane/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for this. I only have a few trivial comments:

 2.1.3, first paragraph:

The seems redundant to similar normative language in 2.1.1

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?

Editorial:

2.3.3, first sentence: This is pretty convoluted. You might consider
breaking it into a few simpler sentences.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 27 May 2015 23:56:30 +0000

> 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.

> 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).

> 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?

-- 
	Viktor.

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 27 May 2015 22:32:46 -0500

> 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.

> 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?

> RRSet becomes the actual TLSA base domain.

Much, than you.

Thanks!

Ben.