Re: [TLS] Review of draft-wouters-tls-oob-pubkey-00.txt
Paul Wouters <paul@xelerance.com> Thu, 28 July 2011 00:17 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 A069D21F86C2 for <tls@ietfa.amsl.com>;
Wed, 27 Jul 2011 17:17:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.534
X-Spam-Level:
X-Spam-Status: No, score=-6.534 tagged_above=-999 required=5 tests=[AWL=0.066,
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 FMRMzObczDBJ for
<tls@ietfa.amsl.com>; Wed, 27 Jul 2011 17:17:10 -0700 (PDT)
Received: from newtla.xelerance.com (newtla.xelerance.com [193.110.157.143])
by ietfa.amsl.com (Postfix) with ESMTP id C0C0B21F86C1 for <tls@ietf.org>;
Wed, 27 Jul 2011 17:17:09 -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 BDA6357124;
Wed, 27 Jul 2011 20:18:05 -0400 (EDT)
Date: Wed, 27 Jul 2011 20:18:05 -0400 (EDT)
From: Paul Wouters <paul@xelerance.com>
To: Eric Rescorla <ekr@rtfm.com>
In-Reply-To: <CABcZeBMerdSOU7bqGRB2D=cB4CquYW3qxsn781xcpb4AwcSy=A@mail.gmail.com>
Message-ID: <alpine.LFD.1.10.1107271935380.28391@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>
User-Agent: Alpine 1.10 (LFD 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
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 00:17:11 -0000
On Wed, 27 Jul 2011, Eric Rescorla wrote: >> With that reasoning, we'd all be riding horses still. The extension offers a >> way >> out of some overly complex outdated overkill technology, with no impact on >> people >> who wish to remain using horses. > > For some reason this argument is not exactly convincing. Funny, this exact topic came up today at the Privacy Enhancing Technology conference in Waterloo today (that I'm sadly missing because it conflicted with IETF). Do you trust Peter Gutmann's research more? http://www.nspw.org/papers/2006/nspw2006-gutmann.pdf Dealing with X.509 is hard, even for CS people. It might not seem logical to you or anyone else skilled enough to participate with the IETF, but it is true nonetheless. > Regardless, as I said in my review, this seems like it's largely > duplicative of cached info (and in fact, rather clumsier). 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. This extension basically lets the client say "I have trust for this key, no need to send it in PKIX" and the server to simply suppress that message. It's not like this is something complicated as writing up some 80's container format from hell, add an arbitrary inception and expiry date, some magical key purpose bits that will not get used, property bits to be ignored, and some made up conflicting identity for us to later ignore and then grab all of that and wrap it up by signing itself. Seriously, what is "clumsy" is saying "Just make up some unvalidatable data for the PKIX container and then have the client ignore it later". > Is there something here that couldn't be accomplished > by a SPKI cache type in cached-info? You mean apart from dragging in less then just the subjectPublicKeyInfo from ASN.1? Yes we could use a side effect of "caching" or "trusted_ca_keys", though they "MAY" would force every new TLS client to still drag in all of PKIX. I see value in a clear and unambiguous method for a TLS client to say "I am not going to use PKIX validation - do not send me PKIX". As for your 99.99999% figure - if you don't have a technical method to opt out of PKIX validation, then sure, 99.9999% of TLS in 20 years will use PKIX. But it would not proof your point. instead, you would made it happen. I for one hope to see that in 20 years people can just use a "generate key" and "generate TLSA" command, and put that in their DNS zone - even without a CS PHD. Paul
- [TLS] Review of draft-wouters-tls-oob-pubkey-00.t… Eric Rescorla
- Re: [TLS] Review of draft-wouters-tls-oob-pubkey-… Paul Wouters
- Re: [TLS] Review of draft-wouters-tls-oob-pubkey-… Eric Rescorla
- Re: [TLS] Review of draft-wouters-tls-oob-pubkey-… Paul Wouters
- Re: [TLS] Review of draft-wouters-tls-oob-pubkey-… Eric Rescorla
- Re: [TLS] Review of draft-wouters-tls-oob-pubkey-… Paul Wouters
- Re: [TLS] Review of draft-wouters-tls-oob-pubkey-… Eric Rescorla
- Re: [TLS] Review of draft-wouters-tls-oob-pubkey-… Paul Wouters
- Re: [TLS] Review of draft-wouters-tls-oob-pubkey-… Eric Rescorla
- Re: [TLS] Review of draft-wouters-tls-oob-pubkey-… Martin Rex
- Re: [TLS] Review of draft-wouters-tls-oob-pubkey-… Paul Wouters
- Re: [TLS] Review of draft-wouters-tls-oob-pubkey-… Paul Wouters
- Re: [TLS] Review of draft-wouters-tls-oob-pubkey-… Martin Rex
- Re: [TLS] Review of draft-wouters-tls-oob-pubkey-… Nikos Mavrogiannopoulos
- Re: [TLS] Review of draft-wouters-tls-oob-pubkey-… Martin Rex
- Re: [TLS] Review of draft-wouters-tls-oob-pubkey-… Paul Wouters
- Re: [TLS] Review of draft-wouters-tls-oob-pubkey-… Nikos Mavrogiannopoulos
- Re: [TLS] Review of draft-wouters-tls-oob-pubkey-… Paul Wouters
- Re: [TLS] Review of draft-wouters-tls-oob-pubkey-… Martin Rex