Re: [TLS] Fwd: Clarification on interleaving app data and handshake records

Yoav Nir <ynir.ietf@gmail.com> Sun, 06 December 2015 06:59 UTC

Return-Path: <ynir.ietf@gmail.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 76CE51A0378 for <tls@ietfa.amsl.com>; Sat, 5 Dec 2015 22:59:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, SPF_PASS=-0.001] 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 QhnmPbWSafD5 for <tls@ietfa.amsl.com>; Sat, 5 Dec 2015 22:59:38 -0800 (PST)
Received: from mail-wm0-x233.google.com (mail-wm0-x233.google.com [IPv6:2a00:1450:400c:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E149A1A0373 for <tls@ietf.org>; Sat, 5 Dec 2015 22:59:37 -0800 (PST)
Received: by wmww144 with SMTP id w144so105923638wmw.1 for <tls@ietf.org>; Sat, 05 Dec 2015 22:59:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=w46pxY+K4LyDLjIX9L4JEzdptHGQwkroxAIxCXSGCbs=; b=y4//uVUD1qITaYFm+vaIX6FdAqCI0eusMJonQSZRJ+m7keHi/eN3BGW2tp71AKDzbp hy9bLZFQSlsk+hGDZDt/P8fcKH9ZiyWHDNNd/LIucCy1XLh20VyxO9EqAB0GSJWFhxqt R4QJdfDIJJ+dpQwF4RywR8gh/4WCUXpCREuQRXRxavOTC6ag6rNGE2xUwZ/dFDeo0D8V 8g7MyZP6Vy3gsk8h2QU8hc65olp3XXyOxARiTC93Knn26H87EybKSrOMi2/Dokic2S/n WIUnOia6kCkVqPwWqSKShXYJAiIynhTlO1rVB8MLB3ddn73zZPY5XHyxR8vV7Dbibj+R Ua6A==
X-Received: by 10.28.188.84 with SMTP id m81mr13441611wmf.38.1449385176589; Sat, 05 Dec 2015 22:59:36 -0800 (PST)
Received: from yoavs-mbp.mshome.net ([176.12.139.87]) by smtp.gmail.com with ESMTPSA id r74sm10817091wmb.2.2015.12.05.22.59.34 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 05 Dec 2015 22:59:35 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <CACsn0cmenEcWq-Zzct4rfEyJ_QEp92VNDHiPOnB06ZvWz=twkw@mail.gmail.com>
Date: Sun, 06 Dec 2015 08:59:31 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8DCA2D60-443F-41C1-82A2-294FD16D15D7@gmail.com>
References: <20151015130040.9F1BB1A2EF@ld9781.wdf.sap.corp> <2977428.j4DNTR9LXR@pintsize.usersys.redhat.com> <20151016203610.GA5596@roeckx.be> <2348468.lpGyMim7ub@pintsize.usersys.redhat.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9B3DA@uxcn10-5.UoA.auckland.ac.nz> <CACsn0ckLkgMA2xHphro-a1N3tr+NJAvRV_NvVKP2K-=7zj1OfA@mail.gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9B509@uxcn10-5.UoA.auckland.ac.nz> <CACsn0cmUzez7zttX+F-axEfCo098FWOWyj2UkBuV2Nc+weoSqQ@mail.gmail.com> <9A043F3CF02CD34C8E74AC1594475C73F4B9B5C9@uxcn10-5.UoA.auckland.ac.nz> <CACsn0cmenEcWq-Zzct4rfEyJ_QEp92VNDHiPOnB06ZvWz=twkw@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
X-Mailer: Apple Mail (2.3096.5)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Ewmxjb2DSGGQPhh0QzkH16d-htg>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Fwd: Clarification on interleaving app data and handshake records
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 06 Dec 2015 06:59:39 -0000

> On 6 Dec 2015, at 4:44 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
> 
>  If you disagree, please cite the sentence of the TLS
> RFC which prohibits accepting application data records during the
> handshake.

OK, I’ll bite. Top of page 36:

      Client                                               Server

      ClientHello                  -------->
                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      Certificate*
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data

             Figure 1.  Message flow for a full handshake


See?  Application data goes *after* the Finished message. Not between ClientHello and anything else. Now this swim track diagram may not look like a formal definition, but RFCs are written to be processed by humans, not computers. If I add some application data in the middle there like this:

      Client                                               Server

      ClientHello                  -------->
                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      Application Data
      ClientKeyExchange
      CertificateVerify*
      [ChangeCipherSpec]
      Finished                     -------->
                                               [ChangeCipherSpec]
                                   <--------             Finished
      Application Data             <------->     Application Data


Any human can see that this is not the same as what’s in Figure 1, and thus is wrong. We don’t need the RFC to provide a regular expression or a state machine diagram to figure that out.

Yoav