Re: WGLC of draft-ietf-xmpp-dna-09

On 5 March 2015 at 19:34, Ben Campbell <[email protected]> wrote:

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


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.

_______________________________________________
xmpp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/xmpp