[147043] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd:

daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Wed Sep 11 16:43:03 2013

X-Original-To: cryptography@metzdowd.com
In-Reply-To: <20130911184052.CB894DD09@a-pb-sasl-quonix.pobox.com>
Date: Wed, 11 Sep 2013 15:44:49 -0400
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Bill Stewart <bill.stewart@pobox.com>
Cc: Cryptography Mailing List <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com

--===============0930018642910005741==
Content-Type: multipart/alternative; boundary=089e011827aeb335b104e620da03

--089e011827aeb335b104e620da03
Content-Type: text/plain; charset=ISO-8859-1

On Wed, Sep 11, 2013 at 2:40 PM, Bill Stewart <bill.stewart@pobox.com>wrote:

> At 10:39 AM 9/11/2013, Phillip Hallam-Baker wrote:
>
>> Perfect Forward Secrecy is not perfect. In fact it is no better than
>> regular public key. The only difference is that if the public key system is
>> cracked then with PFS the attacker has to break every single key exchange
>> and not just the keys in the certificates and if you use an RSA outer with
>> an ECC inner then you double the cryptanalytic cost of the attack (theory
>> as well as computation).
>>
>
> I wouldn't mind if it had been called Pretty Good Forward Secrecy instead,
> but it really is a lot better than regular public key.
>

My point was that the name is misleading and causes people to look for more
than is there. It took me a long time to work out how PFS worked till I
suddenly realized that it does not deliver what is advertised.



> The main difference is that cracking PFS requires breaking every single
> key exchange before the attack using cryptanalysis, while cracking the RSA
> or ECC outer layer can be done by compromising the stored private key,
> which is far easier to do using subpoenas or malware or rubber hoses than
> cryptanalysis.
>

That is my point precisely.

Though the way you put it, I have to ask if PFS deserves higher priority
than Certificate Transparency. As in something we can deploy in weeks
rather than years.

I have no problem with Certificate Transparency. What I do have trouble
with is Ben L.'s notion of Certificate Transparency and Automatic Audit in
the End Client which I imposes a lot more in the way of costs than just
transparency and moreover he wants to push out the costs to the CAs so he
can hyper-tune the performance of his browser.


-- 
Website: http://hallambaker.com/

--089e011827aeb335b104e620da03
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 Wed, Sep 11, 2013 at 2:40 PM, Bill Stewart <span dir=3D"ltr">&lt=
;<a href=3D"mailto:bill.stewart@pobox.com" target=3D"_blank">bill.stewart@p=
obox.com</a>&gt;</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">At 10:39 AM 9/11/2013, Phi=
llip Hallam-Baker wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Perfect Forward Secrecy is not perfect. In fact it is no better than regula=
r public key. The only difference is that if the public key system is crack=
ed then with PFS the attacker has to break every single key exchange and no=
t just the keys in the certificates and if you use an RSA outer with an ECC=
 inner then you double the cryptanalytic cost of the attack (theory as well=
 as computation).<br>

</blockquote>
<br></div>
I wouldn&#39;t mind if it had been called Pretty Good Forward Secrecy inste=
ad, but it really is a lot better than regular public key.<br></blockquote>=
<div><br></div><div>My point was that the name is misleading and causes peo=
ple to look for more than is there. It took me a long time to work out how =
PFS worked till I suddenly realized that it does not deliver what is advert=
ised.</div>
<div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The main difference is that cracking PFS requires breaking every single key=
 exchange before the attack using cryptanalysis, while cracking the RSA or =
ECC outer layer can be done by compromising the stored private key, which i=
s far easier to do using subpoenas or malware or rubber hoses than cryptana=
lysis.<br>
</blockquote><div><br></div><div>That is my point precisely.</div><div><br>=
</div><div>Though the way you put it, I have to ask if PFS deserves higher =
priority than Certificate Transparency. As in something we can deploy in we=
eks rather than years.</div>
<div><br></div><div>I have no problem with Certificate Transparency. What I=
 do have trouble with is Ben L.&#39;s notion of Certificate Transparency an=
d Automatic Audit in the End Client which I imposes a lot more in the way o=
f costs than just transparency and moreover he wants to push out the costs =
to the CAs so he can hyper-tune the performance of his browser.</div>
</div><br clear=3D"all"><div><br></div>-- <br>Website: <a href=3D"http://ha=
llambaker.com/">http://hallambaker.com/</a><br>
</div></div>

--089e011827aeb335b104e620da03--

--===============0930018642910005741==
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
--===============0930018642910005741==--

home help back first fref pref prev next nref lref last post