On 9/22/05, Tijl Houtbeckers [EMAIL PROTECTED] wrote:
On Thu, 22 Sep 2005 22:53:20 +0200, JD Conley [EMAIL PROTECTED]
wrote:
This is bad engineering i.t.o. creating undesirable impact on the
broader
Internet.
What is the undesirable impact? .
It is, at least, a minor security
On Sat, 24 Sep 2005 17:59:00 +0200, Peter Millard [EMAIL PROTECTED]
wrote:
On 9/22/05, Tijl Houtbeckers [EMAIL PROTECTED] wrote:
On Thu, 22 Sep 2005 22:53:20 +0200, JD Conley [EMAIL PROTECTED]
wrote:
This is bad engineering i.t.o. creating undesirable impact on the
broader
Internet.
Not really, if you use the example of SMTP you cant run two
entirely different email services on the same domain.
Just because a lot of server developers think of MUC and standard c2s as
two different components doesn't mean that users do. In fact, it's
exactly the opposite. Here's an
On 9/24/05, Richard Dobson [EMAIL PROTECTED] wrote:
Just because a lot of server developers think of MUC and standard c2s as
two different components doesn't mean that users do. In fact, it's
Sorry but that is a bit of an erroneous comparison, in the cases where orgs
snip
I think the point
The major problem with this sort of second-guessing DNS isn't even the
security problems it possesses (by assuming that DNS nesting MUST
imply some sort of trust relationship of services running under those
names).
It is that servers which implement the XMPP standard and which don't
add this DNS
On 24 Sep 2005, at 22:35, Hal Rottenberg wrote:
If you want to run a MUC service on its own domain then you have
to setup
the DNS entries, if you dont want to have to setup those entries
then follow
So, let's say you have the choice between two IM systems. One you
can
double click an
Hey all,
We take security issues very seriously and appreciate the feedback.
However, some of the reactions in this thread are simply unreasonable.
Why do so many JSF discussions wax into flame wars? :)
So, I'd like to take a step back and try to step through the issues.
First, unless there's an
Kevin,
Let's please quickly agree that it's something to address,
and that second-guessing dns entries isn't the way to do it.
I disagree that our algorithm is a serious security issue (see my last
email), but would still love to get rid of it. It's a hack that's only
there because there's
On 9/24/05, Matt Tucker [EMAIL PROTECTED] wrote:
However, some of the reactions in this thread are simply unreasonable.
Why do so many JSF discussions wax into flame wars? :)
I firmly believe in flame wars. I think that this is one of the more
productive discussions since The Great Encryption
On Sun, 25 Sep 2005 00:33:11 +0200, Matt Tucker [EMAIL PROTECTED]
wrote:
Assume your server is down so some Jive Messenger instance tries to make
the connection to dyndns.org. If an evil XMPP server truly lives at that
address, how could you possibly trust that your dynamic DNS entry is
also
On 9/25/05, Matt Tucker [EMAIL PROTECTED] wrote:
Hey all,
We take security issues very seriously and appreciate the feedback.
However, some of the reactions in this thread are simply unreasonable.
Why do so many JSF discussions wax into flame wars? :)
So, I'd like to take a step back and
On 24 Sep 2005, at 23:47, Matt Tucker wrote:
Let's please quickly agree that it's something to address,
and that second-guessing dns entries isn't the way to do it.
I disagree that our algorithm is a serious security issue (see my last
email), but would still love to get rid of it. It's a hack
On 25 Sep 2005, at 00:14, Johannes Fröhlich wrote:
My suggestion would be to list services like server.net/service.
This would be a
resource for the server. A muc-room would be server.net/muc/room and
a user using
this mucroom would have the jid [EMAIL PROTECTED]/muc/room or
just [EMAIL
Well, lets start with the two things that occur to me.
1) #-prefixes for room names, like IRC. Remember that this isn't a
retrospective change, we're not asking for people who currently have
multiple DNS entries to give them up, we're providing a method for new
servers to be set up.
2)
On Sun, 25 Sep 2005 01:14:45 +0200, Kevin Smith [EMAIL PROTECTED]
wrote:
Well, lets start with the two things that occur to me.
1) #-prefixes for room names, like IRC. Remember that this isn't a
retrospective change, we're not asking for people who currently have
multiple DNS entries to
Tjil,
I did that in my first reply, the other problem I pointed out
was in my last reply; Instead of having to steal the DNS
record you can steal one that's hardly used or doesn't even
exist. This gives attacks a lot more stealth.
Are you playing devil's advocate or are you serious? If I
On 9/24/05, Matt Tucker [EMAIL PROTECTED] wrote:
It's a bummer that JID's weren't constructed to deal with this
sub-domain issue from the beginning. For example, they could have been
in the form:
node/[EMAIL PROTECTED]
This would work great since / is already a prohibited character in
David,
Yep, I'm in agreement with all of your points. We thought long and hard
about how to come up with a reasonable workaround for the name collision
issue and couldn't. That's how we arrived at the parent DNS algorithm
workaround.
Regards,
Matt
-Original Message-
From: [EMAIL
On 9/24/05, Matt Tucker [EMAIL PROTECTED] wrote:
Tjil,
snip
While requiring a signed certificate is a step up, it is only
a small step it. It are still unknown servers you are talking
to, thus unknown certificates.
That's the point of a CA. If a CA signs a cert, that means you should
On Sun, 25 Sep 2005 01:58:35 +0200, Matt Tucker [EMAIL PROTECTED]
wrote:
Tjil,
I did that in my first reply, the other problem I pointed out
was in my last reply; Instead of having to steal the DNS
record you can steal one that's hardly used or doesn't even
exist. This gives attacks a lot
On Sun, 25 Sep 2005 02:55:09 +0200, David Waite [EMAIL PROTECTED] wrote:
On 9/24/05, Matt Tucker [EMAIL PROTECTED] wrote:
Tjil,
snip
While requiring a signed certificate is a step up, it is only
a small step it. It are still unknown servers you are talking
to, thus unknown certificates.
Are you playing devil's advocate or are you serious? If I had to guess,
I'd say that 99.9% of public XMPP servers are deployed at [domain].com
or [sub].[domain].com. They're not deployed at
[sub].[sub].[sub].[domain].com. This means that there are generally
never unused or hardly used
On Sun, 25 Sep 2005 03:36:09 +0200, Perry Lorier [EMAIL PROTECTED] wrote:
Are you playing devil's advocate or are you serious? If I had to guess,
I'd say that 99.9% of public XMPP servers are deployed at [domain].com
or [sub].[domain].com. They're not deployed at
Tijl Houtbeckers wrote:
On Sun, 25 Sep 2005 03:36:09 +0200, Perry Lorier [EMAIL PROTECTED] wrote:
Are you playing devil's advocate or are you serious? If I had to guess,
I'd say that 99.9% of public XMPP servers are deployed at [domain].com
or [sub].[domain].com. They're not deployed at
On Sun, 25 Sep 2005 03:53:29 +0200, Perry Lorier [EMAIL PROTECTED] wrote:
Tijl Houtbeckers wrote:
On Sun, 25 Sep 2005 03:36:09 +0200, Perry Lorier [EMAIL PROTECTED]
wrote:
Are you playing devil's advocate or are you serious? If I had to
guess,
I'd say that 99.9% of public XMPP servers
We run our conference server on
conference.jabber.meta.net.nz. This is a
sub.sub.sub.domain.nz, and is probably very common for
companies using jabber outside the US where their domain is
in a CC TLD.
Thanks, that's a good point. The algorithm should be refined to account
for
26 matches
Mail list logo
