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

On 2/26/14, 2:28 PM, Philipp Hancke wrote:
> Am 04.02.2014 21:23, schrieb [email protected]:
>>
>> 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