[TLS] Delegated Credentials: The impact of a hypothetical Bleichenbacher attack

Nimrod Aviram <nimrod.aviram@gmail.com> Thu, 19 March 2020 11:17 UTC

Return-Path: <nimrod.aviram@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A4D733A2769 for <tls@ietfa.amsl.com>; Thu, 19 Mar 2020 04:17:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id LkaxLtFylPEQ for <tls@ietfa.amsl.com>; Thu, 19 Mar 2020 04:16:55 -0700 (PDT)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D1813A275F for <tls@ietf.org>; Thu, 19 Mar 2020 04:16:55 -0700 (PDT)
Received: by mail-lf1-x132.google.com with SMTP id j15so1275710lfk.6 for <tls@ietf.org>; Thu, 19 Mar 2020 04:16:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=rHZ4J3DPXC9gKzgTEofZV2E1LmcMAf1fo1MCdwHDivo=; b=eVCOXAGrAJv8CtnyKvcQRecAZJCvWhek92lI288Kvnw7H5ZBizCvKZaekwlSDgTQbo 17mjS6hIkQQtfVYTulTaFTYBnknIvGMmX0NNWl6EeGc7QTf1b5OmF0p/M4pXmiDCf9vT F0FdZ26x3NxMxhVmgnTwvazGYJbee6gfIXmHE7hFrui3sJ8js0Cd7WyD8q7rWvQxiK3U pOuTAAFM1XEfBryrbab8sH7+j3lf4TvsFT7vX1uLAwRD2HHQs7xkHT6vzJItCXCsiloA 6E8HzKPqCw5atYphk3bqqN4LDUcPOGgg6uWGW1Mv5yAB3z3OneUJ8g3stDAkoUvpOZYw eUOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=rHZ4J3DPXC9gKzgTEofZV2E1LmcMAf1fo1MCdwHDivo=; b=a3HCFGrviqX6lZp/AaWNFal9+HapqvGam9VlJ0wY+maf8w+6JOKEWRJJ1jqy/9L+fc 7wdpXDwuLuMhW/h4qe73Xy3lhDDOCCCdAwXAd+xilUSzcBAd8Z+92jwE4p+TbJR/dnDJ mLWP5WlCfv6Yf3EPPoexNIOr9dmd8nVmxfRaQqAGpPu9Fo16G5SWmKIUQRgLglW0S3fK ZwLQMxrQG2qPYezApAx7KkSL8lAp2/NvO0Y+l0qVuJBexh4AR439Ziqoia9k5GbvZ+op /BSYZpW0fZ4tqmbZzOwSykUYfpOs9zlL6eqQfsMBnKrTkozYW81fyL4Y7DN13DCRqmse 4XfA==
X-Gm-Message-State: ANhLgQ11bZgjYggv+BLquzfahtdAwDrLLZHtTmNl14ylO1dqiLHMmlFN YxY5Z/kMLubDQIz8WIq7DlhCS4MBHniSU9X7qoWY79xgHaM=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vsUHbYp/E9odofPu+LgHlOq8R5QvXszGn8euPuk?= =?utf-8?q?4+hSInkotk0DFgT/DmQQtswFcQVg1ALEl1UZRDRPbXtyVjs=3D?=
X-Received: by 2002:a19:ac41:: with SMTP id r1mr1816782lfc.113.1584616613094; Thu, 19 Mar 2020 04:16:53 -0700 (PDT)
MIME-Version: 1.0
From: Nimrod Aviram <nimrod.aviram@gmail.com>
Date: Thu, 19 Mar 2020 13:16:42 +0200
Message-ID: <CABiKAoSiGk1+SJAJRRBEe_cAHmi3Uo24T-PsXmw0TvxVtqhdmg@mail.gmail.com>
To: tls@ietf.org
Cc: Juraj Somorovsky <juraj.somorovsky@upb.de>, robert.merget@rub.de
Content-Type: multipart/alternative; boundary="00000000000054316e05a1334e63"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/lNweLZidcpxadM0FcE2czxlkuEA>
Subject: [TLS] Delegated Credentials: The impact of a hypothetical Bleichenbacher attack
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Mar 2020 13:07:38 -0000

Hi folks,

We're writing to ask (and share some concerns) about the potential impact
of a Bleichenbacher attack when delegated credentials are in use.

This issue is already discussed in the standard:
In Section 3:
```   It was noted in [XPROT] that certificates in use by servers that
   support outdated protocols such as SSLv2 can be used to forge
   signatures for certificates that contain the keyEncipherment KeyUsage
   ([RFC5280] section  In order to prevent this type of cross-
   protocol attack, we define a new DelegationUsage extension to X.509
   that permits use of delegated credentials.  (See Section 4.2.)

And Section 4.2:
```   The client MUST NOT accept a delegated credential unless
   the server's end-entity certificate satisfies the following criteria:

   *  It has the DelegationUsage extension.

   *  It has the digitalSignature KeyUsage (see the KeyUsage extension
      defined in [RFC5280]).

Currently, it seems the standard does not discuss the common situation
where the certificate has both the digitalSignature and keyEncipherment
If we understand correctly, for such certificates using Bleichenbacher's
attack to forge a single signature once over a delegated credential,
would grant an attacker the equivalent of a man-in-the-middle certificate.
Section 3 mentions SSLv2, and this protocol indeed enabled a severe form
of Bleichenbacher's attack, but these attacks are not limited to older
protocol versions.
There have been implementations of TLS 1.2 vulnerable to Bleichenbacher's
attack, even by server operators as competent as Facebook, as discussed
e.g. in the ROBOT paper.

Also, coming back to SSLv2, one problem at the time was that the
recommended way to disable SSLv2 in OpenSSL did not in fact disable
SSLv2. Administrators who followed the guidelines falsely assumed they
had disabled the protocol, but had no way to verify it was disabled. It
would be prudent to assume this may happen again, e.g. administrators will
be unaware that they have obsolete or vulnerable cryptography enabled.

In light of the above, we would recommend one of two alternatives:
1. Change the text in Section 4.2 to say "[the certificate] has the
digitalSignature KeyUsage, and does not have the keyEncipherment KeyUsage.
Furthermore, the certificate does not share its public key with any
certificate that has the keyEncipherment KeyUsage."
- or -
2. Add text in the Security Considerations Section explaining that:
2.1. The recommended way for server operators to defend in depth against
this type of attack is to use a certificate as in alternative 1 with
delegated credentials.
2.2. Absent that, server operators should be aware of this risk.

We would be happy to continue the discussion and help in any way.

best wishes,
Juraj, Robert and Nimrod