Subject: [xmpp] Fwd: I-D Action: draft-miller-xmpp-dnssec-prooftype-01.txt

From: Matt Miller <[email-masked]>
Date: Fri, 8 Jun 2012 14:27:54 -0600

FYI, version -01 published based on feedback.

- m&m

Matt Miller - <[email-masked]>
Cisco Systems, Inc.

Begin forwarded message:

> From: [email-masked]
> Date: June 8, 2012 14:22:12 MDT
> To: [email-masked]
> Subject: I-D Action: draft-miller-xmpp-dnssec-prooftype-01.txt
> Reply-To: [email-masked]
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : Using DNSSEC and DANE as a Prooftype for XMPP Delegation
> 	Author(s)       : Matthew Miller
>                          Peter Saint-Andre
> 	Filename        : draft-miller-xmpp-dnssec-prooftype-01.txt
> 	Pages           : 7
> 	Date            : 2012-06-08
> 
>   This document specifies how to use DNSSEC and DANE to securely
>   delegate an XMPP service identified by a domain to a host associated
>   with a different domain.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-miller-xmpp-dnssec-prooftype-01.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-miller-xmpp-dnssec-prooftype-01.txt
> 
> The IETF datatracker page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-miller-xmpp-dnssec-prooftype/
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Matt Miller <[email-masked]>
Date: Wed, 27 Jun 2012 10:19:39 -0600

On Jun 27, 2012, at 09:16, Philipp Hancke wrote:

> i'm pondering on the proof name. The prooftype is using dnssec, but uses it to extend the 6125 to allow secure delegation.
> I.e. it either explains how to do delegation within a PKI prooftype or is a proof PKI-Delegation proof.
> 
> DNSSEC alone might (mostly in the context of s2s and server dialback) be a different proof (used by the connecting server instead of dialbacks current faith in insecure dns).
> 

First; Peter and I will be submitting a new DNA (Domain Name Associations) draft soon, which defines a few terms like "prooftype", "delegation method", and "assertion mechanism".  The goal is to have it published before the end of the week, so stay tuned!

I don't think if DNSSEC in and of itself is really a proof; it's not providing verification material directly.  I do think it is a delegation method, which then makes dialback keys a worthwhile prooftype!

- m&m

---

From: Philipp Hancke <[email-masked]>
Date: Wed, 27 Jun 2012 19:29:19 +0200

> I don't think if DNSSEC in and of itself is really a proof; it's not providing verification material directly.  I do think it is a delegation method, which then makes dialback keys a worthwhile pro…

I expect dial-back keys (the xep 0185 stuff) to (gradually) become 
obsolete. The cridlandish samecert optimization yields a similar proof 
of possession using the shared private x509 key and has less 
round-trips. There are a few cases where this does not work, typically 
large sites that use multiple certificates, but one might expect them to 
deploy DANE.

DNSSEC still helps to ensure that you send stanzas to the right peer.

---

From: Philipp Hancke <[email-masked]>
Date: Wed, 27 Jun 2012 17:16:40 +0200 (CEST)

i'm pondering on the proof name. The prooftype is using dnssec, but uses 
it to extend the 6125 to allow secure delegation.
I.e. it either explains how to do delegation within a PKI prooftype or is 
a proof PKI-Delegation proof.

DNSSEC alone might (mostly in the context of s2s and server dialback) be a 
different proof (used by the connecting server instead of dialbacks 
current faith in insecure dns).

Thoughts?