Re: Client Certificates - re-opening discussion

Yoav Nir <> Mon, 21 September 2015 06:13 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 115221A00DB for <>; Sun, 20 Sep 2015 23:13:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.011
X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id eqTyF1DkQc5l for <>; Sun, 20 Sep 2015 23:13:24 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EE1AE1A007D for <>; Sun, 20 Sep 2015 23:13:23 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1ZduId-0006BA-F7 for; Mon, 21 Sep 2015 06:10:03 +0000
Resent-Date: Mon, 21 Sep 2015 06:10:03 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZduIW-0005Su-Qv for; Mon, 21 Sep 2015 06:09:56 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZduIV-00074W-Bu for; Mon, 21 Sep 2015 06:09:56 +0000
Received: by wicfx3 with SMTP id fx3so95850001wic.0 for <>; Sun, 20 Sep 2015 23:09:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=31J/OtokDrY9wAryDsV2jfQkSu6hUqz0vakq0An6OrM=; b=kgt0sHCBg6PLz1Yw4elbc2Z0zpFTkPUm0bx0asXa/3X7PrucJ2Q03BypqaqQz+pglI 4UIV4pi2XYwFKrvHvBBlVhIIgqCi5T4XO4WFdv7qmsmxHojI/hM15/PRDWxkRFFCYU4U qEUm+D6Vkp+YY7eIIBX5YMlsXZ1CmN+XTACXAsnKkV00zTuP8Ibgq9tm8PF076GHZg6J g+QuF27DCOikekFqjri3GiRd3NQJhuSfYrs9auNTtEvFEXbYI16fXw/Nia6DD/vKYEft 1v+M90aBATuRafPibtqOJ4lvWXaK/yrOQY2GZbKbKRZ+7FQfijaUZQ0D6AY/LEFOlN1j vEqw==
X-Received: by with SMTP id n8mr24260181wjq.134.1442815768796; Sun, 20 Sep 2015 23:09:28 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id ja14sm734333wic.7.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 20 Sep 2015 23:09:27 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_73E6F337-68FF-406A-9834-6B7458841420"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Mon, 21 Sep 2015 09:09:18 +0300
Cc: Eric Rescorla <>, Stefan Eissing <>, Ilari Liusvaara <>, Mark Nottingham <>, Henry Story <>, HTTP Working Group <>
Message-Id: <>
References: <> <> <> <> <20150918205734.GA23316@LK-Perkele-VII> <> <> <> <> <>
To: Mike Bishop <>
X-Mailer: Apple Mail (2.2104)
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.3
X-W3C-Hub-Spam-Report: AWL=-0.593, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1ZduIV-00074W-Bu eb88893075b748421762dad2d2ba3314
Subject: Re: Client Certificates - re-opening discussion
Archived-At: <>
X-Mailing-List: <> archive/latest/30241
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

> On Sep 21, 2015, at 6:30 AM, Mike Bishop <> wrote:
> Better than renegotiation?  Nothing – which is the point.  Renegotiation worked, and our first step is parity with downlevel.

So if this working group rejected renegotiation (which worked), why would this new mechanism be acceptable?

> Renegotiation, however, attempted to bring many functions together, some of which made the TLS WG uncomfortable.  This PR creates a more scoped feature targeted at only the presentation of client credentials to the server, which is the feature we actually need.

That’s a good thing, but IMO it doesn’t matter to httpbis.

> It sounds like, in part, we have different understandings of why renegotiation was prohibited in the first place.  You argue it was prohibited because there’s some inherent indeterminacy, particularly if the application layer doesn’t stall.  I’d argue that that indeterminacy can and should be handled by the application that knows what resources care about the client’s identity and which don’t.

Having the application layer stall doesn’t help. The client requests resources A, B, and C. Resource B requires client authentication. By the time the application stalls, waiting for the client authentication, resources A and C may not have been noticed, or the requests may have been serviced, with A and C in a buffer waiting to be encrypted, or the requests may have been serviced and encrypted and on the way back to the client. A and C may be received in the authenticated or the non-authenticated context. Imagine, for example, that A is a bit of HTML that says “Hello, guest” in the unauthenticated context, or “Hello, Mike” after authentication. You can get the certificate picker and still see the “Hello, guest” on the page.

What’s more, I think HTTP authentication has the same issue. If one request gets processed and generates a 401 with WWW-Authenticate, other resources may or may not have been serviced. You can fix this by carefully designing the application so that you don’t load resources that are different based on state at the same time as the authentication is going on.

> If multiple requests cause the server application to query the HTTP layer for the client’s certificate, then all those requests will wait until the client authentication has completed, just as they would have on a non-multiplexed connection.  Where multiplexing adds a new wrinkle is that, under HTTP/1.1, those connections that didn’t require authentication would proceed without interruption until they’re used for a protected request.
> Perhaps the fundamental question is, when does the client need to know that the server had seen the certificate prior to generating the response?  In HTTP/1.1 over TLS 1.x, it could know that the server had seen it, but couldn’t know whether the server cared.

Does it matter for the client?