Re: [TLS] Proposed text for removing renegotiation

Brian Smith <> Wed, 28 May 2014 17:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6A8491A0417 for <>; Wed, 28 May 2014 10:35:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6YZ0ZuMFaB5A for <>; Wed, 28 May 2014 10:35:28 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 49E911A0A2B for <>; Wed, 28 May 2014 10:35:28 -0700 (PDT)
Received: by with SMTP id i50so18820869qgf.3 for <>; Wed, 28 May 2014 10:35:24 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=B9pixl/MwEq/qpox+yY2RcKNi1djhOAiTa0r1l1rXzQ=; b=QB+D4XgZfZTFU3Zu7poM25vJk6Dyv1G5tXDHXF6Mf9y+SQChiHiXZzOUTnbJhoNwyK /Lz800DSkYJ8BjFFaWYLvJZY6VbtEueSEGlKLBhiebQ30Ve0Abd76XvzZArbkA5YUptX Gg0bKysrhcqWpxp+GS2JlBRer0bAyMYqZbWVSoEHVLn4E39PsifxKtI43X7qweaCe1SG ubBIoL+BwtvX46saQRInXFcl4eOVoQ54uicCS3IGWszye5TM+qznswxhGQLc91nmCt8l 64t8+wDhLLsv8FaMVuQhPlx8kJFezutdqN4uX0pmNo2IwEGmtPgCUQ0izUJkQReeme4u mPqQ==
X-Gm-Message-State: ALoCoQl+3rWWg5I28dKR7eZvvWGDwCYAPrv1J8Ab/31glr8pPIObg20ZzOcwaH0VVRrLran362FS
MIME-Version: 1.0
X-Received: by with SMTP id j50mr1475206qga.27.1401298524226; Wed, 28 May 2014 10:35:24 -0700 (PDT)
Received: by with HTTP; Wed, 28 May 2014 10:35:24 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Wed, 28 May 2014 10:35:24 -0700
Message-ID: <>
From: Brian Smith <>
To: Yoav Nir <>
Content-Type: multipart/alternative; boundary="001a113a7e5cc2dcd704fa793cc1"
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 17:35:30 -0000

On Wed, May 28, 2014 at 3:00 AM, Yoav Nir <> wrote:

> 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.)
> 1. Client Authentication.


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

FWIW, I think the idea that Martin is pursuing is the right approach to
this issue.

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

As you say, these applications are not delay sensitive. Also, these
applications have to be able to recover from long-lived connections being
broken. So, for these applications, why isn't it acceptable to just close
the connection/session and open a new one?

I think it would be helpful to see some examples of real-world applications
(preferably, but not exclusively open source) that actually do currently
use renegotiation to rekey a long-lived connection.

Assuming rekeying would be an optional feature like renegotiation is, would
web browsers and/or common web servers actually implement rekeying? It
would be very tempting to leave it out to reduce the chance of
implementation mistakes if it were optional.