Re: [keyassure] Objective: Restrictive versus Supplementary Models

Stephen Kent <kent@bbn.com> Wed, 30 March 2011 11:40 UTC

Return-Path: <kent@bbn.com>
X-Original-To: keyassure@core3.amsl.com
Delivered-To: keyassure@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C933E28C157 for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 04:40:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.554
X-Spam-Level:
X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z8Sx6SJqbaqN for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 04:40:00 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 087BE28C0DB for <keyassure@ietf.org>; Wed, 30 Mar 2011 04:40:00 -0700 (PDT)
Received: from dommiel.bbn.com ([192.1.122.15]:58034 helo=[130.129.71.125]) by smtp.bbn.com with esmtp (Exim 4.74 (FreeBSD)) (envelope-from <kent@bbn.com>) id 1Q4tmL-000A36-GJ; Wed, 30 Mar 2011 07:41:37 -0400
Mime-Version: 1.0
Message-Id: <p06240801c9b8bf84de49@[130.129.71.125]>
In-Reply-To: <Pine.LNX.4.64.1103300450160.25974@newtla.xelerance.com>
References: <AANLkTik1Uzd8XSZzopBBDHywrhSjsBQYxC91BZXdkMwg@mail.gmail.com> <Pine.LNX.4.64.1103300450160.25974@newtla.xelerance.com>
Date: Wed, 30 Mar 2011 07:13:08 -0400
To: Paul Wouters <paul@xelerance.com>, Eric Rescorla <ekr@rtfm.com>
From: Stephen Kent <kent@bbn.com>
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Cc: keyassure@ietf.org
Subject: Re: [keyassure] Objective: Restrictive versus Supplementary Models
X-BeenThere: keyassure@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Key Assurance With DNSSEC <keyassure.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/keyassure>
List-Post: <mailto:keyassure@ietf.org>
List-Help: <mailto:keyassure-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/keyassure>, <mailto:keyassure-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 30 Mar 2011 11:40:01 -0000

At 4:51 AM -0400 3/30/11, Paul Wouters wrote:
>On Wed, 30 Mar 2011, Eric Rescorla wrote:
>
>>  To follow up on my comments at the microphone, there are two potential
>>  objectives for
>>  technology of this type:
>>
>>  1. Protecting against CA mis-issue (as in CA/cert lock).

Eric's text provide a good rationale for this, and I think a solid 
rationale is an important part of the requirements spec.  I would be 
a bit more precise, and note that the CAs that pose a threat are the 
TAs configured into the system, any CAs below those TAs, and any 
other CAs that have been accepted by the client as TAs.

>  > 2. Allowing TLS to work without getting a certificate from one of the
>>  established trust
>>  anchors.

right. also, don't we want the TAs acquired via DANE to be treated, 
for the session in question, to be as god as the configured TAs, 
i.e., yield no error messages/  (I'll duck for the moment the issue 
of EV certs and whether we ought
to have a DANE-validated icon, and what color it should be :-).)

>3. Enhancing privacy by reducing OCSP lookups to CA operators potentially
>keeping statistics on these (as proven recently with Comodogate)
>
>Paul

Presumably #3 applies only to the configured TAs (and their offspring), right?

Steve