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
