Re: [TLS] CCS and key reset and renegotiation
Michael StJohns <msj@nthpermutation.com> Tue, 10 June 2014 23:45 UTC
Return-Path: <msj@nthpermutation.com>
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 8AC8F1A0264 for <tls@ietfa.amsl.com>; Tue, 10 Jun 2014 16:45:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CblHFHwHG3HB for <tls@ietfa.amsl.com>; Tue, 10 Jun 2014 16:45:16 -0700 (PDT)
Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49AAC1A0195 for <tls@ietf.org>; Tue, 10 Jun 2014 16:45:16 -0700 (PDT)
Received: by mail-qa0-f52.google.com with SMTP id w8so3235683qac.39 for <tls@ietf.org>; Tue, 10 Jun 2014 16:45:14 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=dluXd4/gX1gYB/zSVwIWYngKUxUG4dptfqbgkvLMLxQ=; b=GatUG/bztT6Jru68df0V2GA/6vejW8O2lqWVUR5ZNkXDZgJzEBDZxYUezszR/aGwZU pIiBjiWSOuvLpB8c5+0YGSEPQQLbYsU27GJD98t3kyZzpI/bWM/3pyhc/0tk0cpTBT2a tzfowKHED1hw5V1FseyC6VBWDmPOk/3iY+mJHbNBdhV9/d0JI/RRGtOr6xhqUEoofWlc 1DtuZnIAq9A1Vo/T4YeQPo62VKGohKdGEYi60IBbAf0QxZ6B05qNs9ZQKy1KyoBHOQpt XsboTFa+3ptJoReETFg34GY6Nmc1ZzbuO/2dQSOXXu4R9A/Q34wfhJ6xNiB24xgyi7+u 9iwg==
X-Gm-Message-State: ALoCoQmflWB1bshSS9US+U6U8XoCpZssM4G8rMBrNPbPWj9dDP+sRq8oaoDVqLfBfV4X31xIi4zC
X-Received: by 10.224.36.141 with SMTP id t13mr43643921qad.75.1402443914337; Tue, 10 Jun 2014 16:45:14 -0700 (PDT)
Received: from [192.168.1.114] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id i9sm38140833qaq.14.2014.06.10.16.45.13 for <tls@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 10 Jun 2014 16:45:13 -0700 (PDT)
Message-ID: <5397988B.1040706@nthpermutation.com>
Date: Tue, 10 Jun 2014 19:45:15 -0400
From: Michael StJohns <msj@nthpermutation.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: tls@ietf.org
References: <9A043F3CF02CD34C8E74AC1594475C738DEC4F7F@uxcn10-tdc06.UoA.auckland.ac.nz>
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C738DEC4F7F@uxcn10-tdc06.UoA.auckland.ac.nz>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Wc62XuUo-kv4nrC1O2Lh-JLOLOA
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 23:45:18 -0000
On 6/10/2014 11:58 AM, Peter Gutmann wrote: > "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. The issue with understanding TLS via state machines is that it's not one state machine, but more like 6 - Client and server versions of a) negotiate cipher suite, b) negotiate keys, c) authenticate. The three state machines on either side are interconnected - events in one state machine trigger transitions in other state machines. Messages sent/received related to specific state machines are interleaved in TLS in an attempt to reduce roundtrips. Generally, if you can express things as a ladder diagram, you can find a way of expressing them as a state machine and vice versa. I tend to prefer state machines because I can generally figure out if I'm missing something (e.g. dead states, unhandled messages, exception handling). Ladder diagrams are linear, and don't give you great indications of how the exception cases are handled. But both have their place. Ladder diagrams are especially helpful when you're dealing with more than 2 entities and/or protocols and trying to understand who knows what when. Mike > > (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. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
- Re: [TLS] CCS and key reset and renegotiation Viktor Dukhovni
- [TLS] CCS and key reset and renegotiation Salz, Rich
- Re: [TLS] CCS and key reset and renegotiation Watson Ladd
- Re: [TLS] CCS and key reset and renegotiation Nico Williams
- Re: [TLS] CCS and key reset and renegotiation Salz, Rich
- Re: [TLS] CCS and key reset and renegotiation Martin Thomson
- Re: [TLS] CCS and key reset and renegotiation Peter Gutmann
- Re: [TLS] CCS and key reset and renegotiation Watson Ladd
- Re: [TLS] CCS and key reset and renegotiation Nico Williams
- Re: [TLS] CCS and key reset and renegotiation Viktor Dukhovni
- Re: [TLS] CCS and key reset and renegotiation Yoav Nir
- Re: [TLS] CCS and key reset and renegotiation Viktor Dukhovni
- Re: [TLS] CCS and key reset and renegotiation Yoav Nir
- Re: [TLS] CCS and key reset and renegotiation Jeffrey Walton
- Re: [TLS] CCS and key reset and renegotiation Peter Gutmann
- Re: [TLS] CCS and key reset and renegotiation Watson Ladd
- Re: [TLS] CCS and key reset and renegotiation Salz, Rich
- Re: [TLS] CCS and key reset and renegotiation Watson Ladd
- Re: [TLS] CCS and key reset and renegotiation Salz, Rich
- Re: [TLS] CCS and key reset and renegotiation Paul Lambert
- Re: [TLS] CCS and key reset and renegotiation Salz, Rich
- Re: [TLS] CCS and key reset and renegotiation Peter Gutmann
- Re: [TLS] CCS and key reset and renegotiation Michael StJohns