[JDEV] servers specifying from fields

[Mathew A Johnston]

I'm not sure if I understand the significance of, "specifically for
sending namespace fragments, and not for sending entire XML documents. In
particular, specify whether you can send multiple namespace extensions
through, and make sure people know they cannot do  things like insert a
DTD or PI instructions (including <?xml version=1.0?>"

You mean whether they can send more than 1 <x> element within the
encrypted block? Why is sending entire xml messages illegal?

I think an error reporting method - ie "I dont recognise this
namespace" would be a good thing. For the client to simply send back a
message saying "huh? i dont understand namespace xyz?" is what I'm
thinking. I'm thinking that there's already some support for this - i sort
of recall hearing about this somewhere.

I think we need a better method of key exchange - maybe an ability to use
a 3rd party certificate authority. Of course, this is all client
dependant, and does not necessarily need to have anything to do with
jabber it's self; but I do think that we need a standard. Like you said,
if it's easy to forge online messages that include the user's public key
(to later be used for encrypted messages sent to the user), its hard to
trust that we're actually sending to who we want to. Different levels of
key security should be offered:

	low: dont ever use encrypted messages
	medium low: accept whatever key user claims on presence
	medium: warn on change from last known key
	medium high: 3rd party certificate authority
	high: manual key exchange

My two main concerns with jabber security are the ability to send messages
encrypted (of any sort) and the strength of key exchange between clients.

I think that if we can secure key exchange, and offer a way to send <x>
elements encrypted (since all extentions should use x elements right?) we
can provide a way for developers to implement their own secure private
namespaces in their clients, to fill their needs. Right now, unless they
implement what we're talking about, people cant really write extentions
that are nice and secure, which sucks.

Mathew Johnston



On Sat, 3 Mar 2001, David Waite wrote:

> Interesting.
> 
> Actually I have a couple of things to say about this.
> 
> Currently there isn't a way to broadcast capabilities within Jabber, meaning
> that there isn't some general field you can read to see that someone supports
> this draft extension. Encrypted messages work because it requires presence to be
> signed, which does little more than indicate the key to use for sending messages
> (I say this because saying your status is 'Online' is *extremely* open for
> replay - but who is going to hack into your account and set the status to signed
> 'Online' just to have the priviledge to receive encrypted messages?). You will
> need some sort of indicator that the client supports your namespace, or to try
> to propose capability reporting. Especially for encryption, you want to be
> careful of clients who say 'err, hmm, no i don't support encrypted content,
> could you send it again in plaintext?'
> 
> Would the client ever want to know the namespace of the encrypted block before
> decrypting? If you send me an encrypted xhtml block, and I don't support rich
> text...
> 
> Finally, I fear multiple extensions in a message, all encrypted. Five pgp blocks
> per message will just kill bandwidth. I don't think that is really a problem
> with your proposal.
> 
> Other than that, I would suggest adding the following comments:
> - This is specifically for sending namespace fragments, and not for sending
> entire XML documents. In particular, specify whether you can send multiple
> namespace extensions through, and make sure people know they cannot do things
> like insert a DTD or PI instructions (including <?xml version=1.0?> in ;-)
> - Make sure for future note that clients should recognize encrypted content.
> Specifically, a jabber:x:delay packet indicates a message delay - the server
> cannot verify that someone isn't forging a message delay timestamp if it is
> encrypted, so a client would need to have the logic to discard this information
> (or even better, indicate someone is trying to fake an older message).
> - Specify specifically if character encoding matters. Everything Jabber uses
> UTF8, so I assume this would as well.
> 
> 
> -David Waite
> 
> Mathew A Johnston wrote:
> 
> > Re-read megaepic.com/~johnston/nestedencrypted.txt
> > The only legal encrypted element would be an x element... x elements do
> > not usually include any reference to from addresses. (they should not).
> >
> > Mathew Johnston
> >
> > On Sun, 4 Mar 2001, Matthias Wimmer wrote:
> >
> > > Hi Mathew!
> > >
> > > But where is then your problem with the server setting the from-attribute?
> > > Let it set the attribute of the envelove of the encrypted data and ignore
> > > it if you prefere Data from within the encryted data ... but you need the
> > > data also outside the encrypted package to allow bouncing of messages if
> > > e.g. the receipiend has sent a message rule for auto reply.
> > >
> > > Tot kijk
> > >    Matthias
> > >
> > >
> > > Mathew A Johnston schrieb am 2001-03-02 19:11:09:
> > > > First, I want to make sure that everyone understands the point I'm trying
> > > > to make. Currently, there is no way to send encrypted messages where the
> > > > encrypted message is a block of xml to be parsed upon decryption. The
> > >
> > > _______________________________________________
> > > jdev mailing list
> > > jdev at jabber.org
> > > http://mailman.jabber.org/listinfo/jdev
> > >
> >
> > _______________________________________________
> > jdev mailing list
> > jdev at jabber.org
> > http://mailman.jabber.org/listinfo/jdev
> 
> 
> _______________________________________________
> jdev mailing list
> jdev at jabber.org
> http://mailman.jabber.org/listinfo/jdev
>