-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Kurt,
Am 04.07.2014 00:41, schrieb Kurt Roeckx: > On Thu, Jul 03, 2014 at 11:42:08PM +0200, Wilfried Klaebe wrote: >> Am Thu, Jul 03, 2014 at 07:20:46PM +0200 schrieb Kurt Roeckx: >>> On Thu, Jul 03, 2014 at 08:08:52AM -0400, Hubert Kario wrote: >>>> ----- Original Message ----- >>>>> From: "Benny Baumann" <be...@geshi.org> To: >>>>> openbsd-t...@openbsd.org, openssl-dev@openssl.org Sent: >>>>> Wednesday, 2 July, 2014 8:49:18 PM Subject: [PATCH] >>>>> LibReSSL/OpenSSL: Adjust/remove keysize restrictions >>>>> >>>>> Hi folks, >>>>> >>>>> I know the following patches will cause a controversy just >>>>> like the issues they resolve caused me and several other >>>>> people headaches when debugging them. >>>>> >>>>> But first things first. The attached patches >>>>> (intentionally) do the following two things: >>>>> >>>>> 1. Adjust the limit for maximum allowed size of a received >>>>> public key to be increased from 516 bytes (just barely >>>>> enough for 4 KBit RSA public keys) up to 8200 bytes (enough >>>>> for 64KBit RSA keys with some minor margin) >>>>> >>>>> 2. Remove the crippling of the DH/DSA routines for working >>>>> with at most 10kBit parameters. >>>> >>>> Current general recommendation is that if you require more >>>> than 128 bit security you shouldn't be using RSA or DHE in >>>> the first place but use ECC. >> >> You'd need someone signing your ECC certificates though. > > There are CAs doing ECC certificates. I see about 100 that trace > back to the mozilla certificate store. They might not be popular, > but it does exist and is being used. Sure. But still people are free to choose their CA for other parameters. Also people ARE using 8192 RSA certificates in the wild and with server certificates this is no problem. Currently things break horrible with client certificates of this size - for NO good reason. > >>>> Just generating 16k DH params takes inordinate amount of >>>> time. With 4096 bit DH parameters I'm getting less than 20 >>>> key exchanges a second with a fast i7 CPU. I'd hazard a guess >>>> that with 16k DH you'll be able to do less than 1 key >>>> exchange a second. >>>> >>>> That's a very neat way to DoS your server. >> >> That's why Benny suggested making the limit configurable instead >> of flatly raising it. > > But the patch just raises the limit to something I think you > shouldn't consider using. If you read my first mail you /might/ have found a paragraph stating that I'm well open for discussion given one of two things is honored with the choosen solution: 1. Either do a fix limit at 65536 Bit (as it's now) 2. OR do a dynamic limit with a default at the next level above the currently wide used size (8192 Bit) With the first option I offered a limit as low as 16384 Bit which unfortunately due to it's implementation affects all public keys transmitted to the server. Not fixing this means having inconsistent behaviour between RSA and DSA when both offer similar strength - DSA being limited at 10k while RSA breaking at 4k. By adjusting the limit you could get this to at least be consistently breaking at 16k regardless of whether you use RSA or DSA. Unfortunately adjusting DSA also involves adjusting DH, because the limit is implemented *in*the*bignum*library* - one of the worst places to do so. That's why I said DSA/DH is crippled: You just might want to allow arbitrary sizes for keys in the offline case and limit things in the online case - if you are at arguing with the "performance" part of things. > >>> According to the NIST recommendations >>> (http://www.keylength.com/en/4/), 16384 bit would be close to >>> the 15360 bit if you want to reach the 256 bit level. >>> >>> But there currently is no way to reach the 256 level with TLS >>> as far as I know. The best you can currently do is 192 bit, >>> which The most you can get is 192 Bit using SHA384 based ciphers with either RSA, DSA or EC curve P-571. >>> would be a 7680 assymetric key. So I think that anything >>> above 8192 bit doesn't make any sense at the moment. Granted. 8k is the max I currently use and what I have seen in the wild - but 8192 bit IS being used to a point where it starts to matter. >> >> Considering that #319 is unresolved for nearly 12 years now, and >> part 1 of this patch would at least mitigate that one for quite >> some time into the future, could the OpenSSL Project please apply >> at least that one really soon now, please? > > It got applied 12 years ago? Just not to the limit you want now. Nope. It was fixed in 2004 earliest if I read the comments in that ticket correctly. And even then it took them TWO YEARs two change one number holding everyone back Wouldn't it be better to be proactive here and be one step ahead by allowing 8192 Bit certificates if people really want to use them (and I WANT to use them). The current limit is breaking software and thus it IS a bug. > > > Kurt > > ______________________________________________________________________ > > OpenSSL Project http://www.openssl.org > Development Mailing List > openssl-dev@openssl.org Automated List Manager > majord...@openssl.org > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCgAGBQJTtmofAAoJEPHTXLno4S6txAEQALUGuJslY1pvusX0CUiGzQxd d+XCzSz/Sx7ViV5vDkpMKRumtfDIITYr1PIKC5a8TTUjpd4XpOIlPXDj6Q+Pr+pD TWML4V8oP/GHNWLc1WL6d2swamFTdUVgP8QDpleRLn9zLTXneu36GbhbGVmQTXPO Wswa6nwKMLLQG4KFZdT+xS7/czkfL8beoLbnay+vOn80IQYd7gPCT0UHHHl/A6PR aVUmerVoV9LndkePXOthVRIwXFWuldN40qUUeDcZo9hGpjpEuTycRmdFMg5Xwuuo hd87wAx0IwoYx/3GtLxmDnAyJVK78uACUvtIcmv2gC8zC10DpCr3lD+nx3xQY6PH 49TJhsq0GDj1FSK8YyGmFYjlS38I5Xy1JpxVIsnWAeV0kxCLcD08Y/ahP1WPCWnO kJdl7iWfkJYjf6/UQPHzJZkk/McUWOmb3vstmOEtNTsbWh/qfSzXe1ThECKucf9Q P8Ux2c/PiCBCrpaZx8ARbUcaKvx5omdbdiXuMXYBUpCpgYAVuZ8s1iAjLrSSXjN7 NYwht4pcjamNYpKaH55XueYDXl2IBFD2wTf3FduTs0+5Xx+r4ZmdBxkWpz+aUuFq 7vDinkCT2h20Brz7hkTppA8r9+RqWKNsVbOHT8oq4w69ydFFmIvi1xVfoz8CGEB9 cjxRlBahEColQMC6kOlv =IXrD -----END PGP SIGNATURE----- ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
