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

From: Richard Barnes <[email-masked]>
Date: Fri, 2 Mar 2012 10:23:10 -0500

Hey Matt,

Thanks for picking this thread back up.  Couple of observations inline below.

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

+1  

Also, seems relevant to C2S as well as S2S, since you're trying to authenticate the destination domain in both cases.

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

Well, yes, when you abstract this much, it looks a lot like SASL :)

I would keep in mind that the DNS-based solutions below, there would probably be no actual SASL; you would probably pass the challenge and proof out-of-band, in advance of the actual XMPP connection.  For example, in the DANE case, the initiating side will pull DANE records from the DNS before initiating TLS to the responding side.

<bikeshed>It seems like what we're doing here should be doable at the TLS layer, since authenticating domain names is what TLS does all the day long.</bikeshed>

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

If the "db sans db" solution is the one I wrote up in draft-ietf-xmpp-dna, then I think we can put that one aside for now in favor of the DANE solution.  

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

I would also be glad to help out with a DANE version.  Version -1:
0. denmark.lit wants to connect to capulet.lit
1. denmark.lit queries for TLSA records under _xmpp-server._tcp.capulet.lit, gets DANE assertions
2. denmark.lit connects to capulet.lit [normal connection process]
3. denmark.lit initiates STARTTLS and verifies that the presented certificate matches the DANE assertions

Note that part of this process will be specifying how to use DANE for XMPP, since the DANE WG declined to define something that would cover XMPP.

--Richard

---

From: Matt Miller <[email-masked]>
Date: Fri, 2 Mar 2012 08:54:30 -0700

> Also, seems relevant to C2S as well as S2S, since you're trying to authenticate the destination domain in both cases.

I'm glad there's some agreement!

> I would keep in mind that the DNS-based solutions below, there would probably be no actual SASL; you would probably pass the challenge and proof out-of-band, in advance of the actual XMPP connectio…

I fully expect most of the mechanisms/algorithms/processes/thingies will be out-of-band of XMPP.  The in-band came from some off-line discussions with a couple other server implementors and architects.

If no one else sees value in that, I'm more than happy to preclude any mechanism-specific exchanges in-band.

> <bikeshed>It seems like what we're doing here should be doable at the TLS layer, since authenticating domain names is what TLS does all the day long.</bikeshed>

Once DNSSEC and DANE are ubiquitous, I'd be more than happy to drop anything else.  Until then, I think we need to keep our options slightly more open.

> Note that part of this process will be specifying how to use DANE for XMPP, since the DANE WG declined to define something that would cover XMPP.

Thanks for the offer!  Peter and I were planning to work on the DANE-based proposal in his Life after IESG™ period.

- - m&m

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

---

From: Dave Cridland <[email-masked]>
Date: Fri, 02 Mar 2012 17:03:52 +0000

On Fri Jan 27 20:05:22 2012, Matt Miller wrote:
> 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.
> 
> 
You need to ensure you've additionally added in piggybacking (Or  
stream multiplexing, or whatever we call this now) - or at the very  
least not prevented it.

This changes the scenery rather a lot.

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

Mmmmm.... Kind of.

Yes, users need to authenticate and authorize their servers.

But the thing is, users never need to piggyback target domains, and  
additionally, for users, they've typically got mutual authentication  
via SASL.

Finally, we can cheat a bit and lessen the need for signalling - if  
we do this - so the authorizing agent can handle the entire  
authorization process without any support from the authorizee - then  
it saves us a 
In fact, I'm not even convinced we ever need signalling, aside from  
the fact people will march on me with flaming pitchforks if I suggest  
that. But since I've just had a new moat put in at Castle Cridland,  
and the drawbridge is properly oiled...

> 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

OK. ".well-known from HTTPS", and "attribute certificates" (and  
signed-blobs-of-XML) are all equivalents.

d-w-d on the other hand is a hunk of protocol for declaring a need to  
authenticate.

Let me put up a concrete proposal:

Our authorization proof is going to consist of a copy of the hosting  
certificate held at the domain owner's HTTPS site at  
.well-known/authorization/hosted-domain/_tcp/_xmpp-server/certificate.crt 
in DER (ie, not PEM). I'm going to call this protocol TurboHalibut.

The details don't really matter that much.

The name *absolutely* does.

So, for [email-masked], connecting to his server is business as  
usual, since it's self hosted.

For [email-masked], on the other hand, things are a bit  
different. The certificate she gets from connecting normally doesn't  
match. At this point, traditional wisdom is for her to disconnect  
with an error. In practise, what actually happens is that Juliet's  
client will ask Juliet if she wants to ignore years of careful  
security analysis and just continue anyway.

But with TurboHalibut, her client can now take the additional step of  
connecting to the HTTPS site https://capulet.lit, checking *that*  
certificate against capulet.lit, and then checking the certificate  
held in TurboHalibut is the same one it's got from the XMPP service.

Look, mom, no signalling - shakespeare.lit doesn't need to support  
any new protocol for this use-case, because it's all been handled out  
of band. Juliet's client, though, does need to implement TurboHalibut.

So Hamlet decides to send a message to Juliet.

denmark.lit connects to shakespeare.lit, and sees the wrong  
certificate - but denmark.lit can verify it in exactly the same way.  
Again, shakespeare.lit needn't support TurboHalibut.

Finally, when, some time later, Juliet deigns to respond, "Art thou  
not Hamlet, and in completely the wrong play?", then shakespeare.lit  
connects to denmark.lit.

Now denmark.lit can again use TurboHalibut to validate  
shakespeare.lit's certificate.

None of this, you'll note, uses any dialback - probably. It can all  
use SASL EXTERNAL just as well, at the very least. But it *could* use  
<db:result/> as the authentication mechanism just as well - in fact,  
it's somewhat more reliable doing it this way, because servers are  
always good enough to supply a to and from, and it's faster because  
it uses fewer round-trips.

The fact that the corresponding <db:verify/> traffic never happens is  
just a distraction.

It gets a lot more compelling doing things this way if Romeo,  
wondering why Hamlet is chatting up his romantic interest, drops him  
a message.

Shakespeare.lit already has a connection to denmark.lit from  
capulet.lit, and it's already authenticated that connection - so it  
makes sense to reuse it. It can't use SASL, so instead it just sends  
a <db:result/>. Denmark.lit treats this *exactly the same way* as a  
SASL EXTERNAL - it checks the from address against the certificate,  
and should this fail - and it does, of course - it uses TurboHalibut  
to validate the certificate, and sends back the authorizing  
<db:result/>.

Again, in this case, shakespeare.lit need not know anything about  
TurboHalibut. In fact, it can cheerfully assume that denmark.lit is  
doing "real" dialback.

However, I stress - dialback without dialback is merely a solution  
for piggybacking.

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

---

From: Philipp Hancke <[email-masked]>
Date: Mon, 05 Mar 2012 08:47:05 +0100

Dave Cridland wrote:
> You need to ensure you've additionally added in piggybacking (Or stream
> multiplexing, or whatever we call this now) - or at the very least not
> prevented it.
>

As does bidirectionality. "trying to authenticate the destination 
domain" and "trying to authenticate the source domain" become the same 
task then -- the only difference is when this happens.

[...]
> In fact, I'm not even convinced we ever need signalling

I suspect that the unhappy paths such as dealing with bounces might get 
alot harder without signalling.

[...]
> d-w-d on the other hand is a hunk of protocol for declaring a need to

d-w-d is an umbrella term. It is about getting rid of the old notion of 
"server dialback" as a ten/four step process as explained in RFC 3920 
and (embarassingly so) again in the "harmonized" versions of XEP 220 0.9+.

[...]
> TurboHalibut. In fact, it can cheerfully assume that denmark.lit is

Actually, shakespeare.lit does not care whether it is authenticated by 
denmark.lit. What matters is that denmark.lit has signalled that it is 
going to accept stanzas from shakespeare.lit. The only reason to use 
<db:result/> for this is that backward compability works like a charm.

---

From: Matt Miller <[email-masked]>
Date: Wed, 14 Mar 2012 12:45:59 -0600

Thank you for this feedback.

So far, I'm hearing a lot if favor of out-of-band validation, and little-to-none in favor of in-band.  Whether it's DANE or HTTPS/.well-known or something else is mostly irrelevant.  It's effectively happening within the software's "TLS support" (for various definitions of "TLS support").

I also met with Peter Saint-Andre about this, and we came to a similar conclusion regarding validation.  Questions that arose:
- - do we need a way to signal a preferred prooftype (probably not?)
- - order of operations (SRV, TLS, DANE, HTTPS/.well-known) matter?
- - how long to suspend disbelief on TLS? (interactions with existing software)

It looks like we need to codify the HTTPS/.well-known and/or DANE validation processes; and to formalize d-w-d, presumably starting with draft-ietf-xmpp-dna-01.

- - m&m

03, Dave Cridland wrote:

>> 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.
> You need to ensure you've additionally added in piggybacking (Or stream multiplexing, or whatever we call this now) - or at the very least not prevented it.
> 
> But the thing is, users never need to piggyback target domains, and additionally, for users, they've typically got mutual authentication via SASL.
> 
> Finally, we can cheat a bit and lessen the need for signalling - if we do this - so the authorizing agent can handle the entire authorization process without any support from the authorizee - then it saves us aIn fact, I'm not even convinced we ever need signalling, aside from the fact people will march on me with flaming pitchforks if I suggest that. But since I've just had a new moat put in at Castle Cridland, and the drawbridge is properly oiled...
> 
> OK. ".well-known from HTTPS", and "attribute certificates" (and signed-blobs-of-XML) are all equivalents.
> 
> d-w-d on the other hand is a hunk of protocol for declaring a need to authenticate.
> 
> Our authorization proof is going to consist of a copy of the hosting certificate held at the domain owner's HTTPS site at .well-known/authorization/hosted-domain/_tcp/_xmpp-server/certificate.crtin DER (ie, not PEM). I'm going to call this protocol TurboHalibut.
> 
> So, for [email-masked], connecting to his server is business as usual, since it's self hosted.
> 
> For [email-masked], on the other hand, things are a bit different. The certificate she gets from connecting normally doesn't match. At this point, traditional wisdom is for her to disconnect with an error. In practise, what actually happens is that Juliet's client will ask Juliet if she wants to ignore years of careful security analysis and just continue anyway.
> 
> But with TurboHalibut, her client can now take the additional step of connecting to the HTTPS site https://capulet.lit, checking *that* certificate against capulet.lit, and then checking the certificate held in TurboHalibut is the same one it's got from the XMPP service.
> 
> Look, mom, no signalling - shakespeare.lit doesn't need to support any new protocol for this use-case, because it's all been handled out of band. Juliet's client, though, does need to implement TurboHalibut.
> 
> denmark.lit connects to shakespeare.lit, and sees the wrong certificate - but denmark.lit can verify it in exactly the same way. Again, shakespeare.lit needn't support TurboHalibut.
> 
> Finally, when, some time later, Juliet deigns to respond, "Art thou not Hamlet, and in completely the wrong play?", then shakespeare.lit connects to denmark.lit.
> 
> Now denmark.lit can again use TurboHalibut to validate shakespeare.lit's certificate.
> 
> None of this, you'll note, uses any dialback - probably. It can all use SASL EXTERNAL just as well, at the very least. But it *could* use <db:result/> as the authentication mechanism just as well - in fact, it's somewhat more reliable doing it this way, because servers are always good enough to supply a to and from, and it's faster because it uses fewer round-trips.
> 
> The fact that the corresponding <db:verify/> traffic never happens is just a distraction.
> 
> It gets a lot more compelling doing things this way if Romeo, wondering why Hamlet is chatting up his romantic interest, drops him a message.
> 
> Shakespeare.lit already has a connection to denmark.lit from capulet.lit, and it's already authenticated that connection - so it makes sense to reuse it. It can't use SASL, so instead it just sends a <db:result/>. Denmark.lit treats this *exactly the same way* as a SASL EXTERNAL - it checks the from address against the certificate, and should this fail - and it does, of course - it uses TurboHalibut to validate the certificate, and sends back the authorizing <db:result/>.
> 
> Again, in this case, shakespeare.lit need not know anything about TurboHalibut. In fact, it can cheerfully assume that denmark.lit is doing "real" dialback.
> 
> However, I stress - dialback without dialback is merely a solution for piggybacking.
> 
> Dave.
> --

---

From: Philipp Hancke <[email-masked]>
Date: Wed, 14 Mar 2012 20:44:15 +0100

Am 14.03.2012 19:45, schrieb Matt Miller:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>

Matter of local service policy.

> - - order of operations (SRV, TLS, DANE, HTTPS/.well-known) matter?

Likewise.

> - - how long to suspend disbelief on TLS? (interactions with existing software)

"but it works with jabber.org" is the argument I most frequently heard 
when telling people that their certificate is wrong (for various 
meanings of that).

> It looks like we need to codify the HTTPS/.well-known and/or DANE validation processes; and to formalize d-w-d, presumably starting with draft-ietf-xmpp-dna-01.

A blend of XEPs 220 and 288 might be a better start. I wanted to merge 
both documents at some point anyway.

Proof types should be separate documents:
One for dial-back (essentially <db:verify/>, historical),
certificate-equality (as a replacement for 0185),
trusted-cert (replaces SASL EXTERNAL),
HTTPS/.well-known and DANE.
Last but not least TurboHalibut of course!