Re: [TLS] Proposed text for removing renegotiation

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

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 28DAB1B298C for <>; Wed, 2 Jul 2014 10:08:55 -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 YNZoNYvyZIBo for <>; Wed, 2 Jul 2014 10:08:52 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8E8481A05C3 for <>; Wed, 2 Jul 2014 10:08:52 -0700 (PDT)
Received: by with SMTP id u57so11762184wes.33 for <>; Wed, 02 Jul 2014 10:08:51 -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=J9TGNna+wczTdwqGKHnGGBkGvpp7BrGQPfU6IrnU5w4=; b=GB39MzT5mhnyRvc9N+WWniC/W9h848vJp3Bv3jCAjP71l5xPJpvIOBImmronyDKgbC 0akEABdiunjVSSOb8JF/8zSE5/a9N2croJzWFIPMapAIThPVAPuDm4/4gB7vYnvEt1cH 734h7nAOYNE0Qoi7vRdklAiPqTwwHQWKEpBnucRuda95rBsHSAAW15E3n30uy/6Md7ab rkZ3ZNwitHBgz5TkVDhu1qvyTIGQIEvzC1pkSZs6an6HF6yJE0nWi0jrsoWkUavLBtA0 BL2+xpI/WyzSNWiLL0wlioG/EHkuxFvCfwVaBr4IkCJkaAnvxbf3n+1Q5tPtEE0LTMRc ZyOw==
X-Gm-Message-State: ALoCoQkGoesBfyerfhhUwGznt+48wYK+l5ikqPvf8hL5whYejU/oIgNNKDVyHntxxko389RAADs0
X-Received: by with SMTP id hb3mr5686405wib.8.1404320931012; Wed, 02 Jul 2014 10:08:51 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id m3sm57170413wik.7.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Jul 2014 10:08:37 -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:08:25 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <>
To: Martin Thomson <>
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:08:55 -0000

On 9 Jun 2014, at 20:17, Martin Thomson <> wrote:

> On 9 June 2014 00:34, Nikos Mavrogiannopoulos <> wrote:
>> Could somebody elaborate on what is that issue and why does it need to
>> be solved? (it is not even mentioned in the TLS 1.3 charter) As someone
>> who follows the mailing list that proposal comes out of the blue with no
>> context whatsoever.
> I think that this has been covered in the thread, but piecemeal:
> * Renegotiation is a major source of security issues, both of the "we
> screwed the TLS design up" sort and of the "my application didn't
> realize that these things could change" sort.  There is a clear desire
> to remove features that enable either sort of problem.
> * Renegotiation is just more protocol complexity.  Removing it
> potentially makes implementations simpler.
> I think that either might be sufficient justification for removing the feature.
> However, a number of use cases depend on renegotiation to achieve
> their ends.  Of these, we have identified:
> * mid-session client authentication, which uses renegotiation seems to
> only be used in HTTP

As you know, but others may have missed, this is proving to be very useful
to create distributed authentication, which can be used for distributed 
access control, which is what is needed to create a distributed secure social
web, which is the best answer to problems Snowden revealed - which are inevitable
when centralised services amass huge amounts of data on a huge number of individuals.

In the WebID authentication over TLS spec as specified currently a server SHOULD 
use this renegotiation in order to provide a sensible user experience.

The client side certificate features of TLS would be useless without reneg, because
a server would always have to ask for the identity of the user, even if the
user only asks for public resources.

So given that there is a feature in TLS that is in fact useful to increase
communication security by increasing secure p2p interaction on the most used protocol
in the world ( HTTP ), I think we need to make absolutely sure that the
removal of this feature is not going to remove the ability to do this distributed
authentication. Otherwise one could argue that removal of this feature could
be used to increase the surveillance state we are allready in (by removing a
key feature that would enaple secure p2p communication).

So I know there is
that could be deployed in conjunction with a "WWW-Authenticate: Certificate" HTTP headers 
to allow a client to ask the server that it be authenticated. [1]

But is draft-thomson-tls-care going to be part of TLS1.3? 
Are we absolutely sure this will work?

I'd say that one should not allow removal of TLS client renegotaiton unless one
can be very clear that this is so.


> * very long-lived connections, which require renegotiation to re-key
> occasionally
> The former we have decided to solve in HTTP.  As a side note, we just
> decided to forbid renegotiation in HTTP/2.
> The latter can be addressed by my proposal, or any of a number of mechanisms.
> _______________________________________________
> TLS mailing list

Social Web Architect