[TLS] draft-ietf-tls-exported-authenticator questions

Ilari Liusvaara <ilariliusvaara@welho.com> Thu, 20 July 2017 07:02 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 C46091242F5 for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 00:02:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001] 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 hZBroh_Z75a6 for <tls@ietfa.amsl.com>; Thu, 20 Jul 2017 00:02:20 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9135F127866 for <tls@ietf.org>; Thu, 20 Jul 2017 00:02:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 035F7232B7 for <tls@ietf.org>; Thu, 20 Jul 2017 10:02:19 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id LAweFJkurnv3 for <tls@ietf.org>; Thu, 20 Jul 2017 10:02:18 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id C368527F for <tls@ietf.org>; Thu, 20 Jul 2017 10:02:17 +0300 (EEST)
Date: Thu, 20 Jul 2017 10:02:17 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: tls@ietf.org
Message-ID: <20170720070217.xvwmrd3ootvjr2fu@LK-Perkele-VII>
References: <D6717B12-60FE-4E08-812E-4C5FB1B908F6@sn3rd.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <D6717B12-60FE-4E08-812E-4C5FB1B908F6@sn3rd.com>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/I0r4vKLazxQH86QVjTq4OTO0Wt4>
Subject: [TLS] draft-ietf-tls-exported-authenticator questions
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 20 Jul 2017 07:02:23 -0000

While reading/implementing draft-ietf-tls-exported-authenticator I came
across the following:

1)

The exporter labels are the opposite way around for handshake
contexts and finished keys, which makes little sense.

The text seems to imply that the finished key label the client
uses for sending is "EXPORTER-server authenticator finished key".

2)

In TLS 1.2, even if TLS PRF is not used, the hash function that
absolutely must exist is called "the hash function to use in the
Finished message computation" or "the hash function defined for the
Finished message computation" (and if TLS PRF is used, this hash is
the same hash function as the one underlying TLS PRF).

TLS 1.3 is less consistent:

- "the Hash algorithm for the handshake" (4.4.4)
- "KDF hash algorithm" (4.6.1)
- "the cipher suite hash algorithm" (7.1)
- "the [...] hash algorithm to be used with HKDF" (B.4)

... All those apparently refer to one and the same thing.

3)

What is the Hash() in

"Hash(Handshake Context || Certificate)" and
"Hash(Handshake Context || Certificate || CertificateVerify)"

?

I presume it is the same hash as the one took the output length of
in 2).

4)

What is "the hash function from the handshake" exactly? I presume it
is the same hash as in 3).


5)

Test vectors would be nice (use some deterministic signature, like
Ed25519)...

I have one set of vectors I dumped from my implementation, but no
idea if those are correct (for example, I assumed that the handshake
context and finished labels are the same way around, and the hash for
points 2 to 4 is the hash function defined for the Finished message
computation in the TLS connection the authenticator is to be created
from).



-Ilari