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

Peter Saint-Andre - &yet <peter@andyet.net> Wed, 24 June 2015 21:44 UTC

Return-Path: <peter@andyet.net>
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 EAD761B2E58 for <xmpp@ietfa.amsl.com>; Wed, 24 Jun 2015 14:44:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_17=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
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 nZMqLmZpXTVU for <xmpp@ietfa.amsl.com>; Wed, 24 Jun 2015 14:44:24 -0700 (PDT)
Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) (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 167E01B2E54 for <xmpp@ietf.org>; Wed, 24 Jun 2015 14:44:24 -0700 (PDT)
Received: by igblr2 with SMTP id lr2so43147907igb.0 for <xmpp@ietf.org>; Wed, 24 Jun 2015 14:44:23 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1Mrip28M5TK03shqzNnQwKjKHbbQDxfU2ekOqo5vMEk=; b=axiC8KjTJNWT4qg8ZpOZpTLUUfno0Fd5rzbnwdyemKiaDbloUZn97DC8Kh+s5OYKSw 3X0gYAbWams1bMNvUXm5pShyUqEO7q8DCA05OwbEKGqfDdWdJ8gYBGVsI8packH3+qNP m7jD+IyRSYQybzeq7EEZwj3JI7myEsljRjiIjIOe0FO4nfRKYTcnW+8Qs9FFojJzeYIG oeQdk7f9fPE6g7APNykMY0d30xhCzcTJTxjVdhjj+2SgYKSBgD7hiv2ZIlymvNptVMM1 J1wkAWWQKvBiR0eT6sPzBLlb6IQ+N79tpabtZG/QF3o6T6NLQCoxLFBI0Y1eQp3ije1/ RJ0Q==
X-Gm-Message-State: ALoCoQnOZQpFR6vR+dj65lFn+cjgGn/DCsrBfCJq4KaTdR5gzEQAmm2fO11VqyhYOMR0jBue/9L+
X-Received: by 10.107.47.224 with SMTP id v93mr55120011iov.86.1435182263484; Wed, 24 Jun 2015 14:44:23 -0700 (PDT)
Received: from aither.local ([2601:282:4201:ef5b:7dc6:738e:73e4:2f00]) by mx.google.com with ESMTPSA id p39sm18161884ioi.5.2015.06.24.14.44.21 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 24 Jun 2015 14:44:22 -0700 (PDT)
Message-ID: <558B24B3.3010406@andyet.net>
Date: Wed, 24 Jun 2015 15:44:19 -0600
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Ben Campbell <ben@nostrum.com>, draft-ietf-xmpp-dna.all@tools.ietf.org, XMPP Working Group <xmpp@ietf.org>
References: <AAD102C6-53B3-440D-B265-83F8E726BB5D@nostrum.com>
In-Reply-To: <AAD102C6-53B3-440D-B265-83F8E726BB5D@nostrum.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/xmpp/SD7EBiTjODA82tUMRh7Du7F-czU>
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: Wed, 24 Jun 2015 21:44:26 -0000

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/