Hi, all!
Previously, I had set the deadline for merging small features into 0.2.3.x as Jan 6. Due to work that had piled up or suddenly appeared in the new year, I wasn't able to get patches reviewed this week as much as I wanted, so I'm going to push the small-feature merge window back to Jan 13.
This is the deadline for me to merge stuff, not for stuff to get submitted: I probably will not consider any patches where the first version is submitted after Monday, unless they are surprisingly tiny and obviously correct.
Barring exceptional circumstances, any large features must wait for 0.2.4.x, as must any features that don't get merged by Friday. Once this window closes, only bugfixes will be okay for 0.2.3.x. As before, I'm going to leave the definitions of "exceptional", "large", and "feature" a little vague, and err on the side of getting a good 0.2.3.x release candidate done soon.
happy hacking,
On Thu, Jan 5, 2012 at 5:05 PM, Nick Mathewson nickm@torproject.org wrote:
Hi, all!
Previously, I had set the deadline for merging small features into 0.2.3.x as Jan 6. Due to work that had piled up or suddenly appeared in the new year, I wasn't able to get patches reviewed this week as much as I wanted, so I'm going to push the small-feature merge window back to Jan 13.
This is the deadline for me to merge stuff, not for stuff to get submitted: I probably will not consider any patches where the first version is submitted after Monday, unless they are surprisingly tiny and obviously correct.
I just did an initial triage over all Tor tickets that are in state "needs_review" in the bugtracker. If your ticket is not tagged with "small-feature," or it is not in state "needs_review", then it is not on my list of small features to review and merge (or not) by Friday. If I missed something, please let me know!
This was not a triage over bug reports; only feature patches... so don't worry if there's a pending bugfix (or pending bug) that I didn't tag. For my next round of triage, I'll take all remaining tickets that look like a feature request to me, and remove them from the 0.2.3.x milestone.
yrs,
On 01/09/2012 04:33 PM, Nick Mathewson wrote:
On Thu, Jan 5, 2012 at 5:05 PM, Nick Mathewson nickm@torproject.org wrote:
Hi, all!
Previously, I had set the deadline for merging small features into 0.2.3.x as Jan 6. Due to work that had piled up or suddenly appeared in the new year, I wasn't able to get patches reviewed this week as much as I wanted, so I'm going to push the small-feature merge window back to Jan 13.
This is the deadline for me to merge stuff, not for stuff to get submitted: I probably will not consider any patches where the first version is submitted after Monday, unless they are surprisingly tiny and obviously correct.
I just did an initial triage over all Tor tickets that are in state "needs_review" in the bugtracker. If your ticket is not tagged with "small-feature," or it is not in state "needs_review", then it is not on my list of small features to review and merge (or not) by Friday. If I missed something, please let me know!
This was not a triage over bug reports; only feature patches... so don't worry if there's a pending bugfix (or pending bug) that I didn't tag. For my next round of triage, I'll take all remaining tickets that look like a feature request to me, and remove them from the 0.2.3.x milestone.
Hey Nick,
My old prop 179 branch has largely been merged but I realize now that one key change hasn't - it's the two line change at the top of crypto.h - basically it sets the TLS public key modulus to be 2048:
+/** Length of our TLS keys. */ +#define TLS_PK_BYTES 2048
And later:
+ if (crypto_pk_generate_key_with_bits(rsa,TLS_PK_BYTES)<0)
I made this change and it worked fine - the major objection is that the DH parameter isn't 2048 bits.
I rather think that we should make the 2048bit rsa key change and also the DH change. I propose that I hack up crypto_generate_dynamic_dh_modulus to use a 2048bit modulus. That way, we'll have by default, a 2048bit key for TLS and a 1024bit DH right away and if you flip the random DH option, you'll also get a 2048bit DH. And in the future, I propose that we flip the random DH option by default.
Should I make such a branch and request it for review?
All the best, Jake
On Mon, Jan 9, 2012 at 8:49 PM, Jacob Appelbaum jacob@appelbaum.net wrote:
Should I make such a branch and request it for review?
I don't think this is a good idea for 0.2.3.x without data. Specifically:
* What fraction of servers on the net right now use 2048-bit RSA link keys and 2048-bit DH groups? (Or 1024 bit RSA keys and 1536-bit DH keys, etc) * How much would this slow down typical clients and servers?
From a security POV, increasing the link key modulus size of 2048 bits
doesn't seem to do anything useful. If somebody wants to decrypt an intercepted communication, the DH g^x value is what they need to solve. OTOH, if we want to stop somebody from *impersonating* a server, then using a 2048-bit link key wouldn't do any good: factoring the identity key would give equally good results.
So I think unless we can make identity keys larger, increasing link key size doesn't help. And without analysis, making the above changes on this timeframe seems like a worrying idea.
So my thought is that we should target 0.2.4.x for this kind of thing, and do it properly.
yrs,
On 01/09/2012 06:01 PM, Nick Mathewson wrote:
On Mon, Jan 9, 2012 at 8:49 PM, Jacob Appelbaum jacob@appelbaum.net wrote:
Should I make such a branch and request it for review?
I don't think this is a good idea for 0.2.3.x without data. Specifically:
- What fraction of servers on the net right now use 2048-bit RSA
link keys and 2048-bit DH groups? (Or 1024 bit RSA keys and 1536-bit DH keys, etc)
All new EV certs must be 2048-bit RSA - generally speaking, they all use 1024-bit DH groups or a different default provided by the web server software.
- How much would this slow down typical clients and servers?
That's a good question - how shall we answer that?
From a security POV, increasing the link key modulus size of 2048 bits
doesn't seem to do anything useful. If somebody wants to decrypt an intercepted communication, the DH g^x value is what they need to solve. OTOH, if we want to stop somebody from *impersonating* a server, then using a 2048-bit link key wouldn't do any good: factoring the identity key would give equally good results.
I want to stop sniffers from having useful data. A 2048-bit link key with a 2048-bit DH group seems like a fine idea and seems to be far beyond the current reach of anything public - whereas 1024bit seems less than perfect in short order...
So I think unless we can make identity keys larger, increasing link key size doesn't help. And without analysis, making the above changes on this timeframe seems like a worrying idea.
I think that is only true for active attacks.
So my thought is that we should target 0.2.4.x for this kind of thing, and do it properly.
Ok. I suppose the good news is that this is all server side. So we really only need a few thousand servers to upgrade rather than millions of clients, right?
All the best, Jake
On Mon, Jan 9, 2012 at 9:13 PM, Jacob Appelbaum jacob@appelbaum.net wrote:
On 01/09/2012 06:01 PM, Nick Mathewson wrote:
On Mon, Jan 9, 2012 at 8:49 PM, Jacob Appelbaum jacob@appelbaum.net wrote:
Should I make such a branch and request it for review?
I don't think this is a good idea for 0.2.3.x without data. Specifically:
* What fraction of servers on the net right now use 2048-bit RSA link keys and 2048-bit DH groups? (Or 1024 bit RSA keys and 1536-bit DH keys, etc)
All new EV certs must be 2048-bit RSA - generally speaking, they all use 1024-bit DH groups or a different default provided by the web server software.
Well, we can't forge EV certs, so we should probably instead be looking at the fraction of 2048 non-EV certs out there.
Also, having longer RSA keys than DH groups is totally backwards for our needs. We'd like the work factor for breaking forward-secrecy to be pretty high, since it's relevant for longer, whereas the work factor for impersonating a server is less important, since we can move to longer keys later.
I wonder if EFF's SSL observatory has data here.
* How much would this slow down typical clients and servers?
That's a good question - how shall we answer that?
Testing or calculation, I'd guess.
From a security POV, increasing the link key modulus size of 2048 bits
doesn't seem to do anything useful. If somebody wants to decrypt an intercepted communication, the DH g^x value is what they need to solve. OTOH, if we want to stop somebody from *impersonating* a server, then using a 2048-bit link key wouldn't do any good: factoring the identity key would give equally good results.
I want to stop sniffers from having useful data. A 2048-bit link key with a 2048-bit DH group seems like a fine idea and seems to be far beyond the current reach of anything public - whereas 1024bit seems less than perfect in short order...
For beating passive observer, it's the DH group size that matters.
[...]
So my thought is that we should target 0.2.4.x for this kind of thing, and do it properly.
Ok. I suppose the good news is that this is all server side. So we really only need a few thousand servers to upgrade rather than millions of clients, right?
Sounds right. Though really, we should also be looking into similar increases in key strength for our other crypto too, particularly our circuit handshake. My new-crypto-ops draft tried to make progress here; I should try to revise it soon.
cheers,
-
Jacob Appelbaum -
Nick Mathewson -
Nick Mathewson