Subject: [dane] A browser's myopic view redux: DNSSEC stapled self-signed X.509 certificates

From: =JeffH <[email-masked]>
Date: Fri, 17 Jun 2011 15:03:41 -0700

of posible interest: Adam Langley's blog post from yesterday...

DNSSEC authenticated HTTPS in Chrome (16 Jun 2011)
http://www.imperialviolet.org/2011/06/16/dnssecchrome.html

=JeffH

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 24 Jun 2011 17:49:27 -0400

Thanks for pointing this out.

Couple of notes:

- This mechanism uses the CAA mechanism from draft-ietf-pkix-caa with the "Relying Application Use" bit set -- the one that conflicts with DANE.  

- This mechanism would actually not be implementable with DANE, because the "stapled" DNSSEC information is included in the cert -- including the terminal CAA record.  So if DANE (protocol-07) were used instead of CAA, then the cert would have to include a hash of itself, which is kind of an impossibility.

- These certs have subject==issuer=="DNSSEC Signed".  That breaks RFC 6125 rather badly, but since the certs are self-signed maybe that's not a big deal.

- The DNSSEC information is held in a certificate extension.  The format of this extension would be a nice PKIX draft.

--Richard

On Jun 17, 2011, at 6:03 PM, =JeffH wrote:

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

---

From: Adam Langley <[email-masked]>
Date: Sat, 25 Jun 2011 10:05:41 -0400

> - This mechanism would actually not be implementable with DANE, because the "stapled" DNSSEC information is included in the cert -- including the terminal CAA record.  So if DANE (protocol-07) were…

Although added after I wrote that code, I believe that DANE could
support it without a hash cycle by using type 3:

http://tools.ietf.org/html/draft-ietf-dane-protocol-07#section-2.1.1

> - These certs have subject==issuer=="DNSSEC Signed".  That breaks RFC 6125 rather badly, but since the certs are self-signed maybe that's not a big deal.

I considered enforcing that the certificates have a certain form but I
didn't in the end. It might still be a good idea in the future but,
for now, the "DNSSEC Signed" string is just for clarity and just a
convention in the example generating code.

> - The DNSSEC information is held in a certificate extension.  The format of this extension would be a nice PKIX draft.

Based on other comments from people, it does seem that a way of
serialising an arbitrary DNS record with DNSSEC proof would be useful.
I'll write it up at some point.

Cheers

AGL

-- 
Adam Langley [email-masked] http://www.imperialviolet.org

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Sat, 25 Jun 2011 12:30:33 -0400

> I'll write it up at some point.

Very much so for CAA as DNSSEC only adds value to CAA if the CAs have a
means of archiving the DNSSEC chain on the CAA record that they claim gave
them authorization.

If this is a standard we could imagine a scheme in which CAs keep the
pickled DNSSEC-CAA chain in a public repository.

A big concern for me is that I recently heard a report of an organization
that I presume to be a national security team attempting to compromise a
trusted third party through extortion.

The only reliable security control in such circumstances is multi-party
control with non-repudiable audit logs of all activity.

-- 
Website: http://hallambaker.com/

---

From: Paul Wouters <[email-masked]>
Date: Sun, 26 Jun 2011 13:02:39 -0400 (EDT)

> I'll write it up at some point.

While doing a negotiation where both parties present their dnssec signed
chain from the root down to their first common trusted ancestor is a good
that idea that has been floating around for a while, encapsulating this
in PKIX and storing it at CA's as PHB suggests seems to like a terrible
idea. DNS(SEC) assumes properties based on TTL and RRSIG expiry. Mixing
those up with PKIX signatures and offline storage could only lead to
ignoring dnssec validated properties.

While I encourage the use of DNSSEC as a bandaid for PKIX, it is important
to realise a bandaid is no replacement for proper care.

Paul
ps. The first I heard of this was when Michael Richardson proposed
two offline devices could exchange their DNSSEC chain from the root to
themselves . They would be able to validate each other by receiving each
others chain to (at worst) the commonly trusted root. Andrew encouraged
me to write a draft in my copious spare time, which alas, has not happened.