Sorry for the late response.
Just a quick add to one point:
> What are the chances of someone—anyone—being attacked this way?
Encrypt-then-MAC counters the padding oracle attacks as we have seen
first by Serge Vaudenay [1] and resulted in the POODLE attack or the
broken PKCS#1.5 padding.
The extended master secret mitigates the triple handshake attacks, which
breaks authentication schemes that relay on the master secret (or the
same sesssion id).
Prof. Matthew Green (Johns Hopkins University) got asked why we should
care about injection attacks. He answered:
"You probably don’t, unless you happen to be one of the critical
applications that relies on the client authentication and renegotiation
features of TLS."
The extended master secret is activated for OpenSSL 1.1.0 or later, for
the encrypt-then-MAC extension I don't know. I just found a fix for a
crash of this extension in 1.1.0e.
So I think there is a wide support for these features, which is honourable.
But I also think you are right, a wider spread for TLS 1.3 would be
better than trying to fix protocol errors.
[1] https://www.iacr.org/archive/eurocrypt2002/23320530/cbc02_e02d.pdf
Am 05.07.2017 um 21:50 schrieb Ivan Ristic:
> 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]
> <mailto:[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]
> <mailto:[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] <mailto:[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
> <https://tools.ietf.org/html/rfc7627>
> [2] https://tools.ietf.org/html/rfc7366
> <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]
> <mailto:[email protected]>
> https://lists.sourceforge.net/lists/listinfo/ssllabs-discuss
> <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]
> <mailto:[email protected]>
> https://lists.sourceforge.net/lists/listinfo/ssllabs-discuss
> <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
