[Cryptography] Toxic Combination

[Tony Arcieri]

On Wed, Dec 3, 2014 at 1:33 PM, Guido Witmond <guido at witmond.nl> wrote:

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

There's nothing new in your system, and a lot of orthogonal concerns which
are unrelated and complicate the discussion.

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)
>

This is how the web works today.

ad b) the site operator has a few extra steps to take:
>  - set up their own CA;
>  - sign server certificates;
>

Having each site run an intermediary server CA accomplishes nothing if you
decide to trust it using DNSSEC/DANE.


>  - setup the DNSSEC and DANE records;
>

You want to preserve privacy, but you recommend DNSSEC and DANE over X.509?

DNSSEC is not encrypted, it only provides authentication, so you're already
worse off from a privacy perspective.

DNSSEC keys are held by governments, so you can't prevent a government
holding a key higher up the hierarchy from impersonating you (e.g. if you
have a *.com domain, the NSA probably has a way to MitM it)

DNSSEC has no solution to these problems on the horizon: where a lot of
effort has gone into building an X.509 transparency system (Certificate
Transparency), no work (to my knowledge) has gone into building one for
DNSSEC.

Don't get me wrong, there are aspects of DNSSEC I like, but it doesn't
solve any of the problems you described and is in fact arguably worse at
all of them given your requirements.

Furthermore, all of this is orthogonal to user authentication: you've
muddled up the problems of authenticating the user and authenticating the
site.

 - sign client certificates;
>

This can be done today using the HTML <keygen> tag to generate a client
certificate. A CSR is sent to the server, which can sign it under its own
client CA, and send the signed certificate back to your browser for
installation.

Unfortunately, there's one problem: the user experience! All of the
technical problems are solved, but it's still a terribly confusing process
for users.

Everything you've described can be built and deployed today without any
changes to (most) browsers. But the user experience is so bad and confusing
that nobody will use it:

- Different browsers have different trust stores
- Users have to pick which certificate to use to authenticate
- Users have to copy certificates from browser-to-browser or
computer-to-computer
- Users need to back up certificates so they don't lose them
- Users need some way to recover their account if they do lose the
certificates

Fixing the user experience problem is where systems like FIDO alliance
U2F/UAF come in:

- Hardware tokens generate and statelessly manage user credentials
- Credentials follow the same-origin policy and are thus privacy-preserving
(unique credential per origin)
- Support for U2F hardware tokens shipped in the latest releases of Chrome
and will be present in Windows 10

-- 
Tony Arcieri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20141204/35fcc165/attachment.html>