Subject: [TLS] GH repo location for draft-ietf-tls-exported-authenticator

From: Sean Turner <[email-masked]>
Date: Thu, 13 Jul 2017 15:21:22 -0400

Nick reminded me to create a repo for draft-ietf-tls-exported-authenticator.  It can be found here:
https://github.com/tlswg/tls-exported-authenticator
Nick’s going to copy the draft from his private repo to this one soon.

spt

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 20 Jul 2017 10:02:17 +0300

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

---

From: Watson Ladd <[email-masked]>
Date: Thu, 20 Jul 2017 09:33:40 -0700

> uses for sending is "EXPORTER-server authenticator finished key".

That is clearly bug. Thanks for commenting.

> I presume it is the same hash as the one took the output length of

That is what I interpreted it as.

> is the same hash as in 3).

It's sad that there is not a hash function determined by negotiation in
TLS. What text would identify it?

> computation in the TLS connection the authenticator is to be created

There is a site at leftshark.tls13.com that uses this extension. It hasn't
been updated for the latest draft just yet

>
>
>
> -Ilari
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 21 Jul 2017 14:55:21 -0500

Unrelated to Ilari's questions, I wonder if we want to say anything
about certificate_request_context values being unique across both in-TLS
post-handshake auth and exported authenticators.

-Ben

---

From: Watson Ladd <[email-masked]>
Date: Fri, 21 Jul 2017 22:17:08 -0700

On Fri, Jul 21, 2017 at 12:55 PM, Benjamin Kaduk <[email-masked]> wrote:
> Unrelated to Ilari's questions, I wonder if we want to say anything about
> certificate_request_context values being unique across both in-TLS

This context is not a security sensitive thing: it is for disambiguation.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 22 Jul 2017 08:34:54 +0300

> This context is not a security sensitive thing: it is for disambiguation.

I'm not so sure about that.

If crc is repeated within a connection, then the old certificate
message can be replayed.

If crc is guessed, then reply can be pregenerated anytime during
connection.

However, neither seems crticial, but might be of magnitude to note.

-Ilari

---

From: Watson Ladd <[email-masked]>
Date: Fri, 21 Jul 2017 22:42:08 -0700

> However, neither seems crticial, but might be of magnitude to note.

Yes, if we want  freshness then we need a challenge-response protocol.
I don't recall if the H2 draft does.

---

From: Martin Thomson <[email-masked]>
Date: Sat, 22 Jul 2017 10:13:51 +0200

> I don't recall if the H2 draft does.

It cannot.

The question is whether freshness regarding the request is necessary,
or whether it is just freshness with respect to connection that we
need.  That is, was the response generated for this connection, or was
it generated in response to a specific request.  I think that a
binding to the connection is sufficient.

In terms of use cases, the current design is a much better fit.  It
allows for spontaneous assertions of identity rather than requiring a
request/response exchange.

If we need request/response - which I don't think we do - then that
should be integral to this mechanism.  I don't want to rely on the
using protocol doing the right thing.