[148191] in cryptography@c2.net mail archive
Re: [Cryptography] Moving forward on improving HTTP's security
daemon@ATHENA.MIT.EDU (Ben Laurie)
Sat Nov 16 15:52:48 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <5285B904.3030308@echeque.com>
Date: Sat, 16 Nov 2013 10:29:30 +0000
From: Ben Laurie <ben@links.org>
To: "jamesd@echeque.com" <jamesd@echeque.com>
Cc: Cryptography Mailing List <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============3101824761203837627==
Content-Type: multipart/alternative; boundary=047d7ba97a944399dc04eb48ca0f
--047d7ba97a944399dc04eb48ca0f
Content-Type: text/plain; charset=ISO-8859-1
On 15 November 2013 06:02, James A. Donald <jamesd@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.
--047d7ba97a944399dc04eb48ca0f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><br><div class=3D"gmail=
_quote">On 15 November 2013 06:02, James A. Donald <span dir=3D"ltr"><<a=
href=3D"mailto:jamesd@echeque.com" target=3D"_blank">jamesd@echeque.com</a=
>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"im">On 2013-11-15 05:50, Tony =
Arcieri wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
And what of other solutions like CT or Tack?<br>
</blockquote>
<br></div>
With CT, when your browser hits a site, gets a certificate, it needs to che=
ck if the certificate is in a CT file, which is cryptographically secured t=
o be the same for everyone.<br></blockquote><blockquote class=3D"gmail_quot=
e" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But, if you have check each newly encountered certificate in real time, why=
does it need the CA's signature? =A0(Other than to avoid threatening t=
he CA business model.)<br></blockquote><div><br></div><div>This is not how =
CT works, the check is asynchronous: you get a signature from a log along w=
ith the certificate, and you later check that the log was honest. That is, =
trust but verify.</div>
<div><br></div><div>Synchronous checks would be nice, but the failure rate =
is too high. Even if it weren't, the extra latency is also a problem.</=
div><div><br></div><div>CT is a careful compromise that balanced deployabil=
ity with effectiveness. Once it is in place, I'm sure we'll start w=
orking on compromises that move the needle towards even higher security at =
the cost of slower deployment.</div>
<div><br></div><div>For example, revocation is often cited as a problem. I =
agree. But to solve it without introducing other problems, we need to chang=
e servers. Changing _all_ servers takes around a decade.</div><div>=A0</div=
>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
The social mechanism underlying CT is:<br>
<br>
1. not everyone is allowed to write to the CT files. =A0It is a valuable pr=
ivilege.<br>
<br>
2. the cryptographic properties of CT files make it easy to detect misbehav=
ior.<br>
<br>
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 f=
ar more credible than the threat to take a CA off the browser CA list.<br>
<br>
This being so, why should we care about CA signatures? =A0If a certificate =
is in the CT files, that is far more credible evidence of being a good cert=
ificate than if it is signed by a CA. =A0Let us allow all domain name regis=
trars to write to the CT files, conditional, of course, on correct behavior=
.</blockquote>
<div><br></div><div>I think if you want this system, the appropriate vehicl=
e 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, tho=
ugh.</div>
<div><br></div></div></div></div>
--047d7ba97a944399dc04eb48ca0f--
--===============3101824761203837627==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
--===============3101824761203837627==--
