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/
- [xmpp] AD Evaluation of draft-ietf-xmpp-dna-10 Ben Campbell
- Re: [xmpp] AD Evaluation of draft-ietf-xmpp-dna-10 Peter Saint-Andre - &yet
- Re: [xmpp] AD Evaluation of draft-ietf-xmpp-dna-10 Ben Campbell