Re: AD Evaluation of draft-ietf-xmpp-dna-10

On 6/24/15 2:16 PM, Ben Campbell wrote:
> 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?

Yes, it belongs farther up.

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

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

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

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

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/

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