I think you make a good point. I've now removed the E grade because I don't
think it's going to be needed.
I am going to keep the D grade for the time being. I think it might be
useful to differentiate between obsolete configuration (C) and severe
problems (F).
On Thu, Jul 6, 2017 at 12:48 PM, Vincent Lynch <[email protected]> wrote:
> In the Qualys blog post you write:
>
> "Although the A-F grading we have in place works great, we’re not making
>> full use of the entire grade range."
>
>
> Reading the *Rules *section of the new proposal, it looks like there are
> still a few grades which are not being utilized. Only one rule results in a
> "D" grade. None of the rules result in an "E" grade.
>
> In America, the "A-F" grading scale skips E. I would suggest eliminating
> the "E" grade altogether as it does not seem to serve a vital role and may
> encourage very bad configurations to be left unchanged. I suspect a "good
> enough" or "at least its not failing" mentality from some users.
>
> If the "D" grade only exists for one or two conditions, I would also
> suggest eliminating it for the sake of simplicity. Similar to how TLS 1.3
> stripped away alot of the configuration options that were very weak or hard
> to implement while not being technically broken, I think a new SSL Labs
> grading schema should similarly consider dropping grades that are for very
> weak yet not currently exploitable configurations.
>
> -Vince
>
>
>
> On Wed, Jul 5, 2017 at 3:50 PM, Ivan Ristic <[email protected]> wrote:
>
>> Yes, but that's only justifiable if there is a clear benefit to
>> upgrading. For example, has anyone been exploited because they didn't have
>> support for the extended master secret? What are the chances of
>> someone—anyone—being attacked this way?
>>
>> Another problem is this: is the extension commonly supported, for
>> example, if I run a patched RHEL 7.x, do I have it? If not, what do I do?
>>
>> We also need to consider if it's likely that the extension will take
>> hold. I don't think it will and that's why I think we should focus on TLS
>> 1.3 instead.
>>
>> In my opinion we need to look at the big picture, and that's lack of
>> encryption and lack of HSTS, rarely issues with mixed content. Then maybe
>> TLS 1.3, but a long way further.
>>
>>
>> On Wed, Jul 5, 2017 at 8:23 PM, Lily <[email protected]> wrote:
>>
>>> site owners can add extensions the same way they can add TLS 1.3: by
>>> updating software when updates become available instead of insisting on
>>> using ancient software. just like some of them have to do to add things
>>> like TLS 1.2 and ECDHE+AEAD suites.
>>>
>>> On Wed, Jul 5, 2017, 14:45 Ivan Ristic <[email protected]> wrote:
>>>
>>>> Hi Matthias,
>>>>
>>>> I don't think that's very practical. Put yourself into the shoes of a
>>>> web site owner; how would they go about adding support for some TLS
>>>> extension? Having a requirement like that would only frustrate them and
>>>> turn them away from SSL Labs.
>>>>
>>>> I think a much better use of our energy and everyone's time would be to
>>>> focus on helping TLS 1.3 adoption, which addresses the issues you mentioned
>>>> and then some.
>>>>
>>>>
>>>> On Tue, Jul 4, 2017 at 8:06 PM, Matthias Terlinde <[email protected]
>>>> > wrote:
>>>>
>>>>> Hi list,
>>>>> > Happy to discuss here, but you can also leave comments on the
>>>>> document
>>>>> > itself.
>>>>> Thanks for the invitation.
>>>>>
>>>>> In my eyes you should add some TLS extension into the context.
>>>>> For a A/A+ grading I recommend the "extended master secret extension"
>>>>> as
>>>>> defined in RFC5246 [1].
>>>>> In TLS 1.2 the master secret isn't cryptographically bound to the
>>>>> session parameters which enables man in the middle attacks on session
>>>>> resumption.
>>>>>
>>>>> Do you take the "encrypt-then-mac extension" [2] into account for
>>>>> authenticated encryption for the A grade?
>>>>>
>>>>> Another discussable extension is the "truncated_hmac extension" [3],
>>>>> which reduces the hmac to 80 bits. I didn't found any related research
>>>>> to hmac truncatoin and TLS.
>>>>> Do you have any hints, that this one is insecure to use?
>>>>>
>>>>> Have a nice evening,
>>>>> Matthias
>>>>>
>>>>> [1] https://tools.ietf.org/html/rfc7627
>>>>> [2] https://tools.ietf.org/html/rfc7366
>>>>> [3] http://www.iana.org/go/rfc6066
>>>>>
>>>>>
>>>>> ------------------------------------------------------------
>>>>> ------------------
>>>>> Check out the vibrant tech community on one of the world's most
>>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>>>> _______________________________________________
>>>>> ssllabs-discuss mailing list
>>>>> [email protected]
>>>>> https://lists.sourceforge.net/lists/listinfo/ssllabs-discuss
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Ivan
>>>> ------------------------------------------------------------
>>>> ------------------
>>>> Check out the vibrant tech community on one of the world's most
>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot______
>>>> _________________________________________
>>>> ssllabs-discuss mailing list
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/ssllabs-discuss
>>>>
>>>
>>
>>
>> --
>> Ivan
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> ssllabs-discuss mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/ssllabs-discuss
>>
>>
>
>
> --
> Vincent Lynch
>
--
Ivan
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
ssllabs-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ssllabs-discuss
