Subject: [apps-discuss] AppsDir review of draft-ietf-dane-protocol-14

From: Barry Leiba <[email-masked]>
Date: Sun, 22 Jan 2012 20:05:39 -0500

An Applications Area Directorate review has been requested for
draft-ietf-dane-protocol-14, and I have been selected as the reviewer
(for background on appsdir, please see
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate).

Summary: The protocol appears solid and useful, and the document does
not seem to have any major issues.  I have some comments below, a few
substantive but most editorial.  I've marked the substantive ones (and
the editorial ones that I think significantly affect the understanding
of the document) with "SUBSTANTIVE".

--------------
Section 1.2

OLD
   DNSSEC, which is defined in RFCs 4033, 4034, and 4035 ([RFC4033],
   [RFC4034], and [RFC4035]), uses cryptographic keys and digital

Trivial, but I think it will read better this way:

NEW
   DNSSEC [RFC4033] [RFC4034] [RFC4035] uses cryptographic keys and digital

OLD
   Information
   retrieved from the DNS and that is validated using DNSSEC is thereby
   proved to be the authoritative data.

The non-parallel construction of the first two clauses made me read
this too many times before I could parse it.

NEW
   Information that is
   retrieved from the DNS and that is validated using DNSSEC is thereby
   proved to be the authoritative data.

--------------
Section 2.1.1

OLD
   This will be an IANA registry in order
   to make it easier to add additional certificate usages in the future.

NEW
   This value is defined in a new IANA registry [see sec 7.2] in order
   to make it easier to add additional certificate usages in the future.

I also suggest adding section references in sections 2.1.2 and 2.1.3,
to the other two IANA registries.

OLD
   formats for certificates, those certificates will need their own
   certificate types.

NEW
   formats for certificates, those certificates will need their own
   certificate usage values.

--------------
Section 2.1.3

SUBSTANTIVE

OLD
   Using the same hash algorithm as is used in the signature in the
   certificate will make it more likely that the TLS client will
   understand this TLSA data.

I think I know what this is meant to say, but I had to work too hard
for it to become clear.  Maybe this?:

NEW
   Because a client support for multiple hash algorithms might be
   limited, it is advisable to use the same hash algorithm for the
   matching type as is used for the signature in the certificate.
   Doing so will increase the likelihood of interoperability.

--------------
Section 2.1.4

SUBSTANTIVE

OLD
   The "association data" to be matched.  The field contains the bytes
   to be matched or the hash of the bytes to be matched.  The source of
   the data to be matched is controlled by the Matching Type field.

It's definitely NOT the "hash of the bytes to be matched", right?  The
hash *is* the set of bytes to be matched.  I know what you're trying
to say, but this seems an imprecise way to say it.  Maybe this?:

NEW
   The "association data" to be matched.  The field contains the bytes
   to be matched -- the raw data, for matching type 0, or the hash of
   the raw data, for matching types 1 and 2.

--------------
Section 2.3
SUBSTANTIVE
The first example has an opening parenthesis after "IN TLSA"; the
second and third don't.

--------------
Section 3

SUBSTANTIVE

   2.  The protocol name of the transport on which a TLS-based service
       is assumed to exist is prepended with an underscore character
       ("_") to become the second left-most label in the prepared domain
       name.  The transport names defined for this protocol are "tcp",
       "udp" and "sctp".

Should there be a registry for these, as well?

--------------
Section 4.1

OLD
   Certificate usage 0 is used to specify a CA certificate, or the
   public key of such a certificate, that the must be found in any of
   the PKIX validation chains

Spurious "the".

NEW
   Certificate usage 0 is used to specify a CA certificate, or the
   public key of such a certificate, that must be found in any of
   the PKIX validation chains

--------------
Section 4.4

OLD
   Some
   specifications such at [RFC6125] detail how to match the identify
   given in a PKIX certificate with those expected by the user.

Two typos here: "such at" and "identify".

NEW
   Some
   specifications such as [RFC6125] detail how to match the identity
   given in a PKIX certificate with those expected by the user.

OLD
   o  If the DNSSEC validation state on the response to the request for
      the TLSA RRset is bogus, this MUST cause TLS not to be started or,
      if the TLS negotiation is already in progress, to cause the
      connection to be aborted.

Non-parallelism.

NEW
   o  If the DNSSEC validation state on the response to the request for
      the TLSA RRset is bogus, this MUST cause TLS not to be started or,
      if the TLS negotiation is already in progress, MUST cause the
      connection to be aborted.

...or, alternatively, remove "to cause" entirely.  I prefer changing
"to" to "MUST"; the repetition is more clear, I think.

OLD
   Clients that validate the DNSSEC signatures themselves MUST either
   use standard DNSSEC validation procedures or a secure transport (such

Misplaced "either".

NEW
   Clients that validate the DNSSEC signatures themselves MUST use either
   standard DNSSEC validation procedures or a secure transport (such

Moreover, I find that the parenthesized list separates the "MUST use
secure transport" from "between A and B" with too much, making it easy
to lose the message.  Maybe this?:

SUBSTANTIVE

NEW NEW
   Clients that validate the DNSSEC signatures themselves MUST use either
   standard DNSSEC validation procedures or a secure transport between
   themselves and the entity performing the DNSSEC signature validation.
   Examples of such secure transport are TSIG [RFC2845], SIG(0) [RFC2931],
   and IPsec [RFC6071]. Note that it is not sufficient to use secure
   transport to a DNS resolver that does not do DNSSEC signature validation.

--------------
Section 5
   The different types of certificates for association defined in TLSA
   are matched with various sections of [DANEUSECASES].  The three use
   cases from section 3 of [DANEUSECASES] are covered in this protocol
   as follows:

There are four use cases in DANEUSECASES; you don't mention 3.4
Delegated Services.  Is that an oversight, or should you say, "Three
of the use cases ..." ?

   (note that some of these might be excessively glib)

That seems like an odd thing to say in a completed document, so I
presume you'll either decide to say more or take that parenthesized
statement out.  For my part, I think what's there now is fine.

--------------
Section 6

OLD
   A system creating TLSA records that conforms to this specification
   MUST be able to create TLSA records containing certificate usages 0,
   1 and 2.  A system creating TLSA records that conforms to this
   specification MUST be able to create TLSA records with selectors 0
   (full certificate) and 1 (SubjectPublicKeyInfo).  A system creating
   TLSA records that conforms to this specification MUST be able to
   create TLSA records using matching type 0 (no hash used) and matching
   type 1 (SHA-256), and SHOULD be able to create TLSA records using
   matching type 2 (SHA-512).

Here, the repetition seems clumsy, heavy.  May I suggest this?:

NEW
   A system creating TLSA records that conforms to this specification
   MUST be able to create TLSA records
      o  containing certificate usages 0, 1 and 2,
      o  with selectors 0 (full certificate) and 1 (SubjectPublicKeyInfo), and
      o  using matching type 0 (no hash used) and matching type 1 (SHA-256).
   In addition, the system SHOULD be able to create TLSA records using
   matching type 2 (SHA-512).

Similarly, I suggest this for the next paragraph:

NEW NEXT
   A TLS client conforming to this specification MUST be able to
      o  correctly interpret TLSA records with certificate usages 0,
         1 and 2,
      o  compare a certificate for association with a certificate
         from TLS using selectors type 0 and 1,
      o  compare a certificate for association with a certificate
         from TLS using matching type 0 (no hash used) and
         matching type 1 (SHA-256).
   In addition, the client SHOULD be able to make such comparisons
   using matching type 2 (SHA-512).

--------------
Section 7.2

SUBSTANTIVE

   This document creates a new registry, "Certificate Usages for TLSA
   Resource Records".  The registry policy is "RFC Required".

Have a look at
   http://tools.ietf.org/html/draft-leiba-iana-policy-update
and you'll see where this comment is coming from.  RFC Required might
be the right choice for this registry, and the fact that you're using
Specification Required for the other registries makes me confident
that you've thought about it and chosen for a good reason.  I'd like
to see the reason(s) documented here.  Something like, 'The registry
policy is "RFC Required" because community review of this parameter is
necessary to ensure [blah-blah].'  Reasonable?

--------------
Section 7.3
The other two registry definitions say:

   Applications to the registry can request specific values that have
   yet to be assigned.

...and this one doesn't.  I presume it should for consistency.  Or is
there something else here?

--------------
Section 8

SUBSTANTIVE

   The client, seeing the proxy's new certificate
   for the supposed destination will not set up a TLS session.  Thus,
   such proxies might choose to aggressively block TLSA requests and/or
   responses.

Having not been in on the discussions about this, I'm not sure whether
this is (1) advice to SSL proxies, (2) a warning to intended hosts, or
(3) a warning to clients.  If (1), I'm also not sure how it would do
the blocking, and whether something should be said about that here.
If (2) or (3), I'm also not sure what, if anything, they should be
advised to do about the situation.

--------------
Appendix A

I started to correct errors here, but then found that there are *so*
many typos, missing "the", number disagreements, and other grammatical
errors in the appendix that I just have to suggest to Paul that you go
through it and fix them -- I'm sure they're a result of non-native
English writing.  The RFC Editor will eventually fix what's left, but
we should do our best first.

--------------

Barry

---

From: Barry Leiba <[email-masked]>
Date: Tue, 24 Jan 2012 10:40:29 -0500

> draft-ietf-dane-protocol-14, and I have been selected as the reviewer

Just for the record:

* This was requested as an early review; the document is not even in
working-group last call yet.

* The document editors and WG chairs responded to me privately, and
the editors will be making most of the changes I've suggested (and I'm
happy with the responses).

* I'll re-review during WGLC, and give it a check during IETF Last Call as well.

Barry