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

From: Nick Sullivan <[email-masked]>
Date: Sat, 06 Aug 2016 01:38:40 +0000

<https://tools.ietf.org/html/draft-sullivan-tls-post-handshake-auth-00>

We discussed on this list a proposal to allow secondary certificate
authentication in HTTP/2 (https://tools.ietf.org/html/draft-bishop-httpbis-
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.

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.

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.

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

Nick Sullivan

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 6 Aug 2016 20:26:05 +0300

> 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
usage.

> 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
[1]

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

hash(extended_handshake_hash + certificate_request* + certificate) +
resumption_context

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.

or

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

> 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
connection).

> 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.

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Mon, 8 Aug 2016 11:19:39 +1000

> coordination above TLS layer (like HTTP/2)?

The companion h2 draft hasn't been updated, but this will need support
from the application layer to use.  The intent is to take the
structure of draft-bishop-httpbis-http2-additional-certs and remove
the stream 0 components and replace them with this draft.

> (HTTP/2 absolutely needs to be able to refer to client authority).

The API might take one of two forms:
1. an application requests that authentication happen and get the
identifier that TLS uses in return
2. an application requests authentication and specifies the identifier
(the TLS stack will have to verify that this is unique and conforms to
the restrictions)

> reporting handled? One can't use alerts for non-fatal reports.

Good question.  Errors in encoding or otherwise problems following the
rules in the spec should result in a connection-level fatal error.
But if the certificate isn't trusted, handling that will be up to the
application.

> so they can immediately follow with appdata coordinating the

Not sure where you are going here.

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 8 Aug 2016 09:14:13 +0300

> (the TLS stack will have to verify that this is unique and conforms to

In 2, I would imagine the context is probably usually a sequence
number of some kind.
 
> But if the certificate isn't trusted, handling that will be up to the

And that should presumably be communicated somehow...

> Not sure where you are going here.

Being able for application to to wait for certificate/cv/finised
message to be sent, so it can do something special in application
layer immediately after that.

-Ilari

---

From: Martin Thomson <[email-masked]>
Date: Mon, 8 Aug 2016 16:42:10 +1000

> In 2, I would imagine the context is probably usually a sequence

The draft defines some rules for construction of identifiers that
prevent collisions and the like.

> And that should presumably be communicated somehow...

Of course.  See
https://github.com/grittygrease/tls13-post-handshake-auth/issues/18
(feel free to contribute)

> layer immediately after that.

Sure.  The usual async API guarantees apply here; I don't know that
this needs special treatment in the spec though.  If you disagree, I'm
sure that my coauthors would be happy to take suggestions for
improvements.

---

From: Nick Sullivan <[email-masked]>
Date: Wed, 17 Aug 2016 21:50:32 +0000

Is there any support for either of the following ideas:

1) moving the OCSP and SCT server extensions to inside the Certificate
message
2) removing post-handshake client authentication from TLS 1.3 in favor of
dedicated and more detailed draft