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

Dave Garrett <> Tue, 11 August 2015 06:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C3CB11A024E for <>; Mon, 10 Aug 2015 23:06:02 -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 S2Me98D2hbGL for <>; Mon, 10 Aug 2015 23:06:01 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4DFD51A0248 for <>; Mon, 10 Aug 2015 23:06:01 -0700 (PDT)
Received: by qkcs67 with SMTP id s67so43742907qkc.1 for <>; Mon, 10 Aug 2015 23:06:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=KIsaZdeesHQjZFHnCZj+Nx0BXVx26G8cumk3Im9GSNY=; b=kTkEy00J3vyZTUwUj6H/zlBfpx2JwGbQLQ4/WwAaVOS8di64tbqiX7jLzaXOSjaTA+ HCDr3mjmz4Fk8ez9A39SJnkf1/4QeZbrOGW4eHc0PCgOntNjb4ZUwnyVoQix+0cSrOEs mIMNlSpyRsSP5KUG+AGc69cSwvCtd/FnTPmc9r0PavRHnldSNloiAYO+YPd/7XJAtTvr CPeyEKwgtiMXlTnNqL4/09tFTqqtODslkTGlgAVCm+Md9okHpdT0EqmNDe9Q6MCtM0vj Ggt0ulagz8rXLAPEVzaaiR02LwJasmHDTRtSXGbTYLiz+x/IflOipgHIBZeQQ1NWBV2r WC/Q==
X-Received: by with SMTP id k84mr11664904qkh.15.1439273160560; Mon, 10 Aug 2015 23:06:00 -0700 (PDT)
Received: from dave-laptop.localnet ( []) by with ESMTPSA id 65sm582478qks.30.2015. (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 10 Aug 2015 23:06:00 -0700 (PDT)
From: Dave Garrett <>
Date: Tue, 11 Aug 2015 02:05:58 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <20150720141036.GA32204@LK-Perkele-VII> <20150808090351.GA14947@LK-Perkele-VII> <>
In-Reply-To: <>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <>
Archived-At: <>
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 06:06:02 -0000

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.