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

Nick Sullivan <nick@cloudflare.com> Fri, 20 March 2020 16:57 UTC

Return-Path: <nick@cloudflare.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 848313A0C63 for <tls@ietfa.amsl.com>; Fri, 20 Mar 2020 09:57:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 FMDceDQ_79Fd for <tls@ietfa.amsl.com>; Fri, 20 Mar 2020 09:57:19 -0700 (PDT)
Received: from mail-ua1-x92b.google.com (mail-ua1-x92b.google.com [IPv6:2607:f8b0:4864:20::92b]) (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 9B9D63A0BEF for <tls@ietf.org>; Fri, 20 Mar 2020 09:57:18 -0700 (PDT)
Received: by mail-ua1-x92b.google.com with SMTP id b2so2455307uas.13 for <tls@ietf.org>; Fri, 20 Mar 2020 09:57:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=pXigUibTLv9X0FOODs6oEb5lsPPe7KNTGf9bwdC/WR8=; b=mwFoGrstw2jXi39MzwXUdfCUf3kR7VavuJuJdAQJbZ5xRbDg+SArnkkFcHxQJByYvb /lkQQUJsfy8LV2XhY1RUk5t08/vv5UGNxGlLKVLmGd/sRwjFjC2Zd5pT5FPV0mv8eLVT AxLXq07om3GkbupoBm7dj3HCX/RE5JRP7MyF8=
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=pXigUibTLv9X0FOODs6oEb5lsPPe7KNTGf9bwdC/WR8=; b=JcGsVaRZgMJKlIUIstfWeRIO5Q2ADUGMJS9yacOWiBCkvpBpWqyGrOk0TsFwnhIQ7B 7KcCzehPgCQitGLgAE6FABoRKXSC99N0zlAU40lRXyDOeHspPv1F9cvNBoch4TfePJ4i IEVUYkZFtH9GaIt8Il2eiWbQ0fL5T3yBI6sVmdCmMVTJqq0oX1fe3llXSJBVCECOeC7m juZd8ewra8V7zK2zO5DnooDZFbC4bq6Vom7q8rqUw2TVzC1uGPL9/2PHnZMoPSjp4Guu 0xvYSlcbgePEXAoK+6igv471u8g1Sb3BEGdiGwyq8DASykKUH2NvtoZxWLSCTFbMbo3H ZenA==
X-Gm-Message-State: ANhLgQ1AsKJU/l8yfaX7QzEhnCkPrJVdEhciHJxkHGWXwnXWp6D9ODuQ NLZvYual0xMa9mqGn02R0ww5P37XSFTLFkBn+BWtiw==
X-Google-Smtp-Source: ADFU+vs1wMWM1Nqd5Ty4DBUjszAQVWtH34zRfkvO9Na18fnT987BkETgZiR7LlRXZpk+CPE22AW9Mt5x59Vhg+fLK3M=
X-Received: by 2002:ab0:5a42:: with SMTP id m2mr5926381uad.55.1584723437124; Fri, 20 Mar 2020 09:57:17 -0700 (PDT)
MIME-Version: 1.0
References: <CABiKAoSiGk1+SJAJRRBEe_cAHmi3Uo24T-PsXmw0TvxVtqhdmg@mail.gmail.com> <CAFDDyk-eqwJSxT9R5KurEzXjcKFzu6sBD9w1mihKziL8F+aA2Q@mail.gmail.com> <CABiKAoQDxkSfyd-oPvgGqZXbcG2puMy0SYWD2+PTg=VAJ5rQ-A@mail.gmail.com>
In-Reply-To: <CABiKAoQDxkSfyd-oPvgGqZXbcG2puMy0SYWD2+PTg=VAJ5rQ-A@mail.gmail.com>
From: Nick Sullivan <nick@cloudflare.com>
Date: Fri, 20 Mar 2020 09:54:57 -0700
Message-ID: <CAFDDyk9K6fyB3q_MDGvhW3db+oC25ZWV+iGp0D69JnSoi6++PQ@mail.gmail.com>
To: Nimrod Aviram <nimrod.aviram@gmail.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>, Juraj Somorovsky <juraj.somorovsky@upb.de>, robert.merget@rub.de
Content-Type: multipart/alternative; boundary="00000000000089a62805a14c2da7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/6CEnDSoFR7twN3YyyP2M40-tVRQ>
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:57:24 -0000

On Fri, Mar 20, 2020 at 9:23 AM Nimrod Aviram <nimrod.aviram@gmail.com>
wrote:

> 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?
>

This doesn't stop the attack, it just reduces the probability that a new
oracle will be exploitable in servers that implement DCs. If the oracle
exists in existing legacy servers where the cert is used, it doesn't matter
what DC-enabled servers do. Removing support for TLS-RSA in TLS 1.2 is a
valid TLS policy choice for today's age, but enforcing it in the protocol
document doesn't improve the security versus known attacks like DROWN.
Requiring EC keys for DC-enabled certificates is also an artificial
limitation that should be avoided -- not all CAs support EC certs and not
all software supports EC code.

What you really want is to prevent keys from being used across different
contexts. I see two options for this:

1) Add strong wording in the security considerations section about how it
is dangerous to use the same key in different contexts. Advise implementers
to use DC-enabled certificates only for signing DCs, not for terminating
TLS or SSL -- if their software allows it.
2) Enforce on the client-side that DC-enabled certificates can only be used
for DC handshakes. This option prevents DC certificates from being used in
an DC-capable server by DC-enabled clients, but it doesn't prevent the
certificate from being deployed on legacy services exposing an oracle. The
downside of this restriction is that it adds complexity for server
implementations (need the ability to load certificates dynamically based on
client hello), and operators (two certificates need to be managed per
service, not just one).

My preference is for 1)


> 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>, 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
>>
>