-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This is a supplemental AppsDir review of draft-ietf-dane-protocol (for
background on AppsDir, please see
<http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate>).
Although Murray Kucherawy has already reviewed this I-D on behalf of
the AppsDir, folks in the Applications Area realize that wide
deployment of the TLSA Resource Record might have a significant impact
on applications, so we are performing additional reviews. Please treat
these comments just as you would any other Last Call feedback.

Document: draft-ietf-dane-protocol
Title: "The DNS-Based Authentication of Named Entities (DANE) Protocol
for Transport Layer Security (TLS)"
Reviewer: Peter Saint-Andre
Review Date: 2012-04-23
IETF Last Call Date: 2012-04-25
IESG Telechat: not yet scheduled

Summary: This draft is almost ready for publication as an Standards
Track RFC but has a few issues that should be fixed before publication.

Major Issue:

This document does not mention that TLSA records cannot be used
directly in application protocols that depend on SRV (or NAPTR or
similar technologies). Although I realize that the DANE WG decided,
after much discussion, that the interaction between TLSA records and
SRV records is out of scope for this specification (and I do not mean
to reopen that discussion now), it would be very helpful for this
specification to reflect the results of that discussion. Although I
make specific suggestions regarding text under the Minor Issues below,
in general I think this document needs to be clearer about the
assumptions it has made in this regard; in fact, it seems to me that
an explicit applicability statement is warranted to avoid confusion of
the kind that Dave Cridland experienced (see his Last Call comments).
Absent such an applicability statement, it would be good to state up
front something that currently is not made explicit until the first
sentence of the Security Considerations:

   The security of the DNS RRtype described in this document relies on
   the security of DNSSEC as used by the client requesting A/AAAA and
   TLSA records.

The import of "and" in that sentence is significant, and needs to be
highlighted earlier in the specification.

Minor Issues:

1. In Section 1.2, these sentences might involve a slight
oversimplication:

   A TLS client begins a connection by exchanging messages with a TLS
   server.  It looks up the server's name using the DNS to get an
   Internet Protocol (IP) address associated with the name.  It then
   begins a connection to a client-chosen port at that address, and
   sends an initial message there.

1a. The second sentence might be construed as requiring only one step
(look up the name, get an IP address), whereas we know that sometimes
multiple steps are involved (think SRV). I'd be more comfortable if we
added a clause at the end along the lines of "sometimes via multiple
steps".

1b. The term "client-chosen port" makes it sound as if the client can
choose any port it pleases when connecting to the TLS server. Yet
typically the port is derived from a URI, "hardcoded" into the
application protocol (sometimes as a fallback), or discovered via the
DNS (again, think SRV). We needn't reflect those alternatives in the
text, but at the least "appropriate" is better than "client-chosen".

2. In Section 1.3, it is said that "This document only applies to PKIX
[RFC5280] certificates, not certificates of other formats." Does this
mean that a new RR type would need to be defined to handle other
formats (e.g., PGP as in RFC 6091), or only that documents defining
how to use TLSA records with those other formats would need to define
new values for the Certificate Usage field? Please clarify.

3. In Section 1.3, the following paragraph is true only for
application protocols that do not make use of SRV or similar technologies:

   This document defines a secure method to associate the certificate
   that is obtained from the TLS server with a domain name using DNS;
   the DNS information needs to be be protected by DNSSEC.  Because the
   certificate association was retrieved based on a DNS query, the
   domain name in the query is by definition associated with the
   certificate.

For example, in the case of XMPP the application client might discover
through a DNS SRV lookup that the XMPP service for example.com is
actually provided at im.example.net. In this case, the domain name in
the certificate presented by the TLS server (im.example.net) is not
the same as the certificate discovered via the DNS TLSA lookup
(example.com), so we can't simply stipulate that "the domain name in
the query is by definition associated with the certificate". Here
again that applicability statement would be helpful, because this
document assumes that you're connecting to the IP address that you
discover by means of DNS A/AAAA lookup on the domain name contained in
the prefixed DNS domain name defined in Section 3. (As noted, this is
made explicit in the first sentence of the Security Considerations.)

4. In Section 2.2, the term "whitespace" is underspecified. Does that
include, say, any Unicode space separator (Unicode General Category
Zs) or also line separators (Unicode General Category Zl) or only
certain code points in the ASCII range? Further, is the whitespace
significant in the examples from Section 2.3?

5. To those of us accustomed to SRV records, at first glance the
prefixed DNS domain name format defined in Section 3 looks strange:
why not _http._tcp.www.example.com instead of
_443._tcp.www.example.com? But when we take off our SRV-colored
glasses and realize that DANE assumes a DNS A/AAAA lookup on the
domain name, it all makes sense. Perhaps it would be helpful to
mention the reasoning behind the port number (instead of application
name) here?

6. In section 4, no mention is made of the application service that
the TLS expects to encounter at the TLS server:

   The TLS session that is to be set up MUST be for the specific port
   number and transport name that was given in the TLSA query.

Yet surely the application protocol can matter here, no? In
particular, given that 443 is the one true port, we know that folks
might run non-HTTP applications over that port (for evil reasons, of
course). Does DANE elide over the application protocol because we
simply assume that the "right" service is being served over any
particular port? What about service providers that wish to restrict
the usage of a certificate to a particular application service type
(cf. RFC 6125)? Or do we assume that it is enough to differentiate
among application services based on the underlying transport (as seems
to be the case in the text on "Multiple Ports" in Section 5)? IMHO we
have a bit of a muddle here.

7. The paragraph about SSL proxies in Section 8 says that "the TLS
client will get a certificate association from the DNS that will not
match the certificate that the SSL proxy uses with the client";
however, if the SSL proxy is working in concert with an external DNS
validator, is it possible to mimic the behavior of current SSL proxies?

Nits:

1. In Section 1.1, I suggest changing "using encryption" to "using
channel encryption" (since TLS uses connection-oriented encryption
methods, not object encryption).

2. Section 1.1, uses the term "subdomain" in the sentence "This
prevents an untrustworthy signer from compromising anyone's keys
except those in their own subdomains." The term "subdomain" is not
always well understood. I suggest explicitly citing Section 3.1 of RFC
1034 here.

3. In Section 1.3, the phrase "the domain name where the data is
found" makes it sound as if DANE applies only to application protocols
that involve data retrieval, whereas we know it can be used also for
technologies that involve communication (email, IM, etc.). I suggest
"the domain name for the relevant application service" or somesuch.

4. In Section 1.3, I suggest changing "server" (which might be
confused with the TLS server itself) to "service" or "application
service" in this sentence: "A DNS query can return multiple
certificate associations, such as in the case of a server is changing
from one certificate to another."

Typo: "have lead" should be "have led".

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk+VygoACgkQNL8k5A2w/vxyDwCfTTdHCQ1Vo/gHdumTbLGD8gP+
xJwAn0SQ1CkXK3t/38rWE881tc6ZbySt
=ZnZX
-----END PGP SIGNATURE-----