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

Am 05.03.2015 um 13:21 schrieb Dave Cridland:
> 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.

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


> 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

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
> clear on its value.

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

> 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

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.

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

Right.

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

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

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

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.

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

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

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

+1

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

keep'em coming :-)