Re: [Trans] Threat model outline, attack model

Stephen Kent <kent@bbn.com> Mon, 15 September 2014 19:03 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 AB8D11A87C7 for <trans@ietfa.amsl.com>; Mon, 15 Sep 2014 12:03:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.853
X-Spam-Level:
X-Spam-Status: No, score=-5.853 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, 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 u3Mb-EdmfP0b for <trans@ietfa.amsl.com>; Mon, 15 Sep 2014 12:03:18 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 288141A700C for <trans@ietf.org>; Mon, 15 Sep 2014 11:53:00 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:59645 helo=comsec.home) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1XTbOj-000POJ-Kg for trans@ietf.org; Mon, 15 Sep 2014 14:53:13 -0400
Message-ID: <54173589.3000404@bbn.com>
Date: Mon, 15 Sep 2014 14: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: trans@ietf.org
References: <5411E511.1040605@bbn.com> <CABrd9STmog8-JZCg9Tfv_ToUswY=9LBcZAPQM2cqUVcO0dhAnQ@mail.gmail.com>
In-Reply-To: <CABrd9STmog8-JZCg9Tfv_ToUswY=9LBcZAPQM2cqUVcO0dhAnQ@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/leo2HqRADEn4ZPQVNCZ2GNEXCaU
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 19:03:21 -0000

Ben,

Thanks for explaining what you and your co-authors have in mind when
you use the term mis-issuance. This is a very important first step toward
clarification for CT.
>
>> 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?)
> This is not the only form of mis-issue - for example, the Baseline
> Requirements impose key size limits, lifetime limits, usage bits
> restrictions and so forth.
>
> EV adds even more stuff.
So the scope of mis-issuance is much broader than what I had imagined.

I think we may need to add two things to 6269-bis:

     - normative references to CABF documents that are the basis for the 
broader
       set of cert issuance criteria that you note

     - maybe two appendices to enumerate the criteria. this will be 
critical if
       if the CABF docs contain other criteria that are outside the 
scope of CT,
       e.g., criteria that cannot be evaluated based on what is logged.

Do you agree?
>
>> ...
> The other recourse is to revoke directly in the browsers - either the
> whole CA or the offending certificate(s). This is what happened to
> DigiNotar, for example.
I agree that one might do that, but I am aware of no IETF standards for
doing so. My understanding is that DigiNotar, as a trust anchor, was
removed from the TA list. I am not aware (but then I am not a browser
vendor) of an equivalent mechanism for CAs below TAs. Also, the TA list
mechanism is not an IETF standard. We need to cite a spec, preferably
a standard, on how to deal with browser-based revocation. Is there an
appropriate CABF document that needs to become a normative reference?

> ...
> I do agree that we need to define the gossip protocol to complete the CT story.
I'm glad that we're in agreement here.

Steve