Subject: Re: [xmpp] Fwd: New Version Notification for draft-barnes-xmpp-dna-00

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 8 Sep 2010 14:19:55 -0400

Hey all,

Haven't seen any comments on this draft or the other DNA draft since  
they were last updated.  Does anyone still care about this problem?

Fishing for comments....

--Richard

On Aug 19, 2010, at 5:31 PM, Richard L. Barnes wrote:

> Hey all,
>
> After the DNA presentation I did at the last IETF, I promised to  
> write an I-D describing the different options and their trade-offs.   
> The document is now available on the IETF website:
> <http://www.ietf.org/id/draft-barnes-xmpp-dna-00.txt>
>
> The document lays out a general process for authenticating inter- 
> domain delegations, and explores some options for how the specifics  
> can work.
>
> Based on the trade-offs discussed in the document, my current  
> favorite solution is to take a pure DNS approach, signing SRV  
> records with DNSSEC and embedding DNSSEC trust anchors in CERT  
> records alongside the SRV records (Corresponding to sections 4.1 and  
> 5.2 in the document).  This is basically the same system I described  
> in Maastricht, with the modification that instead of being passed in  
> the XMPP channel, the certificates are provisioned in the DNS so  
> that the client can look them up and validate the delegation before  
> connecting.
>
> Comments welcome,
> --Richard
>
>
>
> Begin forwarded message:
>
>> From: IETF I-D Submission Tool <[email-masked]>
>> Date: August 19, 2010 5:26:45 PM EDT
>> To: [email-masked]
>> Subject: New Version Notification for draft-barnes-xmpp-dna-00
>>
>>
>> A new version of I-D, draft-barnes-xmpp-dna-00.txt has been  
>> successfully submitted by Richard Barnes and posted to the IETF  
>> repository.
>>
>> Filename:	 draft-barnes-xmpp-dna
>> Revision:	 00
>> Title:		 Domain Name Assertions
>> Creation_date:	 2010-08-19
>> WG ID:		 Independent Submission
>> Number_of_pages: 13
>>
>> Abstract:
>> Many Internet applications allow service delegation via the DNS.
>> However, in the absence of DNSSEC, these delegations are
>> unauthenticated, so clients have to authenticate the delegate as if
>> he were the original service.  This situation causes several
>> operational problems.  This document describes a mechanism for
>> clients to discover and validate information that authenticates DNS-
>> based service delegations, without relying on the global deployment
>> of DNSSEC.
>>
>>
>>
>> The IETF Secretariat.
>>
>>
>
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 08 Sep 2010 12:36:47 -0600

I'm interested and I think others are as well, but folks might be a bit
"reviewed out" right now. :)

On 9/8/10 12:19 PM, Richard L. Barnes wrote:
>> After the DNA presentation I did at the last IETF, I promised to write
>> an I-D describing the different options and their trade-offs.  The
>> document is now available on the IETF website:
>> The document lays out a general process for authenticating
>> inter-domain delegations, and explores some options for how the
>> specifics can work.
>>
>> Based on the trade-offs discussed in the document, my current favorite
>> solution is to take a pure DNS approach, signing SRV records with
>> DNSSEC and embedding DNSSEC trust anchors in CERT records alongside
>> the SRV records (Corresponding to sections 4.1 and 5.2 in the
>> document).  This is basically the same system I described in
>> Maastricht, with the modification that instead of being passed in the
>> XMPP channel, the certificates are provisioned in the DNS so that the
>> client can look them up and validate the delegation before connecting.
>>
>> Comments welcome,
>> --Richard
>>
>>
>>
>> Begin forwarded message:
>>
>>> *From: *IETF I-D Submission Tool <[email-masked]
>>> <mailto:[email-masked]>>
>>> *Date: *August 19, 2010 5:26:45 PM EDT
>>> *To: [email-masked] <mailto:[email-masked]>
>>> *Subject: **New Version Notification for draft-barnes-xmpp-dna-00 *
>>>
>>>

---

From: Ben Campbell <[email-masked]>
Date: Thu, 23 Sep 2010 15:29:43 -0500

This discussion seems to have fizzled. Does anyone still care about the DNA effort? Should we continue the effort, or kill it off?

Thanks!

Ben.

Begin forwarded message:

> From: "Richard L. Barnes" <[email-masked]>
> Date: August 19, 2010 4:31:39 PM CDT
> To: [email-masked]
> Subject: [xmpp] Fwd: New Version Notification for draft-barnes-xmpp-dna-00
> 
> Hey all,
> 
> After the DNA presentation I did at the last IETF, I promised to write an I-D describing the different options and their trade-offs.  The document is now available on the IETF website:
> The document lays out a general process for authenticating inter-domain delegations, and explores some options for how the specifics can work.
> 
> Based on the trade-offs discussed in the document, my current favorite solution is to take a pure DNS approach, signing SRV records with DNSSEC and embedding DNSSEC trust anchors in CERT records alongside the SRV records (Corresponding to sections 4.1 and 5.2 in the document).  This is basically the same system I described in Maastricht, with the modification that instead of being passed in the XMPP channel, the certificates are provisioned in the DNS so that the client can look them up and validate the delegation before connecting.
> 
> Comments welcome,
> --Richard
> 
> 
> 
> Begin forwarded message:
> 
>> A new version of I-D, draft-barnes-xmpp-dna-00.txt has been successfully submitted by Richard Barnes and posted to the IETF repository.
>>

---

From: Kevin Smith <[email-masked]>
Date: Thu, 23 Sep 2010 21:39:53 +0100

On Thu, Sep 23, 2010 at 9:29 PM, Ben Campbell <[email-masked]> wrote:
> This discussion seems to have fizzled. Does anyone still care about the DNA
> effort? Should we continue the effort, or kill it off?

DNA's still interesting, I think we're (I'm) just suffering from
bis-burnout still.

/K

---

From: Matt Miller <[email-masked]>
Date: Thu, 23 Sep 2010 14:44:14 -0600

> DNA's still interesting, I think we're (I'm) just suffering from

Agreed.

- m&m

---

From: Dave Cridland <[email-masked]>
Date: Thu, 23 Sep 2010 22:43:33 +0100

On Thu Sep 23 21:29:43 2010, Ben Campbell wrote:
> This discussion seems to have fizzled. Does anyone still care about  
> the DNA effort? Should we continue the effort, or kill it off?

I've been reviewing this, actually.

It's quite interesting, actually, and its single biggest flaw is that  
it has almost nothing to do with XMPP, so it'll end up swallowed by  
some security area WG. But if we're lucky, and we rig the secdir  
review system, maybe we can sneak it past.

The essential premise - that you validate the DNS-level delegation by  
using DNSSEC, or, failing that, using a kind of poor-man's DNSSEC  
with jerry-built use of CERT records - is basically fine, although  
obviously anyone realising that this is poor-man's DNSSEC will throw  
up their hands in horror.

The major problems are:

1) SRV delegates to a hostname. To use this, a provider would need a  
hostname-based certificate for each server. Currently, providers use  
xmppAddr SANs for the hosted domains, so they'd now need dNSName SANs  
of each node in the cluster.

2) Multiple SRV records are commonplace. So having a CERT records at  
_dna._xmpp-server._tcp.example.org has to mean that record can  
validate all the extant SRV records.

Proposal:

Express pure delegation as a single CNAME. Sign that.

Hence, if a domain source.com delegates to target.com, which runs  
it's service from machine1 and 2 in host.com, we'd have:

1) _xmpp-server._tcp.source.com. CNAME _xmpp-server._tcp.target.com.
2) _xmpp-server._tcp.target.com. SRV 1 1 machine1.host.com.
3) _xmpp-server._tcp.target.com. SRV 1 1 machine2.host.com.

Which is a sane way of doing delegation anyway, and would work today.

This document would then add:

4) _dna._xmpp-server._client.source.com. CERT [...]

Dave.
-- 
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