Subject: Re: [xmpp] WGLC of draft-ietf-xmpp-dna-09

From: "Ben Campbell" <[email-masked]>
Date: Thu, 05 Mar 2015 13:34:26 -0600

Reminder: This WGLC ends tomorrow. I have not seen any feedback.

If you have read the draft, and think it is ready to go, please say so.

Thanks!

Ben.

On 20 Feb 2015, at 15:36, Ben Campbell wrote:

> This is an XMPP Working Group Last Call of draft-ietf-xmpp-dna-09. The 
> draft is available at the following URL
>
> https://datatracker.ietf.org/doc/draft-ietf-xmpp-dna/
>
> The WGLC will conclude on March 6, 2015. Please send your comments to 
> the authors and the XMPP mailing list.
>
> (Given that the draft deadline for IETF92 is the following Monday, I 
> suspect the authors would really appreciate people not waiting till 
> the last minute to send feedback.)
>
> Thanks!
>
> Ben.
>
> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp

---

From: Matthew Wild <[email-masked]>
Date: Thu, 5 Mar 2015 19:38:41 +0000

> If you have read the draft, and think it is ready to go, please say so.

Thanks for the reminder! I spent some time reading through the
document, and I think it's ready to go.

Regards,
Matthew

---

From: Lance Stout <[email-masked]>
Date: Thu, 5 Mar 2015 11:44:07 -0800

> If you have read the draft, and think it is ready to go, please say so.

The draft looks good to go.

- Lance

---

From: "Ben Campbell" <[email-masked]>
Date: Thu, 05 Mar 2015 14:24:12 -0600

(as individual)

I suppose I should send my own review :-)

I think the draft is pretty much ready to go, and support publication. I 
have a couple of minor comments, neither of which are critical.

-- section 5.1, step 4: It might be nice to repeat the secure DNS 
reference here.

-- section 6: It seems like this section has a fair amount of redundancy 
to section 5. (especially 5.0 and 5.2).

> If you have read the draft, and think it is ready to go, please say 

[...]

---

From: Dave Cridland <[email-masked]>
Date: Thu, 5 Mar 2015 21:21:52 +0000

> If you have read the draft, and think it is ready to go, please say so.

I do not think this draft is ready, sorry. I should have looked at this in
detail before.

The major problem is the implications in §4.3, which are unfortunately very
much incorrect. Specifically, it is loosely describing XEP-0220 as enhanced
by XEP-0344, and touches on the impact of XEP-0288. This is in itself
probably useful, though by restating much of those XEPs I'm not entirely
clear on its value.

To start with, the title of the section is "One-Way Authentication". This
is most certainly incorrect. To say that authentication is one way is to
assert that one or other end is considered anonymous by its peer. Server A,
the initiating entity, intends sending stanzas to b.example - there is
clearly no way that Server A will send those stanzas to Server B unless it
has authenticated Server B as hosting b.example. Meanwhile, Server B will
not accept stanzas from Server A unless it has also authenticated Server A
as hosting a.example. Therefore, if stanzas get sent from A to B, mutual
authentication must have taken place.

This is a shame, as conceptually, XEP-0220 can be viewed as taking a
one-way authentication method (traditionally "DNS and hope") and using it
to gain a mutually authenticated session which can then be used for stanza
transmission.

At the end of the section, it then says that "at this point the servers are
using two TCP connections instead of one" - this is problematic too,
because servers can use either a "verify-only" session, or can use the
reverse connection to send stanzas on. If they authenticate using PKIX,
however, they still have to open a second connection to return stanzas.

The text then goes on to assert that XEP-0288 can be used "to tie the
authentication achieved on the second TCP connection to the first TCP
connection" - that's not even slightly true - in fact that's what XEP-0220
does.

Instead, XEP-0288 simply removes the (historical, and somewhat silly)
restriction that S2S channels can only transmit stanzas from initiator to
receiver, by a (too) simple negotiation.

There are other minor issues; I'll go through those in detail later.

---

From: Philipp Hancke <[email-masked]>
Date: Thu, 05 Mar 2015 18:04:59 -0800

> I do not think this draft is ready, sorry. I should have looked at this in

Thanks for doing it, even if late. That's quite good feedback, I missed 
those issues.

> by XEP-0344, and touches on the impact of XEP-0288. This is in itself

I had _totally_ forgotten that we had documented some of this in 0344.
I'll see where this fits best and if it makes 4.3 easier.

> probably useful, though by restating much of those XEPs I'm not entirely

I don't think we mention this case in 0344 which, in 2.4 describes only 
the other way round.

> is most certainly incorrect. To say that authentication is one way is to

This section assumes a trusted certificate at the receiving server so 
the authentication is using PKIX only one-way (originating server uses 
pkix, dane, posh etc to authenticate the receiving server).

I'll see if I can come up with a better term.

> authentication must have taken place.

Right.

> to gain a mutually authenticated session which can then be used for stanza

0220 only works for asserting the senders identify. The receiving 
servers identity has always been DNS and hope if the certificate was not 
trusted. Unless that's what you mean, hope in the one direction and dns 
in the other ;-)

> however, they still have to open a second connection to return stanzas.

Good catch.

For bidirectional communication, they will end up using two connections, 
but that is not shown here. Unless they use 0288, they will end up 
repeating the process in the reverse direction.

Which is described in 0220 so it makes little sense to repeat it here.
I think that paragraph should just go away.

> connection" - that's not even slightly true - in fact that's what XEP-0220

Yes, that should have referenced 0220 instead. Will either fix or remove.

> receiver, by a (too) simple negotiation.

+1

> There are other minor issues; I'll go through those in detail later.

keep'em coming :-)