Subject: [xmpp] draft-hildebrand-dna-00 review

From: Jonas Lindberg <[email-masked]>
Date: Wed, 25 Nov 2009 17:38:10 +0100

A few comments on http://tools.ietf.org/html/draft-hildebrand-dna-00 :

---

4.2. Validation

Assumption: not all service administrators will provide an attribute
certificate proof for their domain.

Given assumption above, a feature that may be useful for a large
hosting providers is allowing domain administrators to choose their
policy for what is an acceptable proof. Some domain administrators may
require strong evidence like attribute certificates proofs. Others
administrators may be OK with some weaker proof (e.g. SRV record
lookup) if that enables their users to chat with with more domains.

Implementing per domain proof policies using the current draft
protocol would be a bit clunky, since for a given stream a remote
domain is either valid on invalid as far as all local domains are
concerned.

One possible solution is to do assertions on domain pair basis, adding
a from attribute to the valid stanza and so on:

  <valid xmlns='urn:ietf:params:xml:ns:dna' to='asserted.tld'
from='target.tld'/>

This requires sending significantly more assert/valid stanzas, but if
done on demand this setup overhead would hopefully be small on average
compared to subsequent traffic between the domains.

Thoughts?

---

4.3.  Invalidation

Here or elsewhere, suggest saying that a server SHOULD send an
impossible element when it is no longer authoritative for a given
domain that it previously validated. The remote server should
re-resolve SRV record when receiving the 'impossible' to see if
service moved.

Servers may also want to periodically resolve SRV and redo validation
of remote domains, just in case the remote service fails to notify
that it no longer authoritative for a domain.

---

4.4:

   <challenge xmlns='urn:ietf:params:xml:ns:dna' to='asserted.tld'>
     <proof xmlns='urn:ietf:params:dna:proof:attribute-cert'/>
     < type='http://example.com/proof/custom'/>
   </challenge>

Why not:

   <challenge xmlns='urn:ietf:params:xml:ns:dna' to='asserted.tld'>
     <proof xmlns='urn:ietf:params:dna:proof:attribute-cert'
       type='http://example.com/proof/custom'/>
   </challenge>

?

---

6.4:

   Once an originating server completes this first validation it signals
   that it is willing and able to participate in bi-directional XMPP
   federation traffic, as long as all of the domains required have been
   asserted and validated at least once on this stream.

At Google, we run one set of servers for inbound s2s traffic and one
set for outbound for reasons that have to do with our production
setup. Changing this to accommodate bi-directional traffic should be
doable, but if others have similar setups then it may make sense to
consider a one-way traffic option.

---

6.7:

   If the server receiving a proactive validation is no long authoritative for
   a given domain, it MUST send an "impossible" element, at which point
   the sender MUST remove the receiver from any cache and not send any
   stanzas on this stream to the given domain."

s/long/longer

---

6.9

   Ensure that only one challenge is outstanding on a given connection
   for a given domain.  Ensure that only one assertion or one proof is
   outstanding on a given connection for a given domain.

Assume 'for a given domain' means 'for a given local domain/remote
domain pair'?  Seems useful for two big hosting providers to validate
many domain pairs in parallel when setting up a connection.