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
------------------------------------------------------------------------------
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
