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

Martin Thomson <> Tue, 11 August 2015 16:39 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 05DA91AC3E5 for <>; Tue, 11 Aug 2015 09:39: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 COpBUQJLExfG for <>; Tue, 11 Aug 2015 09:39:21 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c04::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1210C1A8AF7 for <>; Tue, 11 Aug 2015 09:39:21 -0700 (PDT)
Received: by lbcbn3 with SMTP id bn3so22157982lbc.2 for <>; Tue, 11 Aug 2015 09:39:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=liV9z4iQJGyJlzptVrWTt6pp+1kM+MSrVwoaks5H+DM=; b=G6yiW00st5ZxzUTVACUvT+EtjkBi8vEWyb74xE2TjXnOglYaproNrw/t79Nsu/VAv4 jlCk/YZ7703UBD+e8i0fwsWlVNWlZWVFkYMjLE+Js60QB8l/YBn3VIHjVJJD9Cnc0OGr BfWTUwcifF1YGrR/R0N9R6x/7o4f8NdpAOJlHjZ+HEcG0ShAEbYJr4mWjPoqI+zK4zqK YNTgJtg2J1GxtvRtK1e0Y6u1cZoNNQtNuvOrNjy+nYOXTls2d156r63yJezqGT8dOgUQ Qs6wnqE6xm2Hohosuk+cNqAAXxIL2MwjhSWUsd6EspTK8q8e0lPRhZNdh+JEU2PjRKAd T+qQ==
MIME-Version: 1.0
X-Received: by with SMTP id g5mr27440245laa.101.1439311159493; Tue, 11 Aug 2015 09:39:19 -0700 (PDT)
Received: by with HTTP; Tue, 11 Aug 2015 09:39:19 -0700 (PDT)
In-Reply-To: <>
References: <20150720141036.GA32204@LK-Perkele-VII> <20150808090351.GA14947@LK-Perkele-VII> <> <>
Date: Tue, 11 Aug 2015 09:39:19 -0700
Message-ID: <>
From: Martin Thomson <>
To: Dave Garrett <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Tue, 11 Aug 2015 16:39:23 -0000

Before people get too far down that road, here:

Andrei has made it clear that these do not work for his use case (I'm
not yet convinced that they are inadequate, but I am convinced of the
fact that Andrei thinks that they are inadequate ;).


This is well-trodden ground.

On 10 August 2015 at 23:05, Dave Garrett <> wrote:
> On Monday, August 10, 2015 01:10:38 pm Andrei Popov wrote:
>> > 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.
> This is just an idea, but what about just allowing a renegotiation-like mechanism via 0-RTT with PSK resumption to be triggered on a TLS alert or HTTP response code? The rough idea would be like this:
> 1) client connects to server and fetches public resources
> 2) client requests restricted resource; server sends auth required response (TLS alert or HTTP code)
> 3) client creates a replacement connection using PSK-based resumption and early data in the first flight for the request along with the client cert.
> There's a 1 roundtrip cost in there for a new TCP connection, which could possibly be optimized away by using TCP fast open.
> This general concept is relatively simple in comparison to doing something mid-connection. Instead of attempting to renegotiate on an existing connection, just make creation of resumed connections cheap enough to start over with client auth in the handshake from the start.
> It's a very rough idea, but I'm wondering if it sounds like something worth discussing.
> Dave
> _______________________________________________
> TLS mailing list