Subject: [xmpp] _xmpp-delegate SRV record

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 16 Feb 2010 10:48:12 -0700

At XMPP Summit #8 in Brussels last week, we discussed the problem of
delegated XMPP services in relation to encrypted streams. For example,
let's say that im.example.com is hosted by Google Apps. To provide TLS
for an XML stream to that domain, we would either need something like
domain name assertions (draft-ietf-xmpp-dna) or some kind of alternate
solution whereby example.com could officially delegate its XMPP service
to Google. The approach we discussed would be to define a new SRV record
for an XMPP delegate:

_xmpp-delegate._tcp.im.example.com google.com

The connecting entity would then perform a standard SRV lookup on the
delegate, for example:

_xmpp-server._tcp.google.com

The connecting entity would then resolve one of the provided hostnames
and connect to that IP address. When the digital certificate presented
says "google.com" instead of "im.example.com", the connecting entity
would know that it's OK to proceed.

The primary problem with this approach is that, absent DNSSEC, it is
insecure (someone could point your XMPP service at some other hosting
provider). However, the assembled throng in Brussels had rough
(non-IETF) consensus that this would be a fine approach for delegating
service once we have DNSSEC, so the security issues are temporary.
However, we promised to raise this on the XMPP WG list for broader
discussion.

Thoughts?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Jonathan Schleifer <[email-masked]>
Date: Tue, 16 Feb 2010 19:32:27 +0100

> Thoughts?

I think doing so before DNSSEC is a MUST is a very bad idea. Until  
then, it will make all certificate validation pretty useless. This is  
something that might be an idea in 5 or 10 years.

--
Jonathan

---

From: Dave Cridland <[email-masked]>
Date: Tue, 16 Feb 2010 21:14:41 +0000

> Thoughts?

I had a series of lengthy chats with various people, and none could  
answer (and some raised) the following questions:

1) Without DNSSEC, how is this more secure than what we have?

We have a choice of either:

_xmpp-server._tcp.example.org SRV 1 1 5269 xmpp.google.com

Or:

_xmpp-delegate.example.org CNAME google.com
_xmpp-server._tcp.google.com SRV 1 1 5269 xmpp.google.com

The latter seems marginally better for management purposes, but I  
don't see any improvement for security - indeed, it seems to increase  
the ability to spoof DNS, potentially.

2) With DNSSEC, how is this more secure than what we have?

Given we now* can use TLS solely to validate the host, then the SRV  
records we have always had are sufficient.

[*] Where "now" means when DNSSEC is ubiquitous, to the extent even  
my flying rocket car supports it.

So while I see benefits from the sense of management, I fail to see  
advantage in terms of security.

I'm still thinking along the lines of either a "proper" attribute  
certificate, or else some other signed "thing" with roughly the same  
properties.

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: Jesse Thompson <[email-masked]>
Date: Tue, 16 Feb 2010 16:18:39 -0600

On 2/16/2010 3:14 PM, Dave Cridland wrote:
> The latter seems marginally better for management purposes, but I don't
> see any improvement for security - indeed, it seems to increase the
> ability to spoof DNS, potentially.
>
> [*] Where "now" means when DNSSEC is ubiquitous, to the extent even my
> flying rocket car supports it.
>

That makes sense.  With DNSSEC, XMPP servers and clients could just 
trust the existing SRV records as adequate authorization and would no 
longer need to look for matching certificates during C2S and S2S TLS 
negotiation.

> certificate, or else some other signed "thing" with roughly the same

Fair enough.  I just hope that the "thing" is easy enough for domain 
owners to acquire and install.

Notice how dead simple Google Apps' process of verifying domain 
ownership is. 
http://www.google.com/support/a/bin/answer.py?hl=en&answer=47283 
Obviously, that only works for one-way authorization; 3rd parties can't 
use Google's authorization to determine if a domain is authorized to be 
hosted by Google since they cannot know what that unique string should 
be.  But it illustrates the level of simplicity domain owners have come 
to expect.

Jesse

-- 
   Jesse Thompson
   Division of Information Technology, University of Wisconsin-Madison
   Email/IM: [email-masked]

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 16 Feb 2010 22:47:54 +0000

> Thoughts?

It could well be that SRV records provide a useful way to
delegate that's easier for implementers than DNA. (That's
sort-of what we did with DKIM key and adsp records, and
without waiting for DNSSEC.)

One issue that arose with DKIM key records was that it
was considered an ok burden for mail domain operators to
publish these records, since they usually have to get
MX records published (and so have a way to get stuff
into DNS). I'm not sure if that'd be the same here, i.e.
would XMPP domain operators typically tend to have
write access to the DNS? If not, that'd be a problem I
imagine.

Also, with or without DNSSEC, a DNS based delegation
mechanism is essentially controlled by whoever manages
the zone files, which will often not be the XMPP operator.
Would that be ok? And without DNS, resolvers local to
the XMPP relying party would also be trusted for the
same thing. (I'm assuming that XMPP when using delegation
is potentially vulnerable to MITM attacks if the MITM
appears to be a valid delegate.)

Lastly, I don't think it'd be wise to wait for DNSSEC
for something that is really required - I think a DNS
based delegation scheme needs to be good enough now
(i.e. wthout DNSSEC), and if that's not possible then
something like DNA would seem to be required.

S.

---

From: Jonas Lindberg <[email-masked]>
Date: Wed, 17 Feb 2010 03:29:32 +0100

On Tue, Feb 16, 2010 at 10:14 PM, Dave Cridland <[email-masked]> wrote:

> I had a series of lengthy chats with various people, and none could answer
> (and some raised) the following questions:
>
> The latter seems marginally better for management purposes, but I don't see
> any improvement for security - indeed, it seems to increase the ability to
> spoof DNS, potentially.
>

A few of us chatted after the discussion and seemed to agree that option (1)
is preferable, because doing (2) didn't seem necessary or a big value add.
But that seem more like a detail here.

> Given we now* can use TLS solely to validate the host, then the SRV records
> we have always had are sufficient.
>

Few thoughts:

- Easy setup/management is important - secure solutions matter only if they
are used. If making secure s2s easier means more domains/admins will adopt
it, to the point where admins become comfortable with disallowing plain-text
s2s, then that would be good.

- There is value in encrypting s2s connections that today are plain-text,
even if the solution would "temporarily" rely on SRV, since MITM attacks are
harder than passive sniffing attacks.

- Not having to hand over a cert to your hosting provider seem like a
security improvement.

> certificate, or else some other signed "thing" with roughly the same

One could consider falling back on existing TLS solution for "real" security
in scenarios where both sides supports it (or one side requires it). Note
that traffic multiplexing between multiple domains pairs isn't supported in
that scenario.

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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 16 Feb 2010 21:33:11 -0500

Peter,

I think this is a fine idea.  Much, much simpler than DNA -- in  
particular, it doesn't require domains doing outsourcing to generate  
certificates, just to manage their DNS zone, which they already do.   
Just in the name of clarity, let me draft the steps:
0. ServerA wants to send a message to <xmpp:[email-masked]>
1. ServerA looks up the host name for "_xmpp-server._tcp.example.com"
1.1. Call this host ServerB, operated by the hosting provider  
"hosting.net"
2. ServerA connects to ServerB
2.1. ServerB authenticates as "hosting.net"
3. Noting that "hosting.net"!="example.com", ServerA looks up "_xmpp- 
delegate._tcp.example.com"
4. If the host name in the result is "hosting.net", then the  
connection proceeds, otherwise fails

With respect to DNSSEC, I don't think that's a show-stopper.  Even if  
you don't have DNSSEC, simply updating the certificate validation  
procedure to accommodate hosted services will enable server-to-server  
traffic to be carried over a secure channel -- protecting it from  
eavesdropping on the wire even if an illegitimate hosting provider has  
claimed it.  And even then, a hosting provider that wants to take over  
a domain would have to actively spoof/cache-poison the resolver for  
each server it deals with, which at least ups the ante.

The only real problem with using DNSSEC is ensuring that the client/ 
resolver has an appropriate set of trust anchors.  Naïvely, this would  
require that the root and all parent domains be signed, but in reality  
there are interim approaches, e.g., the DLV/TAR approaches (which are  
a hack, but might help).

Actually, I think we can exploit XMPP to do some key management here:  
Suppose we replace step (3) and (4) above with these two steps:
3.1. ServerA issues a <challenge/> to ServerB to authenticate as  
"example.com"
3.2. ServerB response with a URI that points to a certificate for  
"example.com" (under a well-known CA)
3.3. ServerA retrieves the certificate
3.4. ServerA retrieves the DNSSEC-protected SRV record for _xmpp- 
delegate._tcp.example.com"
4. Authentication succeeds iff both
4.1. The RRSIG on the SRV record validates using the key in the cert
4.2. The name in the SRV record is "hosting.net"

This is conceptually similar to what Joe proposed before, but with the  
advantages that the URI doesn't have to be secure, so that the hosting  
provider can manage it instead of the hosting customer.

--Richard

---

From: Jonas Lindberg <[email-masked]>
Date: Wed, 17 Feb 2010 03:34:59 +0100

On Tue, Feb 16, 2010 at 11:47 PM, Stephen Farrell <[email-masked]
> wrote:

> write access to the DNS? If not, that'd be a problem I

I think most Xmpp domains admins publish the
_xmpp-server._tcp.example.comSRV record today. We could try to gather
some stats on this if we decide a
delegate SRV record is needed.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 16 Feb 2010 21:53:20 -0800

+1.

On Feb 16, 2010, at 6:33 PM, "Richard L. Barnes" <[email-masked]>  
wrote:

> 1.1. Call this host ServerB, operated by the hosting provider "hosting.net 
> "
> With respect to DNSSEC, I don't think that's a show-stopper.  Even  
> if you don't have DNSSEC, simply updating the certificate validation  
> procedure to accommodate hosted services will enable server-to- 
> server traffic to be carried over a secure channel -- protecting it  
> from eavesdropping on the wire even if an illegitimate hosting  
> provider has claimed it.  And even then, a hosting provider that  
> wants to take over a domain would have to actively spoof/cache- 
> poison the resolver for each server it deals with, which at least  
> ups the ante.
>
> resolver has an appropriate set of trust anchors.  Naïvely, this wou 
> ld require that the root and all parent domains be signed, but in re 
> ality there are interim approaches, e.g., the DLV/TAR approaches (wh 
> ich are a hack, but might help).
>
> Actually, I think we can exploit XMPP to do some key management  
> here: Suppose we replace step (3) and (4) above with these two steps:
> 3.1. ServerA issues a <challenge/> to ServerB to authenticate as "example.com 
> "
> 3.2. ServerB response with a URI that points to a certificate for "example.com 
> " (under a well-known CA)
> This is conceptually similar to what Joe proposed before, but with  
> the advantages that the URI doesn't have to be secure, so that the  
> hosting provider can manage it instead of the hosting customer.
>
> --Richard
>
>

---

From: Philipp Hancke <[email-masked]>
Date: Wed, 17 Feb 2010 08:33:41 +0100

> would know that it's OK to proceed.

The change from the current behaviour would be that proceeding is then
OK instead of a spec violation?

philipp

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 17 Feb 2010 09:41:16 +0100

> longer need to look for matching certificates during C2S and S2S TLS

I don't think that is a good idea.  DNSSEC protects data from tampering
in transit, it doesn't mean that you will end up talking to whom you
believe you are talking to.  TLS certificate matching is still critical
to achieve the latter.

/Simon

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 17 Feb 2010 09:57:15 +0100

> believe you are talking to.  TLS certificate matching is still critical
Not checking the certificates is a terribly bad idea (TM). The question here is
really what to check against and how to avoid having to have certificates
with hundreds of subject alt names.

The problem with the subject alt name model is that it mixes identification and
authorization and that's generally a bad idea. We need to be able to identify
the proper server and by another mean figure out which server that is authorized
to handle a domain. 

Using a DNS entry as a glue is definitely one method. Another solution would be
to simply store the certificate of the server in the DNS. In the edvina.org zone, which you 
will trust by dnssec, I store the certificate of the server I authorize to handle my domain.
In the cert you'll find the DNS name and you can validate the identity of the server
with the certificate's public key.

That's a very simple solution and forces the zone owner to update the cert as it expires and re-evaluate
the trust of the server/service.

/O

---

From: Joe Hildebrand <[email-masked]>
Date: Wed, 17 Feb 2010 01:40:12 -0800

On 2/17/10 12:57 AM, "Olle E. Johansson" <[email-masked]> wrote:

> Using a DNS entry as a glue is definitely one method. Another solution would
> be to simply store the certificate of the server in the DNS. In the edvina.org
> zone, which you will trust by dnssec, I store the certificate of the server I
> authorize to handle my domain. In the cert you'll find the DNS name and you
> can validate the identity of the server with the certificate's public key.

The attribute cert approach that is outlined in the DNA draft is the moral
equivalent of this, but deployable before DNSSEC is widely-available.

-- 
Joe Hildebrand
(as individual)

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 17 Feb 2010 07:05:57 -0500

It's a little bit misleading to say that DNSSEC isn't "widely  
available" right now.  I'm not an expert, but I believe that support  
in modern resolver software is pretty complete.  What's lacking is a  
way to chain the whole DNS up to a small set of trust anchors, but as  
my prior message indicated, there are work-arounds for that problem in  
this case.  So it's very plausible to me that you could use DNSSEC as  
a protocol for securing these records, without relying on DNSSEC as a  
key hierarchy.

--Richard

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 17 Feb 2010 12:17:30 +0000

Richard L. Barnes wrote:
> It's a little bit misleading to say that DNSSEC isn't "widely available"
> right now.  

I guess I'd disagree. Very few records are signed, which, for
me, is the important thing. I think it'd be fine if there's a
solution the WG likes that uses DNS as-is, where the fact that
DNS is relatively insecure is a known, but (in that case
presumably) acceptable source of risk. In that case, whenever
DNSSEC gets deployed things get better, but are already good
enough before DNSSEC deployment (hopefully) occurs.

But a solution for deployment now-ish, that uses DNS *and*
requires deployed DNSSEC would IMO amount to pretending to
address security and would be a bad thing.

S.

> I'm not an expert, but I believe that support in modern
> resolver software is pretty complete.  What's lacking is a way to chain
> the whole DNS up to a small set of trust anchors, but as my prior
> message indicated, there are work-arounds for that problem in this
> case.  So it's very plausible to me that you could use DNSSEC as a
> protocol for securing these records, without relying on DNSSEC as a key
> hierarchy.
> 
> --Richard
> 
> 
>

---

From: Jehan Pagès <[email-masked]>
Date: Wed, 17 Feb 2010 22:23:39 +0900

Hi,

I never read any of DNSSEC specs (just overview description), but from
what I know, my opinions are:

1/ As some others here, I think that WITHOUT DNSSEC, this would be a
huge security leak. I mean it is so easy to fake DNS between the end
user and the finale server and something hard to notice. Not really
"hard" technically but how many people actually checks the DNS route
for each DNS query made by the softwares they use? It would be seen
soon, obviously, but not as fast as a certificate issue (=
immediately). Yet here we simply discard the usefulness of a
certificate: if someone malevolently redirects a DNS to his
server, and as this someone has obviously the right certificate for
his own domain (and it is normal: it is his), then the redirection
would not be seen until someone checks the DNS route manually.

So certificate would not be a security barrier anymore as they are now
completely and easily bypassable: you simply need to change DNS to
fake any XMPP server.

2/ As I said, I don't really know DNSSEC, but from what I understand
with the description I read, if it is really some kind of secure DNS,
then this new SRV records should be ok WITH DNSSEC.
But from my understanding, again, here the goal of this records is not
at all about adding security on normal use, but only a way to securely
delegate the technical hosting to a third party XMPP provider, without
having to give its own certificate (obviously! This would be
unthinkable and huge security issue). Is there any other interest for
this SRV records?

And of course it means we must trust our authoritative DNS server in
case it is not oneself (because we still give such entity the power to
easily bypass our identity certificate). Ironically I guess that the
one who host their own XMPP server will probably also host their own
authoritative DNS server (so for them it is not such an issue).

Anyway in the end, this is a feature made to simplify the service
providing (and I totally understand this!) at the price of a possible
security issue. So this is not easy matter in my opinion.

3/ I don't agree with Jess Thompson on the fact that with DNSSEC,
certificates are not to be checked. EVEN WITH DNSSEC, you must still
check the certificate at the end server for verifying the identity of
this server (though it will be the identity of the delegate end server
domain itself here, and not the identity of the queried initial
domain). Knowing that the DNS information is right through DNSSEC does
not mean at all that the transmission cannot be intercepted afterwards
before reaching your desired service.

So as a conclusion, I think this must be very carefuly thought and
probably such new DNS SRV records should be accepted only for domains
whose DNS answers were signed (using DNSSEC spec). In the XMPP spec,
there may be a security note advicing a XMPP entity to care about
cases where a redirection through this _xmpp-delegate records exists
while the DNS answer was not signed. Then the resulting action may
depend on the kind of entity and of security choices, but at least it
would not be ignored. For instance a client may display a warning to
the user telling him the connection is possibly unsecure (and one can
then click a checkbox "do not tell me again" if one doesn't want to
know, but at least one has been warned... a little like the
problematic of self signed certificates where web browser and XMPP
client usually warns about the possibility of forge of a domain). As a
server, maybe a message to an administrator about this unprotected
redirection could be sent... for instance.
What matters anyway is that, if we leave a forging leak here, at least
we advice the right thing to fix it, and we warn actively about the
big security issue (even if it is annoying, but hey! to have no
warning, just make secure), so that it does not stay a statu-quo.
The real problem here is that it does not make the certificate bypass
leak only for those who will use this SRV record, but for everyone:
even if you don't care and host your own XMPP server, the DNS
information can still be very easily forge and a user may be mislead
on a fake server without noticing. So using this new SRV feature
without all the necessary security (DNSSEC) must raise a warning to a
XMPP entity (maybe not blocker, at least a warning).
Ok. That's my opinion, unless I did not understand something. Bye.

Jehan

---

From: Jesse Thompson <[email-masked]>
Date: Wed, 17 Feb 2010 10:06:41 -0600

> before reaching your desired service.

I agree with that.  I should have been more clear.

Jesse

---

From: Jesse Thompson <[email-masked]>
Date: Wed, 17 Feb 2010 10:22:56 -0600

FWIW.  I'm not advocating against the importance DNSSEC, but I think 
that this is worth mentioning.

Email MX records are just as vulnerable to DNS poisoning as _xmpp-server 
records.  Most SMTP servers do not even attempt TLS, much less require 
the server certificate to match the email domain.  One could question 
(rightly) the email community's inaction on addressing the issue, but it 
also demonstrates the likelihood of S2S records being poisoned in practice.

C2S, on the other hand, is the most likely place where DNS poisoning 
would occur.

Jesse

On 2/17/2010 7:23 AM, Jehan Pagès wrote:
> On 2/17/10, Stephen Farrell<[email-masked]>  wrote:
>>
>>
>> Richard L. Barnes wrote:
>>>> On 2/17/10 12:57 AM, "Olle E. Johansson"<[email-masked]>  wrote:
>>>>

---

From: Dave Cridland <[email-masked]>
Date: Wed, 17 Feb 2010 16:29:00 +0000

On Wed Feb 17 16:22:56 2010, Jesse Thompson wrote:
> FWIW.  I'm not advocating against the importance DNSSEC, but I  
> think that this is worth mentioning.
> 
> Email MX records are just as vulnerable to DNS poisoning as  
> _xmpp-server records.  Most SMTP servers do not even attempt TLS,  
> much less require the server certificate to match the email domain.  
>  One could question (rightly) the email community's inaction on  
> addressing the issue, but it also demonstrates the likelihood of  
> S2S records being poisoned in practice.
> 
> C2S, on the other hand, is the most likely place where DNS  
> poisoning would occur.

That's an interesting observation, and made me wonder - it occured to  
me that most attackers of the email system particularly want traffic  
to be transmitted to the right place - the emphasis is on making the  
traffic come *from* the wrong place - in simpler language, the  
attacks are about spam.

With XMPP, therefore, the same thing would apply - that is, people  
won't be trying to make you connect to them instead of example.com's  
"real" server, but they may well be interested in fooling you into  
thinking that your inbound session is legitimately allowed to send  
messages from "example.com".

This is an attack that's not needed in the SMTP world, and I think  
it's the attack we should be concerned about.

Dave.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Wed, 17 Feb 2010 17:32:24 +0100

17 feb 2010 kl. 17.22 skrev Jesse Thompson:

> FWIW.  I'm not advocating against the importance DNSSEC, but I think that this is worth mentioning.
> 
> Email MX records are just as vulnerable to DNS poisoning as _xmpp-server records.  
Exactly! As well as SIP SRV records.

> Most SMTP servers do not even attempt TLS, much less require the server certificate to match the email domain.  One could question (rightly) the email community's inaction on addressing the issue,
Yes. 

> but it also demonstrates the likelihood of S2S records being poisoned in practice.
I don't follow you here. Either we forget all about any security and follow e-mail or we start working ourselves to a higher level of security, which the XMPP community has done for some time now. I don't think using e-mail as an example helps anything. The lack of identification and trust between mail servers opens that service up for serious misuse - a.k.a spam.

If more and more business-related traffic happens over XMPP, there is of course a vulnerability in the S2S records too.

> 
> C2S, on the other hand, is the most likely place where DNS poisoning would occur.
I don't necessarily agree with you here. Trying to determine where the attacks will most likely happen is a lost cause.

We need to protect all parts of the chain, make sure that the clients verify the local server as well as verify communication between servers. Otherwise, no path will ever be trusted - and that must be the goal here.

/O
>>>>> equivalent of this, but deployable before DNSSEC is widely-available.

---
* Olle E Johansson - [email-masked]
* Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden

---

From: Jehan Pagès <[email-masked]>
Date: Thu, 18 Feb 2010 01:56:43 +0900

Hi,

> that this is worth mentioning.

First of all, sorry I just noticed I made a mistake on your name in my
previous message. It is Jesse, not Jess.

> also demonstrates the likelihood of S2S records being poisoned in practice.

Two points here:

1/ For SMTP and everything email related, I guess that the problem for
all the known security weaknesses of these protocol is simply that
these protocols are just too old. There is too much of a statu-quo
here because it has been like this for so many years (dozens of
years!).
But XMPP is not SMTP. What is the use to make specs of modern protocol
if not taking into account years of accumulated experience indeed
(through a lot of errors). This is not a critic, but a normal process
for evolution of technologies. Yet let's not make errors "on purpose"
that we can avoid from the beginning, because if so, the same will
happen: even with improvements in the future, nobody will implement
them saying «eh it has been like this for years». So let's make solid
bases! This is my opinion.

2/ Of course _xmpp-server is vulnerable to DNS poisoning (without
DNSSEC). But what protects the user at the end is TLS. So there is no
security leak brought by _xmpp-server, nor _xmpp-client records. They
are just here to redirect on the right machines, but these machines
uses certificates, this is what makes the security here. If someone
connects to a forged XMPP server with no certificate, after being
redirected by a DNS poisoning, for a domain supposed to use
certificate with TLS, there will be suspicion from the user
(considering his client gives him such information, which I believe
all client will do in some future... the same way as web browser now
gives the "lock" image information when the connection is well
secured). Even worse if the server proposes indeed a wrong
certificate, then it should bring up an alert (and the user can choose
to ignore it at one's own risk) or refuse the connection, hence
protect the user.

_xmpp-delegate here is a completely different case because we are
proposing a method to completely bypass the TLS certificate
identification of the server through a very classic and simple DNS
poisoning (whatever it is S2S or C2S) and this without any warning
(the forged server will be able to use "legally" his own certificate
and then your client will think "hey all is ok and nice, connection
secured to a legal delegate server). So I think the proposition for
this new SRV record in its current state is very dangerous. It makes
it very simple to pretend to be a server which uses TLS.

In all this, as I said, I would think this is not a problem if it
brings a security issue only to people wishing to use this delegate
provider system. I would think that they takes a know risk thinking it
will be ok (and most of the time it will... until it is proven
wrong!), leaving the self hosted servers their maximum security (I
don't say this because I am self hosted and don't care of others,
simply that when you delegate a XMPP server, this is probably that you
don't care so much about security anyway, like if you have your own
private domain for your family, no dedicated server, and just want to
have a JID with this domain). But we are also shifting this risk to
the self hosted as well (as a DNS poisoning can happen to them to,
redirecting their users to another server with no security warning).
Bye.

Jehan

---

From: Jehan Pagès <[email-masked]>
Date: Thu, 18 Feb 2010 02:49:15 +0900

Hi,

On 2/18/10, Dave Cridland <[email-masked]> wrote:
>> [...]

I am not sure to agree about the fact that it is more interesting for
spammer (or other malevolent people) to pretend "sending from" than to
have legitimate users connecting on your server thinking it is the
good one.
But let's suppose it is the case. I can see, just thinking 30 seconds,
at least two attack scenarios where this new SRV records (without
DNSSEC, supposing that it really prevents it) will enable you to have
spam pretending (with success) coming from example.com.

* Attack 1 (with S2S):
I manage to make a DNS poisoning for a given server which I will call
"recipient.tld". In my DNS poison, I will make "recipient.tld" believe
that "sender.tld" (which is usually a nice domain) has set my domain
"spammer.tld" as its legitimate delegate.

So I send now a lot of spams to recipient.tld coming apparently from
users of sender.tld, all this sent from machine in spammer.tld. When
recipient.tld checks the DNS, it will see that spammer.tld is a
delegate, so it won't be worried when the incoming connection will
present the certificate of spammer.tld (perfectly good, well signed
from a trusted certificate issuer, all in order!).
And here I have successfully pretended to be sender.tld and sent
thousands of spams on its behalf without even a single suspicion from
recipient.tld with a simple DNS poisoning.

With the current state (_xmpp-server), it is not possible even if you
poison the DNS. I mean: it is possible, but there will be suspicion
(so maybe message to an admin directly sent to check this all) or even
rejection of the S2S connection (wrong certificate! Or no certificate
with a very strict security policy, or if recipient.tld keeps track of
the old certificate and consider it very doubtful that sender.tld
removed such a security, etc.).

* Attack 2 (with C2S):

I poison some DNS cache that a XMPP client will use. Therefore it will
connect to my server spammer.tld while it was supposed to connect to
sender.tld. And everything will look good: spammer.tld is a legitimate
delegate (according to the DNS) and it presented a good certificate
for one's domain. So TLS worked: the user is "securely" connected to
spammer.tld, thinking being on sender.tld.

So there are two subcases now:

- spammer.tld connects now in the same time to sender.tld, pretending
to be the user, hence receives the challenge on its behalf, forwards
it directly to the user which sends the response, and then spammer.tld
send this response to sender.tld and... the spammer bot is now
connected on the real sender.tld as though it was the user! It can see
the roster, archived messages, and everything, change the password (if
possible through adhoc commands for instance, so next time it will be
able to calculate itself the response to the changing challenge even
though it means also that the user will soon see the problem) and send
messages to anyone not even pretending, but really being the user of
sender.tld.

- spammer.tld simply propose only some PLAIN authentication, then if
the client is not a little suspicious, it will gives its password. So
spammer.tld can now connect to sender.tld without help of the user (it
can calculate itself any answer to authentication challenges) and
without even changing its password (so might stay not seen for some
time before people report strange behaviour of the user, spammer
without knowing).
Of course knowing the user's real password is obviously also a plus in
order to try it on other services (as many people keep the same
password everywhere!).

So here are two attack scenarios (maybe more are possible) with a very
simple DNS poisoning. Without _xmpp-delegate, warning would have been
raised at the very least, and connection would have been blocked at
best (providing the client makes correct use of TLS and forces it,
which is the current "mandatory-to-implement" technology in the RFC
3920bis-04).
Bye.

Jehan

---

From: Jesse Thompson <[email-masked]>
Date: Wed, 17 Feb 2010 12:07:45 -0600

> bases! This is my opinion.

No argument from me on this point.  Inertia sucks sometimes. :-)

> security leak brought by _xmpp-server,

In theory only.  What is the actual adoption rate of servers enforcing 
TLS (requiring matching certs) for S2S?  Given that it would break all 
Google Apps hosted domains (at the least,) I expect it is very low.  You 
can make the same point about status-quo here.

> wrong!),

I don't agree with your sentiment that delegated domains are less 
concerned with security.  The domains we (as the central IT division) 
host are mostly all part of the same university, and many (especially 
the research departments) are more concerned about security than the 
general university population.  The reason they delegate has more to do 
with specialization and prioritization of departmental IT staff.

I agree with your point about letting administrators decide what is best 
for them.  A pragmatic solution that gives practical tools to the 
user/administrator to be as secure as possible is better than a bullet 
proof solution that no one implements.

The current state of C2S security is broken.  Most hosted XMPP services 
don't have matching certs, so the clients will warn/prompt the user (in 
various ways,) and the user gets to make the decision.  In effect, this 
half-assed requirement for matching certificates does not improve 
security for C2S since the clients have been forced to make it stupidly 
simple for users to click through the warnings.

S2S on the other hand could be left up to the server administrator to 
make the decision (in effect, most server administrators have already 
chosen to not enforce matching certificates for S2S.)  I personally feel 
that spammers will not attempt to use DNS poisoning to masquerade as 
other XMPP domains since it is easier for them to just use their own 
domains, or use generated/compromised accounts in trustworthy services.

Jesse

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 17 Feb 2010 13:17:43 -0500

You're missing the point: This solution doesn't require "deployed  
DNSSEC", in the sense of having DNSSEC deployed in the whole DNS  
tree.  Because you can bootstrap keys out of unsecured XMPP, only the  
hosting customer domain (the delegator) needs to deploy DNSSEC.

So all the "deployment" you need is for the XMPP participants to use  
DNSSEC-compatible software.  Which, like I said before, encompasses  
pretty much all modern DNS software (including, e.g., BIND, NSD,  
unbound, even Net::DNS::SEC):
<http://www.dnssec.net/software>

--Richard

On Feb 17, 2010, at 7:17 AM, Stephen Farrell wrote:

>> available"
>>>> zone, which you will trust by dnssec, I store the certificate of  
>>>> the
>>>> server I
>>>> can validate the identity of the server with the certificate's  
>>>> public
>>>> key.
>>>

---

From: Kevin Smith <[email-masked]>
Date: Wed, 17 Feb 2010 18:18:07 +0000

On Wed, Feb 17, 2010 at 6:07 PM, Jesse Thompson
<[email-masked]> wrote:
> half-assed requirement for matching certificates does not improve security
> for C2S since the clients have been forced to make it stupidly simple for
> users to click through the warnings.

Well, it does give ssh-style leap-of-faith, which is what most people
(empirically) think is good enough. That's better, arguably, than
what's on the table here. With leap of faith, a subsequent DNS (or
other) compromise will be flagged to the user - with _xmpp-delegate, a
DNS compromise will make the certificate appear valid to the user.

/K

---

From: Kevin Smith <[email-masked]>
Date: Wed, 17 Feb 2010 18:21:03 +0000

On Wed, Feb 17, 2010 at 4:29 PM, Dave Cridland <[email-masked]> wrote:
> With XMPP, therefore, the same thing would apply - that is, people won't be
> trying to make you connect to them instead of example.com's "real" server,
> but they may well be interested in fooling you into thinking that your
> inbound session is legitimately allowed to send messages from "example.com".
> This is an attack that's not needed in the SMTP world, and I think it's the
> attack we should be concerned about.

I'm not sure that's true - by spoofing the server for c2s, you can
gather passwords that you can then use to send spam from non-spoofed
users on the real server. (Ok, so authing with digest or scram means
you don't gather the password, but the possibility of a pass-through
is still there (unless someone knows differently)). Both seem
reasonable approaches for spammers.

/K

---

From: Jesse Thompson <[email-masked]>
Date: Wed, 17 Feb 2010 12:21:28 -0600

> DNS compromise will make the certificate appear valid to the user.

Not if there is a requirement that the certificate match the server and 
is signed by a trusted authority.

Jesse

---

From: Kevin Smith <[email-masked]>
Date: Wed, 17 Feb 2010 18:22:38 +0000

On Wed, Feb 17, 2010 at 6:21 PM, Jesse Thompson
<[email-masked]> wrote:
> Not if there is a requirement that the certificate match the server and is
> signed by a trusted authority.

Which bit are you disagreeing with?

/K

---

From: Jesse Thompson <[email-masked]>
Date: Wed, 17 Feb 2010 12:27:52 -0600

> Which bit are you disagreeing with?

"DNS compromise will make the certificate appear valid to the user"

Oh, nevermind.  I take it back.

Jesse

---

From: Jesse Thompson <[email-masked]>
Date: Wed, 17 Feb 2010 12:40:20 -0600

On 2/17/2010 2:57 AM, Olle E. Johansson wrote:
>> Jesse Thompson<[email-masked]>  writes:
>>

Right.  My only issue is with the requirement that the certificate match 
the domain.

If there is a means to ensure that the value of _xmpp-server or 
_xmpp-delegate is correct, then the hosting provider would only need to 
provide a signed certificate to match their own server name.

> with the certificate's public key.

Why not [optionally] use trusted certificate authorities to accomplish 
this?  I say that provider.tld is authorized to host my domain, and you 
trust that is a true statement (dnssec or otherwise,) and the 
certificate presented by provider.tld is signed by CA that you trust.

---

From: Jehan Pagès <[email-masked]>
Date: Thu, 18 Feb 2010 03:41:02 +0900

Hi,

> can make the same point about status-quo here.

It is true, it is current state of the network. But even though big
companies are starting to join, it is still the beginning for XMPP. I
mean: it is still young, we have a chance to make the right choices
now. Google are also heavily working on their XMPP implementation (I
think). Everybody is indeed, because it is still so new and everything
is changing very fast in the XMPP world.

> with specialization and prioritization of departmental IT staff.

If you say so, probably. I just said this as a guess. :-) But then
this is even more a problem even for them.

> simple for users to click through the warnings.

Yes and no. Yes: I agree that most user caught by the evil DNS
poisoner by clicking without reading the warning. No: some users won't
be caught and will say «eh what is this? This certificate is wrong! I
disconnect without sending my password.».

This is true for everything, even out of the internet: some people
cares about warning, other don't (as a matter of fact, in the wild I
often don't listen to warning... :p but I won't advice people to do as
me!). But even though some people may be fool enough not to care about
a sign saying "beware, mine field", and die blown that we should
remove the sign (thus having people die while they would have
otherwise read the sign and backed off).
Here what we propose is no more no less than giving a way to remove
the sign. Then even aware people will get caught by the DNS poisoning
because there will be no warning of it.
We must not make security considerations depending on users who do not
care, but on those who do.

Anyway I expect that in some close future, not only server will get
better security procedures, but also clients, the same way that
security features appear more and more in web browser in the last
years (showing locks or changing colors of address bar when website is
secured, or showing big warning when certificate issues, etc.). How
many years the browsers were uncareful before beginning to understand
this is a key feature for a safe internet? But at least now it is
here. I am trustful than the same thing will happen for XMPP (but even
more secure as XMPP is thought to be secure from the ground).

> domains, or use generated/compromised accounts in trustworthy services.

As I just said, yes now it is bad. But let's make the rules as good as
possible anyway. And I trust all services and client to become safer
and safer with time. As someone said before: we must secure the whole
chain. Because no matter how strong are most of the link if one only
is weak: it will break the whole chain.
Bye.

Jehan

---

From: Jesse Thompson <[email-masked]>
Date: Wed, 17 Feb 2010 12:55:05 -0600

On 2/17/2010 12:41 PM, Jehan Pagès wrote:
> Hi,
>
> On 2/18/10, Jesse Thompson<[email-masked]>  wrote:

I'm saying it's already too late.  Google would need to tell all of 
their Google Apps customers to provide them with certificates by a 
certain date, otherwise they will no longer be able to federate.  Even 
if Google decided that they are willing to risk pissing off their 
customers, it wouldn't actually be Google that enforces the cut-off; it 
would be the rest of us.  Should we do a survey to find out how many of 
us are willing to cut off federation with all Google Apps domains and 
all other domains, delegated or not, that don't have valid signed 
matching certificates?

> is weak: it will break the whole chain.

I just don't think that we should kid ourselves that the "requirement" 
for certificates to match the domain is providing any level of security.

If DNSSEC is the only option, then so be it.

Jesse

---

From: Philipp Hancke <[email-masked]>
Date: Wed, 17 Feb 2010 20:38:00 +0100

> can make the same point about status-quo here.

See http://mail.jabber.org/pipermail/standards/2007-July/016086.html
The situation has not changed since then.

philipp

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 18 Feb 2010 08:35:22 +0100

17 feb 2010 kl. 19.40 skrev Jesse Thompson:

> Right.  My only issue is with the requirement that the certificate match the domain.
> 
> If there is a means to ensure that the value of _xmpp-server or _xmpp-delegate is correct, then the hosting provider would only need to provide a signed certificate to match their own server name.
> 
> 
> Why not [optionally] use trusted certificate authorities to accomplish this?  I say that provider.tld is authorized to host my domain, and you trust that is a true statement (dnssec or otherwise,) and the certificate presented by provider.tld is signed by CA that you trust.
> 
Looking at 
http://mail.jabber.org/pipermail/standards/2007-July/016086.html
* "3785 servers listed"
* "966 servers presented a certificate"
* "of those 966 certificates,  489 were self-signed""

I'd say that most people don't understand TLS and don't understand why they have to pay a tax to a CA.

If we can avoid the CAs and build a trust model with certificates that work with selfsigned or DNS-signed certificates, I'd say we can get the adoption rate up. The software you run can create the keypair and the cert and output it as a DNS record for you to store in DNS.
We all *have* to trust DNS, and DNSsec adds on top of this a system where we can add a CA-like trust model to DNS. Let's use that instead of trying to figure out a list of CAs that all the world should trust in their XMPP implementations.

/O

---

From: Jesse Thompson <[email-masked]>
Date: Thu, 18 Feb 2010 12:14:29 -0600

> * "of those 966 certificates,  489 were self-signed""

It's possible that the reason that so many of the certs are self-signed 
is because of the impractical requirement that the cert match the domain.

A service provider probably already has a signed certificate for their 
own server/service name.

> We all *have* to trust DNS, and DNSsec adds on top of this a system where we can add a CA-like trust model to DNS. Let's use that instead of trying to figure out a list of CAs that all the world sh…

I'm not saying that this couldn't be an alternative to CAs.

Jesse

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 18 Feb 2010 22:21:30 -0700

> equivalent of this, but deployable before DNSSEC is widely-available.

For some sense of deployable. :) One of the reasons we started to
explore the path of _xmpp-delegate in our discussions at the Summit is
that we're concerned about the deployability of attribute certificates
(lack of support in current tools, no real experience with attribute
certs among administrators, etc.).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 18 Feb 2010 22:41:38 -0700

On 2/17/10 9:56 AM, Jehan Pagès wrote:

> uses certificates, this is what makes the security here. 

In theory, yes. In practice, large hosting providers find it difficult
or impossible to offer the right certificates (if you're Google Apps, do
you want to have a cert with 10,000 subjectAltName extensions?). Thus
we're left with no TLS at all. Which of the following exposes a larger
attack surface?

1. No TLS on s2s or c2s streams.

2. TLS on s2s and c2s streams only after a human accepts a mismatched
cert for the XMPP service. (And how many humans know what they're doing
in this regard?)

3. TLS on s2s and c2s streams via something like _xmpp-delegate.

> If someone
> secured to a legal delegate server). 

See above on mismatched certs.

> So I think the proposition for

Please note the order that Richard Barnes described:

###

0. ServerA wants to send a message to <xmpp:[email-masked]>
1. ServerA looks up the host name for "_xmpp-server._tcp.example.com"
1.1. Call this host ServerB, operated by the hosting provider "hosting.net"
2. ServerA connects to ServerB
2.1. ServerB authenticates as "hosting.net"
3. Noting that "hosting.net"!="example.com", ServerA looks up
"_xmpp-delegate._tcp.example.com"
4. If the host name in the result is "hosting.net", then the connection
proceeds, otherwise fails

###

If the certs match correctly when trying the server discovered via the
standard _xmpp-server or _xmpp-client SRV records, the delegate flow
would never be invoked, because you would do this:

###

0. ServerA wants to send a message to <xmpp:[email-masked]>
1. ServerA looks up the host name for "_xmpp-server._tcp.example.com"
1.1. Call this host ServerB, operated in the "standard" case *not* by a
hosting provider but by the authoritative service for example.com
2. ServerA connects to example.com
2.1. example.com authenticates as, well, "example.com"

###

Now, one thing I would clarify in Richard's flow is step 4:

4. If the host name in the result is "hosting.net", then the connection
proceeds, otherwise fails

Maybe. IMHO an application would still need to inform a human user about
the mismatch and ask the user to approve it. The benefit here is that
when we do have DNSSEC, we could put more trust in the delegate than we
would in some random host mismatch.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 18 Feb 2010 22:45:11 -0700

> DNS compromise will make the certificate appear valid to the user.

I'm not convinced of that. The user will still need to connect to the
_xmpp-client host/IP first. This won't be automatic.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Pedro Melo <[email-masked]>
Date: Fri, 19 Feb 2010 08:22:41 +0000

Hi,

On Tue, Feb 16, 2010 at 5:48 PM, Peter Saint-Andre <[email-masked]> wrote:
> delegated XMPP services in relation to encrypted streams.
[...]
> Thoughts?

I've been following along this conversation for quite some time. A
couple of years back we wanted to deploy XMPP servers to about 30k
domains and though about this problems.

I'm no expert on TLS/SSL, so please educate me if my understanding of
what is possible turns out to be wrong.

As for DNSSEC, it will never be our single source of trust. It will be
another tool to provide one layer of security and trust, not *the*
layer of security and trust. Therefore, the solution for this problem
must still be done with TLS/SSL certificates.

As for SSH-style known-hosts, at most you can give a visual
representation of the remote certificate from the second connection
on. The first connection is still the problem, though. So it might
limit future hijacking of identities, but it wont solve the trust
problem in the initial connection.

But back to the original problem: how to have CompanyA delegate trust
to ServiceProviderX in regard to TLS connections?

I don't know if this is possible but maybe something like this would work:

1. CompanyA creates a file (format is not important, as long as the
information is there) with the following data:
  * ServiceProviderX certificate signature;
  * optional expires data;
2. CompanyA signs this file with his own certificate and gives it to
ServiceProviderX;
3. ServiceProviderX uses his own certificate on all TLS/SSL connections;
4. When a client connects to CompanyA domain, it receives
ServiceProviderX. Given that it is different from CompanyA cert, it
asks for a proof of delegation. ServiceProdiderX server sends the file
created above, which the client can verify that it was signed by the
proper certificate and then trust the ServiceProdiderX cert as a valid
delegate. Optionally this file could be send automatically by the
server based on a stream feature to remove the extra round-trip.

To me this problems seems to originate by the fact that the X509
security model is a strict hierarchical system, without the
web-of-trust model of PGP. This extra file that I mention works like a
poor man Web-of-trust for TLS/SSL.

Bye,
-- 
Pedro Melo
http://www.simplicidade.org/
xmpp:[email-masked]
mailto:[email-masked]

---

From: Philipp Hancke <[email-masked]>
Date: Fri, 19 Feb 2010 09:43:34 +0100

> is because of the impractical requirement that the cert match the domain.

Well... why bother to get a signed certificate (available for free at
xmpp.net back then) if it works just as well with a self-signed
one?

---

From: Dave Cridland <[email-masked]>
Date: Fri, 19 Feb 2010 10:25:58 +0000

> poor man Web-of-trust for TLS/SSL.

What you're basically describing is an attribute cert, and is indeed  
covered by X.509.

You don't need the service provider's certificate in the signed  
"thing", just the name of the service provider will do.

If people don't want attribute certificates, then we could do a  
simple XML format, and then hand-wave over revocation.

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Fri, 19 Feb 2010 10:26:24 +0000

> _xmpp-client host/IP first. This won't be automatic.

So your argument is approximately:

- DNS is insecure.
- Therefore we should require it to be spoofed twice.

This suggests that it'll take two spoofs for a subversion, yet only  
one (out of two chances) for a DOS.

Dave.

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 19 Feb 2010 06:17:30 -0700

On 2/19/10 3:25 AM, Dave Cridland wrote:
> You don't need the service provider's certificate in the signed "thing",
> just the name of the service provider will do.
> 
> If people don't want attribute certificates, then we could do a simple
> XML format, and then hand-wave over revocation.

Right, that's just attribute certs. I think we all agree that attribute
certs are the right solution. The question is whether we they are
deployable given the probable need to add support for them (or at least
test such support) in existing crypto libraries, build an open-source
attribute certificate creation tool (we can't expect domain admins to
know how to do this given that no other technology uses attribute certs
right now), define best practices for managing and deploying attribute
certs by both domain admins and hosting providers, etc. This is not a
trivial undertaking. Waving our hands about "just use attribute
certificates" is not enough.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 19 Feb 2010 06:20:14 -0700

On 2/19/10 3:26 AM, Dave Cridland wrote:
>> security

I'm trying to represent the argument of those who have floated the idea
of a delegate record. I'm not yet convinced by the argument, but I'm
working to weigh all the options on the table.

> This suggests that it'll take two spoofs for a subversion, yet only one
> (out of two chances) for a DOS.

Once again, we need to look at the entire threat model, what is easier
to subvert, etc. Yes, Attribute Certs Are The Answer[tm] but I do worry
about deployability, because we have plenty of existence proofs for the
fact that a perfect but undeployable security technology doesn't do us
any good.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 19 Feb 2010 13:29:25 +0000

> "_xmpp-delegate._tcp.example.com"

Why doesn't server A just detect this at step 1 by
noticing that the host name for _xmpp-server._tcp.example.com
is not in the example.com domain?

S.

> ------------------------------------------------------------------------
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 19 Feb 2010 13:34:24 +0000

> fact that a perfect but undeployable security technology doesn't do us

Fully agree with you as to the right thing and the worry.

How about if we try to document three variations in the next dna
draft: the AC-based one that's there already, the xml-ish one
previously discussed on the list and the DNS based delegation one.

I guess that'd allow folks to see how each'd work for them and
we can get rid of two of 'em later on. (I've not heard anyone
say there needs to be >1 mechanism right now, and I think that's
probably correct.)

Sound like a plan? (I've yet to think about when that can get done
mind you.)

S.

---

From: Philipp Hancke <[email-masked]>
Date: Fri, 19 Feb 2010 15:43:30 +0100

> previously discussed on the list and the DNS based delegation one.

Why not DNA-ify dialback?

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 19 Feb 2010 15:07:40 +0000

> Why not DNA-ify dialback?

Not sure what you mean. Is [1] dialback btw? If so,
that's addressing identity/reachability and not
delegation.

S.

[1] http://xmpp.org/extensions/xep-0220.html

---

From: Jesse Thompson <[email-masked]>
Date: Fri, 19 Feb 2010 09:16:45 -0600

On 2/19/2010 2:43 AM, Philipp Hancke wrote:
>> It's possible that the reason that so many of the certs are
>> self-signed is because of the impractical requirement that the cert
>> match the domain.
>

Assuming that you were getting one that matched the domain, then the 
advantage of xmpp.net-signed over self-signed is that clients wouldn't 
complain.

If the cert didn't match the domain, then I guess the only advantages 
over self-signed would depend on the client, since they all handle the 
certificate errors in different ways.  IIRC, some clients seemed to be 
more forgiving for self-signed, while others were more forgiving for 
mismatched-signed.

Jesse

---

From: Jesse Thompson <[email-masked]>
Date: Fri, 19 Feb 2010 09:23:48 -0600

> 3. TLS on s2s and c2s streams via something like _xmpp-delegate.

A pragmatist would argue that #3 is better.

Isn't there an out of band solution for mitigating DNS poisoning? 
Perhaps the client could query https://xmpp.net/ (and possibly other 
trusted 3rd parties as well) to find out what it thinks the value of 
_xmpp-delegate for the domain should be?  If there is consensus, then 
the client can be assured that there is no poisoning.

Jesse

---

From: "Richard L. Barnes" <[email-masked]>
Date: Fri, 19 Feb 2010 13:10:46 -0500

That sounds like a nice idea to facilitate discussion in Anaheim.  If  
it's any help, please feel free to rip off the comparison I did  
earlier between the "ACDNA" and "XDNA" (new option is "SRVDNA"?)
<http://www.ietf.org/mail-archive/web/xmpp/current/msg00342.html>

---

From: Jehan Pagès <[email-masked]>
Date: Sun, 21 Feb 2010 14:48:31 +0900

Hi,

On Fri, Feb 19, 2010 at 5:43 PM, Philipp Hancke <[email-masked]> wrote:
> Jesse Thompson wrote:
>> It's possible that the reason that so many of the certs are self-signed is
>> because of the impractical requirement that the cert match the domain.
>

No, the point is that it does not work as well at all. With a self
signed certificate, you have only the encryption part, not the
authentication part. It means that your communication with the server
is indeed hidden/secret (nobody, as far as the encryption code is not
broken of course, can read your plain communication with a
man-in-the-middle attack), but not that you are indeed communicating
with the server that it claims to be.

It is like: you speak with someone, and you are sure that nobody is
eavesdropping you, but maybe he is an "evil ennemy spy" who you are
giving all your plans and you cannot know this (you just know that he
"claimed" not to be, without any proof).

So for instance, in a XMPP server case, if I can spoof the DNS cache
used by one of your user, I can tell him my machine is your domain's
server, and then on my server I would have a self signed certificate
for your domain (you can write whatever you want on a self signed
cert). This is why it is not at all the same and a warning must be
displayed when a server displays only a self signed, just like they
currently do in modern web browsers (just imagine that my evil spy
tries and proves me who he is by showing me a self made passport
stamped by himself! This is the same. The CA signed cert is like an
official passport: it has been signed by higher autorities who checked
your identity before giving you your passport).

So I guess one of the reason if self-signed certs are common is also
because people did not understand what it was for/how it worked (but
cryptography is indeed a complicated topic).
Bye.

Jehan

P.S.: my laptop is nearly dead and crashes repeatedly. So I may not be
able to continue this discussion before a few days, but... I will be
back. :-)

---

From: Jesse Thompson <[email-masked]>
Date: Mon, 22 Feb 2010 14:08:46 -0600

On 2/20/2010 11:48 PM, Jehan Pagès wrote:
> Hi,
>
> On Fri, Feb 19, 2010 at 5:43 PM, Philipp Hancke<[email-masked]>  wrote:
>> Jesse Thompson wrote:
> [snip]

Well, StartCom pulled the old bait and switch anyway, so those "free" 
wildcard certificates now cost money and require extra verification 
steps which can be a burden if you are part of a large complex organization.

The fact is that XMPP client certificate errors are common (just look at 
Google Apps.)  In the interest of attracting users ,the xmpp clients 
have been developed in a way to make it easy for users to click through 
the certificate warnings.  This has caused xmpp service administrators 
to not bother obtaining signed matching certificates for every domain 
that they host.  Now that StartCom started making obtaining wildcard 
certificates more difficult, the occurrence of non-matching and 
self-signed certificates will be increasing.

Jesse

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 22 Feb 2010 21:34:36 -0500

Certificates are designed to be "out of band" attestations of things.   
So one way to realize your suggestion would be to have a system in  
which a generic domain certificate (which many domains already have)  
is used to attest that the key-pair used to sign a domain (with  
DNSSEC) actually belongs to the domain owner.  The process would run  
something like the following:

1. Originator (client or server) looks up server for example.com using  
_xmpp-server
3. Server authenticates TLS connection as hosting-provider.net
2. Originator challenges server to authenticate as example.com
3. Server presents a certificate (under a well-known CA) for example.com
4. Originator fetches _xmpp-delegate records for example.com with  
corresponding DNSSEC records
5. Originator verifies that
5.1. Certificate presented by server is valid for example.com
5.2. Public key in certificate matches public key in DNSKEY record for  
example.com
5.3. RRSIG record covering _xmpp-delegate SRV record is valid under  
the DNSKEY record
5.4. _xmpp-delegate points to hosting-provider.net

That way, the chain of trust goes something like:
CA --[cert]--> public-key(example.com) == DNSKEY(example.com) -- 
[RRSIG]--> _xmpp-delegate

And moreover, you have *no* need of DNSSEC outside the hosting  
customer's domain -- you're just using the record formats, not the  
overall architecture.

--Richard

On Feb 19, 2010, at 10:23 AM, Jesse Thompson wrote:

> _xmpp-delegate for the domain should be?  If there is consensus,  
> then the client can be assured that there is no poisoning.
>
> Jesse
>
> -- 
>  Jesse Thompson

---

From: Jehan Pagès <[email-masked]>
Date: Tue, 23 Feb 2010 18:33:26 +0900

Hi,

I try to answer, hoping my computer won't crash before I finish this
email. :-) (I will go to Tokyo this week-end probably and will look
for a new laptop)

2010/2/23 Jesse Thompson <[email-masked]>:
> wildcard certificates now cost money and require extra verification steps
> which can be a burden if you are part of a large complex organization.

But for non-wildcard certs, are they for free at Startcom? We could
say that if you don't wanna pay, then you get the burden of having to
"think" which sub-domains you really need for xmpp. Anyway if I am not
mistaken, I remember to have been told once that wildcard certs are
not such a good idea. I think this is some kind of security reason (if
any subdomain is possible, maybe some malevolent people may create
fake subdomains without you noticing immediately? Other reasons? At
least when you specify only what you need, you have more control on
what can be done under your name).

But anyway I do completely agree that a certificate system completely
free of commercial matters would be better. I know that when the
xmpp.net intermediate CA stopped its job, it has been said on the blog
something like «after all, W3C, etc. do not propose cert services». I
personnaly don't agree with this argument:

- First of all, I guess the main reason is that the web protocol has
not been primarily thought with security considerations. There is no
"MUST" for TLS in the http spec. But there is one in XMPP spec which
has been thought from the base like a secure protocol. As so, probably
some measures should be taken (like the xmpp.net CA which was a very
very good idea in my opinion).
- Second maybe if W3C (or other similar standards entity) were
proposing such CA service, the web would be a better place, safer at
least. So, the fact that the neighbour does not do something does not
mean it is better not to do it as well. :-)

But I guess that one of the main reasons was in fact that such a CA
organisation was a lot of work, and the XSF wanted to get rid of such
a burden if there are not enough benevolents to take care of this. :-/
And this argument, I understand very well indeed.

> Google Apps.)  In the interest of attracting users ,the xmpp clients have
> been developed in a way to make it easy for users to click through the
> certificate warnings.  This has caused xmpp service administrators to not
> bother obtaining signed matching certificates for every domain that they
> host.  Now that StartCom started making obtaining wildcard certificates more
> difficult, the occurrence of non-matching and self-signed certificates will
> be increasing.

As I already said, for me this is not at all a good way of thinking.
Of course there will be always most people that won't care. It does
not mean we must stop thinking about security, and worse short-cutting
security systems (like what is proposed with _xmpp-delegate in my
opinion) that worked until now.

And I want to make something clear about my opinion. I am NOT telling
that every must (and will in some perfect future) be secure. Though it
would be good and ideal of course, It will probably never be the case
for many reasons (the burden of taking care of certs among other
things, but also if someday you forget to renew immediately your old
cert, what? Will you be banned from the network? Of course not, simply
a warning to users and you fix fast your cert... Etc. Or simply you
may have a small family server and don't really care much about
security. I just hope that important services will care. They should
at least). What I am telling is only:
    «If a server is secure, show it. If it is not, show it.»
But do not show a server as secure if it is not, and do not shortcut
security! This is all!

I think the XMPP clients could take ideas from the web browser which
recently understood how important it is to show if you are secure
(showing lock icons which you can click to know certificate details,
changing colors on address bar depending on security level, showing
warnings in case of semi-security (self-signed or signed by unknown CA
certs), etc. Of course most people don't care and click "OK". Too bad
for them the day when they connect to their bank website (which is not
this day) and they don't read the warning. This does not mean we must
stop caring for those who read.

So _xmpp-delegate -- as proposed for now! -- is bad because it
proposes to tell that a server is secure in a case where there is a
big leak on the server identity (and most clients nowaydays are bad
because they simply don't care about security, and don't tell
anything; hence you don't know if you are connected in a secure way or
not).

If you really want to use _xmpp-delegate, this is easy to fix:
1/ If you are connecting to a server not using TLS (whether it uses
_xmpp-delegate or not), anyway nothing changes for you, you are not
secure.
2/ If your connection is using TLS with a self-signed cert,
_xmpp-delegate does not bring any more leak anyway (there is already a
problem on the identity of the server which cannot be trusted anyway.
You just have encryption with... "someone").
3/ If you are using TLS signed by a trusted CA without_xmpp-delegate,
it is ok. Connection perfectly secure (because here even if DNS can
still not be trusted, in the end you connected to a server which
showed a trustable cert for the domain you wanted. So unless someone
stole the private key of a certificate, you know you connected to the
right service).
4/ If your connection is using TLS, signed or not by a trusted CA,
with _xmpp-delegate and without DNSSEC. Then you are in the same case
as 2/: the identity cannot be trusted (note then than without being
able to trust the DNS, _xmpp-delegate completely removes the interest
of a trusted CA. A cert signed is here exactly the same thing as a
self-signed CA as for security.)
5/ Your connection uses TLS, signed by a trusted CA, with
_xmpp-delegate and with DNSSEC. This case is the one I am not sure. It
entirely depends on DNSSEC (cf. the mail from Peter where he forwarded
an email from IETF people). If really DNSSEC can be perfectly trusted,
then we are like in case 3/. The connection can be considered secure.
If not, maybe this is some intermediate level of security (good but
not perfect).

As for me then, this _xmpp-delegate proposition will be acceptable
only when the point 5/ will have been perfectly clarified (how
trustable and secure is DNSSEC?) and after this, these different level
of security must be written and made clear in the spec, in the
security section so that the clients (the good ones which will take
care of security) will be able to show the appropriate
warnings/colors/icons-flags/whatever (this can even be subtle, as long
as it is here and that it protects the users in problematic/strange
cases, for those who cares).
Bye.

Jehan
- If you are using

---

From: Jehan Pagès <[email-masked]>
Date: Tue, 23 Feb 2010 19:15:29 +0900

Hi,

On Tue, Feb 23, 2010 at 11:34 AM, Richard L. Barnes <[email-masked]> wrote:
> And moreover, you have *no* need of DNSSEC outside the hosting customer's
> domain -- you're just using the record formats, not the overall
> architecture.
>

If the delegate server has a valid certificate for the service domain
(here hosting-provider.net has a cert for example.com), there is no
need for the _xmpp-delegate either. You are just in the current use of
case. Or maybe I did not understand your flow.

_xmp-delegate is when the actual service provider does not have the
certificate for the service's domain, so it will provide a certificate
for it's own domain, which normally will trigger a security warning,
hence the use of _xmpp-delegate to say "no it's ok, this third-party
domain is our actual provider".
This can be for several reasons like security (you don't want to give
a certificate for your domain to a service provider because you don't
trust it enough) or simplicity (you took a provider not to having to
care about hosting a server, nor having to care about the
certificates), etc.
I don't see other use of _xmpp-delegate for now. But if the service
provider has a valid cert for your domain, then you don't need this
records.
Bye.

Jehan

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Feb 2010 11:15:50 +0000

Richard L. Barnes wrote:
> So one way to realize your suggestion would be to have a system in which
> a generic domain certificate (which many domains already have) is used
> to attest that the key-pair used to sign a domain (with DNSSEC) actually
> belongs to the domain owner.  The process would run something like the
> following:
> 
> 5.3. RRSIG record covering _xmpp-delegate SRV record is valid under the
> DNSKEY record
> CA --[cert]--> public-key(example.com) == DNSKEY(example.com)
> --[RRSIG]--> _xmpp-delegate
> 

So I wonder if that'd conform to DNSSEC really, since RFC4034 says:

  "The DNSKEY RR is not intended as a record for storing arbitrary
   public keys and MUST NOT be used to store certificates or public keys
   that do not directly relate to the DNS infrastructure."

Would (ab)using DNSSEC like that be wise?

S.

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 23 Feb 2010 13:22:53 +0100

> Would (ab)using DNSSEC like that be wise?

No.  Check out RFC 4398, it is intended for storing X.509 certificates
(or fingerprints) in the DNS.  Those records can be protected with
DNSSEC too.

/Simon

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 23 Feb 2010 07:27:49 -0500

I don't think it's abusive of DNSSEC.  The DNSKEY and RRSIG records  
that would be in the DNS would still be used to verify DNS records,  
just as if they were part of a global DNSSEC hierarchy.  We're just  
changing how clients establish some DNSKEY record as a TA.

This idea is a lot like the DNSSEC "trust anchor repositories" (TARs)  
that are out there right now (ISC DLV [1]), but using a CA as an  
mediator instead of a database.  Why not just use a TAR?  Mainly  
because certs are signed objects, so that you can do things like pass  
them in XMPP instead of having to fetch them from the DLV directly  
(relying on channel security).

--Richard

[1] <http://www.isc.org/solutions/dlv>

On Feb 23, 2010, at 6:15 AM, Stephen Farrell wrote:

>> which

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 23 Feb 2010 07:33:17 -0500

Hi Jehan,

> case. Or maybe I did not understand your flow.

Ah, yes, I was slightly unclear: The delegate server has a certificate  
for the service domain -- but *not* the private key for the  
certificate, so it can't use that cert to authenticate.  Just like  
your browser has certs for the CAs it trusts, but can't use them to  
authenticate as, say, GoDaddy.

Instead, the hosting server presents the cert as a way of showing that  
the CA has asserted a binding between the service domain (example.com)  
and a given public key pair, so that the client can use that key pair  
to verify DNSSEC records under the service domain.

You are correct that if the delegate server has the *private* *key*  
for a cert with the service domain's name in it, then there would be  
no problem here.  But the difficulty of managing such certs is the  
reason we're talking about this :)

--Richard

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 23 Feb 2010 07:39:15 -0500

Thanks, I wasn't aware of that, Simon.  So you could actually delete  
the XMPP challenge/response part of the flow I presented and just have  
the client pull CERT records for the domain in question (example.com)  
to get a certificate for the domain.  This is kind of nice in that it  
doesn't require any change to XMPP.

All this document would need to do then is add a requirement that the  
public key in the CERT record match the public key in the NSKEY record  
used to verify the RRSIG on the _xmpp-delegate.  (And explain the  
overall process.

Revised flow:

1. Originator (client or server) looks up server for example.com using  
_xmpp-server
2. Server authenticates TLS connection as hosting-provider.net
3. Originator fetches CERT record for example.com
4. Originator fetches _xmpp-delegate records for example.com with  
corresponding DNSSEC records
5. Originator verifies that
5.1. Certificate from CERT record is valid for example.com
5.2. Public key in certificate matches public key in DNSKEY record for  
example.com
5.3. RRSIG record covering _xmpp-delegate SRV record is valid under  
the DNSKEY record
5.4. _xmpp-delegate points to hosting-provider.net

--Richard

---

From: Jesse Thompson <[email-masked]>
Date: Tue, 23 Feb 2010 09:33:20 -0600

On 2/23/2010 3:33 AM, Jehan Pagès wrote:
> organization was a lot of work, and the XSF wanted to get rid of such

If XFS's reasoning is what you say, consider the implications of their 
decision to drop out of the CA role.

If XMPP requires matching certificates for every domain (and every 
component of each domain) it puts the individual XMPP hosting providers 
in the position of doing all of this same undesirable CA work in order 
to keep customer certificates up to date.  They have to provide forms 
(with secure authentication) for allowing customers to upload/update 
certificates and keys.  They have to build processes to automatically 
install certificates and keys into the XMPP server configuration.  They 
have to send out reminder notices of certificates that are about to 
expire.  Basically, they have to do everything that a CA is responsible 
for, minus the key generation part.

If the XSF thought it was too much work, imagine how each individual 
XMPP hosting provider feels.

> security. I just hope that important services will care.

It's not that they don't care.  It's that there is no reasonable 
alternative.

> What I am telling is only:

This is exactly what the current system provides.  Of our most popular 
clients on campus (Psi, Pidgin and Adium) they all warn the user that 
our certificate doesn't match the domain, and they let the users 
permanently choose to accept the certificate as valid for the domain. 
If the certificate matches the domain, then the clients don't inform the 
user of any problems.

Jesse

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 23 Feb 2010 10:46:50 -0500

> If XFS's reasoning is what you say, consider the implications of  
> their decision to drop out of the CA role.
>
> component of each domain) it puts the individual XMPP hosting  
> providers in the position of doing all of this same undesirable CA  
> work in order to keep customer certificates up to date.  They have  
> to provide forms (with secure authentication) for allowing customers  
> to upload/update certificates and keys.  They have to build  
> processes to automatically install certificates and keys into the  
> XMPP server configuration.  They have to send out reminder notices  
> of certificates that are about to expire.  Basically, they have to  
> do everything that a CA is responsible for, minus the key generation  
> part.
>

This reasoning is correct, but not really germane to the current  
discussion.  You're describing an aspect of the problem, not any of  
the proposed solutions.  None of the three proposed solutions (ACDNA,  
XDNA, SRVDNA) require the hosting provider to act as a CA, and in fact  
the overall cryptographic burden they impose is pretty light:

ACDNA: Hosting customer has a web/domain and uses it to sign a single  
attribute cert (hosting provider just relays it)
XDNA: Hosting customer has a web/domain cert (hosting provider just  
provides an HTTPS URI)
SRVDNA: Hosting customer has a web/domain cert (hosting provider just  
refers to it)

In all of these cases, the CA role is still played by a traditional  
CA.  In the worst case, DNA will require hosting *customers* to act as  
Attribute Authorities -- hosting providers never have to do any crypto  
(which makes sense, since they don't have authority to assert  
delegations).

In addition to all of that, the notion of XMPP "requiring matching  
certificates" is a red herring.  As with all PKI functions, the set of  
trust anchors that a client chooses to use is entirely a matter of  
local policy.  This idea is pretty universally reflected in Internet  
standards.  For example, the HTTPS spec (RFC 2818) says that "If the  
client has external information as to the expected identity of the  
server, the hostname check MAY be omitted."

--Richard

---

From: Jesse Thompson <[email-masked]>
Date: Tue, 23 Feb 2010 09:47:27 -0600

> provider has a valid cert for your domain, then you don't need this

I wouldn't dare give a valid cert/key to Google for wisc.edu (if we were 
delegating to Google Apps.)  I don't expect our campus domains to give 
certs/keys for their domains to us either.

Jesse

---

From: Kevin Smith <[email-masked]>
Date: Tue, 23 Feb 2010 15:57:46 +0000

On Tue, Feb 23, 2010 at 3:46 PM, Richard L. Barnes <[email-masked]> wrote:
> certificates" is a red herring.  As with all PKI functions, the set of trust
> anchors that a client chooses to use is entirely a matter of local policy.

This is true to an extent, but XMPP does further muddy this with
server to server connections, where everything needs to work
transparently. It's not entirely clear to me how much this complicates
matters, though.

/K

---

From: Kevin Smith <[email-masked]>
Date: Tue, 23 Feb 2010 16:06:59 +0000

> The approach we discussed would be to define a new SRV record
> for an XMPP delegate:

I got wondering earlier - how much does this buy us over just storing
As in the SRV, and checking those?

I don't think there's anything inherently more secure about

_xmpp-delegate._tcp.example.com google.com
_xmpp-server._tcp.google.com
(check cert matches google.com - SUCCESS)

than

_xmpp-delegate._tcp.example.com talk.google.com
(check cert matches example.com - FAIL)
(check cert matches talk.google.com - SUCCESS).

It's not entirely clear to me that, if we go with the "Oh,
everything'll be alright once we've got DNSSEC involved" approach of
_xmpp-delegate, that it can't be alright already with _xmpp-server.

Or I'm having a brainfart.

/K

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 23 Feb 2010 11:15:42 -0500

I think you're mostly on track.  But you would need to change the  
validation algorithm and add DNSSEC: Currently, name matching is done  
on the *input* to the discovery process (example.com), which means  
that you don't need to authenticate the DNS records.  It seems like it  
would work to update the XMPP authentication process so that the  
authentication succeeds if either
(1) The authenticated identity matches the input domain (example.com),  
or
(2) The _xmpp-server record is DNSSEC-protected and the authenticated  
identity matches the output domain (google.com).

In this case as well as the _xmpp-delegate case, it seems like it  
would still be useful to specify a way to bootstrap DNSSEC keys,  
either through certs in XMPP or through CERT records.

--Richard

---

From: Justin Karneges <[email-masked]>
Date: Tue, 23 Feb 2010 12:59:08 -0800

> certs/keys for their domains to us either.

This is how hosting services work though.  I upload a private key to my 
hosting provider so that it can serve HTTPS.

If people don't want to upload private keys to XMPP hosting providers because 
they trust the XMPP service less than the HTTPS service (say because they 
handle HTTPS in-house but use a third-party XMPP provider), then one simple 
solution is to have protocol-specific certificates.

Delegation is revolutionary and world-changing concept (for all of the 
Internet, not just XMPP), but I don't know if that's really required to solve 
the core issue here...

-Justin

---

From: Kevin Smith <[email-masked]>
Date: Tue, 23 Feb 2010 21:04:00 +0000

> Internet, not just XMPP), but I don't know if that's really required to solve

There are two issues with delegation, though - there's the
authentication aspect, and the s2s connection issue - the latter we
just don't have with HTTPS.

/K

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 23 Feb 2010 14:15:31 -0700

On 2/23/10 1:59 PM, Justin Karneges wrote:
> This is how hosting services work though.  

Not all of them. The operational issues are such that an organization
like the University of Wisconsin won't hand over its private keys to a
hosting service.

> solution is to have protocol-specific certificates.

That's possible today using the SRVName extension defined in RFC 4985.

> Internet, not just XMPP), but I don't know if that's really required to solve 

Given the significant deployment of XMPP at hosted services, I think we
need to find a solution to the problem at hand. I'm still not sure what
the solution is (DNA, delegation, or something else), but IMHO we need a
solution.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Dave Cridland <[email-masked]>
Date: Tue, 23 Feb 2010 21:17:59 +0000

> Internet, not just XMPP), but I don't know if that's really  

I don't think delegation *is* a world changing concept. The  
difference here is that we're trying to build a security model that  
encapsulates that delegation instead of pretending it doesn't exist.

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Tue, 23 Feb 2010 21:18:30 +0000

On Tue Feb 23 15:46:50 2010, Richard L. Barnes wrote:
>  CA.  In the worst case, DNA will require hosting *customers* to  
> act as  Attribute Authorities -- hosting providers never have to do  
> any crypto  (which makes sense, since they don't have authority to  
> assert  delegations).

Right.

In fact what you've described as XDNA is much the same - the hosting  
customer is operating an AA which signs its delegations implicitly  
via TLS instead of explicitly - the problem is that the hosting  
customer has to hand over their certificate (and control of their  
XMPP service) to yet another third party, so I'm less than convinced  
about that option.

One could easily enough propose a different format to an AC, such as  
an XML format, and do roughly the same thing but in a way that sounds  
more palatable, if that's the perceived stumbling block.

Dave.

---

From: Jesse Thompson <[email-masked]>
Date: Tue, 23 Feb 2010 15:56:07 -0600

Right.

Outsourcing http[s] is more flexible than outsourcing XMPP.  With HTTP 
you don't have to give the key, and for HTTPS you don't have to give 
away the key for your primary domain.  You can outsource a single sub 
domain, and you don't have to use https unless you're doing something 
that requires it.  You don't even need to use your own domain for many 
purposes.  For authentication, SSO systems like SAML negate the need for 
the 3rd parties to be handling credentials at all.  For http content, 
it's easy to link to other domains that provide https content, etc...

For XMPP, you have to use your primary domain (if you care about vanity 
for your JIDs) and you have to use TLS (if you care about securing the 
session.)

> That's possible today using the SRVName extension defined in RFC 4985.

This sounds interesting (especially for sidestepping the wildcard 
certificate security concern.)  How would someone obtain a certificate 
that can only be used for XMPP?

> the solution is (DNA, delegation, or something else), but IMHO we need a

Yes, and I apologize for causing the conversation to go off on tangents.

I don't know what the answer is.  I keep coming back to the line 
thinking that we should use DNS for delegation (xmpp-delegate or 
xmpp-server/client) and rely on an out-of-band DNS verification 
procedure over HTTPS://trusted3rdparty/ that would serve the role of 
warning users about DNS poisoning until DNSSEC is available.  Given the 
lack of response when I initially pitched it, I presume that this is a 
bad solution.

Jesse

---

From: Jesse Thompson <[email-masked]>
Date: Tue, 23 Feb 2010 16:02:02 -0600

On 2/23/2010 3:18 PM, Dave Cridland wrote:
> customer is operating an AA which signs its delegations implicitly via
> TLS instead of explicitly - the problem is that the hosting customer has
> to hand over their certificate (and control of their XMPP service) to
> yet another third party, so I'm less than convinced about that option.
>
> One could easily enough propose a different format to an AC, such as an
> XML format, and do roughly the same thing but in a way that sounds more
> palatable, if that's the perceived stumbling block.

Perhaps the problem with DNA is that it is hard to understand.  I'm not 
sure if I could explain it to our customers (i.e. how would they create 
an AC and provide it to the hosting provider.)  It might help if the 
implementation procedure was mocked up on layman's terms.

Jesse

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 23 Feb 2010 21:36:00 -0700

> is not in the example.com domain?

Here is a real-life example:

$ dig +short -t SRV _xmpp-server._tcp.gmail.com
20 0 5269 xmpp-server3.l.google.com.
20 0 5269 xmpp-server4.l.google.com.
5 0 5269 xmpp-server.l.google.com.
20 0 5269 xmpp-server1.l.google.com.
20 0 5269 xmpp-server2.l.google.com.

Well, gmail.com is not in the google.com domain, is it? We "all know"
that the Gmail service is offered by Google, but gmail.com is not in the
google.com domain. So in a sense even Google Talk is delegated to
google.com!

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 23 Feb 2010 21:37:49 -0700

> the client can be assured that there is no poisoning.

I like that idea, but how is the client going to query xmpp.net (or,
better, a number of services it trusts) if it's not connected to the
XMPP network? Will it do that over HTTP?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 23 Feb 2010 21:48:34 -0700

> that can only be used for XMPP?

Ask your favorite CA. :)

> lack of response when I initially pitched it, I presume that this is a

The problem with a single trusted third party is that it becomes a
single point of failure. We could have multiple third-party vouching
services, but then the client needs a way to find them, weight them, etc.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 23 Feb 2010 22:08:05 -0700

> _xmpp-delegate, that it can't be alright already with _xmpp-server.

I still think we need two things:

1. A pointer from what Richard called the input domain to the machine
you'll connect to. This is currently provided by _xmpp-server, whereby
input.tld points to a machine that you resolve via a standard A/AAAA
lookup to an IP address.

2. An association between the input domain and what Richard called the
output domain, as proposed by _xmpp-delegate. Another approach would be
some kind of two-step whereby _xmpp-server._tcp.input.tld points you to
s2s-foo.hosting.tld and you do another _xmpp-server lookup to find out
that s2s-foo.hosting.tld should be presenting a certificate for
hosting.tld. But existing XMPP originators don't expect to do that kind
of _xmpp-server two-step, which is why I think it's better to define a
separate SRV record for that.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 23 Feb 2010 22:11:14 -0700

On 2/23/10 9:15 AM, Richard L. Barnes wrote:
> validation algorithm and add DNSSEC: Currently, name matching is done on
> the *input* to the discovery process (example.com), which means that you
> don't need to authenticate the DNS records.  It seems like it would work
> to update the XMPP authentication process so that the authentication
> succeeds if either
> (1) The authenticated identity matches the input domain (example.com), or
> In this case as well as the _xmpp-delegate case, it seems like it would
> still be useful to specify a way to bootstrap DNSSEC keys, either
> through certs in XMPP or through CERT records.

It does seem that this approach has some promise. Perhaps before the I-D
deadline we can spec it out in a little more detail, with appropriate
references to the DNSSEC specs (which I am sure are unfamiliar to most
XMPP folks up in the application layer).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Jehan Pagès <[email-masked]>
Date: Wed, 24 Feb 2010 20:07:38 +0900

Hi,

>> that can only be used for XMPP?

So you can ask the CA an XMPP specific cert, so that the service
provider cannot use this cert for anything else (like http, or
whatever else)? In this case, where is the problem and why bother with
this _xmpp-delegate which looks, as far as I see, a lot of added
complication for the client dev (all the additional steps in case the
cert does not match the queried domain) and (in its current state)
adding security leak to the protocol?

I mean if you DO delegate your XMPP service, then it is completely
normal for them to have your cert (as far as it is a specific cert for
the service). It is meaningful: you indeed trust this provider for the
XMPP service.

As for the proposed idea of querying each time some trusted services
(one, xmpp.net for instance, or several as proposed) is not a good
solution, in my opinion. A solution "in-band", in the protocol would
be better. What if the server is out of the network (intranet)? They
could still have security issues, even in an intranet.

And also the idea to add again a new level of "trust" system, because
we broke the previous trusted system, seems absurd to me: we already
have one trust mechanism (the Certificate Authority mechanism), then
we would have an additional trust mechanism (through xmpp.net, or
others), out-of-band this one and to be queried at each new connection
to a delegate service (which won't be so uncommon), in order to ask if
we can trust the first "trust" mechanism (because we did not respect
its way of working, hence we made the original trust system
untrustable anymore). Am I the only one to think that this is
ironical?
Bye.

Jehan

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 24 Feb 2010 08:10:51 -0700

On 2/24/10 4:07 AM, Jehan Pagès wrote:
> this _xmpp-delegate 

Because you still need to give your private key to the hosting provider.
What you get from the CA (if it supports SRVName extensions, which few
if any do right now) is a normal public key certificate, but limited to
XMPP usage (or whatever SRVName you put in there -- see RFC 4985).

> which looks, as far as I see, a lot of added

We have plenty of feedback from organizations that they don't want to
entrust their private keys to hosting providers (for security reasons)
and that hosting providers don't want to have those private keys either
(for liability reasons).

> could still have security issues, even in an intranet.

Agreed.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Joe Hildebrand <[email-masked]>
Date: Wed, 24 Feb 2010 08:14:08 -0700

> (or fingerprints) in the DNS.  Those records can be protected with

The idea of using "esoteric" DNS records, although interesting, seems
fraught with deployment challenges in the real world.  Frankly, getting an
SRV record in place has often been difficult, and that's just plain text.

-- 
Joe Hildebrand
(as individual contributor)

---

From: Jesse Thompson <[email-masked]>
Date: Wed, 24 Feb 2010 10:02:58 -0600

> XMPP network? Will it do that over HTTP?

HTTPS

Jesse

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 24 Feb 2010 09:27:35 -0700

>> XMPP network? Will it do that over HTTP?

Secure HTTP on port 443, sure. But that means opening another port. In
any case I don't think that approach is the solution...

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 24 Feb 2010 09:53:08 -0700

> SRV record in place has often been difficult, and that's just plain text.

Aw, c'mon, XMPP is always pushing the envelope! ;-)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 24 Feb 2010 13:29:22 -0500

Incorporating your option (2), it sounds like we have three name- 
matching cases here:
1. Matching against input domain name (current XMPP)
2. Matching against output of _xmpp-server
3. Matching against output of _xmpp-delegate -> _xmpp-server

The advantage of (3) over (2) is that it allows the hosting customer  
to generically point to the hosting provider's domain, and let the  
hosting provider use its own _xmpp-server records to do things like  
load balancing.

Obviously, the third case can be used to re-create the second case, at  
the expense of an additional DNSSEC verification (on the XMPP-delegate  
record).  So if we want to accommodate case (3), then I would be  
inclined to omit case (2).

--Richard

---

From: Jehan Pagès <[email-masked]>
Date: Thu, 25 Feb 2010 04:03:10 +0900

Hi,

> XMPP usage (or whatever SRVName you put in there -- see RFC 4985).

Ok I read this rfc.
So yes you give a private key, but "in theory" there is no problem
because you give a private key dedicated to them, for this specific
service (RFC4985 here) on this specific domain. Thus the certificate
which will have been signed will limit this key to the XMPP server. Of
course don't make the mistake to give them a certificate including a
public key, along with the corresponding private key, that you use
elsewhere (in fact you can even simply propose the service provider to
provide you their own public key as well -- no need of the private key
-- that they will use. There is no exchange of private key here).

But I see the issue here, which is why I said "in theory": they can
use the certificate somewhere else (a non XMPP service with your
hostname) hoping that the clients won't be RFC-4985 compliant, hence
won't check the SRVName part of the cert. For instance use this cert
on a web server and it will go unseen as long as the users' browsers
do not check the service in the certs (is RFC4985 implemented right
now in browsers anyway?).

So I guess this is not the perfect solution in the current state of
the internet. Moreover from the description, it does not look as this
RFC was made for such a use case (though you can try and derive the
original use cases).

> and that hosting providers don't want to have those private keys either

I understand these points. But someone sooner on this thread also
noted that organizations already provides private keys for delegating
web servers (hence web hosting providers already accept them). If so,
why is this different for them for the XMPP server? Is it ok to leak
security to the web providers, but not to the XMPP ones (are we known
bad guys? :p)?
This was simply a random thought... I noticed that sometimes security
considerations in many organizations are... pretty random as well in
fact. Or messy.

Bye.

Jehan

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 24 Feb 2010 17:21:36 -0700

On 2/24/10 11:29 AM, Richard L. Barnes wrote:
> Incorporating your option (2), it sounds like we have three
> name-matching cases here:
> The advantage of (3) over (2) is that it allows the hosting customer to
> generically point to the hosting provider's domain, and let the hosting
> provider use its own _xmpp-server records to do things like load balancing.
> 

I would, too.

It seems that in practice SRV records are used for two purposes:

1. "Internal" reasons related to deployment (I point an input domain
under my control at a particular machine or set of machines under my
control).

2. "External" reasons related to delegation (I point an input domain
under my control at a hosting provider whose machines are not under my
control).

IMHO this causes confusion, and I think it would be good to disambiguate
them, at least for XMPP.

(Perhaps the SRV delegation idea can be explored more widely, but since
SRV records are not yet widely used for technologies like HTTP I think
that we're running into this issue first in the XMPP community. Ah, the
perils of early adoption...)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 25 Feb 2010 16:22:56 -0800

DNSSEC support is already required by the U.S. and other governments as a
condition of purchase, so that from an implementation point of view, it is
quite real.  On the other hand, attribute certificates are not widely
supported, and the prospects for widespread implementation are not so
great.

Bernard "In the land of the blind, the one eyed man is king" Aboba

On Tue, Feb 16, 2010 at 10:32 AM, Jonathan Schleifer
<[email-masked]>wrote:

> I think doing so before DNSSEC is a MUST is a very bad idea. Until then, it
> will make all certificate validation pretty useless. This is something that
> might be an idea in 5 or 10 years.
>
> --
> Jonathan
>