Re: [xmpp] I-D Action: draft-ietf-xmpp-dna-05.txt
Philipp Hancke <fippo@goodadvice.pages.de> Wed, 26 February 2014 21:28 UTC
Return-Path: <fippo@goodadvice.pages.de>
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 8B98B1A07A9 for <xmpp@ietfa.amsl.com>; Wed, 26 Feb 2014 13:28:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.002
X-Spam-Level:
X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-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 bdoCT3HXCzOo for <xmpp@ietfa.amsl.com>; Wed, 26 Feb 2014 13:28:14 -0800 (PST)
Received: from lo.psyced.org (lost.IN.psyced.org [188.40.42.221]) by ietfa.amsl.com (Postfix) with ESMTP id 72AC21A0798 for <xmpp@ietf.org>; Wed, 26 Feb 2014 13:28:13 -0800 (PST)
Received: from [192.168.0.101] (2.68.130.206.mobile.tre.se [2.68.130.206]) (authenticated bits=0) by lo.psyced.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id s1QLS7Ki001242 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for <xmpp@ietf.org>; Wed, 26 Feb 2014 22:28:11 +0100
Message-ID: <530E5C61.1010000@goodadvice.pages.de>
Date: Wed, 26 Feb 2014 22:28:01 +0100
From: Philipp Hancke <fippo@goodadvice.pages.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: xmpp@ietf.org
References: <20140204202306.13810.80083.idtracker@ietfa.amsl.com>
In-Reply-To: <20140204202306.13810.80083.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/xmpp/IBEQw2WuJjbAm0OpR4gT1JSrElw
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: Wed, 26 Feb 2014 21:28:22 -0000
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. 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. 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?) 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.
- [xmpp] I-D Action: draft-ietf-xmpp-dna-05.txt internet-drafts
- Re: [xmpp] I-D Action: draft-ietf-xmpp-dna-05.txt Matt Miller
- Re: [xmpp] I-D Action: draft-ietf-xmpp-dna-05.txt Philipp Hancke
- Re: [xmpp] I-D Action: draft-ietf-xmpp-dna-05.txt Dave Cridland
- Re: [xmpp] I-D Action: draft-ietf-xmpp-dna-05.txt Ben Campbell
- Re: [xmpp] I-D Action: draft-ietf-xmpp-dna-05.txt Matt Miller
- Re: [xmpp] I-D Action: draft-ietf-xmpp-dna-05.txt Peter Saint-Andre