Re: [TLS] CCS and key reset and renegotiation

Peter Gutmann <pgut001@cs.auckland.ac.nz> Tue, 10 June 2014 15:58 UTC

Return-Path: <pgut001@cs.auckland.ac.nz>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E7D1A01BF for <tls@ietfa.amsl.com>; Tue, 10 Jun 2014 08:58:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzpQHhtYI58H for <tls@ietfa.amsl.com>; Tue, 10 Jun 2014 08:58:21 -0700 (PDT)
Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A238A1A01A7 for <tls@ietf.org>; Tue, 10 Jun 2014 08:58:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; 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-HAT: MAIL-SERVERS - $RELAYED
X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing
Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 11 Jun 2014 03:58:19 +1200
Received: from UXCN10-TDC06.UoA.auckland.ac.nz ([169.254.11.9]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.03.0174.001; Wed, 11 Jun 2014 03:58:18 +1200
From: Peter Gutmann <pgut001@cs.auckland.ac.nz>
To: "<tls@ietf.org>" <tls@ietf.org>
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: <9A043F3CF02CD34C8E74AC1594475C738DEC4F7F@uxcn10-tdc06.UoA.auckland.ac.nz>
Accept-Language: en-NZ, en-GB, en-US
Content-Language: en-NZ
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [130.216.158.4]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QsyyfrIofuZ9pdc5kELJThCG5nU
Subject: Re: [TLS] CCS and key reset and renegotiation
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Jun 2014 15:58:26 -0000

"Salz, Rich" <rsalz@akamai.com> 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
https://www.cs.auckland.ac.nz/~pgut001/pubs/app_sec.pdf.  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, ...").

Peter.