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

From: Matt Miller <[email-masked]>
Date: Wed, 22 Feb 2012 09:50:20 -0700

[Sorry for the late reply]

On Jan 28, 2012, at 02:05, Philipp Hancke wrote:

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

Personally, I would like one solution framework that can apply to both c2s and s2s connections.  Dialback is extremely unlikely to function for clients.

Also, at least in my readings of this, it still comes back to trusting DNS.  Until DNSSEC is ubiquitous, I don't think we really can.  And just because we are today doesn't make it OK.

I'd welcome a specification that defines this more completely.

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

I see the lack of any in-band challenge/response as problematic, but can be convinced otherwise.

- - m&m

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