Subject: [xmpp] AD Evaluation of draft-ietf-xmpp-dna-10

From: "Ben Campbell" <[email-masked]>
Date: Wed, 24 Jun 2015 15:16:49 -0500

Hi,

Here is my AD Evaluation of draft-ietf-xmpp-dna-10. I have a few minor 
comments, but nothing that needs to delay the last call.

Thanks!

Ben.
-------

-- Section 4.1:

Does the "(Section 4.3: No Mutual PKIX authentication)" belong where it 
is, or before the first dialback assertion?

-- 4.3, step 6:

Do I understand correctly that this step involves A sending a valid and 
trusted server cert, when it was previously unable to send a valid and 
trusted client cert? Is that a reasonable assumption? Whether yes or no, 
does it deserve a mention in the text? (It's likely I am missing 
something that should be obvious.)

-- step 7:

The reference to xep-0344 is informative. Should it be normative? If 
not, then perhaps a stronger mention of skipping subsequent steps should 
be included here? (it’s only mentioned in terms of the reference.)

-- 4.4.1, steps 3 and later:

The text says that A sends an initial stream header to B. Should that be 
considered B or C for the rest of the flow? I guess in the example, 
B==C, but is that required? (perhaps B and C coordinate dialback keys?) 
Maybe it doesn't matter from A's perspective.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 24 Jun 2015 15:44:19 -0600

> is, or before the first dialback assertion?

Yes, it belongs farther up.

> something that should be obvious.)

We haven't described this very well. As you point out, Server B doesn't 
trust this certificate (perhaps there's a name mismatch or whatever) and 
that's the whole point of this flow.

> be included here? (it’s only mentioned in terms of the reference.)

In the flow described here (falling back to Server Dialback), the 
subsequent steps are necessary.

I would suggest.

OLD

    6.  The servers attempt TLS negotiation, during which Server A
        (acting as a TLS server) presents a PKIX certificate proving that
        it is a.example.

    7.  Server B checks the PKIX certificate that Server A provided.
        This might be the same certificate presented by Server A as a
        client certificate in the initial connection.  See [XEP-0344] for
        further discussion about skipping the subsequent steps.

    8.  Server B proceeds with Server Dialback in order to establish the
        domain name association.  In order to do this it sends a request
        for verification as described in [XEP-0220]:

        <db:verify from='b.example' to='a.example' id='...'>some-
        dialback-key</db:verify>

    9.  Server A responds to this:

        <db:verify from='a.example' to='b.example' id='...' type='valid/>

        allowing Server B to establish the domain name association.

NEW

    6.  The servers attempt TLS negotiation, during which Server A
        (acting as a TLS server) presents a PKIX certificate.

    7.  Server B checks the PKIX certificate that Server A provided
        (this might be the same certificate presented by Server A as a
        client certificate in the initial connection).  However, Server
        B does not accept this certificate as proving that Server A is
        authorized as a.example and therefore uses another method (here,
        the Server Dialback protocol) to establish the domain name
        association.

    8.  Server B proceeds with Server Dialback in order to establish the
        domain name association.  In order to do this it sends a request
        for verification as described in [XEP-0220]:

        <db:verify from='b.example' to='a.example' id='...'>some-
        dialback-key</db:verify>

    9.  Server A responds to this:

        <db:verify from='a.example' to='b.example' id='...' type='valid/>

        allowing Server B to establish the domain name association.

In some situations (e.g., if the Authoritative Server in Server Dialback 
presents the same certificate as the Originating Server), it is the 
practice of some XMPP server implementations to skip steps 8 and 9. 
These situations are discussed in [XEP-0344].

> Maybe it doesn't matter from A's perspective.

There are only two logical servers (A and B) but they can provide 
service for additional domain names (e.g., c.example in the case of 
Server B). To forestall confusion, it might be good to change "Server A" 
to "Server 1" and "Server B" to "Server 2".

Peter

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

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 24 Jun 2015 22:58:14 -0500

Your responses all sound good. Thanks!

On 24 Jun 2015, at 16:44, Peter Saint-Andre - &yet wrote:

> We haven't described this very well. As you point out, Server B 
> doesn't trust this certificate (perhaps there's a name mismatch or 
> whatever) and that's the whole point of this flow.
>
>> -- step 7:
>>
> In some situations (e.g., if the Authoritative Server in Server 
> Dialback presents the same certificate as the Originating Server), it 
> is the practice of some XMPP server implementations to skip steps 8 
> and 9. These situations are discussed in [XEP-0344].
>
> Server B). To forestall confusion, it might be good to change "Server 
> A" to "Server 1" and "Server B" to "Server 2".
>
> Peter
>
> -- 
> Peter Saint-Andre
> https://andyet.com/