[standards-jig] Re: JEP-0102

Peter Ronez prnz404 at yahoo.com
Thu Jul 3 03:04:24 UTC 2003

--- Jean-Louis Seguineau/EXC/ENG <jean-louis.seguineau at antepo.com> wrote:
> If I understand you correctly, you do not want to implement experimental
> JEPs, and the one you want to implement should not be too complex :)

I think you should re-read my prior post :)

> That said, anything that has to do with "security" hardly fit in a three
> pages JEP. A look at various RFCs around will confirm that. Maybe, before
> being so affirmative that all cases are covered by SSL, PGP and S/MIME you
> could have done some superficial research that may have brought answers to
> these legitimate questions.

You're right Jean-Louis, I shouldn't make hasty conclusions about things before
I investigate them. Unfortunately, that doesn't make you correct either. 

However, this is not here nor there -- let's talk about your JEP. 

> Secondly, although this JEP says experimental (because all JEPs do) it is
> far from experimental, as this has been part of our commercial clients that
> are used by our customers since the beginning of the year. Its a working
> solution that took 1 1/2 month to spec, and a week to implement and test.
> Maybe the short implementation time came from a rather thorough spec ...

Let's start off with some fairly minor points. 

1) Your JEP has an extremely short introduction that and makes only broad
reference that this JEP is the "foundation for securing [...] data." However,
lets be honest, the majority of this JEP has to do with key exchange, correct?
Also, since their are obviously other neophytes like myself out there, how
about putting this JEP in context in terms of all the other security proposals
out there? After all, security is very large, multi-faceted beast.

2) Section 3 seems to take a lot of time trying to establish the fact that
security is a good thing and all the aspects that need securing. And all of
this at 50,000 feet. That's all fine and dandy, but then Section 4 immediately
jumps into the element structures and the cryptographic hash functions
detailing procedures without any motivation. Nowhere is there a discussion
filling in the blanks between all the security problems associated with the
current protocol and how all the key exchange solves all of that. 

Well, you could argue that's the subject of cryptographic texts, but then
what's the point of talking at the beginner level about security in Section 3?

3) Something that I did find cool was being able to do registration without
actually passing the the password in the clear -- that is very nifty, and
obviously a logical extension of the fact that you've agreed on a cypher and a
symmetric key. However, XMPP requires clients and servers to implement TLS so
if we have one very paranoid sysadmin, then he could require the use of TLS for
both client-server and server-server communication as per the XMPP Core spec.
However, more about this later.

4) According to the current JEP-102 is necessary to pass all strings in UTF-16
encoding. XMPP Core requires that implementations support both UTF-8 and
UTF-16, but requiring only UTF-16 seems too restrictive. As far as I can tell,
there is nothing inherent about HMAC algorithms that restrict them to UTF-16.
Sounds like a case of protocol mirroring implementation.

> Finally, everything in the JEP is standard based. On the XML side it uses
> XMLSec and XMLDsig, and for the rest we have just implemented IKE (internet
> Key Exchange). So nothing really new here but XMPP adaptation.

Let's talk about XMPP. According to your comments above, you drew up JEP 102
around November of last year and implemented it in December, correct? I believe
that was right about the time that the IETF working group started seriously
revising the XMPP Core and the XMPP e2e. At the time I'm sure those
specifications were far too large of a moving target to implement. In fact, a
lot of that has only solidified in the past couple of months. I believe Antepo
decided that instead of having SSL, SASL, and PGP, you'd come up with a single
encryption spec that would take care of all of the problems addressed by those
technologies. Might I say that this is a pretty good idea. 

Inspite of that, XMPP Core's current requirement for TLS takes care of most of
the "Security Requirements" as per Section 3.1 of JEP-102. PGP takes care of
the rest where there is no way to make sure that the sessions are encrypted all
the way to a remote end node. Granted, you stuff does provide PKI
infrastructure that isn't accounted for in any of the current XMPP
specifications, but do we really need all of JEP-102 just for key exchange?
Aren't corporations that have PKI going to have other infrastructure for
handling PKI? Maybe this is something to introduction could clarify.

BTW, is Antepo's Jabber solution truly XMPP complaint? As far as I can tell
Antepo's  doesn't support SASL nor the instream STARTTLS mechanism as required
by XMPP Core. Could it be that Antepo wants Jabber.org to approve JEP-102 so
that it can assure it's customers of a proper authorization and encryption
support while dragging its feet implementing SASL and TLS as per XMPP Core?  

> Peter, I don't understand the point you were trying to make, and I believe
> your comment is not appropriate. I understand equally that security issues
> are not mainstream for most people, looking at the small number of
> constructive comments made so far on the JEP. But I am afraid that any
> proper security implementation will have to be as detailed, and probably as
> boring...

Let me tell you the main reason why I don't like this JEP. TLS, SASL, and
PGP/S-MIME are all molded into the Jabber protocol in such a way that the data
transfer is opaque to the client developer; the client developer simply has to
pass the data to a 3rd party library to take care of the rest. Why is this so
great? Well, its great b/c client developers shouldn't be cryptography experts
to work with Jabber. This is what makes Jabber great. The barrier of entry to
working with Jabber ought to be minimal, and I honestly don't think this JEP is
in line with that.

> Tolerance comes with the acceptance of the unknown - Pascal
*** Accept when it comes to security. ***

Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.

More information about the Standards mailing list