Subject: [dane] dane-protocol-16 comments on Sec 1 to 2.1.4

From: John Gilmore <[email-masked]>
Date: Mon, 13 Feb 2012 14:53:23 -0800

[Formatting note: I'll put my commentary in [brackets], original -16
text indented, and suggested replacement text unbracketed and at the
left margin.]

[In general, the complicated parts of this protocol are in how it
interacts with the pre-existing complicated parts of PKIX.  I suggest
that we start off the reader by explaining the least complicated use
cases (e.g. Usage type 3 which avoids invoking signature validation
chains), and then move into the more complicated cases in which new
TLSA constraints or trust anchors get injected into the undefined
process of signature validation chain construction.]

[In general, we should decide whether we are referring to "this
document" or "this protocol" when we make self-referential statements
like:

  The selectors defined in this document are...
  This document does not specify how DNSSEC validation occurs...
  The use cases from Section 3 of [RFC6394] are covered in this protocol...
  ...if extensions to this protocol are made...
  The security of the protocols described in this document...

I am agnostic on the question, merely seeking consistency.]

[What follows starts from section 1, graf 1:]

   server.  Currently, the client must extract the domain name from the
   certificate, must trust a trust anchor upon which the server's
   certificate is rooted, and must successfully validate the
   certificate.

["must trust a trust anchor" seems recursively defined, and should
probably be clarified.  How about "must have access to a reliable
trust anchor (a locally trusted key) from which a signature validation
chain to the server's certificate can be built"?]

[My suggestion uses the "signature validation chain" terminology,
which we haven't defined.  We only use the term in the pseudocode in
the Appendix, so far.  In one other place we talk about "signature
validation" but there we're talking about validating DNSSEC
signatures.  Ideas?]

   Some people want a different way to authenticate the association of
   the server's certificate with the intended domain name without
   trusting an external certificate authority (CA).  Given that the DNS
   administrator for a domain name is authorized to give identifying
   information about the zone, it makes sense to allow that
   administrator to also make an authoritative binding between the
   domain name and a certificate that might be used by a host at that
   domain name.  The easiest way to do this is to use the DNS.

This protocol [or document] describes a different way to authenticate
the association of the server's certificate with the intended domain
name, without trusting an external certificate authority (CA).  The
DNS administrator for a domain name is already authorized to give
identifying information about the zone.  Using this protocol, the
domain administrator can make an authoritative binding between the
domain name, and a certificate that will be used by a TLS server in
that domain.

   1.1.  Certificate Associations

   A certificate association is formed from a piece of information
   identifying a certificate with the domain name where the data is
   found.  The data used to identify the certificate consists of either
   a PKIX certificate or a hash of a PKIX certificate.  When using the
   certificate itself in the certificate association, the entire
   certificate in the normal format is used.

[This is presented without preface, as if we were going to define the
term, but we don't really define it.  It's also in the passive voice
("is formed"); who forms it?]

["where the data is found"?  Where WHAT data is found?]

[I found the "certificate association" terminology to be confusing,
partly because it looks similar to "certifying authority" but isn't at
all related.  It seems that the meaning you want is that a
"certificate association" is what a TLSA record describes.  In that
case we could just call it a TLSA record, avoiding the creation of a
redundant concept.  Later in the document, when defining or describing
the TLSA record, the RDATA field is defined to hold the "certificate
association data" -- so is the certificate association the trailing
part of the RDATA, or is it the whole TLSA record?  Do we really need
this concept?  I would call the trailing part of the RDATA the
"certificate or its identifier".]

[If we keep the concept, how about defining it this way:]

A "certificate association" is a relationship formed by securely
identifying a certificate with a domain name.  [move remaining
sentences to sec 2.1.4]

1.1.  Protocol overview

A domain administrator creates a TLSA record to securely identify a
certificate with a domain name.  He or she publishes the record in the
secured DNS zone that contains the TLS server's domain name.  Each
TLSA record identifies a particular certificate that is valid for
securing TLS communication.  The administrator may create several TLSA
records to provide several ways to validate possible certificates.
Multiple records are useful when a server is changing from one
certificate to another, or when server software running on a
single host may provide different certificates to different clients.

Each TLS client retrieves the set of published TLSA records, validates
them with DNSSEC, and compares them to the certificates provided by
the TLS server.  If they do not match, the client MUST treat the TLS
connection as insecure.

   This document only applies
   to PKIX [RFC5280] certificates, not certificates of other formats.

[This statement seems to be in the wrong place.  I'm not sure where it
belongs, but not in the definition of a c...a...  Should it instead
state "TLSA records can only contain PKIX [RFC 5280] certificates",
rather than talking about what this document applies to?  Or should
the text make it clear that other certificate formats can be used, but
only as extensions to the TLSA record defined in this document?  In
the RDATA Usage field description we take that tack on this question.]

   1.2.  Securing Certificate Associations

   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.

1.2.  Securing TLSA Records

Each TLSA record associates its domain name with the certificate in its
RDATA field.  Each TLSA record needs to be be protected by DNSSEC.

   DNSSEC, which is defined in RFCs 4033, 4034, and 4035 ([RFC4033],
   [RFC4034], and [RFC4035]), uses cryptographic keys and digital
   signatures to provide authentication of DNS data.  Information that
   is retrieved from the DNS and that is validated using DNSSEC is
   thereby proved to be the authoritative data.  The DNSSEC signature
   MUST be validated on all responses that use DNSSEC in order to assure
   the proof of origin of the data.  This document does not specify how
   DNSSEC validation occurs because there are many different proposals
   for how a client might get validated DNSSEC results.

   This document only relates to securely getting the DNS information
   for the certificate association using DNSSEC; other secure DNS
   mechanisms are out of scope.

[removing passive voice]

DNSSEC, which is defined in RFCs 4033, 4034, and 4035 ([RFC4033],
[RFC4034], and [RFC4035]), uses cryptographic keys and digital
signatures to provide authentication of DNS data.  Clients retrieve
information from the DNS and validate it using DNSSEC, thereby proving
it to be the authoritative information.  The client MUST validate the
DNSSEC signatures on all responses that use DNSSEC, in order to assure
the data's proof of origin.  This protocol does not specify exactly how
clients perform DNSSEC validation, because there are many different
proposals for how a client might get validated DNSSEC results.  This
protocol does require that the client have a way to make DNS queries,
and a way to validate the results of those queries via DNSSEC.

This protocol only relates to clients which obtain the TLSA record using
DNSSEC; other mechanisms are out of scope.

   1.3.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   This document also makes use of standard PKIX, DNSSEC, and TLS
   terminology.  See [RFC5280], [RFC4033], and [RFC5246] respectively,
   for these terms.  In addition, terms related to TLS-protected
   application services and DNS names are taken from [RFC6125].

[active voice]

1.3.  Terminology

Please interpret the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
and "OPTIONAL" in this document as described in RFC 2119 [RFC2119].

We also use standard PKIX, DNSSEC, and TLS terminology, defined in
[RFC5280], [RFC4033], and [RFC5246].  In addition, we use terms
related to TLS-protected application services and DNS names from
[RFC6125].

   2.  The TLSA Resource Record

   The TLSA DNS resource record (RR) is used to associate a certificate
   with the domain name where the record is found.  The semantics of how
   the TLSA RR is interpreted are given later in this document.

2.  Fields in the TLSA Resource Record 

DNS Resource Records are generally defined in [RFC 1034] and [RFC 1035].

The TLSA DNS resource record (RR) associates a certificate with the
domain name where the record is found.  We describe the detailed
semantics of the TLSA RR later in this document.

   2.1.  TLSA RDATA Wire Format

   The RDATA for a TLSA RR consists of a one octet usage type field, a
   one octet selector field, a one octet matching type field and the
   certificate association data field.

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Usage     |   Selector    | Matching Type |               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               /
   /                                                               /
   /                 Certificate Association Data                  /
   /                                                               /
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

2.1.  TLSA RDATA Wire Format

The RDATA for a TLSA RR consists of a one octet usage type field, a
one octet selector field, a one octet matching type field and the
certificate or its identifier.

		     1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Usage     |   Selector    | Matching Type |               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               /
/                                                               /
/                 Certificate or its Identifier                 /
/                                                               /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      0 -- The target certificate MUST pass PKIX validation and MUST
      chain through a CA certificate matching the TLSA record

      1 -- The target certificate MUST pass PKIX validation and MUST
      match the TLSA record

      2 -- The target certificate MUST pass PKIX validation, with any
      certificate matching the TLSA record considered to be a trust
      anchor for this validation

      3 -- The target certificate MUST match the TLSA record

[I would suggest renumbering these so that the simplest form is first,
i.e. 3 would become 0.  How the others are numbered I don't care.]

   2.1.2.  The Selector Field

   A one-octet value, called "selector", specifying which part of the
   TLS certificate presented by the server will be matched against the
   association data.

[active voice, and changed name of final RDATA field]

2.1.2.  The Selector Field

A one-octet value, called "selector", specifies which part of the
TLS certificate presented by the server will be matched against the
TLSA record.

   2.1.3.  The Matching Type Field

   A one-octet value, called "matching type", specifying how the
   certificate association is presented.  This value is defined in a new

[active voice]

2.1.3.  The Matching Type Field

A one-octet value, called "matching type", specifies how the
certificate association is presented.  This value is defined in a new

   2.1.4.  The Certificate Association Data Field

   The "certificate association data" to be matched.  This field
   contains the data to be matched.  These bytes are either raw data
   (that is, the full certificate or its SubjectPublicKeyInfo, depending
   on the selector) for matching type 0, or the hash of the raw data for
   matching types 1 and 2.  The data refers to the certificate in the
   association, not to the TLS ASN.1 Certificate object.

[rename; and clarify, particularly the last sentence.]

2.1.4.  The Certificate or its Identifier Field

This field contains the data to be matched against the certificates
provided by the TLS server.  If the matching type is 0, these bytes
are the raw data (that is, the full certificate or its
SubjectPublicKeyInfo, depending on the selector).  If the matching
type is 1 or 2, these bytes contain the hash of the full certificate
or its SubjectPublicKeyInfo, again depending on the selector.

In this section, "the full certificate" means a single one of the
individual PKIX [RFC 5280] certificates offered by the TLS server.  It
does not mean the TLS ASN.1 Certificate object in which these
certificates are offered.  When constructing this field, start from
the entire PKIX certificate in the normal DER format, then possibly
extract the SubjectPublicKeyInfo, then possibly hash.

This protocol does not allow the use of certificate formats besides PKIX.
Doing so would be a reasonable subject for future protocol extensions.

   o  The certificate association data field MUST be represented as a
      string of hexadecimal characters.  Whitespace is allowed within
      the string of hexadecimal characters.

o  The Certificate or its Identifier field MUST be represented as a
   string of hexadecimal characters.  Whitespace is allowed within
   the string of hexadecimal characters.

[That's it for this message.  Subsequent suggestions in another message.

	John]