Re: [TLS] HMAC context of ClientFinished in TLS 1.3

Ilari Liusvaara <ilariliusvaara@welho.com> Fri, 07 October 2016 10:14 UTC

Return-Path: <ilariliusvaara@welho.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 C5C6D129552 for <tls@ietfa.amsl.com>; Fri, 7 Oct 2016 03:14:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.396
X-Spam-Level:
X-Spam-Status: No, score=-4.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-2.996] autolearn=ham autolearn_force=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 tpgMTcs14sbB for <tls@ietfa.amsl.com>; Fri, 7 Oct 2016 03:14:44 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9E4B11294B1 for <tls@ietf.org>; Fri, 7 Oct 2016 03:14:44 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 7739E16871; Fri, 7 Oct 2016 13:14:42 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id P0dNtGVaC-pp; Fri, 7 Oct 2016 13:14:42 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 1ABB421C; Fri, 7 Oct 2016 13:14:42 +0300 (EEST)
Date: Fri, 07 Oct 2016 13:14:36 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Kazuho Oku <kazuhooku@gmail.com>
Message-ID: <20161007101436.GA8774@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CANatvzySkbddprp_mN3Hb4joscUPGANC4KwSz04K7hwRSSL48Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CANatvzySkbddprp_mN3Hb4joscUPGANC4KwSz04K7hwRSSL48Q@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/AN84i67alonEiHG5VERHeElVAi4>
Cc: tls@ietf.org
Subject: Re: [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 10:14:47 -0000

On Fri, Oct 07, 2016 at 06:41:35PM +0900, Kazuho Oku wrote:
> 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.

Nope, it is a running hash:

The server Finished includes the following messages, in this order:

- ClientHello
- HelloRetryRequest (if sent)
- Clienthello (another, if HRR was sent)
- ServerHello
- EncryptedExtensions
- CertificateRequest (if sent)
- Certificate (server's)
- CertificateVerify (server's)

And this exactly corresponds to the send/receive order.


The client finished includes, in this order:

- ClientHello
- HelloRetryRequest (if sent)
- Clienthello (another, if HRR was sent)
- ServerHello
- EncryptedExtensions
- CertificateRequest (if sent)
- Certificate (server's)
- CertificateVerify (server's)
- Finished (server's)
- Certificate (client's, if CR was sent).
- CertificateVerify (client's, if non-empty client cert was sent)

And this exactly corresponds to the send/receive order.


One place to be careful of is client application keys: The hash used
for those is taken immediately after ServerFinished, but the keys are
only commissioned after ClientFinished (whereas server keys have the
hash taken in the same time as those are commissioned in).



-Ilari