Re: [TLS] Review of draft-wouters-tls-oob-pubkey-00.txt

Paul Wouters <paul@xelerance.com> Thu, 28 July 2011 14:05 UTC

Return-Path: <paul@xelerance.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB5BA21F874A for <tls@ietfa.amsl.com>; Thu, 28 Jul 2011 07:05:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.536
X-Spam-Level:
X-Spam-Status: No, score=-6.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LaGTe9bZg+I for <tls@ietfa.amsl.com>; Thu, 28 Jul 2011 07:05:32 -0700 (PDT)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143]) by ietfa.amsl.com (Postfix) with ESMTP id BA55F21F8793 for <tls@ietf.org>; Thu, 28 Jul 2011 07:05:32 -0700 (PDT)
Received: from newtla.xelerance.com (newtla.xelerance.com [127.0.0.1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by newtla.xelerance.com (Postfix) with ESMTP id 0489057124; Thu, 28 Jul 2011 10:06:31 -0400 (EDT)
Date: Thu, 28 Jul 2011 10:06:30 -0400 (EDT)
From: Paul Wouters <paul@xelerance.com>
To: Eric Rescorla <ekr@rtfm.com>
In-Reply-To: <CABcZeBNggXm443GD9JEO3RU5vTPUyKdMET1x1kaKHk0DbsaGFg@mail.gmail.com>
Message-ID: <alpine.LFD.1.10.1107281000420.648@newtla.xelerance.com>
References: <CABcZeBOVWtTgRcCQ_C8jq_E=LW5nKtUYFrTYyaDcb6-WtdtLWQ@mail.gmail.com> <alpine.LFD.1.10.1107271532220.26845@newtla.xelerance.com> <CABcZeBMbA9nzs-e_sdZ0V7hADJexoDQwvAvQ0LbHACQZAhkk=Q@mail.gmail.com> <alpine.LFD.1.10.1107271706230.27352@newtla.xelerance.com> <CABcZeBMerdSOU7bqGRB2D=cB4CquYW3qxsn781xcpb4AwcSy=A@mail.gmail.com> <alpine.LFD.1.10.1107271935380.28391@newtla.xelerance.com> <CABcZeBNggXm443GD9JEO3RU5vTPUyKdMET1x1kaKHk0DbsaGFg@mail.gmail.com>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8BIT
Cc: tls@ietf.org
Subject: Re: [TLS] Review of draft-wouters-tls-oob-pubkey-00.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jul 2011 14:05:33 -0000

On Thu, 28 Jul 2011, Eric Rescorla wrote:

>> I'm interested in knowing why you consider it "clumsy". Especially because
>> it closely follows the RFC 6066 section 6 extension for supressing of
>> sending CA bundles with "trusted_ca_keys".  That apparent clumsiness
>> passed WGLC and IESG.
>
> What's clumsy is:
>
> (1) It's not generic, even though generic caching is useful.

1) It's generic for allowing an arbitrary authentication method outside PKIX, which
    generic caching does not, as it requires the TLS client to compute hashes over
    PKIX information. In fact, the TLS client has to lie about already having the CA
    bundle in order not to receive the PKIX blob.

2) generic caching is useful and it should also proceed through the IETF process.

> (2) It doesn't support bare keys when the client doesn't know the key, which
> is also useful, if you want to use bare keys at all. In fact, it
> doesn't even appear
> to support cases where the client knows only the key hash, which is common.

That is a use case I had not considered. It is not hard to add support for that.

> Whether it follows 6066 doesn't seem particularly relevant here, since we have a
> worked example of something better.

"something better" only works with your other assumption of "sending and signing
cruft in PKIX is fine". I strongly disagree with that.

Paul