Re: [keyassure] Objective: Restrictive versus Supplementary Models

Martin Rex <mrex@sap.com> Wed, 30 March 2011 18:42 UTC

Return-Path: <mrex@sap.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 0791628C190 for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 11:42:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.219
X-Spam-Level:
X-Spam-Status: No, score=-10.219 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8]
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 NNwuLHC19IlE for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 11:42:24 -0700 (PDT)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by core3.amsl.com (Postfix) with ESMTP id F1FD328C18B for <keyassure@ietf.org>; Wed, 30 Mar 2011 11:42:23 -0700 (PDT)
Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id p2UIhlGn024399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Mar 2011 20:43:47 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201103301843.p2UIhlYk017803@fs4113.wdf.sap.corp>
To: rbarnes@bbn.com
Date: Wed, 30 Mar 2011 20:43:46 +0200
In-Reply-To: <9F44BE94-7AC3-48F4-8A42-0748CA40A29D@bbn.com> from "Richard L. Barnes" at Mar 30, 11 01:54:48 pm
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-SAP: out
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
Reply-To: mrex@sap.com
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 18:42:25 -0000

Richard L. Barnes 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).
> >> 2. Allowing TLS to work without getting a certificate from one of the
> >> established trust
> >> anchors.
> > 
> > 3. Enhancing privacy by reducing OCSP lookups to CA operators potentially
> > keeping statistics on these (as proven recently with Comodogate)
> 
> This is isomorphic to the use of domain-issued certs, case 2 above.
> If the TLS server is using a CA-issued cert, the client *should* use
> OCSP (or a CRL) to make sure it hasn't been revoked.  With a
> domain-issued cert, there's probably no place to go for OCSP.

Looking at the recent rush of Browser patches to address Commodogate,
I'm somewhat in doubt that certificate revocation ever really worked.

A sufficiently powerful attacker might be able to interfere with
OCSP lookups and CRL download attempts (making them fail at the
network level).  The necessesity to blacklist the mis-issued certs
seems to indicate that most browser did not (and maybe still don't)
check server certs for revocation when encountering a network error
trying to access OCSP or CRL download URLs from the server's cert.


-Martin