What is the point of unauthenticated encrypted channels? Pavel
On Mon, 25 Aug 2008 12:14:23 -0700 "Eric Rescorla" <[EMAIL PROTECTED]> wrote: > On Mon, Aug 25, 2008 at 4:30 AM, Dirk Meyer <[EMAIL PROTECTED]> 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
