Re: SSL Policy Definitions

[Dirk-Willem van Gulik]

> On 3 May 2017, at 14:09, Graham Leggett  wrote:
> 
> On 03 May 2017, at 2:01 PM, Stefan Eissing  
> wrote:
> 
>> We seem to all agree that a definition in code alone will not be good 
>> enough. People need to be able to see what is actually in effect.
> 
> I think we’re overthinking this.
> 
> We only need to document the settings that SSLSecurityLevel has clearly in 
> our docs, and make sure that "httpd -L” prints out the exact details so no 
> user need ever get confused.
> 
>> If we let users define their own classes, it could look like this:
> 
> Immediately we’ve jumped into functionality that is beyond Mr/Mrs Normal.

Agreed. If our default is simply ‘industry best practice’ (i.e. what we say it 
is*) — then Normal will be the new black.

And everyone else is still in the same boat - i.e. having to specify it just 
like they do today.

All that requires it to make the defaults sane.

Dw.

*: exceed NIST and https://www.keylength.com/  for 
5+ years, PFS, A or better at SSLLabs. 
https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices 




signature.asc
Description: Message signed with OpenPGP

Re: SSL Policy Definitions

[Stefan Eissing]

> Am 03.05.2017 um 14:20 schrieb Luca Toscano :
> 
> Hi Graham,
> 
> 2017-05-03 14:09 GMT+02:00 Graham Leggett :
> On 03 May 2017, at 2:01 PM, Stefan Eissing  
> wrote:
> 
> > We seem to all agree that a definition in code alone will not be good 
> > enough. People need to be able to see what is actually in effect.
> 
> I think we’re overthinking this.
> 
> We only need to document the settings that SSLSecurityLevel has clearly in 
> our docs, and make sure that "httpd -L” prints out the exact details so no 
> user need ever get confused.

+1 
Having the definitions listed via command line is good enough for me.

> 
> I think that in this case documentation is not enough since it tends to 
> quickly fall behind dev commits, plus it would be great for a user to know in 
> a programatic way what are the runtime settings used for SSL (or just to 
> allow admin to manually check/review them).
>  
> 
> > If we let users define their own classes, it could look like this:
> 
> Immediately we’ve jumped into functionality that is beyond Mr/Mrs Normal
> 
> True, even if the idea looks great I'd focus only on Mr/Mrs Normal for the 
> moment :)

Agreed.

Re: SSL Policy Definitions

[Luca Toscano]

Hi Graham,

2017-05-03 14:09 GMT+02:00 Graham Leggett :

> On 03 May 2017, at 2:01 PM, Stefan Eissing 
> wrote:
>
> > We seem to all agree that a definition in code alone will not be good
> enough. People need to be able to see what is actually in effect.
>
> I think we’re overthinking this.
>
> We only need to document the settings that SSLSecurityLevel has clearly in
> our docs, and make sure that "httpd -L” prints out the exact details so no
> user need ever get confused.
>

I think that in this case documentation is not enough since it tends to
quickly fall behind dev commits, plus it would be great for a user to know
in a programatic way what are the runtime settings used for SSL (or just to
allow admin to manually check/review them).


>
> > If we let users define their own classes, it could look like this:
>
> Immediately we’ve jumped into functionality that is beyond Mr/Mrs Normal
>

True, even if the idea looks great I'd focus only on Mr/Mrs Normal for the
moment :)

Luca

Re: SSL Policy Definitions

[Graham Leggett]

On 03 May 2017, at 2:01 PM, Stefan Eissing  wrote:

> We seem to all agree that a definition in code alone will not be good enough. 
> People need to be able to see what is actually in effect.

I think we’re overthinking this.

We only need to document the settings that SSLSecurityLevel has clearly in our 
docs, and make sure that "httpd -L” prints out the exact details so no user 
need ever get confused.

> If we let users define their own classes, it could look like this:

Immediately we’ve jumped into functionality that is beyond Mr/Mrs Normal.

Regards,
Graham
—



smime.p7s
Description: S/MIME cryptographic signature