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

Peter Saint-Andre <> Mon, 09 June 2014 17:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AF3591A01D6 for <>; Mon, 9 Jun 2014 10:12:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.553
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qPjFCwVzBXa9 for <>; Mon, 9 Jun 2014 10:12:58 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 23DCA1A01AC for <>; Mon, 9 Jun 2014 10:12:58 -0700 (PDT)
Received: from aither.local (unknown []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id 39FEB40C58; Mon, 9 Jun 2014 11:12:57 -0600 (MDT)
Message-ID: <>
Date: Mon, 09 Jun 2014 11:12:56 -0600
From: Peter Saint-Andre <>
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 <>,
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [xmpp] I-D Action: draft-ietf-xmpp-dna-05.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: XMPP Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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
>> 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.


> 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.

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