Re: [Trans] Threat model outline, attack model

Ben Laurie <benl@google.com> Fri, 26 September 2014 16:03 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 35BB81A8A54 for <trans@ietfa.amsl.com>; Fri, 26 Sep 2014 09:03:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.165
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qSlv3SxeACl7 for <trans@ietfa.amsl.com>; Fri, 26 Sep 2014 09:03:21 -0700 (PDT)
Received: from mail-ig0-x22d.google.com (mail-ig0-x22d.google.com [IPv6:2607:f8b0:4001:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63E8E1A90EC for <trans@ietf.org>; Fri, 26 Sep 2014 09:00:50 -0700 (PDT)
Received: by mail-ig0-f173.google.com with SMTP id l13so10645348iga.6 for <trans@ietf.org>; Fri, 26 Sep 2014 09:00:49 -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; 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; 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; 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 10.42.191.136 with SMTP id dm8mr19330410icb.23.1411747249723; Fri, 26 Sep 2014 09:00:49 -0700 (PDT)
Received: by 10.64.118.67 with HTTP; Fri, 26 Sep 2014 09:00:49 -0700 (PDT)
In-Reply-To: <54258AF0.7090602@bbn.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>
Date: Fri, 26 Sep 2014 17:00:49 +0100
Message-ID: <CABrd9SQNXHdJQCC3JQJirqdkg_ub0oXCkxPqit9H6LjUPqNioA@mail.gmail.com>
From: Ben Laurie <benl@google.com>
To: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/trans/hhVKi3MC5SK3QUw3PaCrODUGAoo
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, 26 Sep 2014 16:03:23 -0000

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.

> 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.