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

Nimrod Aviram <nimrod.aviram@gmail.com> Tue, 24 March 2020 12:27 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 B94A63A09CC for <tls@ietfa.amsl.com>; Tue, 24 Mar 2020 05:27:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, SPF_PASS=-0.001, 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 Kfzcp2_mkZck for <tls@ietfa.amsl.com>; Tue, 24 Mar 2020 05:27:04 -0700 (PDT)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 7D6903A09EC for <tls@ietf.org>; Tue, 24 Mar 2020 05:27:03 -0700 (PDT)
Received: by mail-lj1-x22c.google.com with SMTP id v16so11297734ljk.13 for <tls@ietf.org>; Tue, 24 Mar 2020 05:27:03 -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=1dRQq2H6uaA802SZnuCUeHtw+t0djv2zknTw1govPh8=; b=g3K36Tve7XoGExXkThwDDqbovki2NTGaQclJniWoz/RydAfJtFnXc6Ch+s/o7s07Dr v1UPKuGff+nQpOiul4UBeJNpiCwPt/vh4a27cM9khxBYoqMzy0s67v6Bi6Jo775TEXzi pCNR26mZiXXXcRJZXFlkGfuTT/7hvmcLT0Z52in7Sk4a3b/WyUA0DEXwkSDsbZgseS4A s6KOgYc3eOdxsdCIL2rhwY6AxZE4/bvfLwUNzlSYuTnLlJULdXnYQBbEMrTLTnTqMGFf BmkYAOmNkcEvwzDOTGdbwf/2jXisQMBOYAnS2N2Q502Dgs9tRuo04K5EteNNRAi3jMHn eaHg==
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=1dRQq2H6uaA802SZnuCUeHtw+t0djv2zknTw1govPh8=; b=HIW6DCHCxa7USt8fgsLexYRiayiDnelWWe+Y1yLlzOpahhpUCaLjkckZNjv4YytRzg 08uk24U4fzKGYqFaNUL4wwYQoCDgu1V27kYvNf+4mh+bQAe2dqTzIv1twjDYX5pm1ETC xNdd9B8LjUlNLFRT1xBQOZE3q/Ub58JuNzVBInZNXkT0cpYn41VRE+tAMo1atv7sdI2Z +9ki7LVzKflULFm5v8lKRslkrYEJIh7jPPzOtk/h7yioSBiK8kztaXQToTZcsSvmF482 X07ur+KRFstLnEndHZyvuNB6hprfWtdmozVNKSwW7U10rhzm6uJ7IrFOQ9m/Wv5mY4z3 cVcg==
X-Gm-Message-State: ANhLgQ1MnB7IZEP7feUMBvhYKSW8NqeaDA41o1TnJf/b+94EhXgNSfJx ielZBKDRL42vQzp7CcJ7f+VnqaJApegkk0xQzfO6NSlP15U=
X-Google-Smtp-Source: ADFU+vvjYLhUdFLkbdTXXcpECKq2Ai0oHDKSDU1g1h3/FLHwW1fQ86HZ5R+zUsdLpY30gJJEmBMbDKLJth904uc9v4A=
X-Received: by 2002:a2e:90da:: with SMTP id o26mr17420774ljg.254.1585052821702; Tue, 24 Mar 2020 05:27:01 -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> <CAFDDyk9K6fyB3q_MDGvhW3db+oC25ZWV+iGp0D69JnSoi6++PQ@mail.gmail.com> <CABiKAoTfCeDFL1tm7e=XFvoa7MRL3JL90NhzPkZXD1H=KhQL6w@mail.gmail.com> <CAFDDyk_Ym=DoXdGqFOHW7cfq+CVAeL+OJ66npAi=ac3NC-e_yQ@mail.gmail.com>
In-Reply-To: <CAFDDyk_Ym=DoXdGqFOHW7cfq+CVAeL+OJ66npAi=ac3NC-e_yQ@mail.gmail.com>
From: Nimrod Aviram <nimrod.aviram@gmail.com>
Date: Tue, 24 Mar 2020 14:26:50 +0200
Message-ID: <CABiKAoSPjRUvoCMjWMa6cVSeik7ndpawYq0pCwn6kxbfPwdQCA@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="000000000000634af405a198de43"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/zf6J6ZTsJSdQxYfHd8ZjkugBqrQ>
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: Tue, 24 Mar 2020 12:27:21 -0000

Hi Nick, thanks!

I sent a PR here:
https://github.com/tlswg/tls-subcerts/pull/60

best wishes,
Nimrod


On Fri, 20 Mar 2020 at 20:45, Nick Sullivan <nick@cloudflare.com> wrote:

> Hi Nimrod,
>
> This is a working group document, so it's open to comments and suggestions
> from anyone in the IETF community. Feel free to send a PR
> https://github.com/tlswg/tls-subcerts and we can discuss on-list.
>
> Nick
>
> On Fri, Mar 20, 2020 at 11:12 AM Nimrod Aviram <nimrod.aviram@gmail.com>
> wrote:
>
>> Hi Nick,
>>
>> Thank you again for the detailed explanation.
>> We agree with your preference for option 1.
>> Would it help if I contribute a draft of the new text for the security
>> considerations section?
>>
>> best wishes,
>> Nimrod
>>
>>
>> On Fri, 20 Mar 2020 at 18:57, Nick Sullivan <nick@cloudflare.com> wrote:
>>
>>>
>>>
>>> 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>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
>>>>>
>>>>