[Security] TLS Certificates Verification

Jonathan Dickinson jonathanD at k2.com
Tue Aug 19 15:52:48 CDT 2008


Oh, and furthermore, this isn't really the thing for software developers to nitpick at. The reason I am jumping at existing protocols is because mathematicians do this for a living: we do it for a living when we need it.

It is beyond our domain, so by all means we should be trying to steer as far away from own home-grown implementation on top of any algorithm.

Just to clarify on David's idea. Did you mean (in less words) wrapping a TLS stream in stanzas? As the following example demonstrates (where a + in the original stream indicates a send where a Nagle algorithm deems nessecary):

B64 TLS Stream: 918734c01n23487c12304u8cn10238947203847cn+0893nc4n987q9048c5n7q0w48957c+07n34890qn4v7890q4n5v+q4098v5nq49807qn4

<message from="joe at server.org" to="jane at server.org" sequence="100">
 <e2e2>918734c01n23487c12304u8cn10238947203847cn</e2e2>
</message>

<message from="joe at server.org" to="jane at server.org" sequence="101">
 <e2e2>0893nc4n987q9048c5n7q0w48957c</e2e2>
</message>

<message from="joe at server.org" to="jane at server.org" sequence="102">
 <e2e2>07n34890qn4v7890q4n5v+q4098v5nq49807qn4</e2e2>
</message>

That sounds pretty attractive.

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

Indeed there are not too many implementations. Wouldn't the new standard break compatibility any way?

However, according to http://en.wikipedia.org/wiki/Off-the-Record_Messaging, there are ones for Miranda, MCabber and pidgin: which is a start (compared to making a new standard which would have no implementations).

I don't think any client supports what has been suggested so far, such as the brilliant (no sarcasm) suggestion by Dave. Dirk also had a good idea with (what looks like) one time passwords, but this would break compatibility.

> Break compatibility with clients that already use the current way.
The new standard will do this anyway right? Maybe a new element on the initiator's iq for E2E could be added (that an unsupported client SHOULD, as per spec, ignore). Hence E2E and E2E2 <grin> would be easily negotiable.
> Libotr thinks our stanzas are HTML and act strange.
Libotr (I am speaking out of turn here) probably collates a bunch of other standards for which I am sure there are many implementations: libotr is (once again, out of turn) ready to port to your language of choice. If we were to use the enveloped encryption stanza (where all of the contents of the original stanza are just encrypted) we could just send the XML as an opaque binary stream to libotr, at which point it won't mess with our XML structure. This would then be b64 encoded and send as follows:

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

And once decrypted the contents would be the ORIGINAL (outer xml) of the encrypted element.

As for the break compatibility argument, the following states would apply.

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.

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

-----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:24 PM
To: XMPP Security
Subject: Re: [Security] TLS Certificates Verification

You seem to totally ignore that there is only one implementation of
OTR: libotr. And this is the reference implementation as the documentation, well, I don't think it's good enough to write a new implementation from scratch from that.

And here come the problems:
* We will break compatibility with clients that already use the current way.
* libotr thinks our stanzas are HTML and act strange.

--
Jonathan


More information about the Security mailing list