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

David Benjamin <davidben@chromium.org> Mon, 10 August 2015 19:34 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 A14A81A0366 for <tls@ietfa.amsl.com>; Mon, 10 Aug 2015 12:34:06 -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 qHxAP-Xth6mY for <tls@ietfa.amsl.com>; Mon, 10 Aug 2015 12:34:04 -0700 (PDT)
Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (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 749E21A028A for <tls@ietf.org>; Mon, 10 Aug 2015 12:34:04 -0700 (PDT)
Received: by iodd187 with SMTP id d187so180112182iod.2 for <tls@ietf.org>; Mon, 10 Aug 2015 12:34:03 -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=2FUCNjmjE7q5HTcABhowwMAYwWoMJjrmqPxfx3TvzF4=; b=FOqVx1krBukjLIT77OAdyiRDhbcs91O52yrINXsdl1zlwEkNSyJMMNkzeF0zdPAFvO XO0023jw7Xy+0ehiaiDnYSF/kWsesjh/qQbxsaHNmLBsMdC6R+p4CS5gwKa0p3AsPAOk T6PieaYm/f08gR5AffSdkuzxEGMPsekHI2T0g=
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=2FUCNjmjE7q5HTcABhowwMAYwWoMJjrmqPxfx3TvzF4=; b=CdOrubAo+QXt6P5CHqGpLhQue2n8dM5CH4U4lroZwMa7OElCYs4Ab5r2HcYPCUza/G zgRpOaPBLwukgExWvja7hKSM9rJNHGSy+iTzpikSJwOiHYnSA6pyxJQR158Qn4QLBXNS rUPXjnIa3UoDRj0/WKQw6NNw9NgBDyOd7Z5ZiIxu2O30fw+YMbsM3cam/XoVpLs/zntu I5G/PlO0FXzpp7Shxl4C6MR5BEe77D5d2XkD7IgR7AE2yUoadyuOQHZDkRiFAcZcTbeB WaXmzyaZlWTFtryzwy2tHy64BdoBonmCfdRgrExcHlKAua2+ZgVILTw7//035hRQ3Kkf TYZQ==
X-Gm-Message-State: ALoCoQlrJF0KT5LsWql2lm+A6SOvgvIymMw3+XGQxqN5DVL3MecXq8ia7XPJF1a+ZAy1nCbqkTYs
X-Received: by 10.107.9.142 with SMTP id 14mr21912869ioj.142.1439235243500; Mon, 10 Aug 2015 12:34:03 -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> <CAF8qwaBADYYuKNkUnanJOwv3+ZurDHK3QTmQMsyqJ-a4yiSkKw@mail.gmail.com> <20150802182908.GA29836@LK-Perkele-VII> <BLUPR03MB139631EC62ABC0732E0C70CA8C760@BLUPR03MB1396.namprd03.prod.outlook.com> <20150808090351.GA14947@LK-Perkele-VII> <BLUPR03MB1396C25B04D58DB47C9676AE8C700@BLUPR03MB1396.namprd03.prod.outlook.com> <7598CD3F-F111-4457-B225-4B7B12287437@gmail.com> <BLUPR03MB139693D20222F5459EFC907F8C700@BLUPR03MB1396.namprd03.prod.outlook.com>
In-Reply-To: <BLUPR03MB139693D20222F5459EFC907F8C700@BLUPR03MB1396.namprd03.prod.outlook.com>
From: David Benjamin <davidben@chromium.org>
Date: Mon, 10 Aug 2015 19:33:53 +0000
Message-ID: <CAF8qwaAFuzrM9CasaSu2qDXf5fFc2ROZDYwE7AaOxAnJO27W5w@mail.gmail.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>, Yoav Nir <ynir.ietf@gmail.com>
Content-Type: multipart/alternative; boundary=001a113f8cf6700dd9051cfa11b9
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/VNuMqNyAnj6kugogtQjstkhhDU4>
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: Mon, 10 Aug 2015 19:34:06 -0000

On Mon, Aug 10, 2015 at 3:05 PM Andrei Popov <Andrei.Popov@microsoft.com>
wrote:

> > Ideally a solution would work with HTTP/1 over TLS 1.3, HTTP/2 over TLS
> 1.3, HTTP/2 over TLS 1.2, and for completeness HTTP/1 over TLS 1.2.
> Correct, anything less than this will create deployment problems.
>

But this proposal is only suitable for HTTP/1 over TLS 1.3 anyway. It can't
be used for HTTP/2 over TLS 1.3 as a client has no way to correlate
transport-level certificate requests with the HTTP request. This is part of
why renego was rightly banned for HTTP/2. Otherwise you need to show a
contextless prompt on a client, and that's really bad UI. Chrome tries very
hard to avoid those.

I would grudgingly consider it acceptable for HTTP/1 over TLS 1.3, but only
because it's no worse than the renego one and we're stuck with that legacy
mistake right now. If that weren't the case, I wouldn't want it in HTTP/1
either. Changing connection-level state mid-stream underneath a
multi-request protocol is very messy, particularly when combined with
socket-pooling optimizations.

Why not do this using HTTP's own auth framework? Have the client sign
something which includes a channel binding, placing it and the certificate
chain in an Authorization header. You could even transition to it in TLS
1.2 deployments, provided EMS is negotiated. When TLS 1.3 and EMS are not
negotiated, fall back to the legacy thing.

David


> > I’d like to point out that I am very interested in this use case, but
> I’m not sure that this is the solution.
> I'm open to alternatives that fix the broken use case.
>
> > We still get a race condition where several requests might be answered
> before, after or during authentication depending on the timing of the TLS
> handshake message vs the HTTP messages.
> The idea is that before answering a request that requires client auth, the
> server checks if a client cred is available. If there is no suitable client
> cred available, the request is blocked until the client authenticates. This
> does not necessarily have to block other requests that do not require
> client auth.
>
> Cheers,
>
> Andrei
>
> -----Original Message-----
> From: Yoav Nir [mailto:ynir.ietf@gmail.com]
> Sent: Monday, August 10, 2015 10:28 AM
> To: Andrei Popov <Andrei.Popov@microsoft.com>
> Cc: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>fi>; tls@ietf.org
> Subject: Re: [TLS] Commentary on the client authentication presentation
> slides
>
>
> > On Aug 10, 2015, at 8:10 PM, Andrei Popov <Andrei.Popov@microsoft.com>
> wrote:
> >
> > Hi Ilari,
> >
> >> What sort of usecase you have in mind for this?
> > This is to support a fairly common website design where the landing page
> does not require client auth, but subsequent request to a protected
> resource triggers client authentication within an existing TLS connection.
> > In TLS<=1.2, this was accomplished via renegotiation. In TLS1.3, there
> is no renegotiation, so we need an alternative solution if we want to
> support these existing sites over TLS1.3.
>
> I’d like to point out that I am very interested in this use case, but I’m
> not sure that this is the solution.
>
> Such sites were first broken by HTTP/2 which forbade renegotiation. Then
> they were broken again by TLS 1.3 that does not include renegotiation.
>
> Ideally a solution would work with HTTP/1 over TLS 1.3, HTTP/2 over TLS
> 1.3, HTTP/2 over TLS 1.2, and for completeness HTTP/1 over TLS 1.2.
>
> Assuming that HTTP/2 is the HTTP of the future (meaning that relegating
> these sites to HTTP/1 is a temporary thing), I don’t think that this new
> mechanism fixes the issue with renegotiation that caused httpbis to reject
> its usage. We still get a race condition where several requests might be
> answered before, after or during authentication depending on the timing of
> the TLS handshake message vs the HTTP messages.
>
> It would be useless IMO to create an alternate renegotiation in TLS only
> for it to not be used in HTTP/2.
>
> Yoav
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>