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

Yoav Nir <> Mon, 10 August 2015 17:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AF4661B3A72 for <>; Mon, 10 Aug 2015 10:28:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QR3XwGLm45Wm for <>; Mon, 10 Aug 2015 10:28:22 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 124431B3A75 for <>; Mon, 10 Aug 2015 10:28:21 -0700 (PDT)
Received: by wibhh20 with SMTP id hh20so160564112wib.0 for <>; Mon, 10 Aug 2015 10:28:18 -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 :content-transfer-encoding:message-id:references:to; bh=o9+FVPhtTCRFN/ucBCjuFx35JgheYGyXvMahNwUhyrQ=; b=H5hAr7Ghmt6P14CTFe5gmfQPnRH6hYWVJfrPR+i8Q9r1kNe3Hmrv5oahQg+9dqNpIF zlttGZ7N1dd/68SfxwYt/5nnxy2He6WWAn8OwzcGyB3HcjFgy1V0lFuKBbloLJ3pD3or WRl9FyK4LiecyIjRTSDfKqo/GFjNXjFybl1oafhAERtVCM+cfhzzlhWKxdAB+TgcpTm3 DkDV2FHbZ/nRduytIT+ON6hM4/vwtrFVNpf2yYRNhCwvPiH48vams953TpN5hHT5z9Xa /1dnL6t7DjmCRp5ekrJ9AczmU1GE1XgswzOoCy9oG060YCCL7+SawxscklOq0gdQayY+ fxYg==
X-Received: by with SMTP id hm18mr25683754wib.45.1439227698848; Mon, 10 Aug 2015 10:28:18 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id b13sm14759472wic.15.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 10 Aug 2015 10:28:17 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Mon, 10 Aug 2015 20:28:14 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <20150720141036.GA32204@LK-Perkele-VII> <> <> <> <20150801084849.GA7162@LK-Perkele-VII> <> <20150802182908.GA29836@LK-Perkele-VII> <> <20150808090351.GA14947@LK-Perkele-VII> <>
To: Andrei Popov <>
X-Mailer: Apple Mail (2.2102)
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] Commentary on the client authentication presentation slides
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 10 Aug 2015 17:28:23 -0000

> On Aug 10, 2015, at 8:10 PM, Andrei Popov <> 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.