Re: [keyassure] Objective: Restrictive versus Supplementary Models

Eric Rescorla <ekr@rtfm.com> Wed, 30 March 2011 12:26 UTC

Return-Path: <ekr@rtfm.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 623A428C160 for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 05:26:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.942
X-Spam-Level:
X-Spam-Status: No, score=-102.942 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, 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 wHQnwx56uLN7 for <keyassure@core3.amsl.com>; Wed, 30 Mar 2011 05:25:57 -0700 (PDT)
Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 8E66128C121 for <keyassure@ietf.org>; Wed, 30 Mar 2011 05:25:57 -0700 (PDT)
Received: by iwn39 with SMTP id 39so1400016iwn.31 for <keyassure@ietf.org>; Wed, 30 Mar 2011 05:27:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.42.75.196 with SMTP id b4mr1164242ick.372.1301488054709; Wed, 30 Mar 2011 05:27:34 -0700 (PDT)
Received: by 10.42.217.2 with HTTP; Wed, 30 Mar 2011 05:27:34 -0700 (PDT)
In-Reply-To: <0AE869F3-0BBB-485F-8CDD-EC1B70EBB9B2@bbn.com>
References: <AANLkTik1Uzd8XSZzopBBDHywrhSjsBQYxC91BZXdkMwg@mail.gmail.com> <0AE869F3-0BBB-485F-8CDD-EC1B70EBB9B2@bbn.com>
Date: Wed, 30 Mar 2011 14:27:34 +0200
Message-ID: <AANLkTi=r884poth6pAXPtot0XVuCXfEprcYQTDdPLR1W@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
To: "Richard L. Barnes" <rbarnes@bbn.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
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 12:26:01 -0000

On Wed, Mar 30, 2011 at 2:18 PM, Richard L. Barnes <rbarnes@bbn.com> wrote:
> I agree with Ekr and Steve that these are the right goals.  I don't have any further goals to add.  Just trying to re-state in bullet-point form:
>
> 1. Cert-lock / CA-lock
> 1.1. Use case:
> 1.1.1. Client initiates TLS connection and gets server cert chain
> 1.1.2. Client performs normal TLS/PKIX validation on cert chain
> 1.1.3. Client retrieves DANE records from DNS
> 1.1.4. DANE records specify EE or CA certs that MUST be present in cert chain
> 1.1.5. Client verifies that TLS cert chain meets DANE constraints
> 1.2. Security goal: Defend against issuance of other certs for this domain
> 1.3. DNSSEC RECOMMENDED, not REQUIRED; attacker can only cause connection failure
>
> 2. Domain-managed authentication
> 2.1. Use case:
> 2.1.1. Client retrieves DANE records from DNS
> 2.1.2. DANE records specify Trust Anchors for PKIX certificate validation
> 2.1.3. Client adds DANE CA certs to TA store (optionally, drops all others)
> 2.1.3. Client initiates TLS connection and gets server cert chain
> 2.1.4. Client performs normal TLS/PKIX validation on cert chain

I don't think this last point has consensus. Certainly, in the case where the
certificate in question is the terminal certificate, I think at least
some people
don't care if it's invalid from a PKIX perspective.

-Ekr

> 2.2. Security goal: Allow TLS to work without pre-configured TAs
> 2.3. DNSSEC REQUIRED; attacker can insert bogus TAs
>
>
>
>
>
> On Mar 30, 2011, at 10:48 AM, 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).
>> 2. Allowing TLS to work without getting a certificate from one of the
>> established trust
>> anchors.
>>
>> In the first case, the idea would be that the relying party would go
>> through its ordinary validation
>> logic and if that failed, would reject the certificate. However, if
>> the validation succeeded,
>> it would check DNS and if that check failed, would then reject the
>> certificate. Only if both
>> checks succeeded would the certificate be accepted. [0] The objective
>> of this type of
>> mechanism would be simply to defend against unauthorized certificate issuance.
>> Note that in this case, the DANE data need not be DNSSEC secured,
>> because an attacker
>> who tampers with it will solely be able to cause a connection failure,
>> and in many cases
>> (TLS, SSH, etc.) an attacker with those capabilities can tamper with
>> the A record and
>> block the connection that way.
>>
>> In the second case, the intention is to allow clients to effectively
>> bypass the existing trust
>> hierarchy by injecting a new trust point via the DNS. Thus, either the
>> certificate validation
>> simply will not be used at all (in the case where a terminal
>> certificate is provided) or will be
>> used up to a newly inserted trust anchor. In either case, the
>> presumptive rationale here
>> is that it's too inconvenient to deal with the existing CAs and that
>> DANE will be easier.
>> This version of DANE *does* need to be protected via DNSSEC because tampering
>> with these records allows the attacker to impersonate the
>> authenticating party to the
>> relying party.
>>
>>
>> The draft to some extent conflates these two objectives, since it
>> *both* injects a new trust
>> anchor and restricts the list of potential certificates. It does not
>> allow you to simply restrict
>> the list of CAs/certificates without also injecting a new trust point.
>>
>>
>> Opinion follows:
>> For my money the most important driving use case for this work is the
>> first case, for two
>> reasons. First, it's the more pressing problem since it's not really
>> *that* hard to get a
>> certificate from one of the existing CAs, but this also means that we
>> have to worry about
>> mis-issue by misbehaving CAs, as we have recently seen. Second, the
>> incremental deployment
>> story is much easier, since clients which don't speak DANE will just
>> not be protected against
>> attack, whereas in the second case clients which don't speak DANE will
>> experience certificate
>> errors when connecting to a DANE-only site.
>>
>> -Ekr
>>
>>
>> [0] The checks can be done in either order. This is only for clarity.
>> _______________________________________________
>> keyassure mailing list
>> keyassure@ietf.org
>> https://www.ietf.org/mailman/listinfo/keyassure
>
>