Re: [TLS] Proposed text for removing renegotiation

"Kemp, David P." <> Thu, 12 June 2014 16:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0DD081A0147 for <>; Thu, 12 Jun 2014 09:12:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MnKJ23n8qo-V for <>; Thu, 12 Jun 2014 09:12:27 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7F22A1B27A4 for <>; Thu, 12 Jun 2014 09:12:26 -0700 (PDT)
Received: from ( []) by with ESMTP id s5CGCPlF056247 for <>; Thu, 12 Jun 2014 12:12:25 -0400 (EDT)
Received: from ([fe80::60c7:cec6:b35c:deed]) by ([fe80::a8ee:8532:895b:b420%14]) with mapi id 14.03.0181.006; Thu, 12 Jun 2014 12:12:24 -0400
From: "Kemp, David P." <>
To: "" <>
Thread-Topic: [TLS] Proposed text for removing renegotiation
Thread-Index: AQHPhVGEfA6PTH75QESiVYAkFY18F5tsDc0A///9z+CAAOT0gIAAtUJA
Date: Thu, 12 Jun 2014 16:12:24 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
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: Thu, 12 Jun 2014 16:12:31 -0000

That's a good rationale for saying TLS implementations SHALL NOT renegotiate unless requested or enabled by the application.  If the API doesn't provide a way to request/enable, then the stack shouldn't do it behind the app's back.

> Either we clean up renegotiation to the point where it can be useful, or we throw it out.

+1.  That's different from saying throw it out, period.

-----Original Message-----
From: Watson Ladd [] 
Sent: Wednesday, June 11, 2014 9:17 PM
To: Kemp, David P.
Subject: Re: [TLS] Proposed text for removing renegotiation

On Wed, Jun 11, 2014 at 1:08 PM, Kemp, David P. <> wrote:
> A decision on the proper place to do access control has nothing to do with the skill of implementers.
> If a web server (or any service provider) doesn't know how to grant access to resources based on authenticated user identity, user attributes, resource attributes and access policy, then a perfect bug-free network stack is not going to help them.

Well, they do know how to grant access based on authenticated user identity. What they don't know how to do is deal with portions of a request being made with one identity, other portions with another.

> If a "certificate changes", then either the application should have requested renegotiation synchronously or it should have asynchronously established conditions for when the stack renegotiates and registered to be notified when it happens.  The proper response to renegotiation is identical to the proper response to negotiating the first time.

Name one program that actually enforces this, or a TLS implementation that permits it, except by banning renegotiation entirely.

> "We know more than the application layer people" - pure hubris.  TLS/IPSEC practitioners should definitely know more about cryptography, which application developers should be able to largely ignore as a black box.  But access control to application resources is inherently an application function for which TLS library coding expertise is no substitute.

Yes, but we can make the job of the application much easier by restricting the transformations that can happen. Applications are mostly unaware that responses could be split across authentication levels. That's why we had the renegotiation fix.

Things can get even worse: if I want to restrict a resource to some ciphersuites, not others, this can be evaded by renegotiation if the first ciphersuite is broken.

The issue is that the state transitions in renegotiation aren't clearly explained or cleanly exposed to applications by most TLS stacks. At this point, given the enormous number of applications using and that should be using TLS, the fact that historically most TLS stacks and applications using TLS have gotten this wrong, I don't see stay the course as a reasonable option. Either we clean up renegotiation to the point where it can be useful, or we throw it out.

Watson Ladd

> -----Original Message-----
> From: TLS [] On Behalf Of Watson Ladd
> Sent: Wednesday, June 11, 2014 7:46 AM
> To: Nikos Mavrogiannopoulos
> Cc:
> Subject: Re: [TLS] Proposed text for removing renegotiation
> On Wed, Jun 11, 2014 at 5:45 AM, Nikos Mavrogiannopoulos <> wrote:
>> On Tue, 2014-06-10 at 14:04 -0300, Watson Ladd wrote:
>>> Quick: what is the proper response when the Certificate changes 
>>> between a negotiation and a renegotiation?
>> That is on the application protocol to decide.
> Always the wrong answer: we know more then the application layer people do about security, just as the networking people know more than we do about sending packets through the network.
> _______________________________________________
> TLS mailing list

"Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin