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

Martin Thomson <martin.thomson@gmail.com> Tue, 11 August 2015 16:39 UTC

Return-Path: <martin.thomson@gmail.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 05DA91AC3E5 for <tls@ietfa.amsl.com>; Tue, 11 Aug 2015 09:39:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COpBUQJLExfG for <tls@ietfa.amsl.com>; Tue, 11 Aug 2015 09:39:21 -0700 (PDT)
Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (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 1210C1A8AF7 for <tls@ietf.org>; Tue, 11 Aug 2015 09:39:21 -0700 (PDT)
Received: by lbcbn3 with SMTP id bn3so22157982lbc.2 for <tls@ietf.org>; Tue, 11 Aug 2015 09:39:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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 10.152.7.37 with SMTP id g5mr27440245laa.101.1439311159493; Tue, 11 Aug 2015 09:39:19 -0700 (PDT)
Received: by 10.25.162.198 with HTTP; Tue, 11 Aug 2015 09:39:19 -0700 (PDT)
In-Reply-To: <201508110205.58799.davemgarrett@gmail.com>
References: <20150720141036.GA32204@LK-Perkele-VII> <20150808090351.GA14947@LK-Perkele-VII> <BLUPR03MB1396C25B04D58DB47C9676AE8C700@BLUPR03MB1396.namprd03.prod.outlook.com> <201508110205.58799.davemgarrett@gmail.com>
Date: Tue, 11 Aug 2015 09:39:19 -0700
Message-ID: <CABkgnnVwEGcMPsEeDrqO-gzJjPc8H7rW91-4=-3WhWxvKM6G_w@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Dave Garrett <davemgarrett@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/BxmRJPHyTf4OG-aLnvGwrMNiTy0>
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: Tue, 11 Aug 2015 16:39:23 -0000

Before people get too far down that road, here:

https://tools.ietf.org/html/draft-thomson-httpbis-cant-01
https://tools.ietf.org/html/draft-thomson-tls-care-00

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 ;).

Also:

https://tools.ietf.org/html/draft-ietf-httpbis-http2-00#section-2.6.9

This is well-trodden ground.

On 10 August 2015 at 23:05, Dave Garrett <davemgarrett@gmail.com> 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls