Re: Some questions

On Sunday 26 October 2003 06:17 pm, you wrote:
> I haven't had much luck searching for an archive of this list, but I would
> have thought that a summary of the current answers/issues of the 'Some
> questions' area of Dans im2000 page would have evolved by now. Could
> someone try and address them please?
>
> http://cr.yp.to/im2000.html
>
-- cut --
> Lester

Here's how NGMP addresses them:

Question #1: How should receivers be identified? How will the sender's ISP 
find the receiver's ISP? Recipients will want to move transparently from one 
host to another.

A: Since NGMP is based on XMPP, this works just like instant messaging. It 
doesn't really matter from what host you connect to the XMPP server. Your JID 
(Jabber ID) is always the same. Are you also interested in allowing messages 
sent to [email protected] to get to [email protected] if I have switched to there.com as 
my XMPP provider? That *could* be done, although I know of no existing 
examples of it in XMPP. That's not how I interpreted the "[r]ecipients will 
want to move transparently from one host to another," however. Perhaps that's 
my mistake.

Question #2: How should senders be identified? How will the receiver find the 
sender's ISP? Recipients will want to provide better handling to known 
senders; in the long run, recipients will want to debit unknown senders.

A: XMPP utilizes dial-back for all s2s (server-to-server) connections. In 
other words, if I ([email protected]) send you ([email protected]) a NGMP message, the 
XMPP s2s component at here.com will tell the s2s component at there.com that 
it wants to establish a connection with it and will send a 'key' value. The 
s2s component at there.com will then perform a DNS lookup on here.com and 
establish a connection with the IP that the domain resolves to and send the 
key to it. That server (presumably here.com's XMPP server) responds whether 
or not the key is valid or invalid. The s2s component at there.com then 
informs the s2s component at here.com whether or not it is authenticated. The 
XMPP spec specifies that "[t]he method for generating and verifying the keys 
used in server dialback MUST take into account the hostnames being used, the 
random ID generated for the stream, and a secret known by the authoritative 
server's network." The "authoritative server" is whatever the originator's 
DNS hostname resolved to when the the receiving server "dialed it back." I 
hope I didn't make that too confusing... Obviously this method isn't 
fool-proof, but it's leaps and bounds better than SMTP. :)

So, the upshot of this is that receivers can be fairly confident about where 
notifications came from and thus the receiver's ISP already knows where the 
sender's ISP is, or the s2s connection would not have proceeded in the first 
place (the vast majority of the time, anyway).

The second part of this question deals with trusting known senders and being 
suspicious of unkown ones. Some of the ideas I have outlined in the NGMP 
Inbound SMTP wiki page (http://ngmp.libretech.org/NgmpWiki/InboundSmtp) could 
be applied to NGMP here. Specifically, maintaining a server-side whitelist 
(probably per-user for NGMP purposes) that is added to when a user sends 
someone a message (is that a good enough indicator?). We must recognize that 
even under an IM2000/NGMP mail scheme, it isn't out of the question that some 
ISPs will still provide service to spammers, even though it is much more 
expensive (and dangerous, due to extreme difficulty of anonymity) for them to 
do so. So, having a system that allows people to blacklist malicious senders 
and eventually entire domains would probably be a good thing. At any rate, 
regardless of the specifics, we get server-side, per-user, persistent storage 
of whatever information we want for free with XMPP (well, at least with 
jabberd, I'm not sure if that's actually in the XMPP spec or not). So, 
however we want to allow people to "debit unkown senders," it should be 
fairly trivial to implement with NGMP. (Am I understanding the terminology 
correctly here? The word "debit" seems to possibly indicate something more/
other than what I'm talking about... If so, feel free to enlighten me).

Question #3: How should messages be identified? How should messages be 
downloaded? Messages could be retrieved through HTTP, but an NFS/FSP-style 
UDP-based protocol would be much more resistant to denial of service.

A: NGMP messages are currently identified by a message ID which is nothing 
more than the hex representation of the SHA1 hash of the message body (and 
only the body). This ID is used to request the message from the sender's ISP 
using HTTP. DoS vulnerabilities notwithstanding, HTTP was chosen mostly 
because NGMP message notifications can be sent to Jabber clients which know 
nothing of NGMP and they present the recipient with a URL to retrieve their 
NGMP message using a web browser. This idea was suggested by Jason (a fellow 
im2000 list subscriber), and it seemed like a good one. However, there's no 
reason that the retrieval protocol couldn't be changed if we wanted to 
(although I personally really like the HTTP method in that it allows a Jabber 
client and a web browser to act as a rudimentary NGMP client).

Question #4: How should notifications, messages, and confirmations be 
protected against espionage and sabotage? DH authenticators seem more 
appropriate than public-key signatures for private email; they're also much 
faster and just as convenient.

A: The NGMP protocol wiki at http://ngmp.libretech.org/NgmpWiki/NgmpProtocol 
has some verbage defining a system by which all NGMP users are guaranteed to 
have a public/private keypair whose public key can be retrieved transparently 
by the sender (by requesting it from the recipient's NGMP server) in order to 
encrypt the message. However, the system outlined on that page is incomplete, 
flawed (not fatally), and generally needs to be rethought (I wrote what's 
there, then thought about it, and decided to stop writing until I'd pondered 
some more; I haven't returned to it yet). I hadn't considered a 
Diffie-Hellman system before. Let me see if I understand how such a system 
would work in this case: The sender and the reciever would have a pre-decided 
common modulus (P) and a common base (A) (could these just be hard-coded in 
all NGMP server implementations? Would we need to "upgrade" them one day?). 
The sender would compute a random, secret number x and the receiver would 
compute a random, secret number y. The sender would transmit A^x (modulo P) 
to the receiver, and the receiver would reply with A^y (modulo P). Now both 
the sender and the receiver can compute A^(xy) (modulo P) because that is 
equal to (A^x)^y (modulo P) and (A^y)^x (modulo P). However, a listening 
third party cannot compute this value because he/she only knows A^x and A^y 
(modulo P). So, once this exchange has taken place, the sender can encrypt 
the message it stores using A^(xy) as a key (using whatever two-way 
encryption scheme is deemed appropriate). The receiver will then use A^(xy) 
to decrypt the message once it has been retrieved. Does that sound about 
right, for those more in the know on DH than I? :) If we combine this with 
automatic confirmation that the message ID and a rehashing (using SHA1) of 
the body by the receiver (after decryption) are equal, it seems to me we can 
be reasonably assured that the message one gets has not been seen by a third 
party and that the message has not been altered between notification and 
retrieval.

Question #5: How should the sender create a message?
Question #6: How should the receiver download a list of notifications?

A: In NGMP, messages are XMPP packets that are sent and received in realtime 
just like IM messages, XML-RPC information, or any other traffic that XMPP 
handles. The sender creates a message by sending it to the NGMP component 
running on their ISP's XMPP server. The component then sends a notification 
of the message to the recipient and stores the message for later retrieval by 
the recipient. Notifications are sent directly to the recipient in realtime, 
so no downloading is necessary, in the narrow sense of that term. I think 
that covers these questions, unless I'm missing something???

Question #7: What format should messages have?

A: NGMP messages are, by nature, XML. That gives us quite a bit of 
flexibility. I honestly don't think we need worry about the "complexity" of 
XML. XML parsing is quickly becoming a "commodity function" of programming 
libraries, and the benefits are well worth it, in my opinion. For instance, I 
already have trivial XSLT stylesheets that transform NGMP messages to HTML 
and MIME (regular email) format. For those who do not want to deal with XML, 
they can request a different format from the retrieval mechanism (the 1.1 
NGMP prototype's CGI script does server-side XSLT transformations). Adding 
formats beyond HTML and MIME is as simple as writing new XSLT stylesheets. 
Even if it weren't required that the messages be XML to be routed by XMPP, I 
would still prefer this format because of its flexibility. Issues of speed 
and complexity are completely due to the newness of XML and will disappear 
over time as hardware and software improve. Indeed, we can see this happening 
already. Of course, this is merely an opinion (to an extent), so feel free to 
disagree (as if anyone needs my permission... :P ).

I hope I have appropriately addressed these questions. As always, I definitely 
welcome any and all feedback on this. Thanks.

Wes Morgan