Re: [xmpp] I-D Action: draft-ietf-xmpp-dna-05.txt

Peter Saint-Andre <stpeter@stpeter.im> Mon, 09 June 2014 17:12 UTC

Return-Path: <stpeter@stpeter.im>
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 AF3591A01D6 for <xmpp@ietfa.amsl.com>; Mon, 9 Jun 2014 10:12:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.553
X-Spam-Level:
X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 qPjFCwVzBXa9 for <xmpp@ietfa.amsl.com>; Mon, 9 Jun 2014 10:12:58 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 23DCA1A01AC for <xmpp@ietf.org>; Mon, 9 Jun 2014 10:12:58 -0700 (PDT)
Received: from aither.local (unknown [24.8.129.242]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 39FEB40C58; Mon, 9 Jun 2014 11:12:57 -0600 (MDT)
Message-ID: <5395EB18.4090701@stpeter.im>
Date: Mon, 09 Jun 2014 11:12:56 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Philipp Hancke <fippo@goodadvice.pages.de>, xmpp@ietf.org
References: <20140204202306.13810.80083.idtracker@ietfa.amsl.com> <530E5C61.1010000@goodadvice.pages.de>
In-Reply-To: <530E5C61.1010000@goodadvice.pages.de>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/kfGiF7l86Xtpf6-Lw8de_VslCcw
Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-dna-05.txt
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: <http://www.ietf.org/mail-archive/web/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: Mon, 09 Jun 2014 17:12:59 -0000

On 2/26/14, 2:28 PM, Philipp Hancke wrote:
> Am 04.02.2014 21:23, schrieb internet-drafts@ietf.org:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts
>> directories.
>>   This draft is a work item of the Extensible Messaging and Presence
>> Protocol Working Group of the IETF.
> [...]
>
> I've been prodded to give feedback again...
> overall, I (still) think the technique described solve the problem.
> The description still confuses me and I want to rewrite this from
> scratch, but lack the time to actually do this.
>
> In part, this confusion seems to be caused by the attempt to do both C2S
> and S2S. DNA is needed for both, but the document mostly describes S2S,
> which is the more complicated case.
>
> I think starting with a C2S scenario would be better. It's alot easier
> because only a single party does DNA. Explaining delegation and
> multi-tenancy is easier, too.

That is all true, and you make a good point. I think I'll work on this a 
bit for the next version, because the C2S case is indeed easier to 
describe and we want folks to understand the general concept.

> I have a problem with the description of S2S.
> Bullet #6 in section 4 (as well as the flow chart) puts the creation of
> the association immediately after the TLS negotation.
>
> While authentication happens during/after the TLS handshake and the
> subsequent exchange of stream headers, there is an identity assertion
> step which is done either using SASL (EXTERNAL) or <db:result/>.
>
> IMO this is where the domain name association is created.

Yes!

> And it gets alot easier to explain the need for stuff like piggybacking
> in subsequent sections.
>
> For C2S (or the client role of S2S), I actually agree that the client
> creates the association immediately after (or during) the TLS handshake,
> i.e. MUST check whether they like their counterparts authorization
> enough to continue. But clients have a concept of expected identity of
> the server (RFC 6125?)

Correct.

> Servers, however, do not yet know who their counterpart is or wants to
> act as (assuming they discarded all information that was obtained in an
> insecure way before the TLS handshake).
>
>
> Additionally, there is no clear definition of what "A establishes DNA
> for B" actually means, which may be another source of confusion.
> It seems to be an entry in a list of "i know who this guy is"-domains
> which can then be used in dialback.
> However, so far I haven't felt a need to explicitly implement it that
> way, probably because most of the time a synchronus lookup in the list
> of domains contained in the cert was enough. DANE and POSH change that
> obviously.

Hmm, yes. We do need to explain this better. Matt and I will go back to 
the workshop and see what we can fashion. :-)

Peter