Subject: [xmpp] dialback in DNA

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Mon, 13 Oct 2014 07:24:55 -0700

Currently draft-ietf-xmpp-dna does not consider server dialback to be a 
DNA prooftype. Matt and I propose adding the following text to §7:

    Although the PKIX prooftype uses the XMPP Server Dialback protocol
    [XEP-0220] for signalling between servers, this framework document
    does not define the exchange of dialback keys (also specified in
    [XEP-0220]) as a DNA prooftype.  However, a future specification, or
    an updated version of [XEP-0220], might define a DNA prooftype for
    dialback in a way that is consistent with this framework.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Philipp Hancke <[email-masked]>
Date: Tue, 14 Oct 2014 00:53:15 +0200

Am 13.10.2014 16:24, schrieb Peter Saint-Andre - &yet:
[...]
> Matt and I propose adding the following text to §7:
>

reuses?

>     [XEP-0220] for signalling between servers, this framework document

[XEP-0220] _syntax_ for ...?

>     [XEP-0220]) as a DNA prooftype.  However, a future specification, or

but doesn't use the semantics for the generation and validation of 
dialback keys?

I'd note that it will still work with server dialback because one of the 
design goals was backward compat. So we don't need to define anything.

>     dialback

I just tried that and failed. Let's try to find some time and a 
whiteboard later this year.

> in a way that is consistent with this framework.

0220 currently says that dialback-without-dialing-back is not described. 
smart servers should not use the db:verify to do any weak identify 
verification of the dialback keys.
But if we make any such statements, they belong into the security 
considerations of xep-0220.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 14 Oct 2014 10:43:15 -0700

> but doesn't use the semantics for the generation and validation of

Will fix.

> design goals was backward compat.

I propose that we add this clause:

"nothing in this document prevents the continued use of server dialback"

> So we don't need to define anything.

I'd need to double-check XEP-0220, one of our favorite documents. ;-)

> I just tried that and failed.

How so?

> Let's try to find some time and a

Always a pleasure. :-)

> considerations of xep-0220.

Makes sense to me.

Peter

-- 
Peter Saint-Andre
https://andyet.com/

---

From: Philipp Hancke <[email-masked]>
Date: Thu, 16 Oct 2014 21:08:16 +0200

>> I just tried that and failed.

I could not figure out which proof of identity I wanted.

Did I want the proof that the receiving server is who it claims to be? 
With dialback, the proof seems to be "oh yeah, it is listening on the 
port DNS says"? That's pretty bad but we know it is vulnerable to DNS 
poisoning...

For the sending server, the proof is slightly better, db:verify and 
merlins spell assert the sender shares a secret with the authoritative 
server.

I just need to write up the formal prooftype definition for both.

It seems this is more complicated for dialback than for PKIX or 
POSH/DANE because it's not symmetric there. OTOH, we might have 
scenarios where we have PKIX in one direction and POSH in the other.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 16 Oct 2014 20:30:21 -0600

> merlins spell assert the sender shares a secret with the authoritative

Thanks for the clarification.

> scenarios where we have PKIX in one direction and POSH in the other.

True, that's possible. These things get messy. I think one way around 
the messiness is to say that DNA applies only to a single stream in a 
single direction. Bidi is interesting but what matters for DNA is that I 
check my server or peer.

Peter

-- 
Peter Saint-Andre
https://andyet.com/