<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Dec 3, 2014 at 1:33 PM, Guido Witmond <span dir="ltr"><<a href="mailto:guido@witmond.nl" target="_blank">guido@witmond.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I humbly believe I've came a long way towards a system that fits all of<br>
these requirements:<br></blockquote><div><br></div><div>There's nothing new in your system, and a lot of orthogonal concerns which are unrelated and complicate the discussion.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
ad a) the user agent (yes: browser) manages the cryptographic operations<br>
and verifications for the user. The user has to decide:<br>
 - whether to create an account;<br>
 - when to log in;<br>
 - when to log out;<br>
 - whether to trust the site with his private information or not. Until<br>
then, the user is anonymous (except for ip-addresses, cookies etc)<br></blockquote><div><br></div><div>This is how the web works today.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">ad b) the site operator has a few extra steps to take:<br>
 - set up their own CA;<br>
 - sign server certificates;<br></blockquote><div><br></div><div>Having each site run an intermediary server CA accomplishes nothing if you decide to trust it using DNSSEC/DANE.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 - setup the DNSSEC and DANE records;<br></blockquote><div><br></div><div>You want to preserve privacy, but you recommend DNSSEC and DANE over X.509?</div><div><br></div><div>DNSSEC is not encrypted, it only provides authentication, so you're already worse off from a privacy perspective.</div><div><br></div><div>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)</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Furthermore, all of this is orthogonal to user authentication: you've muddled up the problems of authenticating the user and authenticating the site.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 - sign client certificates;<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><br></div><div>- Different browsers have different trust stores</div><div>- Users have to pick which certificate to use to authenticate</div><div>- Users have to copy certificates from browser-to-browser or computer-to-computer</div><div>- Users need to back up certificates so they don't lose them</div><div>- Users need some way to recover their account if they do lose the certificates</div><div><br></div><div>Fixing the user experience problem is where systems like FIDO alliance U2F/UAF come in:</div><div><br></div><div>- Hardware tokens generate and statelessly manage user credentials</div><div>- Credentials follow the same-origin policy and are thus privacy-preserving (unique credential per origin)</div><div>- Support for U2F hardware tokens shipped in the latest releases of Chrome and will be present in Windows 10</div></div><div><br></div>-- <br><div class="gmail_signature">Tony Arcieri<br></div>
</div></div>