Subject: [xmpp] Ponderings on Domain Name Assertions (DNA)

From: Matt Miller <[email-masked]>
Date: Fri, 27 Jan 2012 13:05:22 -0700

I've been asked to (attempt to) revive DNA, so here are some thoughts I have after reviewing what's been said and done.

To restate the problem:  How to determine that a multi-domain hosting service is authorized for a given domain, in a manner that allows connections to a hosting service be shared for multiple domains.

An example:

* denmark.lit hosts an XMPP service for its users
* montegue.lit has XMPP service that is hosted at shakespeare.lit
* capulet.lit has XMPP service that is hosted at shakespeare.lit
* shakespeare.lit hosts XMPP services (plural) for others (possibly including itself)...
* denmark.lit wants to talk to montegue.lit, but wants to be sure that shakespeare.lit really is the actual host.

I think this can (should?) also apply to the users at a domain; how does [email-masked] know that the servers for shakespeare.lit hosts his domain.

Solution:

The solution talked about to date has been to develop a protocol framework to assert (or challenge) an domain from a set of possible proof types.  It is assumed that all connections are secured via TLS, although not trusted until the assertions are accepted.  Since part of the proving happens in protocol, it means that the end-points suspend disbelief about the certificates until this additional validation completes.

There are two basic use cases (I am not a playwright, so no critiques of the dialogue):

1) "asserting": A server connects to another server, and asserts it is authorized for a domain

  (1.0 denmark.lit: I can accept your assertions!)
   1.1 montegue.lit: I am montegue.lit!
   1.2 denmark.lit: prove it, using one of these forms... (possible optimization: accepted because of other channels)
   1.3 proving ...
   1.4 denmark.lit: Accepted (or rejected)

2) "challenging": A server (or client) is connected to another server, and challenges if it is authorized for a domain ("Are you X?")

  (2.0 montegue.lit: I can assert my identity!)
   2.1 denmark.lit: Are you montegue.lit?  Prove it, using one of these forms...
   2.2 proving ...
   2.3 denmark.lit: Accepted (or rejected)

Here, "proving" is a protocol exchange of proof-specific details.  In practice, this might look a lot like SASL...

There are a couple prooftypes that have been discussed (on- or off-list) so far, plus some other avenues that can be investigated:

* .well-known from HTTPS
* attribute certificates
* DANE
* "dialback without dialback"[1]

This list is not complete; it's expected that new prooftypes can be added over time.

As for documenting this, I'll be looking at starting at least two drafts: the protocol framework and the HTTPS/.well-known prooftype.  I'll later look into another draft for the attribute certificate prooftype, and help Peter Saint-Andre for a DANE prooftype.

- m&m

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

[1] Dave Cridland - "Dialback. Now without Dialback" <http://blog.dave.cridland.net/?p=116>

---

From: Philipp Hancke <[email-masked]>
Date: Sat, 28 Jan 2012 10:05:08 +0100

Matt Miller wrote:
[...]
> [1] Dave Cridland - "Dialback. Now without Dialback"<http://blog.dave.cridland.net/?p=116>

If you re-read that carefully (neither Dave or I understood the full 
implications of that, see XEP-0288 0.2 for some more hints) you might 
notice that this "dialback" is used as a framework.

It works different from your approach like this:
(client is the s2s tls client, server the s2s tls server)
1) client: I would like to send stanzas from montague.lit denmark.lit
2) server checks it hosting denmark.lit and check (by any means 
available, with the lowest possible proof being certificate equality
3) server notifies client that it can start sending (or not).

The advantage is that this is reusing what currently works:
dialback (assuming that you have tls on all connections you can replace 
the XEP-0185 stuff with certificate equality and skip <db:verify/> at 
all), multiplexing and bidi.
It even enables us to get rid of what does not work (SASL EXTERNAL).
It is limited in the sense that it does not allow any in-band 
challenge/response.

Depends on a good specification of dialback though :-p

philipp
-- 
<http://goo.gl/voEzk>