[147033] in cryptography@c2.net mail archive
Re: [Cryptography] People should turn on PFS in TLS (was Re: Fwd:
daemon@ATHENA.MIT.EDU (Phillip Hallam-Baker)
Wed Sep 11 13:49:38 2013
X-Original-To: cryptography@metzdowd.com
In-Reply-To: <20130911055905.B286BE6FD@a-pb-sasl-quonix.pobox.com>
Date: Wed, 11 Sep 2013 13:39:40 -0400
From: Phillip Hallam-Baker <hallam@gmail.com>
To: Bill Stewart <bill.stewart@pobox.com>
Cc: james hughes <hughejp@mac.com>, "Perry E. Metzger" <perry@piermont.com>,
Peter Fairbrother <zenadsl6186@zen.co.uk>,
Cryptography Mailing List <cryptography@metzdowd.com>
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
--===============3459679347706319125==
Content-Type: multipart/alternative; boundary=001a11c349321e3fb204e61f1bc8
--001a11c349321e3fb204e61f1bc8
Content-Type: text/plain; charset=ISO-8859-1
On Tue, Sep 10, 2013 at 3:56 PM, Bill Stewart <bill.stewart@pobox.com>wrote:
> At 11:33 AM 9/6/2013, Peter Fairbrother wrote:
>
>> However, while the case for forward secrecy is easy to make, implementing
>> it may be a little dangerous - if NSA have broken ECDH then
>> using it only gives them plaintext they maybe didn't have before.
>>
>
> I thought the normal operating mode for PFS is that there's an initial
> session key exchange (typically RSA) and authentication,
> which is used to set up an encrypted session, and within that session
> there's a DH or ECDH key exchange to set up an ephemeral session key,
> and then that session key is used for the rest of the session.
> If so, even if the NSA has broken ECDH, they presumably need to see both
> Alice and Bob's keyparts to use their break,
> which they can only do if they've cracked the outer session (possibly
> after the fact.)
> So you're not going to leak any additional plaintext by doing ECDH
> compared to sending the same plaintext without it.
One advantage of this approach is that we could use RSA for one and ECC for
the other and thus avoid most consequences of an RSA2048 break (if that is
possible).
The problem I see reviewing the list is that ECC has suddenly become
suspect and we still have doubts about the long term use of RSA.
It also have the effect of pushing the ECC IPR concerns off the CA and onto
the browser/server providers. I understand that many have already got
licenses that allow them to do what they need in that respect.
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 think this is the way forward.
--
Website: http://hallambaker.com/
--001a11c349321e3fb204e61f1bc8
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 Tue, Sep 10, 2013 at 3:56 PM, Bill Stewart <span dir=3D"ltr"><=
;<a href=3D"mailto:bill.stewart@pobox.com" target=3D"_blank">bill.stewart@p=
obox.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">At 11:33 AM 9/6/2013, Pete=
r Fairbrother wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
However, while the case for forward secrecy is easy to make, implementing i=
t may be a little dangerous - if NSA have broken ECDH then<br>
using it only gives them plaintext they maybe didn't have before.<br>
</blockquote>
<br></div>
I thought the normal operating mode for PFS is that there's an initial =
session key exchange (typically RSA) and authentication,<br>
which is used to set up an encrypted session, and within that session there=
's a DH or ECDH key exchange to set up an ephemeral session key,<br>
and then that session key is used for the rest of the session.<br>
If so, even if the NSA has broken ECDH, they presumably need to see both Al=
ice and Bob's keyparts to use their break,<br>
which they can only do if they've cracked the outer session (possibly a=
fter the fact.)<br>
So you're not going to leak any additional plaintext by doing ECDH comp=
ared to sending the same plaintext without it.</blockquote></div><div class=
=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div>One advanta=
ge of this approach is that we could use RSA for one and ECC for the other =
and thus avoid most consequences of an RSA2048 break (if that is possible).=
</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">The problem=
I see reviewing the list is that ECC has suddenly become suspect and we st=
ill have doubts about the long term use of RSA.</div><div class=3D"gmail_ex=
tra">
<br></div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I=
t also have the effect of pushing the ECC IPR concerns off the CA and onto =
the browser/server providers. I understand that many have already got licen=
ses that allow them to do what they need in that respect.</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Perfect For=
ward Secrecy is not perfect. In fact it is no better than regular public ke=
y. The only difference is that if the public key system is cracked then wit=
h 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 computa=
tion).</div>
<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra"><br></div><=
div class=3D"gmail_extra">I think this is the way forward.</div><div class=
=3D"gmail_extra"><div><br></div>-- <br>Website: <a href=3D"http://hallambak=
er.com/">http://hallambaker.com/</a><br>
</div></div>
--001a11c349321e3fb204e61f1bc8--
--===============3459679347706319125==
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
--===============3459679347706319125==--
