I try to summarise the many replies (and thanks for the interest!), to sketch
out a possible path forward.
1. Overall
----------
Replies in general have been very positive.
wr...@rowe-clan.net: "I like the proposal."
rainer.j...@kippdata.de: "I like the idea."
champio...@gmail.com: "+1 to this idea"
Some concerns were raised:
> Am 02.05.2017 um 22:42 schrieb Daniel <dferra...@gmail.com>:
> I am a bit concerned about the implications something like this may bring to
> you guys, let me explain.
> [...after updating...]
> it will fail, maybe the Mr. and Ms. Normal won't be able to figure out since
> they changed nothing and the thing just started failing for them?
> Am 02.05.2017 um 23:10 schrieb Eric Covener <cove...@gmail.com>:
> They upgraded. The few broken users will have a better chance of
> understanding what changed from CHANGES or the manual then most users
> have of understanding what "HIGH:!PSK:!aNULL:!EXP:!SRP" really
> "means".
Others have similar things. OpenSSL itself defines classes (not specifically
targeted at HTTP. I once talked with Rich Salz about this and he said the
OpenSSL is not aware of the application protocol. Layering.) and AWS has
standard and user-defined policies. Something very similar. it seems.
Besides security policy, this could be used for other things:
> Am 02.05.2017 um 23:01 schrieb Helmut K. C. Tessarek <tessa...@evermeet.cx>:
> It would be great to explain the performance impact per setting.
>
Whatever categories we define where etc. I think we can agree that
a. Security policy needs to be an opt-in. No existing config will change
unless the user choses a policy.
b. One value of policy names is that they can be easier to understand (if
there are not too many), if given a comprehensible name.
Less clear:
c. Another value of security policies is that their definition can be updated
by the project. "modern" is not "modern" from 2005.
There is discussion needed about this aspect. Basically, do we want
policies like
i. "modern" which we update, or
ii. "strong-2017" which we freeze
The upside of i. is we can improve life for people who are not full time
employed as apache admins. The downside of it is that we can break sites with a
policy update.
2. Categories
-------------
a. There is discussion if we should use the Mozilla Policy definions "modern",
"intermediate" and "old". There is discussion if especially "old" is useful.
b. There is discussion about the impact on config merging:
> Am 02.05.2017 um 19:28 schrieb Rainer Jung <rainer.j...@kippdata.de>:
> a) in order of occurrence in the config files (order of reading)
> b) the most secure settings win
> c) first apply the "intent" directive, then merge the existing detail
> settings on top
> I guess c) would be the most logical, but probably needs some additional
> feature in config parsing.
> Am 02.05.2017 um 19:32 schrieb Ruediger Pluem <rpl...@apache.org>:
> c) would be the best, but a) IMHO would be acceptable since overwriting is
> for the more advanced users anyway and they
> can be told to do stuff in the correct order.
I think this merits its own thread.
3. Place of Definition
----------------------
Code vs. Config Files vs. Macros vs. "Owned Macros"
> Am 03.05.2017 um 00:48 schrieb Jacob Champion <champio...@gmail.com>:
> If all of the settings that are part of this new directive can be described
> in terms of other already-existing directives, could we implement it as a
> server-owned Macro?
> Am 03.05.2017 um 03:11 schrieb Daniel Ruggeri <drugg...@primary.net>:
> I actually was going to respond in a similar way by proposing the use of
> files that could be Included. I really like this idea for all the reasons
> mentioned - the biggest being that it's trivial for a SecAdmin or WebAdmin to
> see what is in the Included file and its macros and what gets applied. I am
> also in support of regularly evolving the values because an admin making use
> of them is aware that they are delegating responsibility to us or their
> package vendor. The downside (which may no longer be valid - haven't looked
> in ages) is that I think Includes and Macros confuse line numbers in error
> messages.
> Am 03.05.2017 um 09:37 schrieb Luca Toscano <toscano.l...@gmail.com>:
> One thing that I'd would really like to see as admin would be a quick way to
> dump/inspect/visualize what SSLSecurityLevel 2017-05 corresponds to
> (SSLDirectiveX set to foo, SSLDirectiveY set to bar, etc..). Even better
> would be to have also a little bit of description attached to the dump, or
> just a reference to the docs.
I think this also merits its own thread.
4. Update Process
-----------------
Some people talk about the need for new processes here.
> Am 03.05.2017 um 10:03 schrieb Issac Goldstand <mar...@beamartyr.net>:
>
> What would work, in my eyes, if people are open to it, is treating the
> contents of these definitions/macros (and I'm all for the macros, just
> so that interested sysadmins can see *exactly* what the settings are on
> their setup) as apart from the httpd sources, and thus not subject to
> the normal release cycle. To clarify, I mean the httpd tarball release
> cycles specifically, not our policies for how we perform and vote on the
> releases (although we'd need to come to agreement on how to allow for
> quick releases in the face of security issues, so a 3 day vote followed
> by release may not work). Instead, we could do something similar to the
> spamassassin project does with their base rules, where we have external
> tooling (or internal tooling, if it's preferred) fetch the up-to-date
> definitions from an ASF mirror server on a regular basis and override
> the local definitions.
And a simpler version:
> Am 03.05.2017 um 11:46 schrieb Dirk-Willem van Gulik <di...@webweaving.org>:
>
> We, here, simply define ‘one’ setting as the industry best standard - which
> roughly corresponds to what ssllabs their test would get you an A+ and that
> pretty much meets or exceeds the various NIST et.al. recommendations for key
> lengths for the next 5 years.
>
> We’d wrap this into a simple policy document. Promise ourselfves that we’d
> check this every release and at least once a year review it. And have a small
> list of the versions currently meeting or exceeding our policy.
>
> And this is the setting you get when you do ‘SSLEngine On’.
>
> Everything else stays as is.
Personally, I think we will end with some new things we do. But I'd prefer them
to emerge from what we decide to offer our users. Example: if we offer
something like "modern", I do not see a need for a quick, separate update cycle
of that definition. That will evolve with more glacial speed.
Cheers,
-Stefan
