On 08/23/2013 02:03 AM, Gervase Markham wrote:
On 22/08/13 19:21, Robert Relyea wrote:
The attack profile protection of PFS versus non-PFS is basically two points:
1) some government agency could force a server to give up it's private
keys and decrypt all the traffic sent to that server. But we already
know that government agencies with such power simply ask for the the
data on the server.
2) some well funded attacker could spend the resources to attack the
server's private key and get all the traffic sent to it. However, we
don't actually check to see that the server is giving us a unique key in
the ephemeral case. A way to cut some of the server cost of DHE/ECDHE is
to generate a single them key as use it for all connections. We have
know way of knowing the server is doing this, which brings back this
particular attack.
3) Someone who has captured some or all of the traffic could use a 0-day
to get into the server and pinch the private key.
This sort of thing is much more likely if the victim is a person of
noteworthiness and the attacker is a government (perhaps that person's
government), but is not the government of the jurisdiction where the
server is based.
This has the same characteristics as 1. Once in the server, it's more
likely the attacker will fetch the data at rest than try to decrypt
recorded SSL connection. Once the private key is pinched, future
connections are vulnerable even if they are PFS.
As for 2), there are lots of ways a server can sabotage a
seemingly-encrypted connection if it chooses. Why is this one special?
Most ways the server could sabotage the connection are detectable to the
client. I'm also pointing out that PFS is not a panacea. It's often
touted as such, but it's relatively easy to defeat.
To be clear, I'm not against PFS, and I don't disagree that it should be
placed forward, what I am pointing out is that any argument based on
performance to put 128 over 256 is completely ignoring the fact that PFS
is at least 3 times as expensive as the equivalent non-PFS algorithms
for only marginal theoretic security enhancement.
I think we need to be consistent in our choices here (of course as a
security guy, I'm quite happy with security over performance as the
default).
bob
smime.p7s
Description: S/MIME Cryptographic Signature
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
