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

Your responses all sound good. Thanks!

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

> 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