[TLS] HMAC context of ClientFinished in TLS 1.3

Kazuho Oku <kazuhooku@gmail.com> Fri, 07 October 2016 09:41 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 06766129528 for <tls@ietfa.amsl.com>; Fri, 7 Oct 2016 02:41:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 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, 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 1ODrwRlhSnqV for <tls@ietfa.amsl.com>; Fri, 7 Oct 2016 02:41:38 -0700 (PDT)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 87A2312944D for <tls@ietf.org>; Fri, 7 Oct 2016 02:41:38 -0700 (PDT)
Received: by mail-wm0-x22f.google.com with SMTP id f193so3379068wmg.0 for <tls@ietf.org>; Fri, 07 Oct 2016 02:41:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=GO6YDQ9OEupUP1Pt/ff7l7IghH3rOQExWudGVCzdKKg=; b=L1TYBs+rmg3PZLiDFh4aPN1mWFhKRrla21HsxWjEUx5XzT7mRehoxxVYs5aI+T5ETx rn2o0TDfczje4Kg4xu+HGaT+q02s6bBruD3omwWxvtyH574N8vrTFnk2JBn4wYkbHLsL XUWcg9tUHaJ0e0Z52okPkXbRknr/LLrJTLukJ71/ChUy4TLvZtRh9r1p9KoKbN78DaBd r92/pLMlTZ4L5KkJg/laH29jKPEM84fGyVMY8f0N9VOsJUZekfzvsGz+2NrkNF4WrSwJ YxjBuxPjJg3IOwztsZn8rNV+3cBDBiXcG6pu8XZb8nGD8NkX3DilOLAlCwSfOMrNMtXh AWqg==
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 :content-transfer-encoding; bh=GO6YDQ9OEupUP1Pt/ff7l7IghH3rOQExWudGVCzdKKg=; b=XmtvLkcRnijGcZsQ+uhyg4kQ2k8I2hZ06eOjdiplIpccyOxWdcO+GlTwmhjfj6HQ9L xdEflozLGQKvpPadfcItjxpW1FB2e2fGBLHMIm1APr522EPT00w4PhGy7fDcoJO63F1T iSKzvqpxe+7h5P0g3okNcAwGBLbaQ+uW7sK0oHOP8QzGzCkfGW1M/CwbSr9D2YnA2w2R fG9FEt9u+50Lqaul5hJbxF0xkJFIUyxJBXeVk3czZR14PZIlx+5Fcpzu/Yb85VqONSVR +2WNVZE/HM9G7BABG4VIUvALShewalRxzKBhYGL/IOwW8L4e4V+Dixv+zvuaxN+G9chg aF8g==
X-Gm-Message-State: AA6/9Rm03O8SQ8IbZ5VxOkLLd9Fogy+0kRLCRBEQ+Js6/UJZ7yuz32H/toqbkbX0ydp2BoHld7M1B3hfNdHDLA==
X-Received: by 10.194.155.35 with SMTP id vt3mr1669354wjb.223.1475833296561; Fri, 07 Oct 2016 02:41:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.194.163.69 with HTTP; Fri, 7 Oct 2016 02:41:35 -0700 (PDT)
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Fri, 07 Oct 2016 18:41:35 +0900
Message-ID: <CANatvzySkbddprp_mN3Hb4joscUPGANC4KwSz04K7hwRSSL48Q@mail.gmail.com>
To: tls@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/Sdz4OQ8uj1DdX_X05_Bvcq4Vb7o>
Subject: [TLS] HMAC context of ClientFinished 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, 07 Oct 2016 09:41:40 -0000

Hi,

Recently I have started writing a TLS 1.3 implementation. While
working on it, I have noticed the following.

In section 4.4.3, the hash value used for building the HMAC is defined
as: Hash(Handshake Context + Certificate* + CertificateVerify*).

For ServerFinished, this corresponds to the statement following the
formula that states, quote:

    the HMAC input can generally be implemented by a running hash,
i.e., just the handshake hash at this point.

since Handshake Context for 1-RTT server is (as defined in section
4.4): ClientHello … later of EncryptedExtensions/CertificateRequest.

However, for ClientFinished, the two descriptions do not match, since
Handshake Context for 1RTT client is: ClientHello … ServerFinished.

If we follow the way it is defined in the formula, then Certificate
and CertificateVerify needs to be applied to the hash after
ServerFinished, which is in discordance with the statement that it
could be implemented using a running hash.

Is this an error in the draft?

-- 
Kazuho Oku