Re: [TLS] Proposed text for removing renegotiation

Martin Thomson <> Mon, 09 June 2014 21:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 07C651A020E for <>; Mon, 9 Jun 2014 14:28:19 -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 DTo9I6jDapMQ for <>; Mon, 9 Jun 2014 14:28:17 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3A04C1A01CF for <>; Mon, 9 Jun 2014 14:28:17 -0700 (PDT)
Received: by with SMTP id z12so2808649wgg.1 for <>; Mon, 09 Jun 2014 14:28:15 -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=IiKqOEX1hPXdsNMQY/zHP8/TDVaaEgLphATsgXI+PRI=; b=dWC0pOqaXjBmlmWDyCm/9DGchzkyuhlSsM661lObp6Yznb/TCmVZbHiKmvVONJpKgV tkFTwQlfCqZkL8y/kEDtq4e5kiII5bDBD+2O9QzyZxCFud7Eyj0xPokKj7TqJPFrloit ygaCOMBgRP7Kit0jejEK445JV/C59zvnslpk4UbJVGjl6ZZzMs463ykWtu/QNw2D5pyX 4NvESAeVCezqxvNK0d1K78cBzHhfA0O5ogwEm4Sw1RdQJGMdmkl+i/s6iIlvl3fDniN0 2l4yZ6D5P77CoTuty2Y7z6VhbJm9qOECpUq99Sf9jIs/yEaBaegAkMyFTXT4VJ6nS2oN kHrw==
MIME-Version: 1.0
X-Received: by with SMTP id gi8mr35514384wjd.75.1402349295757; Mon, 09 Jun 2014 14:28:15 -0700 (PDT)
Received: by with HTTP; Mon, 9 Jun 2014 14:28:15 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Mon, 09 Jun 2014 14:28:15 -0700
Message-ID: <>
From: Martin Thomson <>
To: Andrei Popov <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "" <>
Subject: Re: [TLS] Proposed text for removing renegotiation
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: Mon, 09 Jun 2014 21:28:19 -0000

On 9 June 2014 11:49, Andrei Popov <> wrote:
>> The former we have decided to solve in HTTP.
> Are you referring to these I-Ds:
> Httpbis-cant talks (rather vaguely) about using "realm" or "other challenge parameters" to select an appropriate client cert. I think client cert selection should be clearly specified before we can say that the mid-session client auth problem has been solved, and remove renegotiation from TLS 1.3.

The selection problem is, as we discussed in Denver, worth addressing.
The short term fix in HTTP/2 will actually be to force these users
down to HTTP/1.1.  That's suboptimal, certainly, but it does fix the
immediate problem.

As far as the -cant draft goes, I simply haven't uploaded an updated
version after our discussion in Denver.  There's a work in progress
version on github:

> It would be even better to solve this problem at the TLS layer, so that each application protocol does not need to come up with a separate solution. And avoiding the round-trips involved in establishing a TCP connection would be awesome, too. The current solution using renegotiation has both of these desirable properties.

I'm sympathetic to this, but if HTTP is the only one that wants this
particular feature, then we are better off leaving them to work around
this.  At least in my opinion.