Re: [TLS] Delegated Credentials: The impact of a hypothetical Bleichenbacher attack
Nick Sullivan <nick@cloudflare.com> Fri, 20 March 2020 18:45 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 33A7A3A0D8A for <tls@ietfa.amsl.com>; Fri, 20 Mar 2020 11:45:47 -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 RGeA5BTc32VB for <tls@ietfa.amsl.com>; Fri, 20 Mar 2020 11:45:44 -0700 (PDT)
Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 EC7FB3A0D7C for <tls@ietf.org>; Fri, 20 Mar 2020 11:45:43 -0700 (PDT)
Received: by mail-ua1-x936.google.com with SMTP id t20so2611845uao.7 for <tls@ietf.org>; Fri, 20 Mar 2020 11:45:43 -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=oyXGKP49W/MEp4AphK+dnHF8HDDlqCZ5Vua54fVWbvs=; b=PAs8dQgpfkcZL3DyYZU8+8hbiJKlmvDmE3i7/cRwQz+fhfggK3qMbOaYhuXD+N/6dR xR6V83RELWa/XJd0JgoKzef1NgXtgsmm4DP+HtxbcyZqnbtLULXB19vGI5w/OQ5+HKw3 DfaYZWf425ZeUzx++Vr17ByT7LXL0CJ2z1usQ=
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=oyXGKP49W/MEp4AphK+dnHF8HDDlqCZ5Vua54fVWbvs=; b=tXBo1SWvbfZtq3cIW9rbkTIRIgQjz/SP1Lib/rz0H5QWi82GeyfCp1WD4AiU8clxwh mrrQvu/M29piJhuIceDJ7jkEgsk3qf0GmzIqM4h6MB1AbRQrL3FKMo55X4sHG4fm2Ka0 S3k5PWG1cyasDYUYesogYwYGTHVG+CoMEOJGyTNNaKEAebHwjCCBWagLQwAnsUtpSs9P duXFAdjQrBVGlAq8TiuAPwFrsdCUGQaHAaUwGjMw1tN7szSkK0ibBUO5PQ9NT0VyBF7q TdbwFVrUcOa+h0llpQ+dCRNr9GF/7Cc4jPRiUDdaf+FqrTsQ9dbtlwykH6O5mqGThyag CDww==
X-Gm-Message-State: ANhLgQ11RZ7q8YHR6kCLjacgdPgfsFxgujzH8/zuitPGywFMHhdg8TeP GuCFO73Ah4NjTUwanFkrQj5ctcGdVaOTtd4uDx3C1Q==
X-Google-Smtp-Source: ADFU+vt7wRLzY37cNRtDoLAxUPj4ppNgqJgeOP5FpQvw/fEC8n3AnxlewZMe/ukTN9lI/a7a5fQ5KxkQGd/mGGTDPwI=
X-Received: by 2002:ab0:5a42:: with SMTP id m2mr6313624uad.55.1584729942228; Fri, 20 Mar 2020 11:45:42 -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>
In-Reply-To: <CABiKAoTfCeDFL1tm7e=XFvoa7MRL3JL90NhzPkZXD1H=KhQL6w@mail.gmail.com>
From: Nick Sullivan <nick@cloudflare.com>
Date: Fri, 20 Mar 2020 11:43:23 -0700
Message-ID: <CAFDDyk_Ym=DoXdGqFOHW7cfq+CVAeL+OJ66npAi=ac3NC-e_yQ@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="00000000000045adf805a14db143"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/-4rGLEJRoDTg2DzqVaMLm_uVuK4>
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 18:46:00 -0000
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>, 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 >>>> >>>
- [TLS] Delegated Credentials: The impact of a hypo… Nimrod Aviram
- Re: [TLS] Delegated Credentials: The impact of a … Nick Sullivan
- Re: [TLS] Delegated Credentials: The impact of a … Nimrod Aviram
- Re: [TLS] Delegated Credentials: The impact of a … Nick Sullivan
- Re: [TLS] Delegated Credentials: The impact of a … Nimrod Aviram
- Re: [TLS] Delegated Credentials: The impact of a … Nick Sullivan
- Re: [TLS] Delegated Credentials: The impact of a … Nimrod Aviram