Re: [TLS] Proposed text for removing renegotiation

"" <> Wed, 02 July 2014 17:48 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EBE671B2875 for <>; Wed, 2 Jul 2014 10:48:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2XnaBvo0lrmH for <>; Wed, 2 Jul 2014 10:48:11 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 40C121B2870 for <>; Wed, 2 Jul 2014 10:48:11 -0700 (PDT)
Received: by with SMTP id n15so10085878wiw.10 for <>; Wed, 02 Jul 2014 10:48:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=r78tRCjWBhCcuP4Wxa56doy4zBmbrw19Ri9fI9Wt5/4=; b=TrE3PhAPlOmGcS3TmDOlS4asOm90/uKZYSSfORHZdm2FebV68S+/2EEDQP7de3hh16 EzTuI+jTop/pS+RLeYwRs+DKTietxluZAaDkPVErv5yrW2u8al9CSDVcWugINVEgWabw wAn/iPejc0+1+hmlH5+zTaRFApIVWpEkQNty2ivrgQcr90zo3S/MZJ79TmqoxKHgH1gV Kabuh33MO7+ELuHah3vz3JCWhgr9QlYwOpUt7B49GSNCsO0CHN9sIkmIOBpFxWtAB9zz 29P/XtLI6GG26I5aYUweEWPDNu91jqdVaMjaptX7q0GG+dtuiwxPUEgVtqgjfAn6des/ hONg==
X-Gm-Message-State: ALoCoQmigGiqnHLGz6og9Obdn1q5xX23aR/bW9sPzt2k4JOXpwipVHkfSPOkITM/rfNWbzRDRcBG
X-Received: by with SMTP id a8mr44664484wiz.36.1404323289845; Wed, 02 Jul 2014 10:48:09 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id cz8sm56450361wjc.11.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Jul 2014 10:48:07 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
From: "" <>
In-Reply-To: <>
Date: Wed, 02 Jul 2014 19:48:04 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
To: Daniel Kahn Gillmor <>
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, 02 Jul 2014 17:48:15 -0000

On 17 Jun 2014, at 22:56, Daniel Kahn Gillmor <> wrote:

> But I suspect most application developers who use TLS don't understand
> that the authentication state or cryptographic protections of the
> connection may change mid-stream.  Of the minority that does understand
> that this state may change, i suspect that many of them don't actually
> handle the situation well (if at all).
> if we want to avoid this on the implementation side, do we need more
> guidance to implementers of TLS stacks?  or guidance for
> application-layer users of those stacks?  or both?

Take this as someone who has come from Java land and has recently moved to Scala-land.
In Java in 1995 the aim was to make APIs very easy to use, for developers used to
thinking in single threaded manners. But currently with the deployment of
multi-core cpus ( Eg. Sun Microsystems T5 with 16 cores and 8 threads per
core for a total of 128 threads, which in an 8 socket system can lead to 
1024 thread system ) and the growth of web apis, functional programming languages 
such as Scala are coming to the fore. Very good libraries are being developped there such
as the actor framework at with very good marketing for
concepts such as reactive programming ( )
and Reactive Streams ( ) which is making it
much easier to code such mid-stream changes, and to think about these issues.

In the past few years of programming in this space I have learned more than
I had in the previous 10 years of programming. In short: programming has become 
enjoyable again, and in great part due to the development of these frameworks.

I just thought I'd mention that, as what may have been difficult 10 years ago,
has perhaps now become easy. So such implementor guidance should take into
account these changes.

All the best,

	Henry Story

PS. a bit of background on me:

Social Web Architect