> On 3 May 2017, at 14:53, Issac Goldstand <mar...@beamartyr.net> wrote: > > On 5/3/2017 12:46 PM, Dirk-Willem van Gulik wrote: >> On 3 May 2017, at 10:03, Issac Goldstand <mar...@beamartyr.net> 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