Re: [cryptography] [Ach] Better Crypto
L. Aaron Kaplan kap...@cert.at 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 cutpaste 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 Peter, hi list, On Jan 16, 2014, at 1:13 PM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: L. Aaron Kaplan kap...@cert.at 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 cutpaste 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 kap...@cert.at - 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
On Jan 7, 2014, at 2:34 AM, Peter Gutmann pgut...@cs.auckland.ac.nz wrote: L. Aaron Kaplan kap...@cert.at 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 cutpaste 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 cutpaste 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 kap...@cert.at - 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 Jan 7, 2014, at 11:24 AM, stef s...@ctrlc.hu 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 kap...@cert.at - 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 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 cutpaste 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 Tue, Jan 07, 2014 at 11:39:42AM +0100, L. Aaron Kaplan wrote: On Jan 7, 2014, at 11:24 AM, stef s...@ctrlc.hu 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
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 axel.hu...@web.de 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 i...@iang.org 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
L. Aaron Kaplan kap...@cert.at 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 cutpaste 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 cutpaste 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
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 cutpaste 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 cutpaste 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
