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

Nick Sullivan <> Thu, 19 March 2020 23:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4AEF63A1207 for <>; Thu, 19 Mar 2020 16:21:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.099
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 71doSxzGCvIQ for <>; Thu, 19 Mar 2020 16:21:24 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::932]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B3B0E3A1209 for <>; Thu, 19 Mar 2020 16:21:24 -0700 (PDT)
Received: by with SMTP id q24so1507337ual.10 for <>; Thu, 19 Mar 2020 16:21:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gW8DCRZZ1MQ2V2bmjEcr+q4Tk0l/9/Uqtpw59KeGMR8=; b=a8agBZCCvWG7jDF5xp66ZstysX/k5TBL9HT1eAz4GeyIVoY4isY4baBCL9OjnB8aIt 1VcSKSEN9JZTdH9EBZVCTkZyPMOaV1Tw8h002BRp34R+nnlbRMwH23oEIfYSKKC2+YBy HjKXtGNKHQOV9nqr8RiXOxkCjR3/DXEi7wD8E=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gW8DCRZZ1MQ2V2bmjEcr+q4Tk0l/9/Uqtpw59KeGMR8=; b=MwEqexKosttRTVeSX+uBwYwWnCWH9YP4OQfJf75kE68eKYnhMhA4oSx/EgPz2LHG8m WKjEMo8DuySPFlAhV/VpVz7q5YwXuEWDnHAv6G0xa8xV59kOJcQ262TeKm3g52oftknm qlc0Unb6P7pZfV6se/qKmrxLi+L6jyHzlaAFeB0kECsUxxeFKeCBywCX4Ap1ixpy0Bzc kL0jW5mGnztF5oDF12qsoGwPwnX5wHmnEjV+cXAX7ih0uTEjztIj5+rchrJeOLTaAC9z BimHzFEf9ilFGH46Dn6Lz2FJKh7BmpZtmUFreTPV45BDnGBQZmNeXCt6pNilzVv+WSy0 XgYQ==
X-Gm-Message-State: ANhLgQ0jxVDoLJWJVZX3XBZtjWYpqPNU17L8Eumhdbe9/VsBRB7El9c8 XlKM7EOhoKBFSNy1jatyxMKqU95hZEcsRpyR9Hzm6g==
X-Google-Smtp-Source: =?utf-8?q?ADFU+vtAcPCGAfqU91Y2FGFnDtB7QvMsIcezzDhulfSo?= =?utf-8?q?x5GY31qBlH8qxf+snLse94xzZ8oO4gb6KkgyzTlp4jbN92c=3D?=
X-Received: by 2002:ab0:5a42:: with SMTP id m2mr3490912uad.55.1584660083287; Thu, 19 Mar 2020 16:21:23 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Nick Sullivan <>
Date: Thu, 19 Mar 2020 16:19:07 -0700
Message-ID: <>
To: Nimrod Aviram <>
Cc: "<>" <>, Juraj Somorovsky <>
Content-Type: multipart/alternative; boundary="0000000000005ad8ac05a13d6dc4"
Archived-At: <>
Subject: Re: [TLS] Delegated Credentials: The impact of a hypothetical Bleichenbacher attack
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Mar 2020 23:21:31 -0000

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.


On Thu, Mar 19, 2020 at 6:08 AM Nimrod Aviram <>

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