[TLS] Request for clarification: "in the same flight"

Thijs van Dijk <schnabbel@inurbanus.nl> Thu, 16 April 2015 16:07 UTC

Return-Path: <schnabbel@inurbanus.nl>
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 B41A61ACDEA for <tls@ietfa.amsl.com>; Thu, 16 Apr 2015 09:07:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.712
X-Spam-Level:
X-Spam-Status: No, score=-0.712 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] autolearn=no
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 cf8WqjW9HHte for <tls@ietfa.amsl.com>; Thu, 16 Apr 2015 09:07:29 -0700 (PDT)
Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (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 E47851A891D for <tls@ietf.org>; Thu, 16 Apr 2015 09:07:28 -0700 (PDT)
Received: by wgin8 with SMTP id n8so85958487wgi.0 for <tls@ietf.org>; Thu, 16 Apr 2015 09:07:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=inurbanus.nl; s=google-inurb; h=mime-version:date:message-id:subject:from:to:content-type; bh=bOzaDQtaGAkzaWICoXHgQgS253gLYtLWwfOu/Sgul9A=; b=VZ7dgidv/7sgJG8C5MA3+F0EF7QqKM8+IxNYp9HMPpxNt9ZuyhQ1ghUKyFlRO5hF71 1a7tw8uG4gwUetxpQRWi9UyDPHG/B8MA75huNdbYq3V1tl+mZT/bbJmNMkJBHHBrM78v z0ebbvi61+9m1pS/hf4boJk8GNnRXdQeZqCVM=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=bOzaDQtaGAkzaWICoXHgQgS253gLYtLWwfOu/Sgul9A=; b=VEBO7RJP9KiHS2WZpkk0vEDIcCAjvBhp6w97Yu+wzzYIp8syeOV56sfg2Y+Il77pYQ Mtzt2qnJmyVxe7FbuiylVUEUN+hwq5T879s8KecVOzlf746G8KUKjwDrF3WVjzJE+FlX 8m2faI1LI7BPK+CK4G34ZSG7m/Xde6Ggpt+slb145ujntJz9CpYDbugwY3m/fhJrjX/7 wlf+MWJl6WDdO7lSHMNes6kNaEuOS+Mz4wAsgVaHBn2//u4zBwY3V/wfMRjtDW6kv30g ylTRU2WUItwiYoW5T2OBhpQfMO3A2bM1UsgTTws01HRuKjG3zSf94QQZNlkGF+tQsqYy snVw==
X-Gm-Message-State: ALoCoQkGYBkmeNE9xtig0Y7tDeS7qCUIehHq8JjEZaI2bEG+4JAmn8CpCsaHDs5hHOq2mxeHcBS/
MIME-Version: 1.0
X-Received: by 10.194.159.105 with SMTP id xb9mr62114753wjb.156.1429200447619; Thu, 16 Apr 2015 09:07:27 -0700 (PDT)
Received: by 10.28.104.138 with HTTP; Thu, 16 Apr 2015 09:07:27 -0700 (PDT)
Date: Thu, 16 Apr 2015 18:07:27 +0200
Message-ID: <CADGaDpHn5UoW3JQ58MYVyVZC7YXb3=fSUUz-i=kGi8YH-AHaSA@mail.gmail.com>
From: Thijs van Dijk <schnabbel@inurbanus.nl>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary=001a11c3aa58fe63030513d9a836
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/QvuZclmtXppsmWJ-bDbCTkJ8e4E>
Subject: [TLS] Request for clarification: "in the same flight"
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: Thu, 16 Apr 2015 16:11:00 -0000

Dear all,

I'm working on a hobby implementation of TLS1.3 as a way of vetting the
spec draft, and I ran into an issue with sending the ClientKeyShare.

The handshake spec (7.2) says it should be sent "in the same flight" as the
ClientHello message, without specifying the correct encapsulation method.
Maybe it's just me, but this phrase could be interpreted as either the
following:

TCP packet
 \- TLSPlaintext  (content_type 22)
     |- Handshake (msg_type 1)
     |   \- ClientHello
     \- Handshake (msg_type 5)
         \- ClientKeyShare

or:

TCP packet
 |  TLSPlaintext  (content_type 22)
 |   \- Handshake (msg_type 1)
 |       \- ClientHello
 \- TLSPlaintext  (content_type 22)
     \- Handshake (msg_type 5)
         \- ClientKeyShare

If I were to venture a guess, I'd say the two are equivalent, but it's also
conceivable that some implementations require any TLSPlaintext to contain
exactly one child struct. (Source: mine does; I'm trying to figure out if
that's a bug or not.)

I think that if we have a preference for either one, the spec should
reflect that. If not, it may be wise to explicitly declare both options to
be correct.

Thoughts?


-Thijs


(I have also opened a Github issue to this effect:
https://github.com/tlswg/tls13-spec/issues/164 )