[Security] Reminder :: Draft feedback on "C2C authentication using TLS"

Pavel Simerda pavlix at pavlix.net
Mon Aug 25 15:34:41 CDT 2008

What is the point of unauthenticated encrypted channels?


On Mon, 25 Aug 2008 12:14:23 -0700
"Eric Rescorla" <ekr at rtfm.com> wrote:

> On Mon, Aug 25, 2008 at 4:30 AM, Dirk Meyer <dmeyer at tzi.de> wrote:
> > Jonathan Schleifer wrote:
> >> Am 25.08.2008 um 12:05 schrieb Dirk Meyer:
> >>
> >>> But where to put the fingerprint? IMHO that is needed to know if
> >>> we can use that mechanism. The information that the other side
> >>> supports X.509 is useless when I have no way to verify the key.
> >>> The only option I see it the 'name':
> >>>
> >>> <item jid='urn:xmpp:c2ctls:x509'
> >>>          name='fingerprint'/>
> >>>
> >>> Looks kind of strange. On the other hand, the fingerprint is some
> >>> sort of name of the certificate.
> >>
> >> Can you please explain me why you want a fingerprint there? That's
> >> totally useless IMO, the server could forge that.
> >
> > It is only some sort of hint. It makes no sense to use a mechanism
> > when you can not verify the key. I added the fingerprint to the
> > <offer> in my proposal (also unsecure at that point) to give the
> > peer a hint what it will get as certificate when choosing X.509.
> > The same for OpenPGP. If we do not add it somewhere in disco#query
> > we will get the same problem. Both clients support X.509 and they
> > open a c2c link because it is a common feature. Now in the TLS
> > handshake the realize that the peer uses self-signed certificates
> > they can not verify. IMHO they should find out about that sooner to
> > switch to OpenPGP or SRP.
> To go meta here for a second, let's assume that there are at least
> 3 cases:
> - The peers have certificates that can be independently validated,
> e.g.,
>   + via a CA
>   + via some sort of out-of-band fingerprint exchange
> - The peers don't have validatable certs but want to use SAS/SRP/SASL
> - The peers don't have validatable certs and don't want to bother to
>   check them at this time (the common use case, I suspect)
> At least one natural UI here, then, is to let the certificate/key
> exchange proceed and then prompt the user for whether they want to
> check the peer's identity via some out-of-band channel. If they do,
> then you prompt them with the SAS or ask for the SRP/SASL password
> and do a rehandshake. If they don't you proceed. It's not clear to me
> it's a virtue to jump right to SRP if you don't expect to be able to
> validate certificates, and of course this isn't really possible with
> SASL, since you need to do TLS first, and if you want to do SAS, you
> can *always* try to compute it...
> -Ekr


Web: http://www.pavlix.net/
Jabber & Mail: pavlix(at)pavlix.net
OpenID: pavlix.net

More information about the Security mailing list