Re: [TLS] CCS and key reset and renegotiation

Peter Gutmann <> Tue, 10 June 2014 15:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C9E7D1A01BF for <>; Tue, 10 Jun 2014 08:58:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KzpQHhtYI58H for <>; Tue, 10 Jun 2014 08:58:21 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A238A1A01A7 for <>; Tue, 10 Jun 2014 08:58:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=uoa; t=1402415901; x=1433951901; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=IfdBHVxUShY+Bzf57m2HMKsCkNlXSsw1M6msl1SGm5o=; b=shQou9hc7OwOLsfSQBq/pB4lBgjG0nTiqj7mqz+Z9sf4LKY5+08H6/Ph I9S9X1UaazGgMKcFayGYk+59buHRXTaSIVdhl8F9HXgwxmwTkuZKGn+OM a5rE6YjowyhkWP4H252uKIN7q7Cqm88erCBH8HzwfBs773wkNTVpKjrD5 A=;
X-IronPort-AV: E=Sophos;i="4.98,1009,1392116400"; d="scan'208";a="257674042"
X-Ironport-Source: - Outgoing - Outgoing
Received: from ([]) by with ESMTP/TLS/AES128-SHA; 11 Jun 2014 03:58:19 +1200
Received: from ([]) by ([]) with mapi id 14.03.0174.001; Wed, 11 Jun 2014 03:58:18 +1200
From: Peter Gutmann <>
To: "<>" <>
Thread-Topic: [TLS] CCS and key reset and renegotiation
Thread-Index: Ac+ExMsoZ2ayMH5PR0ecN/N6iGB4KQ==
Date: Tue, 10 Jun 2014 15:58:17 +0000
Message-ID: <>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [TLS] CCS and key reset and 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: Tue, 10 Jun 2014 15:58:26 -0000

"Salz, Rich" <> writes:

>I wasn't suggesting a set of ladders to replace a state machine.  Peter said
>it's not really a state machine but rather a ladder. I was emphasizing that,
>*if this is true*, then a ladder approach is way much better.

So I did some simple diagrams for SSL years and years ago, see page 10 of  I didn't include
renegotiation because my code doesn't do it (I'd always seen it as a problem,
not a solution) and optional add-ons like client cert auth which can easily be
added.  The whole thing is so obviously a ladder that I never understood why
the RFC tried to make it a state machine.

(Interestingly, the same page also contains the SSH protocol as a ladder
diagram.  SSH does more or less the same thing as TLS, only a lot more
awkwardly, and they don't try and present the protocol as a state machine.
Mind you they don't do it as a ladder diagram either without a lot of digging
in the text "both sides send X, then once X has been sent they go on to Y,
then once that's done they do Z, ...").