Re: [Trans] Threat model outline, attack model

Stephen Kent <kent@bbn.com> Mon, 29 September 2014 14:53 UTC

Return-Path: <kent@bbn.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 19C2B1A8757 for <trans@ietfa.amsl.com>; Mon, 29 Sep 2014 07:53:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.987
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k8hhQh0gFQ9J for <trans@ietfa.amsl.com>; Mon, 29 Sep 2014 07:52:59 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B57701A6FAD for <trans@ietf.org>; Mon, 29 Sep 2014 07:52:59 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:35566 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1XYcJu-0000br-H2; Mon, 29 Sep 2014 10:52:58 -0400
Message-ID: <54297249.1090409@bbn.com>
Date: Mon, 29 Sep 2014 10:52:57 -0400
From: Stephen Kent <kent@bbn.com>
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 <benl@google.com>
References: <5411E511.1040605@bbn.com> <CABrd9STmog8-JZCg9Tfv_ToUswY=9LBcZAPQM2cqUVcO0dhAnQ@mail.gmail.com> <54173589.3000404@bbn.com> <CABrd9SRShqm1r-2ajbqD5w1s686ciyjcEvywsXZaapgmi57NsA@mail.gmail.com> <54242F8A.2080602@bbn.com> <CABrd9SSwAdv-mAgofNT6bMWky7q=bZhAaX=L4gZUQDkROQ-3ZA@mail.gmail.com> <54258AF0.7090602@bbn.com> <CABrd9SQNXHdJQCC3JQJirqdkg_ub0oXCkxPqit9H6LjUPqNioA@mail.gmail.com>
In-Reply-To: <CABrd9SQNXHdJQCC3JQJirqdkg_ub0oXCkxPqit9H6LjUPqNioA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/dKrxRft8w5-7rU8XNYnLE-k8n3s
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, 29 Sep 2014 14:53:03 -0000

Ben,

> On 26 September 2014 16:49, Stephen Kent<kent@bbn.com>  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 
Guidelines
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 
mis-issuanve,
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 
mis-issuance,
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.

Steve