[Security] TLS Certificates Verification

Jonathan Dickinson jonathanD at k2.com
Tue Aug 19 16:04:29 CDT 2008


ESessions is pretty swanky, I must admit. I must have missed the email about it somehow. Has it been reviewed at all? What protocol is it based on?

The <encrypted> stanza was a bad example, it could be put in another stanza (probably of the same type as the original).

I haven't even looked at libotr (which is why I said I was speaking out of turn). If it can't handle binary then I suppose it isn't much use. But the protocol itself is still probably useful if it is made more formal.

All that I am saying is that instead of coming up with our own protocols etc. we should be concentrating on how existing ones could be made to fit into the current XMPP standards. For example, we didn't invent our own SASL mechanism, we used already defined ones and made it configurable. Maybe something like that is needed?

For example:
<iq type="result">
  <query xmlns='jabber:iq:e2e2:protocols'>
   <protocol>esessions</protocol>
   <protocol>otr</protocol>
  </query>
</iq>

A lot like SASL mechanisms. I know it adds extra complexity, but if, for example, a bug is found in OTR a client user could simply refuse incoming OTR requests and require esessions. Plugins could be built. Hell, using that you could use PGP is you _really_ wanted.

-----Original Message-----
From: security-bounces at xmpp.org [mailto:security-bounces at xmpp.org] On Behalf Of Jonathan Schleifer
Sent: Tuesday, August 19, 2008 10:52 PM
To: security at xmpp.org
Subject: Re: [Security] TLS Certificates Verification

Jonathan Dickinson <jonathanD at k2.com> wrote:

> (compared to making
> a new standard which would have no implementations).

ESessions *HAS* implementations! That's the point I bring up again and again against reinventing the wheel and doing something with TLS now!

> <encrypted from="joe at foo.org" to="mary at foo.org">
> 192376123abd078f123aasdjib123khnasd0u123==
> </encrypted>

Now you're even talk about breaking XMPP Core compatibility?
And libotr can't handle arbitrary data, just messages. For which it will add HTML escapes if it's plaintext.

> Originator-Supported
>       Add <e2e2/> tag to iq query.
> Receiver-Supported
>       Recognise <e2e2/> tag and begin e2e2 negotiation.
> Originator-Unsupported
>       No changes made.
> Receiver-Unsupported
>       No changes to code made, new <e2e2/> tag simply ignored if
> present. Negotate e2e as normal. Receiver-Unsupported
> Originator-Supported When first IQ response it aquired,
> <e2e2>...</e2e2> tag is not present. Continue e2e negotiation.

libotr uses whitespaces to detect support. It's hardcoded.


> As you can see it kinda works the kinks out itself.

Doesn't look like that to me.

--
Jonathan


More information about the Security mailing list