Re: Gnutls investigation and request for advice for Jessie

[Antoine Beaupré <anarcat@orangeseeds.org>]

I contacted three parties to try and settle this:

 * the original authors of the paper
 * the GnuTLS upstream
 * the RedHat security team

The original authors "still stand behind what is written in the paper"
and believe only a constant-time implementation is the proper fix. They
point to BoringSSL, OpenSSL and WolfSSL as properly implementing this
now, but acknowledge such a fix might impose API breakage, at least in
the low-level hash functions.

Upstream GnuTLS replied the following:

https://gitlab.com/gnutls/gnutls/issues/456#note_105621260

> The solution applied in gnutls 3.3.30 is a mitigation against the
> attack published by the authors. As such these CVEs are
> addressed. What the authors claim is that these mitigations may not be
> sufficient to address a future attack similar in principle to that
> one; they indeed have a point but I guess that's with all attacks one
> way or another. So backporting these mitigations (or preferably by
> updating to 3.3.30) is sufficient to address that vulnerability. A
> more general solution is tracked at #503.

In other words: that's the solution we got now, use it or wait (possibly
for months) for a longer term fix.

RedHat security hasn't answered yet, but GnuTLS upstream also replied
there:

https://bugzilla.redhat.com/show_bug.cgi?id=1582571#c12

> That is, the existing counter-measures present were improved to
> protect against this attack. Indeed the paper authors mention that
> this may not be sufficient to counter other future attacks, and they
> are correct in that. How critical however would be such future
> attacks? For that one must note what is the actual impact of this
> attack. This type of attacks does only affect the legacy HMAC-based
> ciphersuites and only when the gnutls peer does not implement the
> encrypt-then-mac construction. That's why the majority of HMAC
> ciphersuites are now disabled by default keeping HMAC-SHA1 for
> compatibility only.

In other words: yes, an attack is still possible, but it's not critical
because the impact is smaller.

I agree with this analysis: the fix is imperfect, but it's all we
got. So I'll be looking at backporting this shortly.

Or should we update jessie to 3.3.30 as recommended upstream? There
*were* API/ABI changes since 3.3.8, but only new symbols were added - no
signatures were changed or removed...

A.
-- 
Music gives a soul to the universe, wings to the mind, flight to the
imagination and life to everything
                         - Plato