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