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
>