[OTR-users] OTR transport protocol?

[Ian Goldberg]

On Sun, Apr 04, 2010 at 09:24:48PM -0400, Alex wrote:
> On Sun, 4 Apr 2010 19:48:27 -0400
> Ian Goldberg <ian at cypherpunks.ca> wrote:
> 
> > On Sun, Apr 04, 2010 at 07:23:34PM -0400, Alex wrote:
> > > Hi. Would there be any use for an implementation of OTR in a way
> > > similar to that of TLS?
> > 
> > Good question.
> > 
> > TLS already has the ability to do perfect forward secrecy by using one
> > of the ephemeral Diffie-Helman ciphersuites.  It does mutual
> > authentication using certificates, but I've seen proposals to include
> > PAKE, and even SMP, into TLS.  One would have to figure out exactly
> > what deniability/repudiation properties one was looking for to see if
> > TLS could be coaxed into doing that.
> > 
> > That said, if you squint in the right way, you could pretend that
> > today's OTR was indeed a transport-level protocol, since you can send
> > arbitrary packetized TCP streams over it.  (You'd have to remove the
> > specification of how to interpret the decrypted message, though.)
> > Its utility would be quite different from TLS, though, since it's
> > mainly useful for connecting people who know (and can authenticate)
> > each other, whereas TLS can connect strangers, proving they trust the
> > PKI-in-the-sky. (See, for example,
> > http://government.zdnet.com/?p=8257 )
> > 
> 
> What do you think of a bank whose branch-employees hand out business
> cards containing a fingerprint for use with OTR? The user can go home
> and visit the bank's website (using an OTR transport mechanism), at
> which point a dialog would ask them if they want to trust the given
> fingerprint or not. They can compare it to what is on the business card,
> and the server can be authenticated.
> 
> The bank's servers (seeing that you are unverified) can ask you a
> question only you would know via the shared-secret OTR feature. After
> this point, your fingerprint would become trusted on the bank's end and
> you won't have to go through that again unless you lose access to the
> key (by using a different computer, etc).
> 
> Assuming that the code for this was written and incorporated in to
> most browsers/OSs, this would be very practical solution to the root
> CA problem described in the zdnet article above.
> 
> One potential issue is that people are terribly passive and complacent,
> and they think that if they aren't doing anything wrong that they have
> nothing to hide. I guess we can't code away those problems.

I think most people understand that their banking should be protected.

Your example use case doesn't involve deniability/repudiation or forward
secrecy, so it would seem to be just as good with normal TLS:

The bank hands out its TLS cert's (really its public key's) fingerprint
in its branch.  Users generate self-signed client certs, and associate
the fingerprint of that cert to their account via some secret known only
to them.

Then the only browser change would have to be "for these vital websites,
I'm going to type in the public key fingerprint manually, rather than
trusting a CA".

I bet no one would do it, though.

A friend of mine actually called his bank one day and asked to verify
the fingerprint of the (then SSL) certificate.  He was completely unable
to speak to anyone who knew what he was talking about.

   - Ian