Re: [TLS] Commentary on the client authentication presentation slides
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Sun, 02 August 2015 18:29 UTC
Return-Path: <ilari.liusvaara@elisanet.fi>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E753E1A802E for <tls@ietfa.amsl.com>; Sun, 2 Aug 2015 11:29:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYctnzXy4xd2 for <tls@ietfa.amsl.com>; Sun, 2 Aug 2015 11:29:11 -0700 (PDT)
Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EB061A802A for <tls@ietf.org>; Sun, 2 Aug 2015 11:29:11 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id DCB8469996; Sun, 2 Aug 2015 21:29:08 +0300 (EEST)
Date: Sun, 02 Aug 2015 21:29:08 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: David Benjamin <davidben@chromium.org>
Message-ID: <20150802182908.GA29836@LK-Perkele-VII>
References: <20150720141036.GA32204@LK-Perkele-VII> <BLUPR03MB1396E33D0B7ADBED918C54D08C810@BLUPR03MB1396.namprd03.prod.outlook.com> <CAF8qwaAAXv3Ts8JB25e5GB4Xrh8DU2Xg3UCXuDUObgGHubUFUw@mail.gmail.com> <CAF8qwaCz=ZtdANYas+vSatJGzai6AeyiLtw7_H_qP9iXf7dV8g@mail.gmail.com> <20150801084849.GA7162@LK-Perkele-VII> <CAF8qwaBADYYuKNkUnanJOwv3+ZurDHK3QTmQMsyqJ-a4yiSkKw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CAF8qwaBADYYuKNkUnanJOwv3+ZurDHK3QTmQMsyqJ-a4yiSkKw@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/UM8aMI5snfs2sFqSeuynf98RYPA>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Commentary on the client authentication presentation slides
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 02 Aug 2015 18:29:14 -0000
On Sun, Aug 02, 2015 at 03:38:00PM +0000, David Benjamin wrote: > On Sat, Aug 1, 2015 at 4:48 AM Ilari Liusvaara <ilari.liusvaara@elisanet.fi> > wrote: > > > > What I think would be very useful: A way for client to signal it has a > > client certificate it expects to use, regardless of if valid configuration > > is known. The vast majority of times client certificate is used, the > > client knows about that before initiating a connection. > > Unless I misunderstand you, this isn't true for a browser. Browsers only > look for client certificates based on a CertificateRequest message. Some > platforms, like Android, don't even let you list the user's certificate > store. Instead there's an API to show a trusted certificate picker prompt. Well, TLS is also used for non-browser HTTPS and stuff other than HTTPS. There one likely "preconfigures" client certificates if needed. > Or, given the paragraph below, are you suggesting that we'd start a second > connection on receiving CertificateRequest and only advertise it then? > Yeah, that's actually how Chrome implements client auth anyway. We always > start a second connection with a client certificate configured, even if the > server sent CertificateRequest on a renego. It makes a few things simpler. Doesn't that count as "knowing about client certificate before connecting" (even if the knowledge has been received split-second before TLS handshake starts)? Also, signaling can be at application layer, as talked about below. > > IMO, the proper way to handle "this resource requires client certificate" > > is for server to signal that in application protocol and then client to > > establish a new connection with client certificate (or if application > > protocol supports it, do the authentication at application layer without > > ever involving TLS, except for channel binding). > > Certainly. Chrome doesn't implement TLS_RENEG_PERMITTED for HTTP/2, and I > don't want to allow this mechanism for it either. I consider renego-based > per-resource client auth in HTTP/1.1 to be a legacy mistake we're currently > stuck with. (It's the only reason we ever have to renego. In BoringSSL, > we've settled on stripping renego down to the bare minimum needed to > support this. Simplifies a lot of stuff.) Yeah, I consider it (renego auth in HTTP/1.1) a poor idea as well, and I consider it would be actively dangerous in browser HTTP/2 (due to the multipoint nature of the environment and multiplexed nature of HTTP/2)... Good thing it is banned. > I'm guessing Microsoft has different constraints/goals, given this proposal > and TLS_RENEG_PERMITTED, so if we must have it in the transport, I'd rather > it be some opt-in corner that I don't have to deal with. (Applications can > return HTTP_1_1_REQUIRED in HTTP/2 if they really must do per-resource > client auth.) But I do agree this is a problematic mechanism and don't > think it belongs in TLS. Let the application layer do it with a channel > binding. No need for new connections, and no messy questions about scope > and multi-request protocols. Summary of what auth modes I think are needed: - TLS-level client certificate auth on client request on connect (this currently can't be cleanly done, sometimes one even sees that "renego immediately to provoke CR" hack). - Application-level client auth (via CB capability of TLS). -Ilari
- [TLS] Commentary on the client authentication pre… Ilari Liusvaara
- Re: [TLS] Commentary on the client authentication… Andrei Popov
- Re: [TLS] Commentary on the client authentication… Ilari Liusvaara
- Re: [TLS] Commentary on the client authentication… Andrei Popov
- Re: [TLS] Commentary on the client authentication… David Benjamin
- Re: [TLS] Commentary on the client authentication… Ilari Liusvaara
- Re: [TLS] Commentary on the client authentication… David Benjamin
- Re: [TLS] Commentary on the client authentication… Ilari Liusvaara
- Re: [TLS] Commentary on the client authentication… Andrei Popov
- Re: [TLS] Commentary on the client authentication… Ilari Liusvaara
- Re: [TLS] Commentary on the client authentication… Andrei Popov
- Re: [TLS] Commentary on the client authentication… Yoav Nir
- Re: [TLS] Commentary on the client authentication… Andrei Popov
- Re: [TLS] Commentary on the client authentication… David Benjamin
- Re: [TLS] Commentary on the client authentication… Yoav Nir
- Re: [TLS] Commentary on the client authentication… Andrei Popov
- Re: [TLS] Commentary on the client authentication… Ilari Liusvaara
- Re: [TLS] Commentary on the client authentication… Dave Garrett
- Re: [TLS] Commentary on the client authentication… Martin Thomson
- Re: [TLS] Commentary on the client authentication… Andrei Popov
- Re: [TLS] Commentary on the client authentication… Martin Rex