Re: [dane] I-D Action: draft-ietf-dane-protocol-15.txt

[Scott Schmit <[e-mail]>]

On Sat, Feb 04, 2012 at 09:36:33AM +0100, Jakob Schlyter wrote:
> On 4 feb 2012, at 09:19, [e-mail] wrote:
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories. This draft is a work item of the DNS-based
> > Authentication of Named Entities Working Group of the IETF.
> 
> The new version includes, in addition to minor editorial changes, the
> following updates:

In section 2.1.3:
]  Because a client support for multiple hash algorithms might be
]  limited, ...

Grammar: s/a client/client/ or s/a client/a client's/

> - Text regarding protocol-specific specifications

In section 3:
]  Unless there is an protocol-specific specification that is different
]  than this one, TLSA resource records are stored at a prefixed DNS
]  domain name.  The prefix is prepared in the following manner:

Grammar: s/an protocol/a protocol/

Unless I misread the stated consensus, this draft doesn't address the
result of Issue 28 at all. Warren stated this was the consensus: "use
the first name that has a TLSA record".

If I understand the called consensus correctly, the client should first
do a lookup at the name provided to the client and if the TLSA record
isn't there, check at the hostname on the right-hand side of the SRV
record it's trying to connect to.  Draft -15 doesn't say that at all.

Assuming I'm not totally off-base in my reading of the stated consensus,
here's some proposed text:

|  TLSA resource records are stored at a DNS domain name of the form:
|
|      _<port>._<protocol>.<name>
|
|  <port>:
|      The decimal representation of the port number on which a TLS-
|      based service is assumed to exist.  This number has no leading
|      zeros.
|
|  <protocol>:
|      The protocol name of the transport on which a TLS-based service
|      is assumed to exist.  The transport names defined for this
|      protocol are "tcp", "udp" and "sctp".
|
|  <name>:
|      The DNS domain name the TLSA resource record belongs to.
|
|  The name and port to use to look up the TLSA resource record depends
|  on whether the protocol in use by the client uses SRV to determine
|  the port and address of the service.
|
|  If SRV is not used, the client uses the domain name and port that the
|  client was provided (e.g., by the user and/or a well-known service
|  port) to generate the name for the TLSA lookup.
|
|  For example, to request a TLSA resource record for an HTTP server
|  running TLS on port 443 at "www.example.com", you would use
|  "_443._tcp.www.example.com" in the request.  To request a TLSA
|  resource record for an SMTP server running the STARTTLS protocol on
|  port 25 at "mail.example.com", you would use
|  "_25._tcp.mail.example.com".
|
|  If SRV is used, the client begins with the domain name that the
|  client was provided (e.g., by the user) and first performs a SRV
|  lookup to get an list of port/target pairs sorted as specified by
|  RFC 2782.  For each port/target the client is attempting to connect
|  to, the client first performs the TLSA lookup using the port and the
|  initial name. If that TLSA lookup returns no records, then the client
|  performs a lookup using the port and target name.
|
|  For example, to request a TLSA resource record for an XMPP server
|  with the following SRV records:
|
|    _xmpp-server._tcp.example.com. IN SRV 0 0 1234 xmpp.example.net.
|    _xmpp-server._tcp.example.com. IN SRV 1 0 5678 im.example.org.
|
|  you would first do a TLSA lookup at "_1234._tcp.example.com". If that
|  returns no records, you would then do a lookup at
|  "_1234._tcp.xmpp.example.net". If you are unable to reach
|  xmpp.example.net, you would then do a TLSA lookup at
|  "_5678._tcp.example.com" and so on.
|
|  Future protocol-specific specifications may specify a different
|  scheme for looking up TLSA records.

In section 4.3:
]  This usage allows a domain name administrator to specify a new trust
]  anchor, such as if the domain issues its own certificates under its

should be, given the use case names in RFC 6394:
|  This usage is sometimes referred to as "trust anchor assertion" and
|  allows a domain name administrator to specify ...

Section 5:
]                                     ...  Clients that rely on another
]  entity to perform the DNSSEC signature validation MUST use a secure
]  transport between themselves and the validator.  Examples of secure
]  transports include TSIG [RFC2845], SIG(0) [RFC2931], and IPsec
]  [RFC6071].  ...

Slight nit: "entity" is rather vague and could be interpreted as
"software component" (such as the OS).  Would "host" be a better term?

> - Expanded "TLSA and DANE Use Cases and Requirements"

]  The different types of certificates associations defined in TLSA are

Grammar: s/certificates assocations/certificate assocations/

]  matched with various sections of [DANEUSECASES].  Three use cases

I think you can cover all 4 usage types with a reference to the use
cases in RFC 6394, so s/Three/The/

]  3.3 Domain-Issued Certificates  -- Implemented using certificate
]     usage 3.

Based on the title of section 3.3, I'd rewrite that as:
|  3.3 Trust Anchor Assertion and Domain-Issued Certificates --
|     Implemented using certificate usages 2 and 3, respectively.


In section 8.1:
]  In the following sections, "RFC Required" was chosen TLSA usages, and
]  "Specification Required" for selectors and hashes, because of the
]  amount of detail that is likely to be needed for implementers to
]  correctly implement new usages as compared to new matching types and
]  hash types.

Grammar: s/chosen TLSA/chosen for TLSA/

Also, you don't need any of the commas after the first (and they made
the text harder to read because it made me think it was delineating a
parenthetical clause).

Also, the terms used in the paragraph don't seem consistent with the
rest of the draft/the registry names/itself. Should it read:
|  In the following sections, "RFC Required" was chosen for TLSA usages
|  and "Specification Required" for selectors and matching types because
|  of the amount of detail that is likely to be needed for implementers
|  to correctly implement new usages as compared to new selectors and
|  matching types.

I'm not sure if specification required is sufficient for selectors, not
because they're going to be tremendously complex, but because some could
be a really bad idea, at least in some cases. Imagine I wrote up a
specification for DN matching or certificate policy matching. With
usages 0 & 1, that would be fine, but with usages 2 & 3, that would be
very foolish. Perhaps local client policy considering that to be weak
would resolve that, but it's not written that broadly.

The matching type registry has a similar problem, IMHO. (What about a
URI matching type?)

As far as I can tell from RFC 5226, the main difference between RFC
required & specification required is whether the referenced document
must have IETF consensus. Spec required will be checked for
interoperability, but nothing more AFAICT.

I realize this may never be a problem in practice but why not strengthen
the language?

In section 9 (Security Considerations):

The first two paragraphs talk about looking up A/AAAA records. Do we
need to add SRV to that list? Or maybe we should just refer to DNS
records (as there is also the issue of CNAMEs, etc).

Also, the considerations include:
]  Client treatment of any information included in the trust anchor is a
]  matter of local policy.  This specification does not mandate that
]  such information be inspected or validated by the domain name
]  administrator.

Should this text be expanded to include usage 3?

Do we want to add a paragraph reminding DNS admins that record
expiration is controlled by RRSIG expiration and not TTL, so the
signature period should take into account how long the domain can afford
to wait for the TLSA record to expire in the event of a server key
compromise.

We should probably add a reminder that clients must exercise care that
TAs introduced by type 2 aren't usable for validation of other TLS
connections. It should probably be a MUST somewhere in the text, but I'm
not sure where it would best fit.

In section 11 (with the help of id nits):
* draft-ietf-dane-use-cases has been published as RFC 6394
* draft-ietf-tls-rfc4347-bis has been published as RFC 6347
* Downref: Normative reference to an Informational RFC (the use cases)

In section A.1:
]   When creating TLSA record with certificate usage type 0 (CA
Grammar: s/record/records/

]  and 1 (SubjectPublicKeyInfo).  A careful choice is required because
]  the different methods for building trust chains are used by different
Grammar: s/because the/because/

In section A.1.1:
]  o  The client may not have an associated root certificate in trust
]     store and instead uses a cross-certificate with an identical
Grammar: s/in trust/in its trust/

HTH

-- 
Scott Schmit