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

Nimrod Aviram <nimrod.aviram@gmail.com> Fri, 20 March 2020 16:23 UTC

Return-Path: <nimrod.aviram@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC383A0C1E for <tls@ietfa.amsl.com>; Fri, 20 Mar 2020 09:23:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.086
X-Spam-Level:
X-Spam-Status: No, score=-2.086 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, URIBL_BLOCKED=0.001] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AKZtslYNvR-8 for <tls@ietfa.amsl.com>; Fri, 20 Mar 2020 09:23:50 -0700 (PDT)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 138023A0888 for <tls@ietf.org>; Fri, 20 Mar 2020 09:23:49 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id o10so7042630ljc.8 for <tls@ietf.org>; Fri, 20 Mar 2020 09:23:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/0k43fDdrDk9XMeP5DyJTnWwRvQUEX+8P3xC1icUprk=; b=fQ5JZSNKJCWMhXx49dexTH7n9U8YowPfdZyodt0+7d7mLelCSAiV0YXkJ4wa2/W4Wy BBqjjucFKVW8I8LUnsf/+syw2WrvJt/frwH2VK9BAU/UKyPEPEIj0cAsZatG8++skKm3 B1WnyhH40WfeOtu/w5lZqVOL9oYsfzgMuKz4JozrCrAlPuMUXhA9F51v7SCkPAG5FhNS 8F0evzDF2QyzWenEfX+4KcoM9E+IHz3wL9N+4tsnuw2WvN3MKuWhRMWiEN4ZqSc/xWeN hyUagsdoFCHI+20CYNYwh6n9cfeDaL96sqYMfappPwDZKlstsu6GG0JEwbIp86Tpv2Cy AImw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/0k43fDdrDk9XMeP5DyJTnWwRvQUEX+8P3xC1icUprk=; b=XjkXUaeK4PCFumLwLB0VVcz0Si6VNLhmjyC6yROss8P3hStrwMIPe5sM0zFD3NxU+E QfemksSb0mqC1fcX7uq8XUkNjgIKk/hAb2QQ10+hceT+lrvN5WnM1t9Ykxdaq6Skq3D/ 2g9UcdubFHnKxuDvrbETEYmHjfPfIOIXj9KP0M9RfpSLE9H40qt/CvQbrW9ZnsxPDX2t N7KfOKx8B/DxHb1Mw7U0ns3M4dKSFxTMtLwYDBbZOF/xTk8OK1CX3wCxsEcaRwthKTDk D+CdR8DXiyorcOeKW3+fzXXsgx0LVrLkYH0HT2gpTamkSfMh9U8KHb2a+fVNyiV5n+tb D/nw==
X-Gm-Message-State: ANhLgQ2sBtfALZcTrLIwNOZObKFUDifR8dIfOoJlqQpbQB2TcJOVm12q psMNiKDJe1XmYz99KMZ0i/UZbGzqitu51FACIRU=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vs1TYM/6taE46BXyVMgxvtMOvoyqhcbEu3RlWe+?= =?utf-8?q?KhNCLzQxzt5ukacDL16E+xwt3JvHaK7tOEW2/kTN+XaaBkQ=3D?=
X-Received: by 2002:a2e:2e11:: with SMTP id u17mr5909361lju.90.1584721427970; Fri, 20 Mar 2020 09:23:47 -0700 (PDT)
MIME-Version: 1.0
References: <CABiKAoSiGk1+SJAJRRBEe_cAHmi3Uo24T-PsXmw0TvxVtqhdmg@mail.gmail.com> <CAFDDyk-eqwJSxT9R5KurEzXjcKFzu6sBD9w1mihKziL8F+aA2Q@mail.gmail.com>
In-Reply-To: <CAFDDyk-eqwJSxT9R5KurEzXjcKFzu6sBD9w1mihKziL8F+aA2Q@mail.gmail.com>
From: Nimrod Aviram <nimrod.aviram@gmail.com>
Date: Fri, 20 Mar 2020 18:23:36 +0200
Message-ID: <CABiKAoQDxkSfyd-oPvgGqZXbcG2puMy0SYWD2+PTg=VAJ5rQ-A@mail.gmail.com>
To: Nick Sullivan <nick@cloudflare.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>, Juraj Somorovsky <juraj.somorovsky@upb.de>, robert.merget@rub.de
Content-Type: multipart/alternative; boundary="000000000000c83d1205a14bb5ef"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Q_S-OJHKvLUK8EoJaOA40ri5SAs>
Subject: Re: [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: Fri, 20 Mar 2020 16:23:56 -0000

Hi Nick,

Thank you for the detailed response!

In light of your explanation, we are curious why high-profile servers using
Delegated Credentials need to support TLS-RSA? Most of the relevant clients
(or all of them?) support ephemeral key exchange in TLS. So would it be
possible to improve the state-of-the-art by forbidding TLS-RSA and
demanding correct keyUsage, at least in such high-profile scenarios?

Assuming this is not possible, we agree with your conclusion. It looks like
the second alternative is more effective - to discourage the use of
DC-enabled certificates in contexts where an oracle may be present. One
possible defense-in-depth is to use DC only with EC certificates.

best wishes,
Robert, Juraj and Nimrod

---------- Forwarded message ---------
From: Nick Sullivan <nick@cloudflare.com>
Date: Fri, 20 Mar 2020 at 01:21
Subject: Re: [TLS] Delegated Credentials: The impact of a hypothetical
Bleichenbacher attack
To: Nimrod Aviram <nimrod.aviram@gmail.com>
Cc: <tls@ietf.org> <tls@ietf.org>rg>, Juraj Somorovsky <juraj.somorovsky@upb.de
>


Hello Nimrod, Robert and Juraj,

Thank you for the report!

The fact that a single signature oracle computation can be used to create a
DC and therefore intercept multiple connections for up to 7 days is
something we considered when writing this specification. The mitigation you
proposed in option 1 (requiring the keyEncipherment KeyUsage to not be
present on DC-capable certificates) is sound in theory, but unlikely to be
effective in practice since many servers (including many of the ones
identified in DROWN) ignore the requirement that keyEncipherment KeyUsage
is present. Stating this requirement in the text of this document is
unlikely to prevent existing oracles from being leveraged if the
certificate is used in multiple contexts and is likely to introduce
complexity on the CA side, so I'm inclined not to include this requirement.
I'd be happy to hear an argument to the contrary, though.

I'm more inclined to incorporate some text into the security considerations
to discourage the use of DC-enabled certificates in contexts where an
oracle may be present. Servers may even go as far as to use a different
certificate for DC-enabled handshakes vs regular handshakes --- although
very few servers support this sort of dynamic certificate switching in
practice so it would be difficult to make a hard requirement here.

Nick

On Thu, Mar 19, 2020 at 6:08 AM Nimrod Aviram <nimrod.aviram@gmail.com>
wrote:

> 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 4.2.1.3).  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
> KeyUsages.
> 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
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>