Re: [TLS] Proposed text for removing renegotiation

Andrei Popov <> Wed, 11 June 2014 19:37 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2AF2E1B2896 for <>; Wed, 11 Jun 2014 12:37:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rUIIoN1xQb2G for <>; Wed, 11 Jun 2014 12:37:04 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id AF03C1B2889 for <>; Wed, 11 Jun 2014 12:37:04 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.954.9; Wed, 11 Jun 2014 19:37:02 +0000
Received: from ([]) by ([]) with mapi id 15.00.0954.000; Wed, 11 Jun 2014 19:37:02 +0000
From: Andrei Popov <>
To: Martin Thomson <>
Thread-Topic: [TLS] Proposed text for removing renegotiation
Date: Wed, 11 Jun 2014 19:37:01 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: [2001:4898:80e8:ed31::2]
x-microsoft-antispam: BL:0; ACTION:Default; RISK:Low; SCL:0; SPMLVL:NotSpam; PCL:0; RULEID:
x-forefront-prvs: 0239D46DB6
x-forefront-antispam-report: SFV:NSPM; SFS:(979002)(6009001)(428001)(13464003)(189002)(199002)(51704005)(377454003)(24454002)(15202345003)(81542001)(2656002)(54356999)(101416001)(74316001)(77096999)(83322001)(86362001)(87936001)(99396002)(76176999)(76576001)(85852003)(99286001)(83072002)(74502001)(92566001)(80022001)(21056001)(15975445006)(33646001)(79102001)(19580405001)(4396001)(46102001)(76482001)(81342001)(86612001)(31966008)(74662001)(19580395003)(50986999)(77982001)(20776003)(64706001)(93886003)(24736002)(3826001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB417;; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (: does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is );
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: Wed, 11 Jun 2014 19:37:08 -0000

Thanks Martin for pointing out the updated httpbis-cant I-D on github. It seems to provide the same certificate filtering facilities as the CertificateRequest.

There are other significant problems with the removal of renegotiation from TLS 1.3 (please correct me if I'm missing something):
1. An existing HTTP/1.1 server cannot take advantage of TLS 1.3 if TLS client auth is required. This is because an existing HTTP/1.1 server is not aware of httpbis-cant.
2. An HTTP/2 server requires an updated TLS stack with tls-care support in order to perform TLS client auth. This is because HTTP/2 prohibits renegotiation.
3. Even with the updated TLS stack in place, an HTTP/2 server cannot negotiate TLS 1.2 and earlier if TLS client auth is required. This is because TLS 1.2 and earlier would send the client cert in the clear, which is bad for client privacy.
4. Without renegotiation, TLS client auth requires additional round-trips to establish a new TCP connection.

Perhaps the fundamental problem is that httpbis-cant introduces a client authentication challenge in HTTP that cannot be satisfied at the HTTP layer. This breaks the protocol layering, and causes the types of hard-to-manage dependencies listed above.

Even if httpbis-cant and tls-care both become RFCs, and get commonly implemented, and get widely deployed, I believe that the removal of renegotiation from TLS 1.3 creates more problems than it solves.



-----Original Message-----
From: Martin Thomson [] 
Sent: Monday, June 9, 2014 2:28 PM
To: Andrei Popov
Cc: Nikos Mavrogiannopoulos;
Subject: Re: [TLS] Proposed text for removing renegotiation

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.