Subject: [dane] Draft -17

From: Paul Hoffman <[email-masked]>
Date: Wed, 29 Feb 2012 07:50:41 -0800

Greetings again. As you can see, we turned in -17 with what we think are all the changes asked for by the WG chairs. Please review the changes at <http://tools.ietf.org/rfcdiff?url2=draft-ietf-dane-protocol-17>, and let the list and chairs know if you think we missed anything that the chairs asked us to do.

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Wed, 29 Feb 2012 11:20:18 -0500

Thank you Paul.

<chair hat>
Dear WG,

Please note that the authors have folded in comments and changes as the chairs judged consensus. If any requests were missed, or consensus was incorrectly judged, the fault lies squarely with the chairs, and not the authors. 
In other words, direct flames at us, not the authors...

W

</chair hat>
On Feb 29, 2012, at 10:50 AM, Paul Hoffman wrote:

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

---

From: John Gilmore <[email-masked]>
Date: Wed, 29 Feb 2012 15:22:18 -0800

Thank you, editors!  -17 is a big improvement, editorially, over -16.
Most of my comments are small nits, though there's one 2-paragraph
insertion that I think is worthwhile.

Comments:

In 1.2:
> There are many use cases for such functionality. [RFC6394] lists the	
> ones that the DNS RRtype in this document are meant to apply.

Perhaps you meant "to apply to".  A clearer wording for the last
sentence is "This document's DNS RRtypes are designed to apply to the
use cases listed in [RFC6394]."  Shouldn't we define RRtype the first
time we use it, e.g. "This document's DNS Resource Record types
(RRtypes) are designed to apply to the use cases listed in [RFC6394]."
But why are we talking about RRtypes here in a general statement?
It seems to be because we're unwilling to talk about this document
as defining a protocol, though it clearly defines more than an RRtype.

In 2.1.1 under cert usage 2:

> specify a new trust anchor, for example if the domain issues its	
> own certificates under its own CA that is not expected to be in	
> the end users' collection of trust anchors.

"the end users' collection" uses both the definite article and a
plural possessive of a singular noun.  Since we are talking about
many end users, the plural is right; the singular is not.
How about saying "many end users' collections"?

In section 4:
> An implementation of this protocol makes a DNS query for TLSA records...

If you wanted to avoid the p-word, this sentence will need changing.

> If a certificate association contains a matching type or certificate	
> association data that uses a cryptographic algorithm that is	
> considered too weak for the TLS client's policy, the certificate	
> association MUST be marked as unusable.

s/marked as/considered/g

In section 5:
> Roll-over -- Section 4 states that applications must not cache TLSA	
> records beyond their TTL expiration. This ensures that clients 
> will not latch onto assertions made by expired TLSA records, and 
> will be able to transition between using one DANE mechanism to 
> another.

Section 4 no longer says that about TTL cacheing, so this will need
modification.  Perhaps refer now to section 8.1?  But that describes
security considerations, not requirements on implementations.

I'd also suggest replacing the last phrase with "will be able to
transition from using one DANE public key or certificate usage type to
another."

In section 6:
> A system creating TLSA records that conforms to this specification
> MUST be able to create TLSA records containing certificate usages 0,
> 1, 2, and 3.  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).

I thought we had agreed to pull this paragraph.

In section 7.2:
>  3 Domain-issued certificate             [This]

There's an extra space before "[This]".

In section 8:
> The security of the DNS RRtype described in this document relies on	
> the security of DNSSEC...

This is almost a tautology, caused by replacing "protocol" with "DNS
RRtype".  But it's not the security of the RRtype that the reader should
be concerned with -- it's the security of the TLS-protected communication.
Perhaps we should say so.

> A better design for
> authenticating DNS would be to have the same level of authentication
> used for all DNS additions and changes for a particular owner name.

I'd replace "owner name" with "domain name", since owner name is not
defined anywhere, while everyone knows what a domain name is.

> In such environments,
> the using TLSA records will prevent the SSL proxy from functioning

More clumsy wording used in an attempt to avoid the p-word.
If we can't say the obvious, at least remove "the" from "the using".

In section 8.1:
> Implementations need to
> be cautious in assuming the continuing validity of an TLSA records/
> DNS name association.

"An TLSA records" sounds bad, even though I know it ultimately refers
to "an association".  Perhaps you mean "Implementations need to be
cautious in assuming the continuing validity of the association
between TLSA records and a domain name."  But that is almost a
tautology, caused by the confusing "association" language.  Every DNS
resource record produces an association between the domain name and
the contents of the record.  That association is always only good for
a brief time, specified in the TTL.  So what are we really trying to
say here?

> If implementations cache the results of domain name lookups in order
> to achieve a performance improvement, they MUST observe the TTL
> information reported by DNS.  Implementations that fail to follow
> this rule this rule could be spoofed when a previously-accessed
> server's TLSA record changes, such as during a certificate rollover.

I don't see how this can cause an implementation to be "spoofed".  If
clients cache beyond the TTL, they'll use the old TLSA records, and
may be unable to access a TLS server that uses a new certificate.  But
that's denial of service, not spoofing.  The only way I can see to be
spoofed is if the TLS server's previous private-key credentials had
been exposed (and then this is why the TLS server's certificate has
changed and why the corresponding TLSA records were changed).  In that
case, someone who obtained the server's previous private-key
credentials, and who can also act as a man-in-the-middle of the TLS
connection, can spoof clients who use the old TLSA records.  But
that's a much more detailed and less likely scenario than the one
described.

In section A.1:

> When creating TLSA records care must be taken to avoid
> misconfigurations.  Section 4 of this document states that a TLSA
> RRset whose validation state is secure MUST be used.  This means that
> the existence of such a RRset effectively disables other forms of
> name and path validation.  A misconfigured TLSA RRset will
> effectively disable access to the TLS server for all conforming
> clients, and this document does not provide any means of making a
> gradual transition to using TLSA.

I agree that this paragraph needs to be in the document.  I think it
belongs in the security considerations section rather than in an
appendix.

Also, what is a "conforming client"?  To what does it conform?
Heaven forefend that it conform to a "p-word"!

Here there's an important paragraph or 2 missing, just before "When
creating TLSA records with certificate usage type 0 (CA Certificate)
or type 2 (Trust Anchor)...".  Before we spend a few pages saying
why it can be tricky to use TLSA in many ways, let's describe a
straightforward, non-tricky way to transition to using TLSA:

Many TLS server operators will be looking for a straightforward way to
transition from only supporting traditional CA-based TLS, or
traditional TLS using self-signed certificates, to supporting both
traditional TLS and TLSA-based TLS.  The most straightforward way to
do so is to add a TLSA record with certificate usage 3 which matches
the TLS server's current end entity certificate.  At the moment that
the operator signs the TLSA record and publishes it in the
DNS, clients which understand TLSA records will switch to validating
the end entity certificate by comparing it directly to the TLSA
record.  At the same time, clients which do not understand the TLSA
record will continue validating the TLS server using traditional TLS
as always.  This situation will persist over time without
interoperability problems.

When using certificate usage 3 (domain-issued certificate), whenever
the TLS server's end entity certificate is eventually replaced
(perhaps on a regular rotation schedule, or due to a security breach),
the operator must update the TLSA record to match the new end entity
certificate.  During this process, operators should also have their CA
sign their new certificate as usual (or they should self-sign it) to
preserve access for traditional TLS clients.  Preplanning will avoid
TLSA-based clients being briefly unable to reach the TLS server during
the transition.  If possible, at least one TTL-period before the TLS
server changes its end-entity certificate, the operator should sign
and publish both the new and old TLSA records.  (For example, if your
TTL is 24 hours, publish both records 24 hours or more before you
update the TLS server's certificate.)  Immediately after the operator
changes the TLS server's certificate, whether or not they had
published both TLSA records, they should remove the old TLSA record, and
sign and publish a TLSA RRset consisting of just the new TLSA record.

> When creating TLSA records with certificate usage type 0 (CA
> Certificate) or type 2 (Trust Anchor), one needs to understand the
> implications when choosing between selector type 0 (full certificate)
> and 1 (SubjectPublicKeyInfo).  A careful choice is required because
> different methods for building trust chains are used by different TLS
> clients.  The following outlines the cases that one should be aware
> of and discusses the implications of the choice of selector type.

I'd rewrite to say (particularly after inserting the above graf):
TLSA server operators who create TLSA records with certificate types
0, 1, or 2 must take more care, because of the variability in how TLS
clients build trust chains.  When creating TLSA records with
certificate usage type 0 (CA Certificate) or type 2 (Trust Anchor),
one needs to understand the implications.  The following outlines the
cases that TLS server operators should be aware of.

I don't understand this phrase from the document:
> one needs to understand the
> implications when choosing between selector type 0 (full certificate)
> and 1 (SubjectPublicKeyInfo).

We do have a section later about this (A.1.2), but it seems to me
that the much bigger question for TLS server operators is which
certificate usage type to use, and which certificate it should identify.
Whether it matches the whole cert, or just the public key; and whether it
hashes, or provides the whole thing, are secondary to that initial
choice that we don't even discuss.

For example, the TLS server operator could create a TLSA record
that identifies:

  the end-entity certificate
  the CA certificate that traditionally signs the EE certificate
  some other intermediate CA certificate
  a trust anchor
  and/or, multiple TLSA records that identify more than one of the above.

In several places we suggest identifying the end-entity certificate
as a way to reduce interoperability headaches.  Can we say more than
that, e.g. about what those headaches might be when the TLS server
operator makes one of the other choices?

> Certificate usage 2 is not affected by the different types of chain
> building when the end entity certificate is the same as the trust
> anchor certificate.

Here's a clearer way to say it, which also points out that usage 3 is
also immune from the troubles discussed: "Certificate usages 2 and 3
are not affected by the different types of chain building, if the end
entity certificate provided by the TLS server is the same as the
certificate identified by (or provided in) the TLSA record."

In section A.1.2.2:
> One specific use-case should be noted: creating a TLSA association to
> certificate I1 that directly signed end entity certificate S1 of the
> server.  Since the key used to sign S1 is fixed, association to I1
> must succeed: if a client swaps I1 for I2 (a different certificate),
> its SPKI must match SPKI of I1.  Such and association would not
> suffer from a false-negative failure on client's side if the client
> uses a reissued CA certificate I2 in place of I1.

A few issues here.  This is very dense and hard to understand; it took
me a few readings.  Second, we use "SPKI" without defining it (the
previous graf says SubjectPublicKeyInfo and is where we could hang a
"(SPKI)").  Third, "Such and association" should be "Such an
association".

In Appendix C:

It's not clear whether these examples all refer to the exact same self-signed
certificate.  If they do, the lead paragraph should say so.  If they
don't refer to the same self-signed cert, then perhaps they should.

Examples using Matching type 3 should also be provided.  (Is there a
prejudice in this document against type 3?)

Thanks again...

	John

---

From: Paul Wouters <[email-masked]>
Date: Wed, 29 Feb 2012 23:44:26 -0500 (EST)

On Wed, 29 Feb 2012, John Gilmore wrote:

> This situation will persist over time without

I think you mean "This situation can persist over time ....."

> sign and publish a TLSA RRset consisting of just the new TLSA record.

This is a rather piece of text and only covers ony specific scenario.
I think it will actually be common that domain owners will publish their
personal CA certs instead of end entity certificates (or if they don't
use their own CA, they probably just go straight for bare keys in TLSA,
though keeping it wrapped in a regular cert for compatibility)

Perhaps something more generic like:

If the DNS operator needs to rollover to a new TLSA record, it should
prepublish the new TLSA record along with the old TLSA recrod for at
least as long as the TTL on the old TLSA record, before removing that
old TLSA record from the zone. Some people might consider prepublishing
a TLSA record for a key that is stored offline, to use in case of a
server compromise, so that a compromised certificate can be removed
immediately.

> operator makes one of the other choices?

Using your own CA is also more flexible when quickly changing
certificates on compromised hosts. You don't have to wait any TTL period
to change the certificate, as long as the CA itself is not compromised.

Paul