Re: [TLS] tls 1.3: renegotiation

Martin Thomson <> Mon, 28 July 2014 21:17 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 29B8D1A01E2 for <>; Mon, 28 Jul 2014 14:17:51 -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 tc8U_8Br1ZHf for <>; Mon, 28 Jul 2014 14:17:49 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0A0471A017F for <>; Mon, 28 Jul 2014 14:17:48 -0700 (PDT)
Received: by with SMTP id bs8so5135530wib.3 for <>; Mon, 28 Jul 2014 14:17:47 -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; bh=yMoqK/dj94udtv26u2o9ACnq+yOc41TIhgn/NBKcPJM=; b=AGHHVGKJa0aZ2LYE6vVresxmLftJ5UX56PlOiXftF/Vv+FVdkbeTeGwpjxDtHYXAyd WlOOVzLd97dMSWG7tcowttN6EyeJdDwFwFwM7ugynMsDFcyHQxFGD6KRxKcn1K0iqRFv fp2PtoeGoVwAb+6GQzCP752EFIhBhaupCA1hcUGr0zUv3wigL/3Ut0cKe9m3yBzwr2Yg XB4mqW0ODH5eyyTYxTOD/SYA/eq3r6T7+RGks1bh1gxqDQG1N1od4Hoi6iSTKkvUaPIX CDLXD37ZqrNRcihi0NdRaK2IR+5NRFYU290S4XE22/+QZAeLoL68UhizELaJhfcdp23h a8mw==
MIME-Version: 1.0
X-Received: by with SMTP id ff14mr54101534wjc.9.1406582266466; Mon, 28 Jul 2014 14:17:46 -0700 (PDT)
Received: by with HTTP; Mon, 28 Jul 2014 14:17:46 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Mon, 28 Jul 2014 14:17:46 -0700
Message-ID: <>
From: Martin Thomson <>
To: Robert Ransom <>
Content-Type: text/plain; charset=UTF-8
Cc: " \(\)" <>
Subject: Re: [TLS] tls 1.3: 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: Mon, 28 Jul 2014 21:17:51 -0000

On 25 July 2014 12:27, Robert Ransom <> wrote:
> In addition, I believe that it is not possible for the WG to make an
> informed decision as to whether renegotiation should be removed at
> this time:
> * The rekeying feature and client-initiated client authentication
>   feature have not been specified yet, even to the point of stating
>   the requirements which each feature will meet.  It is not possible
>   for the WG to determine whether the features intended to replace
>   these two uses of renegotiation will be fit for their intended
>   purposes at this time.

We had a good discussion about these in Toronto.  On rekeying, there
are concerns about how much we might want to make changeable; offline
discussions about the complexity/value trade-off space between simple
rekeying (as I have proposed) and something more complete like a full
DH exchange was quite enlightening.

We've talked quite a bit about spontaneous client authentication
(though we might talk about client-initiated authentication, that
implies a solution and so I think that is the wrong focus for the

The problem as always is that the defense of renegotiation is largely
based on its existence alone.  That defense would be stronger if there
it were based on use cases.  I don't find arguments from inertia ("it
exists", or "it's easy") to be at all persuasive.  Saying "it can be
fixed" is actively detrimental to the case.

Arguments in the form "I need to do X and in order to do X I need
renegotiation" are far better.  They are testable.  Andrei's concerns
are a good example of this.  We might disagree on the subjective
elements, but that's a good starting point.