On 5/3/2017 3:59 PM, Dirk-Willem van Gulik wrote: > >> On 3 May 2017, at 14:53, Issac Goldstand <mar...@beamartyr.net >> <mailto: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 >>> <mailto: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.
Which, IMHO, we can safely expect Mr and Mrs Normal to never see. Mr and Mrs normal aren't on the mailing list of most pieces of software, even if they use them. If we truly want to cater to them (and by doing so, do our part in advocating a safer and more secure internet) then I maintain that we'd need to do better. > >>> 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