Subject: Re: [xmpp] DNS-based DNA

From: Sean Turner <[email-masked]>
Date: Thu, 01 Jul 2010 12:19:48 -0400

Richard L. Barnes wrote:
> I would like to re-open the debate on AC-based DNA vs. DNS-based DNA.  I 
> thought about it a little more, and it seems like DNS-based DNA is 
> actually the lighter-weight solution, given current libraries, and 
> actually the more forward-compatible approach.
> 
> I've included pseudo-code for completeness below, but the gist is that 
> the client should:
> 1. Check for a DNSSEC-secure delegation; if it exists, use it
> 2. Connect to server and get name
> 3. If name doesn't match, server can offer a cert as a new DNSSEC TA
> 4. If name in cert matches intended domain, client installs TA and 
> re-queries for delegation
> 5. If delegation validates this time and the name matches the server, go 
> ahead
> 
> Three things in favor of this approach over ACDNA:
> 
> 1. You can check for delegation before connecting, and thus 
> accept/reject faster
> 
> 2. It's doable with existing libraries (see libunbound's ub_ctx_add_ta 
> command)
> 
> 3. It's forward-compatible with DNSSEC deployment; as more of the DNS is 
> secure, more delegations will be handled by line (1) and fewer by lines 
> (3-5).

There's a fourth: No need to bake attribute certificate verification 
code ;)

I think this looks like a really good idea.

spt

> -----BEGIN pseudo-code-----
> // Goal: Connect to destination_name
> 
> // See if the domain is delegated
> // If so, remember the delegated name
> // Also remember DNSSEC validation status with current TAs
> delegate_record = QUERY_FOR_SRV("_xmpp-delegate." + destination_name);
> delegate_name = NULL;
> delegated_flag = false;
> if (delegate_record != NULL) {
>     delegated_flag = true;
>     delegate_name = delegate_record.name;
> }
> dnssec_flag = delegate_record.dnssec_secured
> 
> 
> // Establish TLS connection to the server
> xmpp_server = QUERY_FOR_SRV(destination_name).name;
> tls_connection = TLS_CONNECT(xmpp_server);
> remote_name = tls_connection.authenticated_name;
> 
> // Check the name of the server
> // Deal with easy cases first
> if (!delegated_flag && remote_name == destination_name) {
>     goto SUCCESS;
> }
> if (!delegated_flag && remote_name != destination_name) {
>     goto FAIL;
> }
> else if (delegated_flag && dnssec_flag && remote_name == delegate_name) {
>     goto SUCCESS;
> }
> else if (delegated_flag && dnssec_flag && remote_name != delegate_name) {
>     goto FAIL;
> }
> else {// if (delegated_flag && !dnssec_flag)
>     // Get "External TA" cert using XMPP
>     // <challenge><proof 
> type="urn:ietf:params:dna:proof:dnssec-ta"></challenge>
>     // 
> <proof>http://hosting-provider.com/customers/destination_name.cert</proof>
>     eta_url = XMPP_CHALLENGE("urn:ietf:params:dna:proof:dnssec-eta");
>     eta_cert = HTTP_GET(ta_url);
>     if (!eta_url || !eta_cert) {
>         goto FAIL;
>     }
> 
>     // Check name in ETA cert
>     if (eta_cert.name != destination_name) {
>         goto FAIL;
>     }
> 
>     // Extract key material and install as a DNSSEC TA
>     DNS_RESOLVER_INSTALL_TA(eta_cert.pub_key);
>     delegate_record = QUERY_FOR_SRV("_xmpp-delegate." + destination_name);
>     DNS_RESOLVER_REMOVE_TA(eta_cert.pub_key);
>     if (!delegate_record) {
>         goto FAIL;
>     } else if (!delegate_record.dnssec_secured) {
>         goto FAIL;
>     } else if (delegate_record.name != remote_name) {
>         goto FAIL;
>     } else { // if delegate_record && dnssec_secured && name == remote_name
>         goto SUCCESS;
>     }
> }
> 
> -----END pseudo-code-----
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp
>

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 1 Jul 2010 21:17:23 -0700

I agree that this is worth investigating.

On Jul 1, 2010, at 9:19 AM, Sean Turner <[email-masked]> wrote:

> Richard L. Barnes wrote:
>> I would like to re-open the debate on AC-based DNA vs. DNS-based  
>> DNA.  I thought about it a little more, and it seems like DNS-based  
>> DNA is actually the lighter-weight solution, given current  
>> libraries, and actually the more forward-compatible approach.
>> I've included pseudo-code for completeness below, but the gist is  
>> that the client should:
>> 5. If delegation validates this time and the name matches the  
>> server, go ahead
>> 1. You can check for delegation before connecting, and thus accept/ 
>> reject faster
>> 2. It's doable with existing libraries (see libunbound's  
>> ub_ctx_add_ta command)
>> 3. It's forward-compatible with DNSSEC deployment; as more of the  
>> DNS is secure, more delegations will be handled by line (1) and  
>> fewer by lines (3-5).
>
>>    // <challenge><proof type="urn:ietf:params:dna:proof:dnssec- 
>> ta"></challenge>
>>    // <proof>http://hosting-provider.com/customers/destination_name.cert 
>> </proof>

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 02 Jul 2010 09:40:01 -0600

Yes, definitely worth considering.

On 7/1/10 10:17 PM, Bernard Aboba wrote:
>>> DNA is actually the lighter-weight solution, given current libraries,
>>> and actually the more forward-compatible approach.
>>> 5. If delegation validates this time and the name matches the server,
>>> go ahead
>>> 3. It's forward-compatible with DNSSEC deployment; as more of the DNS
>>> is secure, more delegations will be handled by line (1) and fewer by
>>> lines (3-5).
>>

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Jonas Lindberg <[email-masked]>
Date: Tue, 13 Jul 2010 00:04:29 +0200

This sounds like an interesting idea.

Richard, a few questions on your proposal:
- Does the ETA you use work as described in
http://tools.ietf.org/html/draft-ietf-sidr-ta-04?
- Does the 'client' trust the new TA to be added, because it's signed with a
cert that anchors in a TA client already trust (and because domain names
match)?
- Are there situations in which you would expect corporate or isp dns
proxies/caching services to cause issues (since they don't know about the
eta)?
- Could you please outline the steps a domain admin would go through to set
this up for their domain?

Thanks!

Jonas

On Wed, Jun 30, 2010 at 4:26 AM, Richard L. Barnes <[email-masked]> wrote:

> thought about it a little more, and it seems like DNS-based DNA is actually
> the lighter-weight solution, given current libraries, and actually the more
> forward-compatible approach.
>
> I've included pseudo-code for completeness below, but the gist is that the
> client should:
> 1. You can check for delegation before connecting, and thus accept/reject
> faster
>
> --Richard

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 13 Jul 2010 00:30:37 +0100

> - Does the ETA you use work as described in http://tools.ietf.org/html/draft-ietf-sidr-ta-04?

Basically, yes; that's of course where the terminology comes from.   
However, ISTM that in this case we don't need to quite go to the  
extent that that draft does (with ETA CA and EE certs), since to  
invalidate the DNSSEC signature, you could just remove the DNSKEY and/ 
or RRSIG records from the delegated zone.  But I haven't thought about  
it that deeply.  The main point is to bootstrap from one  
authentication of a domain (i.e., from a CA vouching for ownership of  
a name) into DNSSEC, just as draft-ietf-sidr-ta boostraps from a well- 
known certificate into the RPKI.

> - Does the 'client' trust the new TA to be added, because it's  
> signed with a cert that anchors in a TA client already trust (and  
> because domain names match)?

Right, the idea is that the new TA is valid because it authenticates  
the delegated domain under some TA that the client already trusts.

> - Are there situations in which you would expect corporate or isp  
> dns proxies/caching services to cause issues (since they don't know  
> about the eta)?

Validating resolvers could cause problems.  The XMPP server would need  
to validate the DNS records in question itself, since it needs to  
control the TAs.  As noted, however, current DNS libraries seem to  
support this functionality.  Resolvers that only do caching -- i.e.,  
ones that pass on the relevant DNSSEC records to end clients -- should  
not cause problems.

> - Could you please outline the steps a domain admin would go through  
> to set this up for their domain?

Origin / delegating domain:
-- Generate key pair
-- Sign zone with private key
-- Acquire certificate (== ETA) containing public key from generally  
trusted CA
-- Provide certificate to delegate / hosting provider

Delegate domain / hosting provider:
-- Store certificate for delegated domain

Hope this helps,
--Richard

>    // <challenge><proof type="urn:ietf:params:dna:proof:dnssec-ta"></ 
> challenge>