Re: [TLS] Commentary on the client authentication presentation slides

David Benjamin <davidben@chromium.org> Sun, 02 August 2015 15:38 UTC

Return-Path: <davidben@google.com>
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 8ADB31A87BC for <tls@ietfa.amsl.com>; Sun, 2 Aug 2015 08:38:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
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 NBaqP2lMgdMD for <tls@ietfa.amsl.com>; Sun, 2 Aug 2015 08:38:11 -0700 (PDT)
Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78BA1A8783 for <tls@ietf.org>; Sun, 2 Aug 2015 08:38:10 -0700 (PDT)
Received: by ioeg141 with SMTP id g141so125105059ioe.3 for <tls@ietf.org>; Sun, 02 Aug 2015 08:38:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=ECnFlzvipYxb7kv6r0ITn7bHQXe1KHNga8tGOtFBrNk=; b=jEFGFhcuMXC9bEdt3hgg1hAgD/saTkU7BIqtx+1+SQqRp4jvqiY+E5YMNbneBpCDQk 1ez5RGijU+tTb+ADJriBz/1NuS75rFIdPIMTMWz+TEhk81aX0ACmSw7+ppplcSksRbQi Ff/LkkLICnF+ZKzdPYKR5Pkz2gKyr4KJY4C40=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=ECnFlzvipYxb7kv6r0ITn7bHQXe1KHNga8tGOtFBrNk=; b=E4zP88DfKE4b+6ioNd0U05bV5xxi5dYA+7OfGVxen+GEHXAb3qv59yjd3zUgNnlbvR GbEj5HcgCRNAuKupVh9QILG/ymU4DsBNecUrptm9uVH8LZDwbK56bV+OnBnz3TBfpp1b vXlFDCkFlhO3G/DrXhaaVXMzTE+nBwijk8ecKBMPE7nwlchQnxfHHc53xb31cnX/fdF3 2JX/rnpZpk2KQJp1ps2iNkyAYALsAvGzh8BldSQ2/PbbqqyROFxhWks6lEp33K+Hh0LV JdKEwFJUxLcr+8r3LASLWsQ4sZFOHOP6ALCQwA5xuevyB2CO0ZmQ1TRNX94L6T69+H2T 9t7A==
X-Gm-Message-State: ALoCoQkSKZGZPaOtGXiiPanHS0eaXk79pAtxCPB/esylT8BMCDfarktGaw3ZCEvF6Lyn4Cn6LnK2
X-Received: by 10.107.137.95 with SMTP id l92mr16022265iod.2.1438529890168; Sun, 02 Aug 2015 08:38:10 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <20150801084849.GA7162@LK-Perkele-VII>
From: David Benjamin <davidben@chromium.org>
Date: Sun, 02 Aug 2015 15:38:00 +0000
Message-ID: <CAF8qwaBADYYuKNkUnanJOwv3+ZurDHK3QTmQMsyqJ-a4yiSkKw@mail.gmail.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Content-Type: multipart/alternative; boundary=001a113ecbfe1a67e4051c55d7b8
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ng-ZAIzru1eRhM2cJ0OqPBj5aQ0>
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 15:38:12 -0000

On Sat, Aug 1, 2015 at 4:48 AM Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
wrote:

> > On Tue, Jul 28, 2015 at 6:28 PM David Benjamin <davidben@google.com>
> wrote:
> >
> > > Are you intending that this mechanism be enabled by default for HTTP/2
> or
> > > would the prohibition against renego still apply? Without any way for
> the
> > > client to tie the CertificateRequest to the HTTP request that
> triggered it,
> > > this mechanism would have many of the same problems as renego as far as
> > > HTTP/2 is concerned. (I realize Microsoft has a draft floating around
> for a
> > > TLS_RENEG_PERMITTED HTTP/2 setting. The setting can control this too I
> > > suppose.)
>
> Even if there would be way to tie it to request that triggered the request,
> it would still IMO have some of the nastiest problems of renegotiation,
> especially in context of HTTP/2 in web (the privilege involved is almost
> impossible to handle in any sane way).
>
>
> 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.

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.


> 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.)

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.

David