[Cryptography] Moving forward on improving HTTP's security

[Ben Laurie]

On 15 November 2013 06:02, James A. Donald <jamesd at echeque.com> wrote:

> On 2013-11-15 05:50, Tony Arcieri wrote:
>
>> And what of other solutions like CT or Tack?
>>
>
> With CT, when your browser hits a site, gets a certificate, it needs to
> check if the certificate is in a CT file, which is cryptographically
> secured to be the same for everyone.
>

> But, if you have check each newly encountered certificate in real time,
> why does it need the CA's signature?  (Other than to avoid threatening the
> CA business model.)
>

This is not how CT works, the check is asynchronous: you get a signature
from a log along with the certificate, and you later check that the log was
honest. That is, trust but verify.

Synchronous checks would be nice, but the failure rate is too high. Even if
it weren't, the extra latency is also a problem.

CT is a careful compromise that balanced deployability with effectiveness.
Once it is in place, I'm sure we'll start working on compromises that move
the needle towards even higher security at the cost of slower deployment.

For example, revocation is often cited as a problem. I agree. But to solve
it without introducing other problems, we need to change servers. Changing
_all_ servers takes around a decade.


> The social mechanism underlying CT is:
>
> 1. not everyone is allowed to write to the CT files.  It is a valuable
> privilege.
>
> 2. the cryptographic properties of CT files make it easy to detect
> misbehavior.
>
> 3. Denying someone the right to make further writes to the CT files is not
> disruptive, whereas trying to delete a CA is immensely disruptive, thus the
> threat to withdraw the privilege to write to CT files for misbehavior is
> far more credible than the threat to take a CA off the browser CA list.
>
> This being so, why should we care about CA signatures?  If a certificate
> is in the CT files, that is far more credible evidence of being a good
> certificate than if it is signed by a CA.  Let us allow all domain name
> registrars to write to the CT files, conditional, of course, on correct
> behavior.


I think if you want this system, the appropriate vehicle is DNSSEC. A
variant on CT for DNSSEC is clearly possible, and I hope my team can start
working on that soon. We're a little busy right now, though.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131116/9bdc28a6/attachment.html>