[Cryptography] On the deployment of client-side certs

Ron Leach ronleach at tesco.net
Tue Nov 15 03:59:10 EST 2016

On 15/11/2016 07:59, Pieter Rogaar wrote:

> In today's threat models, there is also the metadata angle to
> consider. Client certificates are exchanged before the TLS connection
> is encrypted.

But that doesn't have to be the case, does it?

In a scheme for authentication by using client-side certificates, 
there could be two stages:

(i) End-to-end private connection is set up by exchange of public 
keys.  At this stage, the connection might actually be Alice to Bob, 
or could be Alice to Mallory.  So ...
(i) Over the private connection, the full certificates are exchanged, 
enabling both ends to each validate their counterparty.  (I assume 
certificates enable both ends to detect that Mallory is present, and 
drop the connection *and* report the intrusion to both ends.)

This could be followed by further exchanges of 'comfort' or 
'assurance' to be really sure, etc.  My bank does this sort of thing, 
When telephoning them, you make initial 'provisional' authentication 
which provides a limited form of capability, after which a human comes 
on and asks some more 'pre-shared secrets' or secrets about the bank 
account status etc.  (Though that helps the bank verify I am me, but 
doesn't help me verify it's the bank, I mention this instead to 
illustrate the 'step by step' approach I'm suggesting to reach a more 
and more authenticated connection, so that the real business can start 
once both sides are satisfied.

This sort of step by step approach presumably isn't in the existing 
protocols, but a dual party authentication scheme could have its own 
protocol on top - just like SMTP or IMAP (sometimes) runs on top of TLS.


More information about the cryptography mailing list