Re: [keyassure] Bare keys again

Paul Wouters <paul@xelerance.com> Mon, 21 March 2011 02:16 UTC

Return-Path: <paul@xelerance.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 577A228C107 for <keyassure@core3.amsl.com>; Sun, 20 Mar 2011 19:16:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.59
X-Spam-Level:
X-Spam-Status: No, score=-2.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599]
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 6phleN1m7o3N for <keyassure@core3.amsl.com>; Sun, 20 Mar 2011 19:16:53 -0700 (PDT)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by core3.amsl.com (Postfix) with ESMTP id 14A8A28C0F0 for <keyassure@ietf.org>; Sun, 20 Mar 2011 19:16:52 -0700 (PDT)
Received: from tla.xelerance.com (tla.xelerance.com [193.110.157.130]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id BFD06C586; Sun, 20 Mar 2011 22:18:22 -0400 (EDT)
Date: Sun, 20 Mar 2011 22:18:22 -0400 (EDT)
From: Paul Wouters <paul@xelerance.com>
To: Matt McCutchen <matt@mattmccutchen.net>
In-Reply-To: <1300669586.2117.12.camel@localhost>
Message-ID: <alpine.LFD.1.10.1103202211390.20162@newtla.xelerance.com>
References: <92D68A5E-5CB7-4C80-8D7B-0B8D55D93608@kumari.net> <alpine.LFD.1.10.1103201932370.20162@newtla.xelerance.com> <9D285351-8D73-4C15-BE2C-5DF731C08DCE@vpnc.org> <alpine.LFD.1.10.1103202028110.20162@newtla.xelerance.com> <1300669586.2117.12.camel@localhost>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: keyassure@ietf.org, Paul Hoffman <paul.hoffman@vpnc.org>
Subject: Re: [keyassure] Bare keys again
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: Mon, 21 Mar 2011 02:16:54 -0000

On Sun, 20 Mar 2011, Matt McCutchen wrote:

>> That difference is muddy anyway, isn't it? Isn't a self-signed certificate a CA?
>
> It is not used to sign any certificates (except itself, but that is
> irrelevant because no one ever relies on the self signature), so no.

So if instead, I would send a list of 1 trusted_root_ca with the selfsigned
Ca, then thatwould be "in spirit" or 6066?

>> The client sends its hello message saying "I have all the CA root trust
>> anchors I need from pre-agreement".  Whether that means it got information
>> from DNSSEC/DANE or elsewhere does not matter. What matters is, is that
>> the client can start the TLS handshake without the server sending any
>> PKIX certs.
>
> How does this look at the message level?  The server sends a Certificate
> message containing a zero-length sequence of certificates?

No, it sends an Hello TLS extension of type "trusted_ca_keys" containing
in its "extension_data" a 'struct' TrustedAuthorities containing one
"TrustedAuthority" that has an "IdentifierType" of "agreed" which is
'struct {}'

>  This is not
> at all what is envisioned by RFC 6066.  To say that your scheme involves
> no TLS protocol changes is a little misleading: you are using existing
> messages but dramatically repurposing them.

Not at all! According to 6066:

6. Trusted CA Indication


    Constrained clients that, due to memory limitations, possess only a
    small number of CA root keys may wish to indicate to servers which
    root keys they possess, in order to avoid repeated handshake
    failures.

    In order to indicate which CA root keys they possess, clients MAY
    include an extension of type "trusted_ca_keys" in the (extended)
    client hello.  The "extension_data" field of this extension SHALL
    contain "TrustedAuthorities" where:

       struct {
           TrustedAuthority trusted_authorities_list<0..2^16-1>;
       } TrustedAuthorities;

       struct {
           IdentifierType identifier_type;
           select (identifier_type) {
               case pre_agreed: struct {};
               case key_sha1_hash: SHA1Hash;
               case x509_name: DistinguishedName;
               case cert_sha1_hash: SHA1Hash;
           } identifier;
       } TrustedAuthority;

       enum {
           pre_agreed(0), key_sha1_hash(1), x509_name(2),
           cert_sha1_hash(3), (255)
       } IdentifierType;

       opaque DistinguishedName<1..2^16-1>;

    Here, "TrustedAuthorities" provides a list of CA root key identifiers
    that the client possesses.  Each CA root key is identified via
    either:

    -  "pre_agreed": no CA root key identity supplied.

> IMO, this scheme should be
> standardized and subjected to the attendant level of scrutiny before we
> consider supporting it in DANE.

The only thing that is different here is that I am using a client contraint
that is different from the examples listed at the start of section 6. Was that
list supposed to be an all encompassing list?

I did not even add "pre_agreed". It is already there!

Paul