Subject: [xmpp] DNA transport

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 15 Jan 2010 12:31:13 -0500

Assuming for the moment that we're going to stick with attribute  
certs: Rather than using both TLS and some new XML to carry DNA  
information, why not just hand the attribute certs over as part of the  
TLS negotiation?  That is, carrying XMPP authorization certs seems  
like a natural application of the TLS authorization extensions [1].   
That way, implementations can save on the crypto costs (since tls- 
authz is reportedly already implemented in OpenSSL, GNUTLS, and NSS),  
and draft-ietf-xmpp-dna can focus on the AC profile.

--Richard

[1] <http://tools.ietf.org/html/draft-housley-tls-authz-extns-09>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 15 Jan 2010 17:41:18 +0000

Richard L. Barnes wrote:
> Assuming for the moment that we're going to stick with attribute certs:
> Rather than using both TLS and some new XML to carry DNA information,
> why not just hand the attribute certs over as part of the TLS
> negotiation?  That is, carrying XMPP authorization certs seems like a
> natural application of the TLS authorization extensions [1].  That way,
> implementations can save on the crypto costs (since tls-authz is
> reportedly already implemented in OpenSSL, GNUTLS, and NSS), and
> draft-ietf-xmpp-dna can focus on the AC profile.

Would tls-authz work for the number of ACs that'd be involved here?
I understood that there could be a lot, which could therefore be a
good reason to do DNA at the application layer. Triggering sending
the right ACs at the right time could also be tricky depending on
the interfaces between the TLS library and the application. So I'd
say this is worth checking out, and would be interested if someone
did that, but I'd be a bit surprised if it were the right answer
in the end.

S.

> _______________________________________________
> xmpp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xmpp
>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 15 Jan 2010 14:10:12 -0500

That's a good point -- looking more closely at the spec, the current  
format only carries one authorization (AC or SAML).  However, it would  
be easy to extend it to support multiple authorizations; I don't see  
any obvious length constraints.  How many authorizations are we  
talking about?

--Richard

On Jan 15, 2010, at 12:41 PM, Stephen Farrell wrote:

>> certs:

---

From: Dave Cridland <[email-masked]>
Date: Fri, 15 Jan 2010 23:03:52 +0000

On Fri Jan 15 17:31:13 2010, Richard L. Barnes wrote:
> information, why not just hand the attribute certs over as part of  
> the  TLS negotiation?  That is, carrying XMPP authorization certs  
> seems  like a natural application of the TLS authorization  
> extensions [1].   That way, implementations can save on the crypto  
> costs (since tls- authz is reportedly already implemented in  
> OpenSSL, GNUTLS, and NSS),  and draft-ietf-xmpp-dna can focus on  
> the AC profile.

Can't - XMPP needs to dynamically add multiple domain credentials on  
the fly during a stream, so I think we'd need to either have a new  
TLS record type, or else carry them in the application protocol.

Carrying them in the application protocol also means we're channel  
independent.

And don't have to wait on the TLS guys quite so long.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Jonas Lindberg <[email-masked]>
Date: Sat, 16 Jan 2010 23:23:07 +0100

Good points. Definitely need the ability to add new domains during a stream,
and most likely don't want the overhead of passing credentials for all
domains that may be used during stream setup. Number of domains could be
large for a big hosting provider.

Jonas

On Sat, Jan 16, 2010 at 12:03 AM, Dave Cridland <[email-masked]> wrote:

>> Rather than using both TLS and some new XML to carry DNA  information, why
>> not just hand the attribute certs over as part of the  TLS negotiation?
>>  That is, carrying XMPP authorization certs seems  like a natural
>> application of the TLS authorization extensions [1].   That way,
>> implementations can save on the crypto costs (since tls- authz is reportedly
>> already implemented in OpenSSL, GNUTLS, and NSS),  and draft-ietf-xmpp-dna
>> can focus on the AC profile.
>>
>
> Can't - XMPP needs to dynamically add multiple domain credentials on the
> fly during a stream, so I think we'd need to either have a new TLS record
> type, or else carry them in the application protocol.
>
> Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]<[email-masked]>

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 18 Jan 2010 08:35:55 +0100

> and draft-ietf-xmpp-dna can focus on the AC profile.

That's not the right picture, at least for GnuTLS -- I implemented
TLS-AUTHZ for GnuTLS, and it was in a released version, but the FSF
(after consultation with the SFLC) decided to remove the implementation
due to patent threats because RedPhone withheld their claim of a patent
application on to the technology.  Given the number of free software
XMPP clients out there, I believe depending on potentially patent
encumbered technology is a poor idea.

See:

http://www.fsf.org/campaigns/software-patents/draft-housley-tls-authz-extns.html
http://www.fsf.org/news/oppose-tls-authz-standard.html
http://www.fsf.org/news/reoppose-tls-authz-standard
http://blog.josefsson.org/2007/10/18/on-tls-authz/
http://blog.josefsson.org/2007/04/11/tls-authz-patent-concerns/

The IETF has removed the original patent disclosure page #833 so you
cannot know what RedPhone originally told the IETF.  Thus today you
don't have access to all the (once) public information available, to
make your own informed decision on the patent situation anymore.  The
current patent disclosure is available from:

https://datatracker.ietf.org/ipr/1026/

Note that RedPhone could file another patent disclosure at any time and
request the IETF to remove the #1026 one, just like they did with #833.

/Simon