Re: [TLS] draft-sullivan-tls-post-handshake-auth-00

Ilari Liusvaara <> Sat, 06 August 2016 17:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CACC312D52C for <>; Sat, 6 Aug 2016 10:26:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0BWteqO9vksk for <>; Sat, 6 Aug 2016 10:26:15 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 38BF012D520 for <>; Sat, 6 Aug 2016 10:26:14 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 24840E8D5; Sat, 6 Aug 2016 20:26:13 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([IPv6:::ffff:]) by localhost ( [::ffff:]) (amavisd-new, port 10024) with ESMTP id lO26lzxFlrIW; Sat, 6 Aug 2016 20:26:12 +0300 (EEST)
Received: from LK-Perkele-V2 ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 767932316; Sat, 6 Aug 2016 20:26:12 +0300 (EEST)
Date: Sat, 6 Aug 2016 20:26:05 +0300
From: Ilari Liusvaara <>
To: Nick Sullivan <>
Message-ID: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.6.2-neo (2016-07-23)
Archived-At: <>
Cc: "" <>
Subject: Re: [TLS] draft-sullivan-tls-post-handshake-auth-00
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 06 Aug 2016 17:26:18 -0000

On Sat, Aug 06, 2016 at 01:38:40AM +0000, Nick Sullivan wrote:
> <>
> We discussed on this list a proposal to allow secondary certificate
> authentication in HTTP/2 (
> http2-additional-certs). In that discussion, some questions were raised
> around whether or not certificate authentication should be handled in the
> HTTP/2 layer or at the TLS layer. This draft is our attempt to create a
> more complete mechanism for post-handshake authentication in TLS 1.3 that
> supports standard use cases like in-browser client certificate
> authentication as well as new use cases like secondary certificate
> authentication in HTTP/2.

Also, how would this be used in applications that need higher-level
coordination above TLS layer (like HTTP/2)?

Can applications specify and receive the context values used? E.g.
to act as handles to refer to the resulting authority objects
(HTTP/2 absolutely needs to be able to refer to client authority).

Also, are all errors (including things like getting extensions
wrong or CA wrong) fatal to the whole connection, or how is error
reporting handled? One can't use alerts for non-fatal reports.

Also, are applications expected to be able to specify exactly
where in stream to put an authentication (response)? Especially
so they can immediately follow with appdata coordinating the

> This draft takes the post-handshake client authentication mechanism from
> TLS 1.3 (Section 4.4.2.) and generalizes it to allow four types of
> post-handshake authentication:
> * solicited client authentication
> * spontaneous client authentication
> * solicited server authentication
> * spontaneous server authentication
> Support for these modes is negotiated in a new TLS extension.

The crypto used looks bit odd. AFAIU, if one wants to chain hashes,
one should expand the chaining value to multiple of input block and
continue from there.

One could even use the normal TLS authentication block with
extended_handshake_hash as base context (with certificate request
included if present). extended_handshake_hash can either be
the same handshake_hash used for calculating EMS/RMS but padded
to multiple of blocksize, or special HKDF-extracted value that
is one hash input in size.

For SHA-256 "one hash input" is 64 bytes, for SHA-384, it is 128 bytes

I.e. the signature TBS (without context) is:

hash(extended_handshake_hash + certificate_request* + certificate) +

And the MAC input is:

hash(extended_handshake_hash + certificate_request* + certificate
+ certificate_verify) + resumption_context

Where extended_handshake_hash can be:

hash(ClientHello...ClientFinished), padded to input block.


HKDF-Expand-Label result with HashValue=hash(ClientHello...ClientFinished)
and length being hash input block.

> As written, this draft is complementary to the current TLS 1.3 draft,
> however, it makes use of modified versions of the Certificate and
> CertificateRequest structures instead of those from TLS 1.3. If the working
> group agrees that a separate draft is a reasonable approach for
> post-handshake authentication, it may make sense to merge the structure
> changes from this draft into the TLS 1.3 specification and remove
> post-handshake authentication from TLS 1.3. Doing so would likely make both
> TLS 1.3 and this draft smaller, simpler to analyze, and easier to implement.

Yeah, the post-handshake parts are annoying to implement even if one
does not support actual post-handshake auth (due to the requirement to
send Finished) if one wants to do anything else except just plain not
respond to server requests (or even worse, just terminate the

> This draft comes with the caveat that the new post-handshake flows still
> need formal a security proof.

Just keep in mind that even if it is secure at TLS level, does not mean
it is secure at application level!

[1] SHA3-256 would have 136, SHA3-384 would have 104. BLAKE2b would
have 128.