Subject: [xmpp] Commonality of proof types

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 28 Mar 2012 16:12:52 +0200

Just musing on what proof types look like...

During the DANE process, Adam Langley proposed a way to serialize 
"DNSSEC chains" [1].  Basically, you write a file with all the DNS 
records you need to chain back from some record to the root.  I wonder 
if this would be a nice format for the .well-known proof type.

For domains that support DNSSEC, at least to the level of having a DS, 
this approach has the advantage of not depending on HTTPS for security. 
  After all, relying on HTTPS for our proof type is just kicking the can 
from a domain where we're not comfortable with hosting providers having 
certs in their clients' names (XMPP) to one where we are (HTTP).

Domains that don't support DNSSEC won't be able to construct a chain all 
the way back to the root, but it seems like we could specify that in 
that case, you just provision the chain as far up as you can (or just 
put in a DANE record), and rely on HTTPS.  At least it provides a smooth 
path forward as more people deploy DNSSEC.

And in any case, there are already open-source encoding and validation 
tools available [2].

Just a thought,
--Richard

[1] <http://tools.ietf.org/html/draft-agl-dane-serializechain-01>
[2] <http://www.imperialviolet.org/2011/06/16/dnssecchrome.html>

---

From: Dave Cridland <[email-masked]>
Date: Wed, 28 Mar 2012 16:37:02 +0100

> Just musing on what proof types look like...

That smells like it's somewhat combining the proof types.

That is, you're saying we'd use DNSSEC if possible, but to maximize  
the potential of it working, we'd serialize the chain and stick it  
somewhere well-known, secured by HTTPS as a final fallback.

The serialization of the chain is basically a potted set of the DNS  
answers (and their signatures) that you'd have got if you'd gone  
through the DNS anyway. If you can (only) trust the HTTPS cert used  
to secure the blob, you use that.

Does that sounds roughly right?

My only concern is that the "bare" certificate in .well-known (as  
exemplified by TurboHalibut) has a very low implementation  
threshold[1], whereas this would invoke DNSSEC quite heavily.

Dave.

[1] - This means it's easy to code.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 28 Mar 2012 17:47:49 +0200

> That is, you're saying we'd use DNSSEC if possible, but to maximize the
> potential of it working, we'd serialize the chain and stick it somewhere
> well-known, secured by HTTPS as a final fallback.
>
> answers (and their signatures) that you'd have got if you'd gone through
> the DNS anyway. If you can (only) trust the HTTPS cert used to secure
> the blob, you use that.
>

Yep, you got it.

> exemplified by TurboHalibut) has a very low implementation threshold[1],
> whereas this would invoke DNSSEC quite heavily.
>
> Dave.
>

Appreciate the concern.  It does help that there are already tools, as in:
<http://www.imperialviolet.org/2011/06/16/dnssecchrome.html>