Re: [Trans] Threat model outline, attack model

Ben Laurie <> Fri, 26 September 2014 16:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 35BB81A8A54 for <>; Fri, 26 Sep 2014 09:03:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.165
X-Spam-Status: No, score=-2.165 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=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qSlv3SxeACl7 for <>; Fri, 26 Sep 2014 09:03:21 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 63E8E1A90EC for <>; Fri, 26 Sep 2014 09:00:50 -0700 (PDT)
Received: by with SMTP id l13so10645348iga.6 for <>; Fri, 26 Sep 2014 09:00:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sxcYPHd2rR7q4pwOiCVI0939pYX4uyMtUer8HcKZQ0M=; b=XsiHJXz2CVV4bBtmul8VftlQyB/ZWCIr6DD8MdYb+IU0um9nWbnqfPAjRCZpcKIaY5 +IA5ANn4XG7dWaeF5Tf6HZ4ZkqlvUW3XkCVlrt5Xyiov4Ya9iLquy98zAhT6PtpvcFmU My+Mk4xCb8sKk6bDGJt/YJxkIvxYG03+RhG2MEYy+us+2cnQebL+hzT0L4ELCKu1t2Zj tqG6EYYbFrfRK98iYBPsjRrXZoco+DIB7yg89O07/TzWJimwhI7wLDxZfpOpgYsiIV3Y QSyZrgNnl/fwrR2L5dIO85s+YoZqX8W1IpSvKHG5hI52vYG8vFUnO1pg1ZmFSEWYMLfr 7SqQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=sxcYPHd2rR7q4pwOiCVI0939pYX4uyMtUer8HcKZQ0M=; b=bLQ3vsbnwj9vNgz7yusVGvuj1hNN4++qTJnx9zQa2vDVF178s4M9b1F4qvJ+buDT4q NNWQ3QE9aQqit6anV/fmXJ8shSADqWQEgAaAvdtGAHFOb4N9sfX8SHj6z61irjQp1MRS sUFxjvgVF45gNfafawEqahwyJrRVw42JbZFj4QQrFIYwdppSRwC4iYuPKmrXiX2ZrzM1 jd4mDL8uyyK1PZM0WVz/60nThDSd8Rw4nPd9gNKo2ZYhMfFAXtRLXfRM7SOhtJmeas7g quUpKEwZev5fcdonRWvo2pBUADI/2mxXtjGhd5O2sapdxJM9nmwgfpi4v2QyAqVjDiDj 3+xg==
X-Gm-Message-State: ALoCoQnmv6POZo3OqnRFsI62JZrMLxPEbQViC9jpgaqpwLHwwhr2yVtcVg/VhuP9MWb2RQZpxus5
MIME-Version: 1.0
X-Received: by with SMTP id dm8mr19330410icb.23.1411747249723; Fri, 26 Sep 2014 09:00:49 -0700 (PDT)
Received: by with HTTP; Fri, 26 Sep 2014 09:00:49 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Fri, 26 Sep 2014 17:00:49 +0100
Message-ID: <>
From: Ben Laurie <>
To: Stephen Kent <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>
Subject: Re: [Trans] Threat model outline, attack model
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Public Notary Transparency working group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Sep 2014 16:03:23 -0000

On 26 September 2014 16:49, Stephen Kent <> wrote:
> Ben,
>> ...
>>> Mis-issuance is the primary (sole?) rationale for CT, so I am not
>>> comfortable
>>> with the notion that mis-issuance is not well-defined.
>> Reality doesn't always make us comfortable :-)
>> We keep finding new ways for people to get certs wrong, and thus
>> creating new rules for them. Also, the exact rules are context
>> dependent, and may even depend on contracts and other things we can't
>> even see.
> I don't accept that rationale as a basis for avoiding creating a definition
> for mis-issuance.
> The CABF Guidelines are revised over time. We can update the RFC to match.
> We do that for other IETF Standards.
> I don't understand the notion of context dependence for the definition
> of mis-issuance. Can you provide some examples? Who decides what constitutes
> a mi-issued cert inn what context?
> I agree that a contracts between a CA and a Subject can include terms and
> conditions that might cause aert to be "mis-issued" relative to those
> Ts & Cs.

This is the kind of thing I meant.

> But, I though CT was trying to enable Monitors to detect
> mis-issuance
> on an Internet-wide scale. Violation of Ts & Cs is something that the
> Subject and CA would be able to determine, but not others, in general.

I want to enable as much to be detected as possible. Certainly if we
could only help in these narrow cases, that would be a cause for
concern - but my point is I don't think we can _fully_ nail down all
instances of mis-issuance.

> At a minimum we need a set of universally-applicable issuance standards to
> apply, based on two things:
> - the syntax of the cert, which everyone can examine
> - comparison of logged certs against reference certs, i.e., valid
> certs already issued to (legitimate) Subjects. A Monitor can
> perform this comparison if provided with a reference cert. if the
> Monitor wants to perform additional checks, that may be fine
> if we're going to create a standard that purports to detect mis-issuance,
> but we can't define mis-issuance in a well-articulated, testable fashion, I
> question the utility of this effort.

I didn't intend to suggest there was no point in defining mis-issuance
to the extent that its possible, just that I don't think its likely
we'll manage to completely define it, so we should not attempt to do
so. i.e. I would not like to see the RFC say "this is mis-issuance,
and nothing else is".

>>> I'm puzzled; how would CT allow a Monitor to determine who generated the
>>> key pair used in a cert that was logged? I don't understand your example
>>> here.
>> I said it wouldn't, so you are right to be puzzled.
> Then why cite this as as an example of mis-issuance, and yet claim that CT
> is intended to detect mis-issuance? That's what I find puzzling.

I was supporting your claim that not all forms of mis-issuance are
detectable by simply looking at the certificate (though I guess almost
all are).

>>>> As far as I know there are no standards in this area. Chrome contains
>>>> a blacklist of certificate hashes (from memory, its been a while since
>>>> I looked at this) - I don't know what other browsers do.
>>> Well, if we can't say how this is done, preferably based on some
>>> standard,
>>> then we can't make an argument that, after being being detected by CT,
>>> that
>>> there is a fix. If so, then the security considerations section will have
>>> to
>>> discuss this residual issue.
>> I think we have ample evidence that there are fixes to mis-issuance.
>> Some of them are based on standards, too (e.g. revoking in CRLs or via
>> OCSP).
> I believe we have to be able to explain how mis-issuance (if it can be
> defined)
> is detected by CT, and then how the detection provided by CT is used to
> address
> the problem. That's why I believe we need an architecture and a
> threat/attack model, so
> that there is a framework for explaining how CT fits into a solution to the
> problem.
> When there are standards-bases ways to respond to mis-issuance detected by
> CT, then we
> need to point to them. When there are not, we need to admit that and say
> that there
> are residual problems, or that there are extant, but not standardized,
> mitigation
> techniques.

Sure thing.