[TLS] Verifying the second HelloRequest in TLS 1.3

Kazuho Oku <kazuhooku@gmail.com> Fri, 18 November 2016 09:19 UTC

Return-Path: <kazuhooku@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C11912941A for <tls@ietfa.amsl.com>; Fri, 18 Nov 2016 01:19:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 nF6Yqz8amZj2 for <tls@ietfa.amsl.com>; Fri, 18 Nov 2016 01:19:32 -0800 (PST)
Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::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 85F4A12955F for <tls@ietf.org>; Fri, 18 Nov 2016 01:19:32 -0800 (PST)
Received: by mail-wm0-x22c.google.com with SMTP id u144so3865297wmu.1 for <tls@ietf.org>; Fri, 18 Nov 2016 01:19:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=yFyEXmmgQo97WEkB7uGMU0vMsVRSDxIlgge0cYwTJbM=; b=K2/CTX2Spq4YyoVA47BP/gPMBFiWtdBOgnINtSm6xp+qdPVBc/MiAXq4x5wa5Lf9A/ iQe6kA24L6fuKNO1l0U6OhVo1zGczQ46Dhn7MJCpeW7OoBr+ZrJ3WNXIwVuF8SF49xEG neRWMebfZMuKucMVALexpEov7Oy+0Ewp9pO/YHK/7usPqFR/FF9TdQ+VroWMq++63WXh p+MnJ2CD1xY1ZMOTeM72OrPov8V1WyV7jsPvwXzFL6AkzL2smCG0QuRlcRpwIWbbd/mo lQf/TC4eqjhI8cT0+dMdWyDcpcnn3Y/EycW89DE6NABOyrjwJI2sHIVUW5Kb4me69iLl X63g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=yFyEXmmgQo97WEkB7uGMU0vMsVRSDxIlgge0cYwTJbM=; b=EwmZz7Ch+s8osrIfJx/UsH6dqLH8pp7MBANcXGwphr0US8n7/FVQqBHE3376KQhbuF EqCq+iTUtl3FwuUSwyjnwZ97h8TH/4d/m45RSsBSiuyxxLMEtrB7AaROSvwLDPBftAp4 M8VjvdEHgp6M6snNgsYcDwIqN07/eR6wDHYexUoBwPc0MJEjgHuDlBfRzK+x5F1XiJA0 Z43afaDwvM4XO1QC1O8vNhs93ab61gC9baJSp/dqjTQycaKs2InKGrtduSAdRpA6QUxP ct+fcWBGbdNZ29lB16+b3lEU8TUzP7BPVpHxzPHazl7QZj4kEZKoNfZZpxayW4QemTV2 Hmeg==
X-Gm-Message-State: AKaTC03XnVNhc5wdinEjrFfeYhonpf7zkuq1ucbPNYa/N9+wVwsKgod2WP8NQjkD6VBV5s2QHP59aTTHm8ZmQg==
X-Received: by 10.194.116.66 with SMTP id ju2mr4854282wjb.223.1479460770792; Fri, 18 Nov 2016 01:19:30 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.32.1 with HTTP; Fri, 18 Nov 2016 01:19:30 -0800 (PST)
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Fri, 18 Nov 2016 18:19:30 +0900
Message-ID: <CANatvzysb4Acn_Ep533eGFmhS_YTvo+AN_t+fsCPy7iQ8817Eg@mail.gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="001a1130d266b3cc0405418fcd62"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/fy2mKq5TTHE3r9AyfLRgLrBrZxI>
Subject: [TLS] Verifying the second HelloRequest in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: Fri, 18 Nov 2016 09:19:34 -0000

Hi,

In section 4.1.2, the latest draft (18) states that a ClientHello sent in
response to a HelloRetryRequest must be identical to the first one except
for addition, modification, and removal of the designated extensions.

To be precise, the draft states:

   In that case, the client MUST send the same
   ClientHello (without modification) except:

   -  If a "key_share" extension was supplied in the HelloRetryRequest,
      replacing the list of shares with a list containing a single
      KeyShareEntry from the indicated group.

   -  Removing the "early_data" extension (Section 4.2.8) if one was
      present.  Early data is not permitted after HelloRetryRequest.

   -  Including a "cookie" extension if one was provided in the
      HelloRetryRequest.

Does this mean that the ClientHello must be at the octet-level be
equivalent (with the exception for the positions at which the necessary
extensions are inserted)?

Or does this mean that a semantically equivalent ClientHello must be
accepted? If this is the case, it would mean that a client is allowed to
exchange the order of the extensions within ClientHello. There could be
other ways to construct an semantically identical ClientHello that looks
different at byte level.

I think the latest draft can be interpreted in either way (please correct
me if I am wrong), and would like to learn what the answer would be.

Thank you in advance.

-- 
Kazuho Oku