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

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.


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.