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

Eric Rescorla ekr at rtfm.com
Mon Aug 25 14:14:23 CDT 2008


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


More information about the Security mailing list