Re: [Trans] Threat model outline, attack model

Ben Laurie <benl@google.com> Fri, 12 September 2014 14:10 UTC

Return-Path: <benl@google.com>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC161A000B for <trans@ietfa.amsl.com>; Fri, 12 Sep 2014 07:10:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.031
X-Spam-Level:
X-Spam-Status: No, score=-3.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham
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 UU1CBb9D-zKf for <trans@ietfa.amsl.com>; Fri, 12 Sep 2014 07:10:30 -0700 (PDT)
Received: from mail-qc0-x236.google.com (mail-qc0-x236.google.com [IPv6:2607:f8b0:400d:c01::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C03761A06D8 for <trans@ietf.org>; Fri, 12 Sep 2014 07:10:05 -0700 (PDT)
Received: by mail-qc0-f182.google.com with SMTP id x13so887259qcv.27 for <trans@ietf.org>; Fri, 12 Sep 2014 07:10:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=Dcxe1Fyllbv1UxgcwqTnoXRvL/clyBhsCv6kyqWCz1w=; b=fHkyzu+j1ghv29G4I8AVqVeBPiJak2TDkI9aaYh53OzccD7wZQkZ0WGyv+uX2F2V97 ctcQluhbmnt68YL8dd+/I6bQ9TTRNuwZsBNoxliaWwokWXBaP99uYrOmu2zHsUjZbG8G 2e0KLWCN6/xVbu3OTpiVzE2o5gQM36OpoxOTZXb+kZ/JdUQ1SgoMO0ZSCd4NHEIyKMPp en1e63Osud0UNn46rBSk8l6eXRoQiqkSUZuCRW6wUmt1Mxv/dkFNZH+vQSOT97eDKdhu N3lM9Zb6GkYPzdM7EI4ybuFNuah0T70oRfSPSGTb1ujZd96HWXwJH1FhWyh/jyG8+s+l ajDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Dcxe1Fyllbv1UxgcwqTnoXRvL/clyBhsCv6kyqWCz1w=; b=RL5Vpv6+QY08zKWRYVD7q03PZHGq9tXCK82R5X2y2ulYNeXvUCCrSX/ABHJFvgCUD4 07kjQUHIyVpI4Y4MPCv5ner7Rdi+SRBGD/mo948SaltFhkOeJSJ16z6XaKbBM/0UZ+xb 5hUxPmn92IxumJOghcac62FmjbBgXUTviYTv9e5y+4bhmoSrtxTa68KlU+vpBvRSNuc3 Z8EV8ePXcE5XNUJczXL0arPchjEIQagCuzwCoooNloqSmJUVchQGFbmUKCEE3hc4m6Pa MuMVxzlNT9YbLHa1+kosAwwKRa7PA14UaPWR2dhJH+n3KwIcuW9k2BYbvaUL9RdzQkB0 HNqg==
X-Gm-Message-State: ALoCoQk+MB2aWkJggkBmIwvpxNf2NxeH/0oaK3+GcsMXMBjuPjvAp+aIx757rv2xmxbePfB0yWyt
MIME-Version: 1.0
X-Received: by 10.140.96.86 with SMTP id j80mr8907766qge.106.1410531004094; Fri, 12 Sep 2014 07:10:04 -0700 (PDT)
Received: by 10.229.247.198 with HTTP; Fri, 12 Sep 2014 07:10:04 -0700 (PDT)
In-Reply-To: <5411E511.1040605@bbn.com>
References: <5411E511.1040605@bbn.com>
Date: Fri, 12 Sep 2014 15:10:04 +0100
Message-ID: <CABrd9STmog8-JZCg9Tfv_ToUswY=9LBcZAPQM2cqUVcO0dhAnQ@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/AjTxmQwqfeAz9nKMyd-4c3aMne4
Cc: "trans@ietf.org" <trans@ietf.org>
Subject: Re: [Trans] Threat model outline, attack model
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Sep 2014 14:10:33 -0000

On 11 September 2014 19:08, Stephen Kent <kent@bbn.com> wrote:
> Since there was a suggestion that the current (-04) CT text contained an
> adequate
> threat model, and if a better one were needed, I should offer text, I have
> done so.

Thanks!

>
> Here is an initial cut at the sort of text I expect to see in an RFC dealing
> with
> security mechanisms.
>
> Steve
> --------
>
> Threat Model
>
>
>
> Certificate Transparency (CT) is intended to detect and mitigate problems
> arising from mis-issuance of certificates, in the Web PKI context. The Web
> PKI context refers to the use of a set of Certification Authorities (CAs)
> that issue X.509 certificates to web servers to enable TLS-protected access
> by clients [cite WPKOPS?].
>
>
>
> A certificate is characterized as mis-issued if the certificate is issued to
> an entity that is not authorized to represent the host (web server) named in
> the certificate Subject field or Subject Alternative Name extension. <do we
> want to focus exclusively on SAN vs. Subject?)

This is not the only form of mis-issue - for example, the Baseline
Requirements impose key size limits, lifetime limits, usage bits
restrictions and so forth.

EV adds even more stuff.

>
>
>
>
>
> <Discuss classes of adversaries, motivations, and capabilities>
>
>
>
> 1. Criminals
>
>
>
> 2. Hacktivists
>
>
>
> 3. Nation states (intelligence organizations)
>
>
>
> 4. Other?
>
>
>
>
>
>
>
> Attack Model and CT Mitigation Mechanisms
>
>
>
> Certificate mis-issuance may arise in one of several ways.  The ways that CT
> helps detect and remedy mis-issuance depends on the context of the
> mis-issuance.
>
>
>
> 1. A non-malicious Web PKI CA may mis-issue a certificate as a result of an
> error or because it was the victim of a social engineering attack. In this
> case the CA has a record of the certificate and it is prepared to revoke the
> bogus certificate once it has been convinced of its error. If the CA is
> submitting the certificates it issues to one or more logs, there will be
> records of the bogus certificate. If one of Monitors to which the
> certificate was submitted is tracking the targeted Subject, it will detect
> the mis-issuance, and will alert the Subject. Because the CA has a record of
> the mis-issuance, the only data needed to identify the bogus certificate is
> the Subject (SAN) and public key, both of which are available from the log.
> The presence of an embed SCT in the bogus certificate, or an SCT
> accompanying the bogus certificate does not appear to contribute to the
> mitigation. (See Note 1 below.)
>
>
>
> 2. A non-malicious Web PKI CA may be the victim of an undetected attack
> (c.f., DigiNotar) which results in mis-issuance of one or more certificates.
> In this case the CA is not aware of the mis-issuance and may have no record
> of the certificate content.
>
>
>
> a. The bogus certificate(s) may have been submitted to one or more logs
> prior to issuance, to acquire an embedded SCT, or post-issuance to acquire a
> standalone SCT. In either case, a Monitor to which the certificates had been
> submitted (and which is tracking the targeted Subject), would detect a bogus
> certificate and alert the targeted Subject. The Subject, in turn, would
> request the CA to revoke the bogus certificate. In this case, the CA will
> depend on the certificate serial number provided via the log entry, to
> effect revocation. (See Notes 1 + 2 below.) If TLS clients rejects a
> certificate when no SCT is present, this might motivate the attacker to log
> the bogus certificates, thus justifying such client behavior. (However, such
> client behavior needs to be defined in a way that is compatible with
> incremental deployment.)
>
> b. A bogus certificate may not have been submitted to any logs. In this
> case, Monitors will not detect the bogus certificate. If clients reject a
> certificate that lacks (or is not accompanied by) an SCT, the attacker will
> be thwarted in this case. (See Note 3 below.)
>
>
>
> 3. A malicious Web PKI CA may mis-issue a certificate as a result of being
> bribed or compelled to do so. (A CA might be compelled to issue a bogus
> certificate my a government agency or a criminal organization.)  This CA
> might be one or more tiers below a trust anchor (aka root CA).
>
> a. The bogus certificate(s) may have been submitted to one or more logs
> prior to issuance, to acquire an embedded SCT, or post-issuance, to acquire
> a standalone SCT. In either case, a Monitor tracking the targeted Subject
> would detect a bogus certificate and alert the targeted subject. The
> Subject, in turn, would request the CA to revoke the bogus certificate. In
> this case, the CA may refuse, or substantially delay, to revoke the bogus
> certificate. (It could make excuses about inadequate proof that the
> certificate is bogus, or argue that it cannot quickly revoke the certificate
> because of local, legal concerns, etc.) In this case, the CT mechanisms have
> detected mis-issuance, but are not able to remedy the problem. (See Note 4
> below.)
>
> b. A bogus certificate may not have been submitted to any logs. In this
> case, Monitors will not detect the bogus certificate. If clients reject a
> certificate that lacks (or is not accompanied by) an SCT, the attacker will
> be thwarted in this case. (See Note 3 below.)
>
>
>
> Notes:
>
>
>
> 1. If a CA submits the bogus certificate to logs, but these logs are not
> watched by a Monitor that is tracking the targeted Subject, CT will not
> mitigate a mis-issuance attack. It is not clear whether every Monitor MUST
> offer to track every Subject that requests its certificates be monitored.
> Absent such a guarantee, how do TLS clients and CAs know which set of
> Monitors will provide “sufficient” coverage. Unless these details are
> addressed, use of CT does not mitigation mis-issuance even when certificates
> are logged.
>
>
>
> 2. A CA being presented with evidence of a bogus certificate probably will
> require more than the serial number of the bogus certificate. It will want
> to verify the Issuer and Subject (SAN) to ensure that the certificate being
> revoked is not one that it has knowingly issued (which would fall under case
> #1). Other certificate fields and extensions may be of interest for forensic
> purposes, but are not required to effect revocation nor to verify that the
> certificate to be revoked is bogus.

I think they are (or, at least, may be, depending on the nature of the
bogosity), see above.

> The SCT itself, because it contains a
> timestamp from a third party, is probably valuable for forensic purposes.
>
>
>
> 3. If a TLS client is to reject a certificate that lacks an embedded SCT, or
> is not accompanied by a post-issuance SCT, this behavior needs to be defined
> in a way that is compatible with incremental deployment. Issuing a warning
> to a (human) user is probably insufficient, based on experience with
> warnings displayed for expired certificates, lack of certificate revocation
> status information, and similar errors that violate RFC 5280 path validation
> rules.
>
>
>
> 4. The targeted Subject might request the parent or the offending CA to
> revoke the certificate of the non-cooperative CA. However, a request of this
> sort may be rejected, e.g., because of the potential for significant
> collateral damage.

The other recourse is to revoke directly in the browsers - either the
whole CA or the offending certificate(s). This is what happened to
DigiNotar, for example.

>
>
>
>
>
> As the analysis above shows, logs play a critical role in enabling detection
> of certificate mis-issuance, although they do not, per se, perform such
> detection. Thus logs represent another target for adversaries who wish to
> effect certificate mis-issuance. If a log generates SCTs for an attacker,
> but does not provide the log entries for these SCTs to all, or some,
> Monitors, CT will not detect mis-issuance. Thus it is critical that Monitors
> be able to compare the results of log data acquisition to detect
> mis-behaving logs.
>
>
>
> Absent a protocol (a so-called “gossip” protocol) that enables Monitors to
> verify that data from logs are consistent, CT does not provide protection
> against logs that may conspire with, or be victims of, attackers effecting
> certificate mis-issuance. Even when a gossip protocol is deployed, it is
> necessary to describe how the CT system will deal with a mis-behaving or
> compromised log. For example, will there be a mechanism to alert all TLS
> clients to reject SCTs issued by such a log. Absent a description of a
> mitigation strategy to deal with mis-behaving or compromised logs, CT cannot
> ensure detection, much less remediation, of mis-issuance.

I do agree that we need to define the gossip protocol to complete the CT story.

> Monitors also play a critical role in detecting certificate mis-issuance,
> for Subjects that have requested monitoring of their certificates. Thus
> Monitors represent another target for adversaries who wish to effect
> certificate mis-issuance. If a Monitor is compromised by, or is complicit
> with, an attacker, it will fail to alert a Subject to a mis-issued
> certificate targeting the Subject. This raises the question of whether a
> Subject needs to request certificate monitoring from multiple sources to
> guard against such failures.
>
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>