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

"Ben Campbell" <ben@nostrum.com> Thu, 25 June 2015 03:58 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: xmpp@ietfa.amsl.com
Delivered-To: xmpp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0A71AD0AB for <xmpp@ietfa.amsl.com>; Wed, 24 Jun 2015 20:58:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.31
X-Spam-Level:
X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_17=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYhJeMT17O4m for <xmpp@ietfa.amsl.com>; Wed, 24 Jun 2015 20:58:32 -0700 (PDT)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96D5C1AD0A8 for <xmpp@ietf.org>; Wed, 24 Jun 2015 20:58:32 -0700 (PDT)
Received: from [10.0.1.23] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.1/8.14.9) with ESMTPSA id t5P3wEmh034405 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 24 Jun 2015 22:58:25 -0500 (CDT) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.23]
From: "Ben Campbell" <ben@nostrum.com>
To: "Peter Saint-Andre - &yet" <peter@andyet.net>
Date: Wed, 24 Jun 2015 22:58:14 -0500
Message-ID: <DDFD9A47-AD07-40D1-96BA-1B0357A9B4D7@nostrum.com>
In-Reply-To: <558B24B3.3010406@andyet.net>
References: <AAD102C6-53B3-440D-B265-83F8E726BB5D@nostrum.com> <558B24B3.3010406@andyet.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.1r5084)
Archived-At: <http://mailarchive.ietf.org/arch/msg/xmpp/o9MtZFtQ6C1IC_uYzFaklmfScrQ>
Cc: draft-ietf-xmpp-dna.all@tools.ietf.org, XMPP Working Group <xmpp@ietf.org>
Subject: Re: [xmpp] AD Evaluation of draft-ietf-xmpp-dna-10
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/xmpp/>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jun 2015 03:58:34 -0000

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/