> On 3 May 2017, at 14:53, Issac Goldstand <[email protected]> wrote:
>
> On 5/3/2017 12:46 PM, Dirk-Willem van Gulik wrote:
>> On 3 May 2017, at 10:03, Issac Goldstand <[email protected]> wrote:
>>>
>>> +1 on the idea
>>>
>>> So far I'm -0 about all of the proposed implementations for 2 reasons:
>>>
>>> 1) Mr and Mrs normal (whom are our primary customers in the original
>>> proposal) usually download Apache from their distro or some other
>>> binary. Their Apache sources are usually not up-to-date, and in the
>>> scenario that a new vulnerability is found it would take ages to
>>> propagate to them, anyway
>>>
>>> 2) For those users who are comfortable building their own source, they
>> ….
>>
>> So how about ‘us’ taking the lead here.
>
> That's the part I was always +1 on :)
>
>> 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.
>
> The problem is, that we don't know what's going to be good going forward
> five years, and IMHO the best standards are shaped at least equally by
> removing "negatives" often because of high-risk vulnerabilities, as by
> adding new "positives" due to new available ciphers/tools
Right - so I think there are two things
1) the general advice of NIST et.al. - summarized nicely at:
https://www.keylength.com
which tells us what our `best acceptable’ choises are in any release going out
and their likely vailidy for the next 5 years.
And then there is our response to things that become known; such as
vulnerability - for which we have a proven update proces that is dovetailed by
us sending mail to announce, the security mailing lists and similar outreach.
>> 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’.
>
> To me this doesn't address the time lags between shipping it in source,
> and it getting implemented on the machine. I don't see it as superior
> in any way to, say, putting the recommended settings in the online docs
> and updating that from time to time - moreso when that update is in
> response to a new vulnerability.
I think we should make sure that 1) any release that goes out meets or exceeds
industry practice (e.g. the BSI 2017 recommendation up to 2022); and 2) that we
keep a list of versions that are still `current’ enough; and that accomodates
what we since their release learned. Typically meaning - update to version X.Y.
Dw
