Re: [TLS] Renegotiation: trying to summarize

"" <> Wed, 02 July 2014 18:05 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 367301B29E1 for <>; Wed, 2 Jul 2014 11:05:24 -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 7OPe3ym619C0 for <>; Wed, 2 Jul 2014 11:05:22 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7AB801A03DE for <>; Wed, 2 Jul 2014 11:05:22 -0700 (PDT)
Received: by with SMTP id r20so985294wiv.4 for <>; Wed, 02 Jul 2014 11:05:21 -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=OGVXG7ZPK8nDiyPVtdDOHni4ElcP8n/R6DQALgPNgys=; b=AUHkkXmgwhJ1wsaCP9OLXUpXyZqUfF7fVQIL6MnbTeu6yGAWN2x1zRJTR2FSnk/Rsi sk2STtEf0audN698sUP9JWpTfUYVMZktE+FHJ58sO+uqx6HoWBPoWYvbSR1rldquKxix qpqOqYV7/5F3CoCGVlyxKA/UK8mP7dkvNCqCx4us9eOrJCrfk95ZBkcKWRwfC0LaVvi7 RVBJrIcux9DIgzbYYgh+iyOr3Qe2+73sYAhKgk+LGbHMIIrVW1FvXVQIeGRWqqrvoxUO 7jlAWkLrhbszXw9AWbb75naWR28gLDESIaqqv6yCs4tsunoc/oztT/dLkti8cHVAA/gM FiVg==
X-Gm-Message-State: ALoCoQk1AtdVq3/dsidNJTRFf7Ip4qQO3jIbtXEmpeEEte+qquIe5RxvbZNle7EnlMFMyBuVrwHt
X-Received: by with SMTP id k6mr45240223wic.1.1404324321055; Wed, 02 Jul 2014 11:05:21 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id ej2sm56526453wjd.21.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 02 Jul 2014 11:05:17 -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, 2 Jul 2014 20:05:14 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <>
To: Peter Gutmann <>
X-Mailer: Apple Mail (2.1878.2)
Cc: "<>" <>
Subject: Re: [TLS] Renegotiation: trying to summarize
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 18:05:24 -0000

On 21 Jun 2014, at 02:16, Peter Gutmann <> wrote:

> Martin Thomson <> writes:
>> 1. Remove renegotiation entirely
>> Brian Smith proposed this.  Arguments for are its beautiful simplicity and
>> the fact that it ensures that you limit the time that a single session (and
>> the corresponding keys) live.
> Another argument strongly in favour of removing it is that in all the
> applications where I've seen a requirement for renegotiation (e.g. in industry
> standards that use TLS), in approximately, oh, 100% of them it was due to some
> misguided perception that it'd do... well, no-one could really explain it, but
> the capability was there so we may as well add a clause requiring it.

Now that you have seen the spec on WebID Authenction over TLS

where we have a number of implementations for ( e.g. )

would you still say that renegotiation is done for some msiguided perception of
what it is doing? And of course the follow up question would be why?

> In some cases the requirement was so clearly ridiculous (infrequent reporting
> from SCADA systems where you'd need to renegotiate on each message) that
> implementers chose to ignore it, but in other cases it wasn't easy to convince
> people that it was pointless, particularly when some standards committee had
> decided that you had to do it.
> I'm strongly in favour of removing it, it's mostly pointless, it's been the
> cause of the first real flaw in the SSL/TLS protocol design (rather than an
> implementation issue), and it really messes things up when other standards
> groups decide they need to mandate it without knowing why.

If you remove it without making efficient crytpographically secure
distributed client authentication feasible then you have in my view
decreased security on the web, or at least closed a door that would
allow us to escape the surveillance state ( by states or large private
players ) because you'll have reduced the ability to communicate in a
peer to peer manner securely. ( efficient Distributed authentication
is key to that ). 

> Peter.
> _______________________________________________
> TLS mailing list

Social Web Architect