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

From: Joe Hildebrand <[email-masked]>
Date: Fri, 04 Dec 2009 15:55:54 -0700

Inline, as individual contributor.

On 11/25/09 9:38 AM, "Jonas Lindberg" <[email-masked]> wrote:

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

Agree.

> 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'/>

I'm fine with that.  There might need to be some text that says that if the
stream has already offered proof that a particular domain would be willing
to accept, a further challenges are not required.

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

If this gets to be a problem with the amount of traffic, we can figure out
some compression or caching schemes later.  Let's get some implementation
experience.

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

+1

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

+1.  Validation probably also requires revocation checks, too.

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

The intent was that those were two different proof options that the
challenger was offering, which your approach doesn't capture.  I also wanted
to preserve the option to add children in the namespace of the challenge
element if we needed to send information there for some challenge types.

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

I'm open to the directionality being negotiated mutually.

> 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

Nod.  

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

Yes, with your addition above, this needs to be per-pair.  There are
probably several other places that need to be cleaned up for that change.

-- 
Joe Hildebrand