Re: [TLS] Proposed text for removing renegotiation

Watson Ladd <> Wed, 28 May 2014 01:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9AB611A084E for <>; Tue, 27 May 2014 18:11:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oTYS79paWim5 for <>; Tue, 27 May 2014 18:11:02 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 326701A0857 for <>; Tue, 27 May 2014 18:10:45 -0700 (PDT)
Received: by with SMTP id 19so7755478ykq.8 for <>; Tue, 27 May 2014 18:10:41 -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=WzdbEyAdPHNt/DoEXrVAIh9LioYxNJT/FWup3Hg7uLs=; b=vkqxL81VNDLZJz+3Eg2+dfbABRAmf+WQ8LO7W0LiSd4GW12LA4nSH0X4m+DWgY2Im/ A4PLkzX7Y5Z8I0Y5xyMECn/PxXNR+dQ4fJ/OKpqlw6j/5E3wsuQNSektvMGl8pOP0lfJ mVzIWbp/F1HyBC2/bYc7vcQ4lAVyQ69uc8XadDMC8w2Z94fKLWkHLA3p2K9flUGzVYR3 Ke2eII4MywbHs4ZS0injOCRnx3DD+sWjZPG6tWstFpZOWlVEty42nkk4pbw7WUpjRiXD gaSl8cBHNLzgqd4om5omdD5OakslYq9fPX8CtRclvRTQf2jpXHbFrr9yZScN95bJgQp5 qDWg==
MIME-Version: 1.0
X-Received: by with SMTP id a9mr16736129yhi.83.1401239441369; Tue, 27 May 2014 18:10:41 -0700 (PDT)
Received: by with HTTP; Tue, 27 May 2014 18:10:41 -0700 (PDT)
Received: by with HTTP; Tue, 27 May 2014 18:10:41 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Tue, 27 May 2014 18:10:41 -0700
Message-ID: <>
From: Watson Ladd <>
Content-Type: multipart/alternative; boundary="20cf3011dacb25ee7e04fa6b7bd8"
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, 28 May 2014 01:11:06 -0000

On May 27, 2014 5:44 PM, "Martin Rex" <> wrote:
> Martin Thomson wrote:
> >
> > Here I'm proposing changes that remove renegotiation.
> >
> > It's not possible to just remove renegotiation.
> > After removing HelloRequest and no_renegotiation, there are some
> > things that need to be fixed.  The current and pending states for
> > both read and write direction are integral parts of the spec.
> I haven't looked at the details, but this sound terrible.
> The beauty of the original TLS renegotiation is that it doesn't
> really exist.  For the state machine, it is a regular full TLS
> handshake, for the record layer, it is just a replacement of
> the current state with the next state upon CCS.
> The only problem with TLS renogitation, if there ever was one,
> is with the flawed assumptions of the application about what
> characteristics it provides (i.e that another successful TLS
> handshake could be abused to provide an OTP-style authentication
> of all data previously received over that TLS channel.

The security considerations never mentioned the issue.  In fact you were
one of the codiscoverers, years after the spec was authored. Do you
consider it a nonissue?

One can argue that TLS never has flaws, just assumptions that it is
"secure" which aren't true. Or one could say that we have to provide
semantics people expect.

> Renegotiation could be combined with an abbreviated TLS handshake
> to provide fast rekeying of the traffic protection keys (not creating
> a new entry in the TLS session cache), and renegotiation could be
> combined with a full TLS handshake, creating a new, self-contained
> entry in the TLS session cache that can be resumed on different
> connections with an abbreviated TLS handshake.
> Conceptually, the TLS session cache is readonly after an entry
> is created, and that is GOOD, i.e. full TLS handshakes create new,
> distict session cache entries, and abbreviated TLS handshakes resume
> existing session cache entries and *NEVER* modify them.
> The original architecture allows for a very simple and robust
> TLS protocol state machine for the TLS handshake (allows!=implies,
> you can implement arbitrarily complicated TLS state machines if you
> so desire, just look at some of the OpenSource implementations).
> >
> > The proposal generates a new master secret from the previous using the
> > same formula that is used to generate the master from the pre-master
> > secret.  Obviously, if we change that formula (and it seems likely
> > that we will) then this should be changed too.
> It sounds like quite a lot more stuff will have to be carried over
> from the previous session state to the next.  Now what does this mean
> for the abbreviated TLS handshake?  When, where and how do you issue
> a new session ID, or how does this change affect abbreviated
> TLS handshakes happening on independent parallel connections?

Does resuming the same connection twice make sense? Now that you mention
the issue I see how it can happen. But we only need to refresh the keys
used for data, not the PMS.

> -Martin
> _______________________________________________
> TLS mailing list