[Cryptography] Toxic Combination

[Guido Witmond]

On 12/03/14 18:56, Ben Laurie wrote:

> [...] - the difficulty has always been the lack of a _usable_ way to
>  _securely_ implement such protocols.
> 
> And by "usable" I mean a user experience that is
> 
> a) satisfactory to the user.
> 
> b) satisfactory to the site operator.
> 
> c) possible to transition to from existing systems easily (for at 
> least the user).
> 
> And it has to be secure - which includes "not allow credential theft 
> _even by the site operator_".
> 
> This appears to be a tall order. But produce it, and I would 
> certainly fight hard for implementation.

Dear mr Laurie,

I humbly believe I've came a long way towards a system that fits all of
these requirements:

ad a) the user agent (yes: browser) manages the cryptographic operations
and verifications for the user. The user has to decide:
 - whether to create an account;
 - when to log in;
 - when to log out;
 - whether to trust the site with his private information or not. Until
then, the user is anonymous (except for ip-addresses, cookies etc)

ad b) the site operator has a few extra steps to take:
 - set up their own CA;
 - sign server certificates;
 - setup the DNSSEC and DANE records;
 - sign client certificates;

These steps can be automated into a single system that adheres to the
protocol. It could be delivered as debian/ubuntu/redhat packages, a
boxed solution or as an outsourced service. Most web hosting providers
should be able to set up this service for their customers. I imagine
that companies that know how to charge money for certificates might be
interested in providing this service. They have the expertise in
operating a HSM properly...

Most web servers already know how to deal with client certificates. The
benefits are: no hassles with password recovery, easier session
management, lower state to maintain at servers as the TLS-layer provides
the authentication.

ad c) The eccentric protocol is using existing web infrastructure. It
requires some changes at the browser and the server but in a backwards
compatible way. One site at a time can convert. The protocol does not
forbid to user password authentication next to client certificates. The
latter have benefits over the former. Transition can be gruadually.

ad d) In the basic version of the protocol -- where clients authenticate
with site-CA-signed client certificates -- there is no incentive for a
site to MitM themselves. But this is limited to user-to-site and
site-to-user communication. When there is a need for user-to-user
communication where the site cannot MitM the endpoints a need for a
verificate service arises. I call that the Registry of Dishonesty[0].

In every case, there is end-to-end key exchange where there is no chance
of a MitM going undetected. There might be a small chance that a site
operator might turn rogue but that is detected almost immediately and
published for the world to know.

I sincerely believe that my protocol raises the bar towards your goals
tremendously. Please spend some time to investigate the ideas[1] behind
it  and let me know what you think is missing before you would fight for it.

Respectfully yours,
Guido Witmond.

0:
http://eccentric-authentication.org/eccentric-authentication/global_registry_of_dishonesty.html
1: http://eccentric-authentication.org/Usable-Security.pdf

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20141203/a550b074/attachment.sig>