[gnutls-devel] GnuTLS | lucky13-type of attack for SHA384 and SHA256 (#456)

[Development of GNU's TLS library]

I'm evaluating the vulnerabilities discussed in the paper titled ["Pseudo
Constant Time Implementations of TLS Are Only Pseudo Secure"](http://ia.cr/2018/747). I'm working on backporting security fixes to
the Debian LTS security suite which currently shipped a patched version
of GnuTLS 3.3.8.

In that paper, the authors claim that:

> However, we believe that the GnuTLS code is still vulnerable to
> variants of the attacks presented in our paper due to its
> padding-dependent memory accesses. We notified the GnuTLS team of our
> concerns about this on June 13th 2018. Our understanding is that the
> GnuTLS team does not plan to address the issues, but prefers to
> promote the use of Encrypt-then-MAC (as specified in RFC 7366) when
> legacy cipher suites are required.

In the Debian security tracker, all three issues are marked as fixed in
3.5.19 or 3.6.3:

 * https://security-tracker.debian.org/tracker/CVE-2018-10844
 * https://security-tracker.debian.org/tracker/CVE-2018-10845
 * https://security-tracker.debian.org/tracker/CVE-2018-10846

Yet the above claim makes me wonder if our characterization is
correct. On top of the concerns outlined by the researchers, one concern
specific to LTS is we are hesitant in breaking backwards compatibility
with older clients. In that respect, Encrypt-then-MAC (EtM) might not be
an acceptable solution as, again according to the authors:

> The “Encrypt-then-MAC” countermeasure from RFC 7366 is supported in
> mbed TLS and GnuTLS, but requires client-side support and has seen
> little uptake elsewhere (e.g.  neither Firefox nor Chrome supports the
> EtM extension).

Considering that at least 10% of TLS traffic still uses CBC, it seems a
little premature to enforce those new algorithms. Removing some SHA
implementations might also be a problem for us.

What should be the course of action for LTS developers?

Do you agree with the researcher's characterization of the solutions
deployed by the GnuTLS project? Are those CVEs really completely fixed
in GnuTLS?

Thanks for any feedback.

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/456#note_105579686
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20181001/62080be0/attachment.html>