[JDEV] Server 1.2 Setup questions

[Lazarus Long]

On Mon, Nov 13, 2000 at 08:06:19PM -0500, David Waite wrote:
 > Delivered-To: lazarus at overdue.ompages.com
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   (Remember this, I did get it, that's relevant below.)
 > From: David Waite <mass at ufl.edu>
  
 > Lazarus Long wrote:
 > > On Mon, Nov 13, 2000 at 02:44:27PM -0500, Keith Minkler wrote:
 > >  > > the message arrives. However, it does not work for anyone on jabber.org.
 > >  > > Any reason why?
 > >  > dialback.  The jabber.com server is using the 1.0 server, jabber.org
 > >  > is using 1.2, if jabber.org cannot verify that your jabber server name
 > >  > matches the IP address for that name in DNS, it will not accept any of
 > >  > your messages.
 > > Eww.  Evil.  Does this happen to anyone wanting to run a 1.2 server?
 > > Are we stuck using 1.0 servers because of this?
 > You can happily run a server assuming DNS works. If DNS is invalid, it 
 > will not work. Why are you doing server-server communication if your 
 > host can't be resolved? How are replies expected to come in?

(See above.)

 > This is actually very good. Before people were very easily able to 
 > spoof, and could also easily send massive amounts of spam from an 
 > invalid address. Soon (not now, as 1.0 still exists and is for the time 
 > being supported), this won't work.
[snip] 
 > >  > need the JUD code from Ryan Eatmon, and a working mySQL database.
 > > I thought that wasn't going to be available for some time now.  I agree
 > > that many of us will not want to make all of our info available on the
 > > public Internet this way.
 > > Once again, privacy seems to be being attacked with changing versions.
 > Clarify that last statement, please.

Okay, go back in the jabber-security archives, early.  There was an
extended discussion about privacy matters, trust, and how far presence
information could be protected.  I'll try to sum up some key points of
that discussion, but you would do better to read the original, in which
it was stated much more clearly than I anticipate doing now.

Consider for a moment, a conversation between two end-users, Andy
and Betty.  For the benefit of discussion, Andy is a stalking victim,
and wishes to hide his presence from his stalker (who happens to be
the best friend of an employee in the IT department of his corporation,
or his home ISP, or whatever.)  Any number of scenarios will suffice,
but domestic violence and stalking seem to be issues that many can relate
with in terms of the importance of maintaining private information private.

(I'm going to ignore the existence of Echelon and Carnivore and other
technologies at "that level" and pretend the only evilness in the world
comes at the hands of one or three "bad technodweebs" or so.  Oh that
life were actually so simple, eh? heh.)

The discussion back then, was something as follows (VERY loosely
paraphrased:)

 - There should be control at the client level.
 - No, we want a thin client, we're fascinated with cell phones. ;-)
 - But there should be control at the client level, and here are
    additional reasons.
 - Tough, we're fascinated with putting Jabber on cell phones so that's
    that, the client remains thin, security is too "fat."

I have obviously grossly paraphrased, and attempted to inject a bit of
humour (don't be offended anyone developing for SMS.)

The bottom line however was that servers MUST be completely trusted,
that an untrusted-server-admin model was NOT to be accommodated, and that
if anyone cared about confidentiality they MUST run their own server.
"But that's okay, it's open source, just run a client and server both
on your Linux box."  (That last may be tongue in cheek on my part,
but it's closer to a direct quote than you may suspect.)

Summary:
 TO ACHIEVE SECURITY / SAFETY / PRIVACY, RUN YOUR OWN SERVER, NOT JUST A CLIENT.
But again, "servers are cheap, everyone can have one, this isn't an evil
centralized trust model" etc., so no problem.

I wasn't entirely happy with this, I'll admit, but that's how it seemed
things were left.

 TO ACHIEVE SECURITY / SAFETY / PRIVACY, RUN YOUR OWN SERVER, NOT JUST A CLIENT.

Back to our example, that leaves Andy and Betty, communicating thusly:

  Andy at home, sending
________________________                                 _______________
| Andy's               |                                 |Betty's      |
| Client --> Andy's    |    "eventually" encrypted       |Server       |
|            Server    | --> transmission across  -----> |  |-> Betty's|
|("localhost" for Andy)|     the Internet, or similar    |      Client |
|______________________|     untrusted hostile network   |_____________|
                                                          Betty at home,
                                                             reading

(BTW, it also bothered me that encryption and security were to be
"eventually added on" rather than central to the design, but it was felt
"easier" that way.  (I'll refrain from pointing out the implications of
that design decision here.)  It's "later" now, so I'll ask: has end-to-end
encryption become part of standard practice yet?  Or is this still on the
"maybe some day" list?)
Quote from the archive, answering someone's concern:
> 2. Whenever I talk to people within my company about using IM products they
> get very worried about the fact that the messages are going out over the
> 'public Internet' in plain text (and that they may be logged or transported
[snip]
You're exactly right. Even though Jabber has less security problems by
containing no routing (your home server sends a message directly to the
recipient's home server) we are still very much aware that IM would
benefit greatly from being encrypted end to end.
End quote.  (Ironic how this also mentions the expected norm is a
server-in-every-home.)

 IF YOU WANT SECURITY / SAFETY / PRIVACY, RUN YOUR OWN SERVER, NOT JUST A CLIENT.

That's the message we were given back then, and that's what my ASCII art
above attempts to illustrate.  I have no great talent in that regard,
so my apologies if it came out a jumbled mess, try to imagine what would
have been intended please.

I'm also going to presume that Jabber is intended for the masses, not
just the hard-core geek with access to his/her own Internic registration,
etc.  Let's hope that's a valid assumption, and that neither Andy's nor
Betty's localhost above need to actually be sitting on a rack in some
colo facility two hops from a major backbone. ;-) (Ah, but we all can
dream, right? heh)

This is not intended as a personal attack David, so please don't take it
as such.  Perhaps, sitting at your .edu domain, you forget that many if
not most of "us" (the end-users out here) are restricted to dialup access.

In the above scenario, Andy has a dhs.org address, and Betty has a
dyndns.com address.  Or perhaps one uses dhis.com and one dhis.org,
or ddt.org, or any of the other myriad services for DYNAMIC addressing
available for us <cough> "lowly" dialup end-users out here among the
great unwashed of the Internet.

Or yes, even overdue.ompages.com, as I do.  You asked:
 > will not work. Why are you doing server-server communication if your
 > host can't be resolved? How are replies expected to come in?
The answer to the first part, why server-server, is detailed above.
 IF YOU WANT SECURITY / SAFETY / PRIVACY, RUN YOUR OWN SERVERS.
(I didn't like it then, but accepted it for the time being, fearing
this day would come when developers FORGOT that "everyone should run
their own server" was the accepted security mantra.)
And the answer to the second part was also addressed above, albeit
briefly:
: > Delivered-To: lazarus at overdue.ompages.com
:   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
:   (Remember this, I did get it, that's relevant below.)

If you do a reverse lookup on that domain, it will undoubtably NOT return
to something owned by ompages.com.  Frankly, the IP you get at the time
you read this email will probably not be the same as it is at the moment
I type this.  Nor is it the same ISP as it was yesterday, when I was in a
different city and used a different provider.  The domain is this box, and
this box does indeed travel from state to state, rather often actually.
It doesn't utilize the same carriers, the same ISPs.  "Not everyone has
a static IP, or even a static situation, as you do there."

This is my point David, not intended as a personal attack, just a reminder
that it might be easy to forget that your (.edu) connection and situation
are not universal.  (Be thankful you don't have to live in fear of online
stalking, any of you that have not experienced such, also.)

This "dialback" concept you refer to, in 1.2 servers, appears to slam
the door in the face of the dialup users out here.  Well, at least
the ones who cared enough about privacy to follow that security mantra
mentioned above.
 IF YOU WANT SECURITY / SAFETY / PRIVACY, RUN YOUR OWN SERVERS.

 > invalid address. Soon (not now, as 1.0 still exists and is for the time
 > being supported), this won't work.

For those desiring security / safety / privacy, it appears Jabber
is "soon" to be an inappropriate solution, if this is an indicator.
The impression I have gotten from your words is that 1.0 is the last
server to allow end-users on dialup connections to run their own servers,
and additionally, that 1.0 is about to be unsupported "soon."
 IF YOU WANT SECURITY / SAFETY / PRIVACY, RUN YOUR OWN SERVERS.

If that is an accurate assessment, this bothers me greatly.
Then again, so does having a door slammed in my face.  Hard.

-- 
Please (OpenPGP) encrypt all mail whenever possible. Request the following
Public Keys for Lazarus Long <lazarus at overdue.ompages.com>

  Type    Bits/KeyID    Fingerprint                   DSA KeyID: vvvv vvvv
ElGamal: 2048g/41783186 47A0 0929 CD9F B53E 49C0  F06C 560E F574 ED0D F80C
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 244 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20001114/95090a26/attachment-0002.pgp>