Re: [TLS] Proposed text for removing renegotiation

Yoav Nir <> Wed, 28 May 2014 10:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5BB301A089F for <>; Wed, 28 May 2014 03:00:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qSjRgGUlFg-O for <>; Wed, 28 May 2014 03:00:13 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A937E1A08B1 for <>; Wed, 28 May 2014 03:00:07 -0700 (PDT)
Received: by with SMTP id q59so11054498wes.35 for <>; Wed, 28 May 2014 03:00:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=J6E1JL1U/8ZPDp8bTBuRyL2gZvaYBbQ3QSV6XueSDtI=; b=W5n9lJTlGluX9OhhnFC8vNLTSgTTWprTEQzitRnkth654jp+INtOc5HM1QJ2AkdtTa c6bw3oQrcF+ZYq+DPS3dmuX86ePrZ3R0SrAt12O5zNIEVQkWydKjDHTGBlGfgXKZyCuS QFozbHnICPrNtKTCpowjX/Arvwo9q5ga+S12njNSRnt9MLKI8ZY9MYxosv6QYu1i8yyy KPpdMtbFBQojYqgsHv+j3wW05MgNwIF/Clb6UdeOCZnDTApszEFP8HCP9nhxZZUZ5IRD BQP4f3l3IumbxLK8wOCmMczhBBk1oigQWfoKWk06cEd8AiAD8JKb6oam1B7N920dhYbr v1pQ==
X-Received: by with SMTP id r4mr19969115wjf.39.1401271203108; Wed, 28 May 2014 03:00:03 -0700 (PDT)
Received: from [] ( []) by with ESMTPSA id ln3sm41998553wjc.8.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 28 May 2014 03:00:02 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_73EBAA94-CC0D-451A-B075-5ADD14CCDCE5"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Wed, 28 May 2014 13:00:00 +0300
Message-Id: <>
References: <> <>
To: Brian Smith <>
X-Mailer: Apple Mail (2.1878.2)
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, 28 May 2014 10:00:15 -0000

On May 28, 2014, at 8:47 AM, Brian Smith <> wrote:

> On Tue, May 27, 2014 at 2:39 PM, Martin Thomson <> wrote:
> It's not possible to just remove renegotiation.
> Why not? What is the motivation for keeping any form of renegotiation, even rekeying? It isn't clear from the public mailing list discussions what is motivating the rekeying feature. (Perhaps I overlooked something; if so, a link to the past decision on this would be appreciated.)

Why not?  Because people are using it to accomplish things, and you can’t just pull it away without giving them some other way of doing what they’re doing, otherwise you get “TLS 1.3 is not suitable for long-lived connections” or “TLS 1.3 is not suitable for mutual authentication”.

With that in mind, in discussions on this list and at the interim meeting two uses for renegotiation were mentioned:

1. Client Authentication. For various UI reasons, web applications don’t want to send a certificate request on the landing page. They want the certificate authentication in response to a request for a protected resource, one that requires an authenticated client. This is not something that Google, Facebook or Tumblr use, but it’s much more common in SSL VPNs, corporate portals, and some banking web sites.  Martin has a couple of drafts for making this happen in a combination of HTTP authentication method (“go away and come back with a certificate”) and a TLS extension (“I have a certificate. Please send a CertReq”).

2. Connections that carry so much traffic and last so very long that you really need to rekey. This was discussed at the meeting, partially on Jabber ([1]). It’s not that common for the web, but I’m assured that XMPP connections sometimes last basically forever, so they need rekeying. My proposal there (at 19:40) was for this use case. Martin is right that it adds “dead air”, but all these use cases are not that delay sensitive, and I think it’s worth it to get the simplified state machine.


[1] around 19:24