Re: [TLS] Proposed text for removing renegotiation

Martin Thomson <> Wed, 11 June 2014 20:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3C09B1A0273 for <>; Wed, 11 Jun 2014 13:01:45 -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 UwDB5WaoWCGE for <>; Wed, 11 Jun 2014 13:01:43 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5B1A91A026D for <>; Wed, 11 Jun 2014 13:01:43 -0700 (PDT)
Received: by with SMTP id p10so254104wes.20 for <>; Wed, 11 Jun 2014 13:01:41 -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=Axbg98c9q6+cSOS5msl3wohVIpSdTm1gaBTn82b9C4Q=; b=dbXDQDuQxychF9YslWHHUDJz/tZYAPYEeLwQfSrTJjPEYZSrQ90wRkfIGtWKxWLMrU nUoR6xl2Co2RNjrVnKsh1s1elTtDeS1rrilrNQFsJdMQUXf2HkOGAxmMO1Z8r+ilUxKK 3NUapTg0SLL98QOVQTDXxwY2cVVBo6u3DsnDb7V8PpdaGDYZ8e5FHFOdn0PU+CfBcEUC F+mhuGuialKVImIkYLGc/K4SmZ5zH089o2m7vqG6NDX01kEnG2bLX/Z5yN7l6lFunQlt 057NV3h5LAog5bnam3xfFA33dkuMrVC7cHDCYPvEs/nlAyfbYxcVkHsjCTtbwgqtZy6V +8mQ==
MIME-Version: 1.0
X-Received: by with SMTP id i9mr144652wie.38.1402516901772; Wed, 11 Jun 2014 13:01:41 -0700 (PDT)
Received: by with HTTP; Wed, 11 Jun 2014 13:01:41 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <>
Date: Wed, 11 Jun 2014 13:01:41 -0700
Message-ID: <>
From: Martin Thomson <>
To: Andrei Popov <>
Content-Type: text/plain; charset="UTF-8"
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 20:01:45 -0000

To establish a bit more context here: the consensus in HTTPbis is to
provide a mechanism whereby servers are able to downgrade to HTTP/1.1
for the purposes of corner cases that are only properly supported by

Aside from some interesting legacy scenarios, client authentication
was considered a major reason for this feature.  We decided not to
adopt something like the -cant draft at the current time, since the
more generic capability was also needed.

On 11 June 2014 12:37, Andrei Popov <> wrote:
> 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.

Correct.  That makes something like -cant a prerequisite of an upgrade
to TLS 1.3 for those servers.

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

This can be worked around.  In fact, the proposed text permits
renegotiation in TLS 1.2 (there is no "earlier" here because we
prohibit the use of earlier versions) prior to starting HTTP/2:

(This isn't in the main spec due to a dependency issue, that text
captures the established consensus from the most recent interim

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

See above workaround.  The cost there is an additional round trip (if
you do false start, that is, it's a lot more without).

> 4. Without renegotiation, TLS client auth requires additional round-trips to establish a new TCP connection.