Re: [cryptography] [Ach] Better Crypto
Hi Peter, hi list, On Jan 16, 2014, at 1:13 PM, Peter Gutmann wrote: > "L. Aaron Kaplan" writes: > >> So, Peter, how about this approach? > > Sorry about the delayed reply, too much other stuff on my plate at the > moment... > >> 1. We will have three config options: cipher String A,B,C ( generic safe >> config, maximum interoperability (== this also makes the mozilla people happy >> then) and finally a super-hardened setting (with reduced compatibility)). >> Admins will get a choice and explanations on when to use which option. > > That sounds good. > okay. We'll discuss this at the next meeting of co-writers then . >> 3. we give people a config generator tool on the webpage which gives them >> snippets which they can include into their webservers, mailservers etc. The >> tool also shows admins (color codes?) which settings are compatible, unsafe >> etc. > > Now that would be very useful. > :) >> 4. In addition to having the config generator on the web page, the config >> snippets are moved to the appendix (as you suggested). The theory section >> moves up. > > Yup, good idea. The single-location-for-config solves the problem of having a > cut&paste of the same (or possibly somewhat out-of-sync when the doc is > updated) text in a dozen or more locations. > same comment applies: I'll discuss this with the co-writers. We skipped the meeting the last Monday and there are many pull requests and change requests in the queue. So, we'll have to resume working on the draft version soon. Thanks very much for your great input and comments! Aaron. --- // L. Aaron Kaplan - T: +43 1 5056416 78 // CERT Austria - http://www.cert.at/ // Eine Initiative der nic.at GmbH - http://www.nic.at/ // Firmenbuchnummer 172568b, LG Salzburg signature.asc Description: Message signed with OpenPGP using GPGMail ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Ach] Better Crypto
"L. Aaron Kaplan" writes: >So, Peter, how about this approach? Sorry about the delayed reply, too much other stuff on my plate at the moment... >1. We will have three config options: cipher String A,B,C ( generic safe >config, maximum interoperability (== this also makes the mozilla people happy >then) and finally a super-hardened setting (with reduced compatibility)). >Admins will get a choice and explanations on when to use which option. That sounds good. >3. we give people a config generator tool on the webpage which gives them >snippets which they can include into their webservers, mailservers etc. The >tool also shows admins (color codes?) which settings are compatible, unsafe >etc. Now that would be very useful. >4. In addition to having the config generator on the web page, the config >snippets are moved to the appendix (as you suggested). The theory section >moves up. Yup, good idea. The single-location-for-config solves the problem of having a cut&paste of the same (or possibly somewhat out-of-sync when the doc is updated) text in a dozen or more locations. Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Ach] Better Crypto
Hi, * Axel Hübl wrote: > I could not agree more. > > Crazy C get's totally against the scope of this document: providing > _relyable_ crypto. > > If someone reads that document and goes for "see, they still list it as > compatible, provide it!" the document lost it's main point. I agree too. Sorry. But that's really not our issue to tackle. If we want to provide a guide for _better_crypto_ we'll need to drop some stuff that eventually breaks compatibility. I'm totally for discussing ECDHE on top of DHE (although curve options as currently implemented in libraries just suck) and SRP (which is a very good scheme in my opinion) - but discussing EOL ciphers like 3DES is somewhat out of scope. After all we want to prompt change in peoples mindset about legacy installations, their security and what should be regarded as safe for customers and users. Nobody has to follow this guide to the letter. Aaron On Tue, Jan 7, 2014 at 1:38 PM, Axel Hübl wrote: > I could not agree more. > > Crazy C get's totally against the scope of this document: providing > _relyable_ crypto. > > If someone reads that document and goes for "see, they still list it as > compatible, provide it!" the document lost it's main point. > > Cheers, > Axel > > On 07.01.2014 13:08, Pepi Zawodsky wrote: > > On 07.01.2014, at 11:55, ianG wrote: > >> Suite C: maximum compatibility > > > > This is what every other guide on the internet already does. We'll > _never_ get to improve the current state if we keep supporting fubared > stuff. If we want the broadest compatibility let's switch back to > plaintext. Works fine with my NCSA Mosaic. :-) > > > > In my opinion Sweet A is where we should be. Yes, this is a > forward-looking setting. It sill shall point the direction everyone should > be headed for. Bravo B is still considered secure as to our best of > knowledge today™ which still supports a wide array of deployed software > without unsafe compromises on the security aspect. > > > > I oppose the introduction of a Crazy C cipher that supports every client > as this scenario would contradict the goal of the project as I see it. > bettercompatibility.org is still available. :-) > > > > Best regards > > Pepi > > ___ > > Ach mailing list > > a...@lists.cert.at > > http://lists.cert.at/cgi-bin/mailman/listinfo/ach > > > > > ___ > Ach mailing list > a...@lists.cert.at > http://lists.cert.at/cgi-bin/mailman/listinfo/ach > > ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Ach] Better Crypto
On Tue, Jan 07, 2014 at 11:39:42AM +0100, L. Aaron Kaplan wrote: > > On Jan 7, 2014, at 11:24 AM, stef wrote: > > > On Tue, Jan 07, 2014 at 11:18:45AM +0100, L. Aaron Kaplan wrote: > >> 1. We will have three config options: cipher String A,B,C ( generic safe > >> config, maximum interoperability (== this also makes the mozilla people > >> happy then) and finally a super-hardened setting (with reduced > >> compatibility)). > > > > lacking the context on > >> this also makes the mozilla people happy then > > There were some discussions on the bettercrypto list regarding also > supporting Windows XP (which means RC4 or 3DES). interesting sudden context switch from mozillans to microsoft-victims. a distraction? > And there was a very good argument that a *lot* of people still use XP and > for many sites it is not an option to exclude them. On the other hand, WinXP > is end of life. It's a hard choice for you it's an easy choice. your products only feature is to provide security, if you forfeit that feature for interoperability, then you have not achieved anything. i'd start looking into who actually proposed that, and what are his intelligence agency or corporate ties. this all sounds to me like the banking crisis, too-big-to-fail, so let's do some security theater, but otherwise leave all the downgrade attack paths open. > So, I guess that was a really good reason and personally I don't see any > reason so far to assume: you have not produced any argument - only a distraction - against that assumption. -- pgp: https://www.ctrlc.hu/~stef/stef.gpg pgp fp: FD52 DABD 5224 7F9C 63C6 3C12 FC97 D29F CA05 57EF otr fp: https://www.ctrlc.hu/~stef/otr.txt ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Ach] Better Crypto
On 7/01/14 13:18 PM, L. Aaron Kaplan wrote: None if this is perfect yet of course. One of the very productive feedback results was that we should make a HTML version. A wiki... I would say. 1. We will have three config options: cipher String A,B,C ( generic safe config, maximum interoperability (== this also makes the mozilla people happy then) and finally a super-hardened setting (with reduced compatibility)). Admins will get a choice and explanations on when to use which option. You could call them: Suite A: maximum security, super hard Suite B: general safe Suite C: maximum compatibility ;) or if you're worried about being sued for trademark violation, how abouts: Sweet A, Bravo B, Crazy C! It would be nice if, typographically, we could see them on the page in some easy fashion. Like, A at left, B in middle, C at right, in consistent columns. Or in colours. That way, a sysadm could implement things in C easily, then move from right to left and try things out. Of course, this is only icing on the cake. If it can do B above, general safe, then that is really a step forward for the world. 2. (time-wise) first we focus on some of the weak spots in the guide like the ssh config (client config is missing...), the theory section etc. 3. we give people a config generator tool on the webpage which gives them snippets which they can include into their webservers, mailservers etc. The tool also shows admins (color codes?) which settings are compatible, unsafe etc. 4. In addition to having the config generator on the web page, the config snippets are moved to the appendix (as you suggested). The theory section moves up. I think the config cut&paste sections are what is important. As Peter mentioned. I'd flip that around: Config sections are the bulk. References to theory found in the Appendix, frequent tips that you'll enjoy some theory too. It's an advice guide, not a schoolbook. Would that be more in your line of thinking? Anyway, we will have a authors' meeting today at ~ 19:00 CET and can discuss this. Anyone who wants to join via teleconference: please get in contact with me. We will arrange for remote participation. good luck. I'm missing out on all the fun. Again! iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Ach] Better Crypto
On Jan 7, 2014, at 11:24 AM, stef wrote: > On Tue, Jan 07, 2014 at 11:18:45AM +0100, L. Aaron Kaplan wrote: >> 1. We will have three config options: cipher String A,B,C ( generic safe >> config, maximum interoperability (== this also makes the mozilla people >> happy then) and finally a super-hardened setting (with reduced >> compatibility)). > > lacking the context on >> this also makes the mozilla people happy then There were some discussions on the bettercrypto list regarding also supporting Windows XP (which means RC4 or 3DES). And there was a very good argument that a *lot* of people still use XP and for many sites it is not an option to exclude them. On the other hand, WinXP is end of life. It's a hard choice So, I guess that was a really good reason and personally I don't see any reason so far to assume: > > if that refers to firefox lack of tlsv1.2 support, it's in there starting from > +24, but the mozilla people are still doing everything to maintain my > suspicion of being complicit with the nsa, so it's not advertised and disabled > by default. you can enable this in about:config where you set > security.tls.version.max to 3 > --- // L. Aaron Kaplan - T: +43 1 5056416 78 // CERT Austria - http://www.cert.at/ // Eine Initiative der nic.at GmbH - http://www.nic.at/ // Firmenbuchnummer 172568b, LG Salzburg signature.asc Description: Message signed with OpenPGP using GPGMail ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Ach] Better Crypto
On Tue, Jan 07, 2014 at 11:18:45AM +0100, L. Aaron Kaplan wrote: > 1. We will have three config options: cipher String A,B,C ( generic safe > config, maximum interoperability (== this also makes the mozilla people happy > then) and finally a super-hardened setting (with reduced compatibility)). lacking the context on > this also makes the mozilla people happy then if that refers to firefox lack of tlsv1.2 support, it's in there starting from +24, but the mozilla people are still doing everything to maintain my suspicion of being complicit with the nsa, so it's not advertised and disabled by default. you can enable this in about:config where you set security.tls.version.max to 3 -- pgp: https://www.ctrlc.hu/~stef/stef.gpg pgp fp: FD52 DABD 5224 7F9C 63C6 3C12 FC97 D29F CA05 57EF otr fp: https://www.ctrlc.hu/~stef/otr.txt ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Ach] Better Crypto
On Jan 7, 2014, at 2:34 AM, Peter Gutmann wrote: > "L. Aaron Kaplan" writes: > >>> As a general observation, it also promotes the thinking that all we need to >>> do >>> is choose magic algorithm A instead of magic algorithm B and everything is >>> fixed. >> >> No, if we created that impression then we failed. > > The problem is that as you read through the text you see, again and again, a > large amount of material telling you how to configure algorithms for OpenSSL > (and then to a lesser extent OpenSSH and others). It seems to be the > overriding theme throughout the document. A better option would be to refer > to a single location for this (in an appendix) and then give users a choice: a > generic safe config (disable null, export ciphers, short keys, known-weak, > etc), a maximum-interoperability config (3DES and others), and a super- > paranoid config (AES-GCM-256, Curve25519, etc), with warnings that that's > going to break lots of things. > I like that idea >> That's what we state in the abstract as well as in the disclaimer. > > That assumes that people will read all of that, as well as the theory chapter > that follows. Since the document is laid out as a cookbook, I have the > feeling that most people who just want to get a server up and running will > flip through until they find the bit corresponding to the software they'll be > running and then cut&paste the config lines they find there. Or at least > that's been my experience in maintaining an open-source crypto library for > nearly two decades, the documentation isn't an instruction manual in the usual > sense but a set of code templates ready to cut&paste into a finished app. > Look at the popularity of HOWTOs for any number of how-to-set-up-XYZ issues, > most people just want a cookbook and won't read long, detailed discussions. > Or for that matter any discussion that goes beyond "do this to get it > running". > I agree... that's how most people will read it probably. Unfortunately. As Aaron Zauner already mentioned, we thought about this a lot and ended up with 1. writing a "How to read this guide" section in the beginning including a flowchart 2. moving the theory section to the end (so that people can quickly find the copy & paste section) and 3. always try to pull in the readers interest to follow up in the theory section. None if this is perfect yet of course. One of the very productive feedback results was that we should make a HTML version. So, Peter, how about this approach? 1. We will have three config options: cipher String A,B,C ( generic safe config, maximum interoperability (== this also makes the mozilla people happy then) and finally a super-hardened setting (with reduced compatibility)). Admins will get a choice and explanations on when to use which option. 2. (time-wise) first we focus on some of the weak spots in the guide like the ssh config (client config is missing...), the theory section etc. 3. we give people a config generator tool on the webpage which gives them snippets which they can include into their webservers, mailservers etc. The tool also shows admins (color codes?) which settings are compatible, unsafe etc. 4. In addition to having the config generator on the web page, the config snippets are moved to the appendix (as you suggested). The theory section moves up. Would that be more in your line of thinking? Anyway, we will have a authors' meeting today at ~ 19:00 CET and can discuss this. Anyone who wants to join via teleconference: please get in contact with me. We will arrange for remote participation. Aaron. > Peter. > --- // L. Aaron Kaplan - T: +43 1 5056416 78 // CERT Austria - http://www.cert.at/ // Eine Initiative der nic.at GmbH - http://www.nic.at/ // Firmenbuchnummer 172568b, LG Salzburg signature.asc Description: Message signed with OpenPGP using GPGMail ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Ach] Better Crypto
On 7/01/14 04:34 AM, Peter Gutmann wrote: give users a choice: a generic safe config (disable null, export ciphers, short keys, known-weak, etc), a maximum-interoperability config (3DES and others), and a super- paranoid config (AES-GCM-256, Curve25519, etc), with warnings that that's going to break lots of things. That's a good idea. I wonder if it could be done efficiently? Hmmm... iang ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Ach] Better Crypto
Hi Peter, Peter Gutmann wrote:> > The problem is that as you read through the text you see, again and again, a > large amount of material telling you how to configure algorithms for OpenSSL > (and then to a lesser extent OpenSSH and others). It seems to be the > overriding theme throughout the document. A better option would be to refer > to a single location for this (in an appendix) and then give users a choice: a > generic safe config (disable null, export ciphers, short keys, known-weak, > etc), a maximum-interoperability config (3DES and others), and a super- > paranoid config (AES-GCM-256, Curve25519, etc), with warnings that that's > going to break lots of things. We try to offer two OpenSSL cipher-strings currently: A and B with A being the tinfoil-hat version. Now we need input from people like you, people that run large-traffic sites, develop SSL libraries, Client and Server software and so forth to find a good common ground. We have recently got a lot of useful feedback from e.g. the Firefox crypto team and I'm sure we'll incorporate that into our paper. We're still in a DRAFT stage and intent to update the paper even after our first release regularly since the world of SSL/TLS changes a lot these days. > That assumes that people will read all of that, as well as the theory chapter > that follows. Since the document is laid out as a cookbook, I have the > feeling that most people who just want to get a server up and running will > flip through until they find the bit corresponding to the software they'll be > running and then cut&paste the config lines they find there. Or at least > that's been my experience in maintaining an open-source crypto library for > nearly two decades, the documentation isn't an instruction manual in the usual > sense but a set of code templates ready to cut&paste into a finished app. > Look at the popularity of HOWTOs for any number of how-to-set-up-XYZ issues, > most people just want a cookbook and won't read long, detailed discussions. > Or for that matter any discussion that goes beyond "do this to get it Yup. But that's a issue we won't be able to solve. If serious system engineers can't find the time to read through a paper and it's reasoning but instead look up ubuntuforums than they probably should not be employed to do security critical decisions. We all know that problem very well - some people just wont RTFM - this is also why the paper is pretty terse and has put the configurations in front of the theory part (used to be the other way around). I still have the feeling that such a project is important since you cannot find anything similar on the web that is useful for operations people. Most people end up reusing configuration settings that someone proposed somewhere on github or in an online forum, often without any prior research. Thanks for your input, Aaron signature.asc Description: OpenPGP digital signature ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Ach] Better Crypto
"L. Aaron Kaplan" writes: >> As a general observation, it also promotes the thinking that all we need to >> do >> is choose magic algorithm A instead of magic algorithm B and everything is >> fixed. > >No, if we created that impression then we failed. The problem is that as you read through the text you see, again and again, a large amount of material telling you how to configure algorithms for OpenSSL (and then to a lesser extent OpenSSH and others). It seems to be the overriding theme throughout the document. A better option would be to refer to a single location for this (in an appendix) and then give users a choice: a generic safe config (disable null, export ciphers, short keys, known-weak, etc), a maximum-interoperability config (3DES and others), and a super- paranoid config (AES-GCM-256, Curve25519, etc), with warnings that that's going to break lots of things. >That's what we state in the abstract as well as in the disclaimer. That assumes that people will read all of that, as well as the theory chapter that follows. Since the document is laid out as a cookbook, I have the feeling that most people who just want to get a server up and running will flip through until they find the bit corresponding to the software they'll be running and then cut&paste the config lines they find there. Or at least that's been my experience in maintaining an open-source crypto library for nearly two decades, the documentation isn't an instruction manual in the usual sense but a set of code templates ready to cut&paste into a finished app. Look at the popularity of HOWTOs for any number of how-to-set-up-XYZ issues, most people just want a cookbook and won't read long, detailed discussions. Or for that matter any discussion that goes beyond "do this to get it running". Peter. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Ach] Better Crypto
On Sun, Jan 5, 2014 at 8:10 PM, L. Aaron Kaplan wrote: > Hi coderman, hi Peter, hello cryptography list and ACH list, > >> > (...) > > I have followed your comments on our small project bettercrypto.org (which we > started only in Sept/Okt 2013) with great interest. In fact, comments like > these are very valuable to our project and help us to write a better version. I have posted your work on the Cryptographers and Cryptanalysts group on Linkedin. Here there are so many people interested in the subject, even within academia. Just a different way of extending the knowledge of your work, I love a lot the mailing lists (this in particular) Best regards ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [Ach] Better Crypto
Hi coderman, hi Peter, hello cryptography list and ACH list, > (...) I have followed your comments on our small project bettercrypto.org (which we started only in Sept/Okt 2013) with great interest. In fact, comments like these are very valuable to our project and help us to write a better version. Upfront: We can change any part of the text - it is still a DRAFT and I am super happy about the interesting feedback we are getting. Also the archived discussion on public mailing lists helps other users to find their own cipher strings. > >> As a general observation, it also promotes the thinking that all we need to >> do >> is choose magic algorithm A instead of magic algorithm B and everything is >> fixed. No, if we created that impression then we failed. In fact, we added the "theory" chapter at the end just in order to help people decide on their own. So, I take this as a good feedback in order to change the text in section "howtoreadthis.tex". >> The crypto is pretty much the last thing you need to worry about, >> since the attackers will ignore it and go for all the other weak points >> instead... > 100% agreed. That's what we state in the abstract as well as in the disclaimer. See also coderman's comment: > i did not get the impression that it promotes a silver bullet mindset. > indeed, the second paragraph of the introductory abstract clearly > states: > """ > ... it seems that intelligence agencies and adversaries on the > Internet are not breaking so much the mathematics of encryption per > se, but rather use software and hardware weaknesses, subvert > standardization processes, plant backdoors, rig random number > generators and most of all exploit careless settings in server > configurations and encryption systems to listen in on private > communications. Worst of all, most communication on the internet is > not encrypted at all by default... > > This guide can only address one aspect of securing our information > systems: getting the crypto > settings right to the best of the authors’ current knowledge. Other > attacks, as the above mentioned, > require different protection schemes which are not covered in this guide. > """ > > > but perhaps a better disclaimer would be more like: > "WARNING: if your adversary can mount attacks against your RC4 and MD5 > using protocols, hardening your cipher suite configuration will not > materially reduce your risk.*" > @coderman: good suggestion :) Yes... I agree. In fact, the that's what we saw in the 30C3 talks:( However, I want to add something here: personally I am less worried about that Never Say Anything agency but about the "nuclear proliferation" issues with all the leaked attack possibilities: other nation-states-agencies or simply criminal groups or "business intelligence" units will be very keen to learn from that biggest agency and adapt and modify their tool-kits. That is why we need to all harden our settings today. And by "all" I really mean all (that includes the Never Say Anything agency). If the NSA had used proper group encryption (like you know PGP works when you send to groups, D'oh), then maybe they would not have had a problem with leaked documents now. In fact, the Surveillance Review Report clearly states on p. 250: "the government’s classified networks require immediate internal hardening." I guess that now applies to all networks. Worldwide. The discussions on how to applied good crypto practices to real world servers is of course just one part of the whole hardening process. For 2014 I have a dream: Just imagine getting 95% of Mail Server sysadmin operators to start using good opportunistic TLS (with whatever cipher) for Mailserver to Mailserver communication within one year. That would for sure be better than what we have now. > > * the only entities for whom this is not true don't need to read this guide. > ;) > > > > > last but not least, the most important section of all in my oh so > humble opinion: "Random Number Generators" is also the least useful. > no mention of physical true random number generator sources and how to > use them (and how NOT to use them,*cough* RDRAND). poor platform > support. etc. i'm trying not to complain too much, as i have not yet > submitted a patch myself either! > > Please send a pull request on github . That would be really much appreciated. We really are simply just trying to push that topic as hard as we can and depend on the feedback of this and similar communities. Send us all your change requests, critique and suggestions please. Concerning Peter's comments on "!SRP": there was some discussion on this here: http://lists.cert.at/pipermail/ach/2013-December/000616.html and here: http://lists.cert.at/pipermail/ach/2013-December/000617.html (just follow the thread) Again: we could include SRP but then we'd have to write something on how to use it . --> pull request? Often it's enough to simply link to the right HOWTO. Final
