Subject: [dane] AppsDir review of draft-ietf-dane-protocol-19

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 23 Apr 2012 15:30:51 -0600

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/

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 27 Apr 2012 11:01:21 -0700

> the kind that Dave Cridland experienced (see his Last Call comments).

Now covered in section 1.3, and includes a note that this document might be updated in the future to cover such things. (Note: it would be grand if an XMPPer would start work on this soon so we still have momentum.)

> mention the reasoning behind the port number (instead of application

I would rather not try to summarize the debate in the spec, given that the result (numbers) are completely clear.

> Yet surely the application protocol can matter here, no?

No.

> In
> course).

Sure. But...

> Does DANE elide over the application protocol because we
> particular port?

Yes, that's the only sane way to do things currently. (The TLS WG is discussing adopting a protocol that would complicate this, but that's a long way off, I suspect.)

> What about service providers that wish to restrict
> (cf. RFC 6125)?

I'm not sure how this is relevant. There is only one application protocol that can be running on 443 after TLS is established.

> Or do we assume that it is enough to differentiate
> to be the case in the text on "Multiple Ports" in Section 5)?

Yes.

> IMHO we

I don't see it.

> validator, is it possible to mimic the behavior of current SSL proxies?

Maybe, but they are undefined.

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Fri, 27 Apr 2012 15:52:33 -0400

> Now covered in section 1.3, and includes a note that this document might be updated in the future to cover such things. (Note: it would be grand if an XMPPer would start work on this soon so we sti…

Yes -- we decided to take the "instead of boiling the ocean / being all things to all people"  approach with the initial doc to instead publish this and then have "How to do DANE with protocol foo" documents... This does mean that we want  need these docs. 
They should be fairly simple to write -- submissions gratefully accepted :-)

W

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 29 Apr 2012 22:34:06 -0700

On 4/27/12 12:52 PM, Warren Kumari wrote:
>>> 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).
>> 
>> Now covered in section 1.3, and includes a note that this
>> document might be updated in the future to cover such things.
>> (Note: it would be grand if an XMPPer would start work on this
>> soon so we still have momentum.)
> 
> Yes -- we decided to take the "instead of boiling the ocean / being
> all things to all people"  approach with the initial doc to instead
> publish this and then have "How to do DANE with protocol foo"
> documents... This does mean that we want  need these docs. They
> should be fairly simple to write -- submissions gratefully accepted
> :-)

Yes, Matt Miller and I plan to work on that one soonish.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Sun, 29 Apr 2012 22:42:42 -0700

On 4/27/12 11:01 AM, Paul Hoffman wrote:
>>  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).
> 
> Now covered in section 1.3, and includes a note that this document 
> might be updated in the future to cover such things.

Thanks.

> (Note: it would be grand if an XMPPer would start work on this soon
> so we still have momentum.)

Yep, it's on my list. :)

>>  prefixed DNS domain name format defined in Section 3 looks 
>> strange: why not _http._tcp.www.example.com instead of 
>>  mention the reasoning behind the port number (instead of 
>> application name) here?
> 
> I would rather not try to summarize the debate in the spec, given 
> that the result (numbers) are completely clear.
> 
>> 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.
>> 
>> 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).
> 
> Sure. But...
> 
>> Does DANE elide over the application protocol because we simply 
>> assume that the "right" service is being served over any
>> particular port?
> 
> Yes, that's the only sane way to do things currently. (The TLS WG
> is discussing adopting a protocol that would complicate this, but
> that's a long way off, I suspect.)
> 
>> What about service providers that wish to restrict the usage of
>> a certificate to a particular application service type (cf. RFC 
>> 6125)?
> 
> I'm not sure how this is relevant. There is only one application 
> protocol that can be running on 443 after TLS is established.
> 
>> Or do we assume that it is enough to differentiate among 
>> application services based on the underlying transport (as seems
>> IMHO we have a bit of a muddle here.
> 
> I don't see it.

OK, your reasoning makes sense to me -- at least your reasoning for
not including more text in the document at this time.

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

Right, and it's not the job of this document to define them.

One more issue is nagging at me: there is no definition or citation
for "domain name" in Section 3. In particular, there is no indication
of whether internationalized domain names are allowed (and, if so, in
what format). I think it would good to make this clear by saying that
a domain name can be either a "traditional domain name" (RFC 1034) or
an "internationalized domain name" (RFC 5890); for the latter I think
it would be best to say that the IDN's internationalized labels are
represented only as A-labels. IMHO a short paragraph on this matter
would be appropriate in Section 3 or in a new section entitled
"Internationalization Considerations".

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 30 Apr 2012 19:43:58 -0700

I've reviewed version -20. Herewith a bit of follow-up.

On 4/23/12 2:30 PM, Peter Saint-Andre wrote:
> This is a supplemental AppsDir review of draft-ietf-dane-protocol 
> (for background on AppsDir, please see 
> 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
> 
> 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 import of "and" in that sentence is significant, and needs to 
> be highlighted earlier in the specification.

The new text in Section 1.3 addresses my concern.

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

The change from "client-chosen port" to "client-define port" is
mystifying to me. Even assuming that "client-defined" was meant, it's
not clear to me what a client-defined port is, and I see no effective
difference between the old text and the new text.

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

The new text reads:

   This document only applies to PKIX [RFC5280] certificates, not
   certificates of other formats.  Later updates to this document might
   specify how to use certificates in other formats.

That doesn't make it clear what would be needed to specify how to use
certificates in other formats (new RR type or new values for the
Certificate Usage field?). I still think it would be better to make
that clear so folks who update this document in the future know what
to do.

>  the DNS information needs to be be protected by DNSSEC.  Because 
> the certificate association was retrieved based on a DNS query, the
> 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.)

This is OK, per the new statement in Section 1.3.

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

I see no change in -20 to clarify this matter.

> mention the reasoning behind the port number (instead of 

This is OK to me now.

> 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
> among application services based on the underlying transport (as
> seems to be the case in the text on "Multiple Ports" in Section 5)?

Paul explained this in a previous message. I think it's OK.

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

As Paul pointed out, the behavior of SSL proxies is undefined in any
spec, and it's not the job of this spec to define them. OK with me.

>  methods, not object encryption).

Done, thanks.

>  always well understood. I suggest explicitly citing Section 3.1
> of RFC 1034 here.

Unchanged, but it's probably OK as-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.

The modified text looks good to me ("the domain name where the server
application runs").

> certificate associations, such as in the case of a server is 
> changing from one certificate to another."

Unchanged, but I think that's OK.

In a follow-up email message, I also noted:

###

###

I still think that this document needs to say something about IDNs.

Peter

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

---

From: Scott Schmit <[email-masked]>
Date: Tue, 1 May 2012 00:01:38 -0400

> that clear so folks who update this document in the future know what

It seems to me that this is addressed by this paragraph in 2.1.1:

  "The certificate usages defined in this document explicitly only apply
   to PKIX-formatted certificates in DER encoding [X.690].  If TLS
   allows other formats later, or if extensions to this RRtype are made
   that accept other formats for certificates, those certificates will
   need their own certificate usage values."

> I see no change in -20 to clarify this matter.

RFC 1035 (normative reference of RFC 4034, which is a normative
reference of this draft), section 5 defines the format for zone files
("Master files" in RFC 1035). That RFC predates Unicode and IDN, and
doesn't appear to be updated by any RFC spelling out use of Unicode in
zone files.

Based on that, I'd say that zone files are still ASCII-only (and a quick
web search seems to confirm that that is the case, though I don't see
any harm in adhering to the robustness principle here).  At any rate,
the definition of the TLSA presentation format and examples in this
draft seem consistent with RFC 1035 and the definition for other RR
types.

> I still think that this document needs to say something about IDNs.

IDNs were defined in such a way that IDN-ignorant software will work
correctly, so I don't see why spelling out the interaction with IDNs
for DANE is necessary.  Drafts governing the presentation, use, and
consumption of IDNs explain how to do so with TLSA RRs just as well as
for any other RR type.

-- 
Scott Schmit

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 30 Apr 2012 21:10:30 -0700

>    need their own certificate usage values."

Right, I missed that. Carry on.

> draft seem consistent with RFC 1035 and the definition for other RR

Does whitespace include tab, linefeed, etc., or only SP (ASCII 20)? It
really ought to be easy to clarify the matter. Just saying "whitespace"
is less than clear, IMHO.

> consumption of IDNs explain how to do so with TLSA RRs just as well as

So it ought to be easy to say "IDNs are covered if they consist only of
A-labels".

Peter

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