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

Martin Thomson <> Fri, 25 September 2015 17:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 658141A854B for <>; Fri, 25 Sep 2015 10:12:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.012
X-Spam-Status: No, score=-7.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 1_SoMomXA-L3 for <>; Fri, 25 Sep 2015 10:12:49 -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 36E5C1A6FCA for <>; Fri, 25 Sep 2015 10:12:48 -0700 (PDT)
Received: from lists by with local (Exim 4.80) (envelope-from <>) id 1ZfWUu-00032i-FU for; Fri, 25 Sep 2015 17:09:24 +0000
Resent-Date: Fri, 25 Sep 2015 17:09:24 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZfWUo-00031x-Gl for; Fri, 25 Sep 2015 17:09:18 +0000
Received: from ([]) by with esmtps (TLS1.2:RSA_ARCFOUR_SHA1:128) (Exim 4.80) (envelope-from <>) id 1ZfWUm-00034S-5Y for; Fri, 25 Sep 2015 17:09:18 +0000
Received: by ykdt18 with SMTP id t18so120959940ykd.3 for <>; Fri, 25 Sep 2015 10:08:50 -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; bh=dqFUpfolteDO31DsjDlkjo6P2/WQgvJU1D9Bbb0TOq8=; b=ZiMIdwkbNYvGh+aICi/3IP750U3rO47bw9AZnkQlQbiuLuS9/zTOqahbYRKxxZodyY 6mpmQemJb4tBgChlEkfXh5/3oNL38a0TFTyuLftC50WCrIIfa3I4nzaLnCq0AOPpPnpJ Ad39EkO5pYCXwGssZJQLxcNeTIBaBqe5V14rv0jVQJ0VtOQw0bT4r52psEXWfr9+cwYD TiJ1uoBrLrV8+dIMqt4W5hfXads6CYQ6P0ZBLm/7ti/2wlyPrSBrlqUZZFMPRhykfvgm FZUvSdA5M3EAdPXQ7XvhEdJmuaIWkeJcJptZrv4riSDoajSHuG3qbT4OV89XX7mEf3mS 7YQA==
MIME-Version: 1.0
X-Received: by with SMTP id w125mr2313663ywg.56.1443200930266; Fri, 25 Sep 2015 10:08:50 -0700 (PDT)
Received: by with HTTP; Fri, 25 Sep 2015 10:08:50 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Fri, 25 Sep 2015 10:08:50 -0700
Message-ID: <>
From: Martin Thomson <>
To: Poul-Henning Kamp <>
Cc: Yoav Nir <>, Amos Jeffries <>, HTTP Working Group <>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-7.9
X-W3C-Hub-Spam-Report: AWL=1.842, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: 1ZfWUm-00034S-5Y d60ad65c14966c72932256e1d31de9d7
Subject: Re: Report on preliminary decision on TLS 1.3 and client auth
Archived-At: <>
X-Mailing-List: <> archive/latest/30275
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

On 25 September 2015 at 03:14, Poul-Henning Kamp <> wrote:
> What I tried to say above is that we don't know which cookie
> identifies the session.

That's definitely true.  Cookies are a pretty crude tool for something
like this.

I think that your general observation about client certificates is
overwhelmingly true.  On the web at least, I'm seeing a general trend
away from using the TLS layer to authenticate clients.  If cookies are
crude, client certificates make them look like a picture of
sophistication by comparison.  As you say, they are a poor fit for
both the protocol and the architecture.

What I neglected to mention earlier is that client certificate
mechanism that was being added was viewed more as a necessary evil
than an important feature.  No one liked having to do this, but as
Mark pointed out, there are far more people relying on having the
functionality than we previously thought.

I'd like to find other solutions for the use cases that drive this,
but the view was that we still needed something like this so that we
don't strand those users on old protocols.  We don't have to *like* it

There was strong agreement that this feature would be accompanied by a
prominent and severe admonishment against using it.  I definitely want
to talk about what the alternatives look like, but perhaps we should
start a separate thread on that subject.