Re: Report on preliminary decision on TLS 1.3 and client auth

Ilari Liusvaara <> Thu, 24 September 2015 19:26 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C8A871A87CE for <>; Thu, 24 Sep 2015 12:26:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.312
X-Spam-Status: No, score=-6.312 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, 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 zxLbl4uCiKgG for <>; Thu, 24 Sep 2015 12:25:59 -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 1AA5A1A87CC for <>; Thu, 24 Sep 2015 12:25:58 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1ZfC6E-00006Q-Uw for; Thu, 24 Sep 2015 19:22:34 +0000
Resent-Date: Thu, 24 Sep 2015 19:22:34 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZfC67-00005B-Gh for; Thu, 24 Sep 2015 19:22:27 +0000
Received: from ([]) by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from <>) id 1ZfC63-0003IK-1p for; Thu, 24 Sep 2015 19:22:26 +0000
Received: from LK-Perkele-VII ( []) by (Postfix) with ESMTP id 0C35E234023; Thu, 24 Sep 2015 22:21:58 +0300 (EEST)
Date: Thu, 24 Sep 2015 22:21:58 +0300
From: Ilari Liusvaara <>
To: Martin Thomson <>
Cc: HTTP Working Group <>
Message-ID: <20150924192158.GA13323@LK-Perkele-VII>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.24 (2015-08-30)
Sender: Ilari Liusvaara <>
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-5.4
X-W3C-Hub-Spam-Report: AWL=-1.510, BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1ZfC63-0003IK-1p 1e9b97aaaf2c210d50bc62afd9bd51eb
Subject: Re: Report on preliminary decision on TLS 1.3 and client auth
Archived-At: <>
X-Mailing-List: <> archive/latest/30271
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On Wed, Sep 23, 2015 at 10:16:42AM -0700, Martin Thomson wrote:
> The security claims associated with client authentication require more
> analysis before we can be certain, but the basic idea is that
> authentication merely provides the proof that a server needs to regard the
> entire session to be authentic. In other words, client authentication will
> apply retroactively. This could allow a request sent prior to
> authentication to be considered authenticated. This is a property that is
> implicitly relied on for the existing renegotiation cases and one that we
> might want to exploit.
> Each certificate request includes an identifier that allows it to be
> correlated with the certificate that is produced in response. This also
> allows for correlating with application context. This is what I think that
> we can use to fix HTTP/2.

How do you deal with server sending reauthentication request (even associated
with some stream) when client has unauthenticable streams (no credentials or
cross-origin coalescing)?

Reset the streams blocking authentication? Refuse identity change? Open
a new connection?

Also, what if after authentication no credentials request is made?
Refuse request with network error? Open a new connection?

With CANT+CARE, it was pretty obvious that client would just route requests
to connections (if needed, opening a new one) in order to deal with these
kind of issues.

> Clients cannot spontaneously authenticate, which invalidates the designs I
> have proposed, however, the basic structure is the basis for the first
> option that I will suggest.

>From some comments it seems "unsolicited client auth" isn't about CARE type
stuff but client just plain sending its CC/CCV mid-connection?