Subject: [dane] "need not change across certificate renewals with the same key"

From: Kyle Rose <[email-masked]>
Date: Tue, 12 May 2015 08:46:54 -0400

I wasn't able to find anything in the archives addressing this, so
apologies in advance if this has been discussed.

The draft statement that the record "need not change across certificate
renewals with the same key" seems misleading. If anything in the
certificate changes—and typically the expiration date will change if a
certificate is regenerated using common tools, whether or not it is likely
to be honored by a client—the certificate digest will change. Since
presumably the TLSA record digest is of the entire certificate and not
simply of the public key, as the authenticity of much of the metadata
within the certificate is still of interest to clients, this means the
digest in the TLSA record will change.

It seems in fact that any renewal of the certificate producing anything
other than a bit-identical output would necessitate a record change.

Or what am I missing?

Kyle

---

From: Paul Wouters <[email-masked]>
Date: Tue, 12 May 2015 08:52:51 -0400 (EDT)

On Tue, 12 May 2015, Kyle Rose wrote:

> The draft statement that the record "need not change across certificate renewals with the same key" seems misleading. If
> anything in the certificate changes—and typically the expiration date will change if a certificate is regenerated using
> common tools, whether or not it is likely to be honored by a client—the certificate digest will change. Since presumably the
> TLSA record digest is of the entire certificate and not simply of the public key, as the authenticity of much of the
> metadata within the certificate is still of interest to clients, this means the digest in the TLSA record will change.
> 
> It seems in fact that any renewal of the certificate producing anything other than a bit-identical output would necessitate
> a record change.
> 
> Or what am I missing?

https://tools.ietf.org/html/rfc6698#section-2.1.2

There are two main pubishers of TLSA records. Those who want an addotional
non-CA third party certificate validator, and those who want to replace
the CA.

For those replacing the CA, the only item of interest in the
certificate is the public key part. These people likely will
need to allow for CA's for the next little while, so they
will do the regular "renewing" of the certificate, but they
won't care to put any of that under TLSA verification, as
it is just a CA/PKIX place holder.

Paul

---

From: Kyle Rose <[email-masked]>
Date: Tue, 12 May 2015 09:26:24 -0400

If the DANE-EE entry has a SubjectPublicKeyInfo hash, then the metadata
within the certificate can be trusted only if the certificate signature is
validated against a trust anchor: a self-signed certificate is sufficient
(and probably ideal) here, since the client has already trusted the public
key via DANE.

Absent signature verification, the client should probably throw away the
rest of the certificate to avoid the temptation of trusting any of it: it's
simply unclear to me what are the security implications to the universe of
clients of having unauthenticated data present in the certificate or
associated client context. What I mean is, what data from certificates
other than the public key modify clients' behaviors? It may be "nothing"
(i.e., that "the only item of interest in the certificate is the public key
part"), but it's not clear to me that this is the case.

Kyle

On Tue, May 12, 2015 at 8:52 AM, Paul Wouters <[email-masked]> wrote:

>> renewals with the same key" seems misleading. If
>> anything in the certificate changes—and typically the expiration date
>> will change if a certificate is regenerated using
>> common tools, whether or not it is likely to be honored by a client—the
>> certificate digest will change. Since presumably the
>> TLSA record digest is of the entire certificate and not simply of the
>> public key, as the authenticity of much of the
>> metadata within the certificate is still of interest to clients, this
>> means the digest in the TLSA record will change.
>>

---

From: Paul Wouters <[email-masked]>
Date: Tue, 12 May 2015 10:21:21 -0400 (EDT)

On Tue, 12 May 2015, Kyle Rose wrote:

> If the DANE-EE entry has a SubjectPublicKeyInfo hash, then the metadata within the certificate can be trusted only if the certificate signature is validated against a trust anchor: a self-signed certificate is
> sufficient (and probably ideal) here, since the client has already trusted the public key via DANE.

None of the meta-data would be used and does not need to be trusted.

> Absent signature verification, the client should probably throw away the rest of the certificate to avoid the temptation of trusting any of it: it's simply unclear to me what are the security implications to
> the universe of clients of having unauthenticated data present in the certificate or associated client context. What I mean is, what data from certificates other than the public key modify clients' behaviors?
> It may be "nothing" (i.e., that "the only item of interest in the certificate is the public key part"), but it's not clear to me that this is the case.

Right. It should not be used and software needs to be updated to not use
or display any of that information not covered by any assurance of PKIX
or DANE.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 12 May 2015 16:29:35 +0000

On Tue, May 12, 2015 at 08:46:54AM -0400, Kyle Rose wrote:

> renewals with the same key" seems misleading.

This is taken out of context.  The full text in Section 5.1 of
draft-ietf-dane-ops is:

   TLSA records published for DANE servers SHOULD, as a best practice,
   be "DANE-EE(3) SPKI(1) SHA2-256(1)" records.  Since all DANE
   implementations are required to support SHA2-256, this record type
   works for all clients and need not change across certificate renewals
   with the same key.

Thus the statement in question is specifically about "3 1 1" records,
which bind *only* the key and not the rest of the certificate.

> other than a bit-identical output would necessitate a record change.

With "3 1 1" the digest is a key digest, not a full certificate digest.

-- 
	Viktor.