Re: [TLS] Proposed text for removing renegotiation

Watson Ladd <> Thu, 12 June 2014 01:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7F7A21B2926 for <>; Wed, 11 Jun 2014 18:17:30 -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 ARua0nsoQUCH for <>; Wed, 11 Jun 2014 18:17:29 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c07::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C84551B2924 for <>; Wed, 11 Jun 2014 18:17:28 -0700 (PDT)
Received: by with SMTP id q9so493710ykb.23 for <>; Wed, 11 Jun 2014 18:17:28 -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:content-transfer-encoding; bh=tuQwLO/eDYlTDg3bCZ+FG/57xMX4G/jxG8TaMZg3htU=; b=pHnPQfZrXHZ8TIseTGkLmtnWRZjHNiMxIAsRJMTqPVR7HeAjZnbVbfNmEntSq7FjAc Tm5BdDwB3qZydInhHzVVOeaeUlDzA+E0OBBQt2/afMsYGqDeDqfZgasYx8kYWg0bvkBH TayLFXDvUwU+nGVgnK1pvQsrfrC8cE/rH9JNwLFfan3q3z8YKD2IWa1msYIuW0C7At6d 7+KDHP0C3FXjm4wiNuEPqht6y/wfm9P4tGBawBvJkVQUyw0QcGeicpYtdPax8zs921zA r1Cei1L31DTiMfc/bU44Jwqth7hEvHQropz1w87kIhYvpabZ5mZRPciHcO8re/F0Wdyd 5YnQ==
MIME-Version: 1.0
X-Received: by with SMTP id b45mr11136971yhf.16.1402535847964; Wed, 11 Jun 2014 18:17:27 -0700 (PDT)
Received: by with HTTP; Wed, 11 Jun 2014 18:17:27 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <>
Date: Wed, 11 Jun 2014 22:17:27 -0300
Message-ID: <>
From: Watson Ladd <>
To: "Kemp, David P." <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Thu, 12 Jun 2014 01:17:30 -0000

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