Re: [Trans] Threat model outline, attack model

Dmitry Belyavsky <beldmit@gmail.com> Mon, 15 September 2014 06:40 UTC

Return-Path: <beldmit@gmail.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 4C8411A06A5 for <trans@ietfa.amsl.com>; Sun, 14 Sep 2014 23:40:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.701
X-Spam-Level:
X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 exL4Mm6KXZCe for <trans@ietfa.amsl.com>; Sun, 14 Sep 2014 23:40:56 -0700 (PDT)
Received: from mail-yh0-x22a.google.com (mail-yh0-x22a.google.com [IPv6:2607:f8b0:4002:c01::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F1BC1A069F for <trans@ietf.org>; Sun, 14 Sep 2014 23:40:56 -0700 (PDT)
Received: by mail-yh0-f42.google.com with SMTP id i57so1912524yha.1 for <trans@ietf.org>; Sun, 14 Sep 2014 23:40:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vmq+j75JtX8lMmzd7t+XVY4IX5wvtQxFNMtnudRTLOc=; b=ZDBbJxpuz2QllDIsLsqnI8NHP19j8He+Z5vHA2as3WNaLyOM9FJuWAWpDwuepEJv5b Ak+1/MOkcVQGe8KJpEiosmF2+mUKi0Yj7vpzXEn7RuxOMkbPLX3EfkvbkEpjliHkOC4c aWcfXD4i4bfWlv0DZFbamKXOzc/sW13L8hzPaGeySn2VAo87BpAdahqfG1yXrx6mnLtX 0TRELDPGxefTwDIcQbTQbnH9wCNYkOJrubNRglESnjz2ikVHXm4xl4Gd8oFfrRzSf1br tXQO8qtr9OQ2Mrv2s0dbQVAzb+LVJac+0QQuJY2U11hq6Qt2SOlt4BmQduDZx22PYSzA 3Wgw==
MIME-Version: 1.0
X-Received: by 10.236.99.97 with SMTP id w61mr30766667yhf.11.1410763255464; Sun, 14 Sep 2014 23:40:55 -0700 (PDT)
Received: by 10.170.170.8 with HTTP; Sun, 14 Sep 2014 23:40:55 -0700 (PDT)
In-Reply-To: <5411E511.1040605@bbn.com>
References: <5411E511.1040605@bbn.com>
Date: Mon, 15 Sep 2014 10:40:55 +0400
Message-ID: <CADqLbzJ1MVjgGu8_Rw9DWm5NXe9pGH1v47WVH=kXFin5NrZuvA@mail.gmail.com>
From: Dmitry Belyavsky <beldmit@gmail.com>
To: Stephen Kent <kent@bbn.com>
Content-Type: multipart/alternative; boundary=20cf300e4d51b44a5d050314ea8a
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/uQfh6zx1pH3MSESQ0voAKRx2nXI
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: Mon, 15 Sep 2014 06:40:59 -0000

Stephen,

thank you for the formal description of treat model.

But I think that the Auditors should be mentioned in it too. If I am not
mistaken, they are designed to watch the certificates with suspicious
properties (CA permissions, etc.).

So the treats which are to be avoided using the Auditors seems to be
missing.


On Thu, Sep 11, 2014 at 10:08 PM, 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.
>
> 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?)
>
>
>
>
>
> <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. 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.
>
>
>
>
>
> 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.
>
>
>
> 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
>
>


-- 
SY, Dmitry Belyavsky