Re: [Trans] Threat model outline, attack model

Stephen Kent <> Mon, 29 September 2014 14:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 19C2B1A8757 for <>; Mon, 29 Sep 2014 07:53:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Status: No, score=-4.987 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id k8hhQh0gFQ9J for <>; Mon, 29 Sep 2014 07:52:59 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B57701A6FAD for <>; Mon, 29 Sep 2014 07:52:59 -0700 (PDT)
Received: from ([]:35566 helo=comsec.home) by with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <>) id 1XYcJu-0000br-H2; Mon, 29 Sep 2014 10:52:58 -0400
Message-ID: <>
Date: Mon, 29 Sep 2014 10:52:57 -0400
From: Stephen Kent <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ben Laurie <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
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: Mon, 29 Sep 2014 14:53:03 -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.
I didn't see replies to my other comments above.

As for the contract example, I think this is out of scope for anything we
are trying to do. If we say that CT enables detection of mis-issuance based
on the model I described in my proposed Appendix, we cover a lot of cases
that are defined objectively, are universal, and have a basis in the 
to which you alluded when you mentioned EV certs. We can say that 
examination of
logs MAY be enable detect ingother forms of mis-issuance, but that 
because we
have no definition of what that might be, it's out of scope for this doc.
>> 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.
And I don't think we cannot discuss, not make design decisions, based on
types of mis-issuance we can't define.
>> 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".
Again, I disagree. We should define what we can and make design decisions
based on that definition. Anything else that might be considered 
is out of scope for purposes of this work. This is the sort of 
delineation that
we often impose on RFCs; we define a scope for a standard and declare 
that other
stuff is out of scope, relative to the standard.
>>>> 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).
Well, there are a lot of examples that I think most folks will agree are 
and which are syntactic. The original case I envisioned, issuing a cert 
to the wrong
entity, is addressed by having a reference to the "right" cert or to 
equivalent data. There
is also the interesting case of non-existence of issuance, as asserted 
by the entity
that controls the Subject name. I didn't address that, but one could 
imagine doing so.
>>>>> 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.
OK. I think we may be converging on some aspects of this issue.