From mboxrd@z Thu Jan 1 00:00:00 1970 From: IT Superhack To: development@lists.ipfire.org Subject: Re: [PATCH] Mark recommended ciphers/algorithms Date: Sun, 13 Dec 2015 16:10:13 +0100 Message-ID: <566D8A55.3070402@web.de> In-Reply-To: <1449767773.31655.108.camel@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1033253826930666068==" List-Id: --===============1033253826930666068== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Hello Michael, Michael Tremer: > Hello, > > this patch was line-wrapped and cannot be merged, but nevertheless, > here are my thoughts: I am unable to submit patches at the moment, since git send-email keeps crashing on every machine I own - sometimes starttls issues, sometimes segfault - and TB seems to line-wrap. > > On Mon, 2015-12-07 at 17:35 +0100, IT Superhack wrote: >> Signed-off-by: Timmothy Wilson >> --- >> diff --git a/html/cgi-bin/ovpnmain.cgi b/html/cgi-bin/ovpnmain.cgi >> index 62af54e..15385f1 100644 >> --- a/html/cgi-bin/ovpnmain.cgi >> +++ b/html/cgi-bin/ovpnmain.cgi >> @@ -1316,7 +1316,7 @@ END >> >> >> >> - >> + >> >> >> > > I agree, that it is desirable to use longer keys. However, I am not > sure if it is a good idea to go all the way for 4096 bit and not only > for e.g. 2048 bit. Why not 8192 even? > Since the SSLTest server page treats 2048 DH primes as "weak", I guess 3072 or better is suitable here. > I would like to read some justification for the values that are picked. Here is one, for example: https://netzpolitik.org/2015/kryptographie-open-source-und-gesellschaft/ (german, please see "8."). In this article is also mentioned that 512 bit hash algorithms should be used. > > Furthermore, I think that we the upper bound should be something that > the average IPFire box is able to handle. I agree with that. Maybe 3072 bits is a good deal between speed and security, what do you think? > >> @@ -4687,7 +4687,7 @@ if ($cgiparams{'TYPE'} eq 'net') { >> >> >> >> - >> + >> >> >> > > I can agree with that since it is already selected by default. This > makes it just more explicit. > > I would have merged this if this was an independent patch in a patch > set. Thanks, but at the moment, i cannot hand in a patch without wrapped lines. > >> @@ -4702,7 +4702,7 @@ if ($cgiparams{'TYPE'} eq 'net') { >> $Lang::tr{'ovpn ha'}: >> >> - >> + >> >> >> > > Why should IKEv2 be recommended? AFAIK there are no known design issues > with IKEv1. Some algorithms might not be available, but this is not an > issue for now since AES, SHA2, (AKA the strong ones) are supported. > >> @@ -2434,7 +2434,7 @@ if(($cgiparams{'ACTION'} eq >> $Lang::tr{'advanced'}) || >> > width="15%">$Lang::tr{'encryption'} >> >> > multiple='multiple' size='6' >> style='width: 100%'> >> - >> + >> >> >> > > Why are the AES-GCM cipher suites with smaller IVs not recommended? > >> @@ -2478,7 +2478,7 @@ if(($cgiparams{'ACTION'} eq >> $Lang::tr{'advanced'}) || >> > width="15%">$Lang::tr{'integrity'} >> >> > multiple='multiple' size='6' >> style='width: 100%'> >> - >> + >> >> >> > > Same again. There seems to be a problem with the word "recommended". In the patches submitted, I recommended always the most strongest cipher. However, as you said, some of them are simply one step too much. Should then both be recommended? In my opinion, this has to be clarified, but since it is a very subjective thing, it might be difficult. > >> diff --git a/langs/de/cgi-bin/de.pl b/langs/de/cgi-bin/de.pl >> index 2bca854..b18cace 100644 >> --- a/langs/de/cgi-bin/de.pl >> +++ b/langs/de/cgi-bin/de.pl >> @@ -1914,6 +1914,7 @@ >> 'rebooting ipfire' => 'Starte IPFire neu', >> 'reconnect' => 'Neu Verbinden', >> 'reconnection' => 'Wiederverbindung', >> +'recommended' => 'empfohlen', >> 'red' => 'Internet', >> 'red1' => 'ROT', >> 'references' => 'Referenzen', >> >> > > The English translation is missing. Oh, sorry, I forgot. > > Best, > -Michael > Best regards, Timmothy Wilson --===============1033253826930666068== Content-Type: application/pgp-signature Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="signature.asc" MIME-Version: 1.0 LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KCmlRRWNCQUVCQ2dBR0JRSldiWXBqQUFvSkVP eUxhMUM1RWF6cjJVUUlBSTlvamcwcCtpNHZlQm41VEhxM0JHNlIKeXJuRkxRWGdWMis0VFcrVytL c01sbytrbXlQWHpxY3hkWGxhczJ0aFBoWXp1V0cxKzJ6Zmg1WDdQR0lRL2J6UAo0Z20vNDUrMkVm SkhUbm91NXNGeFdvRlhXTTBORGRUcmNxSjRXTTNLckVENW9oZFpLa3cvQk8rYXZ6N0k3S3VBCmY5 Y2lwTWd4M2FrZHRXdExkNVpJUHpQS21KY05SdFByRUFQMnpsd1JFRnByUjk4ODhVanNmUHQ5N0M3 THNGTTEKK2I2VDM4T3NRQ2I2WkdPMmZkZHQ3R29IRmlKek5kUjdaZzF5UWx0RUtWT0JZZjg4UlUz aTJWNTlHMjdTY05rUgpRNVRzOC9ibDc4RkpBV0xnV2hJZVJleTNzTjhtZC9ISHBla0h0OFF4N1NJ MWxQZnllWGRmRWJOZFQrSTgxQVU9Cj1maU1NCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQo= --===============1033253826930666068==--