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
