[Cryptography] On the deployment of client-side certs
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