yossarian (1.3.6.1.4.1.55738)a good rule of thumb (that i consistently struggle to not violate) is that any system that uses "policy" as a blanket term for delegating complexity to users is one that deserves extreme scrutiny
Tom Hennen@yossarian say more
@inyourbits in the sense of making secure defaults harder; my experience is:
1. a tool/system comes with secure defaults
2. a user/demo needs a set of exceptions that are contextually reasonable/acceptable
3. the tool/system grows the ability to set "policies," and declaring a custom policy implicitly overrides *all* secure defaults instead of just the ones explicitly overridden
@yossarian oh yeah with you there. I think there's a lot more room for good UX in this space, but I'm not entirely sure what good looks like.
Filippo Valsorda 
@yossarian something related that I'm getting convinced of is that in e.g. crypto/tls we should do profiles instead of config options.
We take responsibility for the defaults, but then we say "if they don't fit, here are all the dials". Instead, we should have opinionated FIPS 140, compatibility, modern, etc. profiles, just like we have the default profile.
Elendol@filippo @yossarian that resonates well with me, definitely something I will think more about
Arcaik@filippo @yossarian I don't understand, isn't that what OP is saying is a bad thing?
Negative Kelvin@Arcaik @filippo @yossarian Seems more like a way for people to have choices without having a bunch of dials to make mistakes with.
Jess👾The problem I've seen when you leave it up to individual developers to set that sort of thing is that in a rush to get their code to work, many will just open up all the security settings to make it work, and "I'll lock it down next sprint" (which of course never actually happens). That's how we keep ending up with crap like public S3 buckets and stuff - because IAM settings are frustrating and annoying.
@filippo @yossarian
@filippo @yossarian
Timothée Ravier@filippo @yossarian You might want to take a look at the crypto system policies in Fedora:
- https://gitlab.com/redhat-crypto/fedora-crypto-policies
- https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies/
- https://gitlab.com/redhat-crypto/fedora-crypto-policies
- https://docs.fedoraproject.org/en-US/packaging-guidelines/CryptoPolicies/
Clemens@siosm @filippo @yossarian We'd love for Go to support that. If you come up with an input format Go would be willing to parse, @monk will happily add a backend to crypto-policies that generates it.
@neverpanic @siosm @yossarian @monk supporting a policy format at the end of the day would be just another way to expose all the dials, as they can still all be turned orthogonally and from the outside.
The difference with profiles is that we'd be able to reason around a few discrete and evolving configurations, based on the user's stated goal.
@filippo @siosm @yossarian @monk and that's precisely what SECLEVEL started out as, targeting a specific security level in bits, adjusted while algorithms were broken. And it's a really bad way to configure things.
Profiles are a good idea, but as I said, details matter. Do you plan on having a profile for what BSI recommends? Or NSA, NIST, something similar to Mozilla's ssl config generator? What do you do when somebody shows up asking for a profile conforming to Chinese standards?
@neverpanic @siosm @yossarian @monk it'd definitely not be about security levels in bits, I don't believe in them anyway.
Mozilla's SSL config generator is what I was thinking about for the compatibility/default/modern profiles. We already effectively have the FIPS 140 profile. Maybe a PQ one? For other profiles, we'd apply the same scrutiny we currently apply to deciding whether to implement those standards at all: IF we implement Chinese algos, it makes sense to have a profile (but we don't).
Ryan Castellucci 
@filippo @yossarian Have you seen how S2N-TLS handles this?
I did find the lack of a Config.LetMeShootMyselfInTheFoot option annoying, but I just got them to add a customized policy for my use case...
@filippo @yossarian I agree in general, but details matter. See OpenSSL's SECLEVEL, for example. It's a total configurability disaster, and I'm sure it started out with good intentions.
Klaus FrankBut don't you like to compromise the security of your entire system when you have to enable SSL3 to connect to that one legacy embedded device that everyone forgot about for the last 15-20 years?
pagefalter@filippo @yossarian So, something like crypto-policies?