Subject: [Unbearable] Clarification needed on two points in spec

From: Bill Cox <[email-masked]>
Date: Sun, 1 Nov 2015 16:42:14 -0800

Hi.  Nick and I wound up with incompatible Token Binding implementations
due to two issues which I don't think are very clear in the spec:

- What is the format of the EC point?  I assumed 64 bytes (X followed by
Y), while Nick assumed that "uncompressed" referred to the standard format
starting with 0x04, then 32-bytes for X, and 32-bytes for Y.  Which is it?
Channel ID used 64-bytes, which is what I went with.

- We've dropped SHA256 as the message digest.  I assumed this is because
EKM already uses SHA256 on all supported TLS versions, and that we are
supposed to generate "raw" signatures of the 32-byte EKM output directly,
rather than using SHA256 to again hash the EKM output.  Nick assumed the
signature is over the SHA256 digest of the EKM output.  Which is it?

Calling yet another SHA256 makes me cringe.  It is bad enough we're using
HMAC, which calls SHA256 twice already, when all we really need is
SHA256("token_binding" || extended_master_secret).  However, OpenSSL does
not support "raw" signatures when using it's EVP_PKEY interface, which I
would prefer to use.  Instead, I had to write the signature algorithms at a
very low level myself to avoid the extra call to SHA256.  This seems a bit
nutty.  Nick's code is cleaner, and more likely to be bug free in this case.

Since the signature algorithms insist on using a hash function, I'm tempted
to compute the hash of "token_binding" || extended_master_secret  in the
signature algorithm and bypass these extra hashing steps.  However,
inefficiency bothers me a lot more than most.

What should we do?

Thanks,
Bill

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 2 Nov 2015 09:48:06 +0900

On Mon, Nov 2, 2015 at 9:42 AM, Bill Cox <[email-masked]> wrote:

> Calling yet another SHA256 makes me cringe.
>

Why? What resource are you trying to conserve?

-Ekr

>   It is bad enough we're using HMAC, which calls SHA256 twice already,
> when all we really need is SHA256("token_binding"
> || extended_master_secret).  However, OpenSSL does not support "raw"
> signatures when using it's EVP_PKEY interface, which I would prefer to
> use.  Instead, I had to write the signature algorithms at a very low level
> myself to avoid the extra call to SHA256.  This seems a bit nutty.  Nick's
> code is cleaner, and more likely to be bug free in this case.
>
> Since the signature algorithms insist on using a hash function, I'm
> tempted to compute the hash of "token_binding" || extended_master_secret
>  in the signature algorithm and bypass these extra hashing steps.  However,
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>
>

---

From: Andrei Popov <[email-masked]>
Date: Mon, 2 Nov 2015 00:53:56 +0000

Hi Bill,

Ø  What is the format of the EC point?
Uncompressed point format per RFC 4492. Will clarify in the next revision.

Ø  We've dropped SHA256 as the message digest.  I assumed this is because EKM already uses SHA256 on all supported TLS versions, and that we are supposed to generate "raw" signatures of the 32-byte EKM output directly, rather than using SHA256 to again hash the EKM output.  Nick assumed the signature is over the SHA256 digest of the EKM output.  Which is it?
I don’t see the need to hash the EKM output once more, and so the spec says “a signature over the exported keying material (EKM) value”

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Bill Cox
Sent: Monday, November 2, 2015 9:42 AM
To: [email-masked]
Subject: [Unbearable] Clarification needed on two points in spec

Hi.  Nick and I wound up with incompatible Token Binding implementations due to two issues which I don't think are very clear in the spec:

- What is the format of the EC point?  I assumed 64 bytes (X followed by Y), while Nick assumed that "uncompressed" referred to the standard format starting with 0x04, then 32-bytes for X, and 32-bytes for Y.  Which is it?  Channel ID used 64-bytes, which is what I went with.

- We've dropped SHA256 as the message digest.  I assumed this is because EKM already uses SHA256 on all supported TLS versions, and that we are supposed to generate "raw" signatures of the 32-byte EKM output directly, rather than using SHA256 to again hash the EKM output.  Nick assumed the signature is over the SHA256 digest of the EKM output.  Which is it?

Calling yet another SHA256 makes me cringe.  It is bad enough we're using HMAC, which calls SHA256 twice already, when all we really need is SHA256("token_binding" || extended_master_secret).  However, OpenSSL does not support "raw" signatures when using it's EVP_PKEY interface, which I would prefer to use.  Instead, I had to write the signature algorithms at a very low level myself to avoid the extra call to SHA256.  This seems a bit nutty.  Nick's code is cleaner, and more likely to be bug free in this case.

Since the signature algorithms insist on using a hash function, I'm tempted to compute the hash of "token_binding" || extended_master_secret  in the signature algorithm and bypass these extra hashing steps.  However, inefficiency bothers me a lot more than most.

What should we do?

Thanks,
Bill

---

From: Bill Cox <[email-masked]>
Date: Sun, 1 Nov 2015 16:57:13 -0800

> Why? What resource are you trying to conserve?

I'm trying to reduce connection latency.  Let's just say that my yearly
salary is on the order of what slowing down connections by 1 microsecond
costs Google.  Signing and verification using P256 typically takes about
0.25 milliseconds, which is a very high price to pay for Token Binding.  I
would rather not see it climb to 0.26 milliseconds if we can prevent it.

Bill

---

From: Andrei Popov <[email-masked]>
Date: Mon, 2 Nov 2015 00:57:29 +0000

I could be wrong, but hashing the EKM seems to serve no purpose. Eric, do you think there is a good reason to do this?

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Monday, November 2, 2015 9:48 AM
To: Bill Cox <[email-masked]>
Cc: [email-masked]
Subject: Re: [Unbearable] Clarification needed on two points in spec

On Mon, Nov 2, 2015 at 9:42 AM, Bill Cox <[email-masked]<mailto:[email-masked]>> wrote:
Hi.  Nick and I wound up with incompatible Token Binding implementations due to two issues which I don't think are very clear in the spec:

-Ekr

  It is bad enough we're using HMAC, which calls SHA256 twice already, when all we really need is SHA256("token_binding" || extended_master_secret).  However, OpenSSL does not support "raw" signatures when using it's EVP_PKEY interface, which I would prefer to use.  Instead, I had to write the signature algorithms at a very low level myself to avoid the extra call to SHA256.  This seems a bit nutty.  Nick's code is cleaner, and more likely to be bug free in this case.

What should we do?

Thanks,
Bill

_______________________________________________
Unbearable mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/unbearable<https://na01.safelinks.protection.outlook.com/?url=https%3a%2f%2fwww.ietf.org%2fmailman%2flistinfo%2funbearable&data=01%7c01%7cAndrei.Popov%40microsoft.com%7cd7e5f893dd924893101808d2e31f705b%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=BryXg2C8QZhdlTToyRuiUa7ADz9rsHhQpiwCfOsDgDA%3d>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 2 Nov 2015 09:59:21 +0900

> would rather not see it climb to 0.26 milliseconds if we can prevent it.

Do you have any measurements that show that the SHA-256 has a significant
impact here, given that the message this is being embedded in probably has
on the order of 20-50 AES-GCM blocks.

-Ekr

---

From: Andrei Popov <[email-masked]>
Date: Mon, 2 Nov 2015 01:00:59 +0000

Probably so, but why hash it if we don’t have to?

From: Unbearable [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Monday, November 2, 2015 9:59 AM
To: Bill Cox <[email-masked]>
Cc: [email-masked]
Subject: Re: [Unbearable] Clarification needed on two points in spec

On Mon, Nov 2, 2015 at 9:57 AM, Bill Cox <[email-masked]<mailto:[email-masked]>> wrote:
On Sun, Nov 1, 2015 at 4:48 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
Calling yet another SHA256 makes me cringe.

-Ekr

I'm trying to reduce connection latency.  Let's just say that my yearly salary is on the order of what slowing down connections by 1 microsecond costs Google.  Signing and verification using P256 typically takes about 0.25 milliseconds, which is a very high price to pay for Token Binding.  I would rather not see it climb to 0.26 milliseconds if we can prevent it.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 2 Nov 2015 10:02:13 +0900

Sure, I'm not aware of any reason not to remove it. I was just trying to
get clarity
around the argument for removing it. Simplicity seems like a stronger
argument
than performance here.

-Ekr

On Mon, Nov 2, 2015 at 10:00 AM, Andrei Popov <[email-masked]>
wrote:

> *From:* Unbearable [mailto:[email-masked]] *On Behalf Of *Eric
> Rescorla
> *Sent:* Monday, November 2, 2015 9:59 AM
> *To:* Bill Cox <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [Unbearable] Clarification needed on two points in spec
>
>
>

---

From: Bill Cox <[email-masked]>
Date: Sun, 1 Nov 2015 17:30:13 -0800

On Sun, Nov 1, 2015 at 4:59 PM, Eric Rescorla <[email-masked]> wrote:

> n the order of 20-50 AES-GCM blocks.
>
> -Ekr
>

I did some "openssl speed" tests on my corp laptop.  SHA256 of a 64-byte
value only takes 0.6us.  Not bad!  Encrypting 256 bytes with aes-128-cbc
takes 0.35us, so it is actually faster to encrypt a TokenBindingMessage
than to call SHA256 once.

Signing and verification, assuming my laptop is the client, and my
workstation at work is the server, take about 250us.  However, we expect to
be able to use Ed25519 in the future, and I expect these totals to drop to
closer to 100us.  This decision seems to have about a 1% latency impact
overall for the cost of Token Binding.

I guess I care more about 1% than most people, but even I have trouble
getting too bent out of shape over it.

Bill

---

From: Andrei Popov <[email-masked]>
Date: Mon, 2 Nov 2015 02:04:17 +0000

From my perspective, if we don’t have to negotiate the hash alg, it’s goodness.

From: Eric Rescorla [mailto:[email-masked]]
Sent: Monday, November 2, 2015 10:02 AM
To: Andrei Popov <[email-masked]>
Cc: Bill Cox <[email-masked]>; [email-masked]
Subject: Re: [Unbearable] Clarification needed on two points in spec

Sure, I'm not aware of any reason not to remove it. I was just trying to get clarity
around the argument for removing it. Simplicity seems like a stronger argument
than performance here.

-Ekr

On Mon, Nov 2, 2015 at 10:00 AM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:
Probably so, but why hash it if we don’t have to?

From: Unbearable [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Eric Rescorla
Sent: Monday, November 2, 2015 9:59 AM
To: Bill Cox <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Unbearable] Clarification needed on two points in spec

-Ekr

-Ekr

---

From: Andrei Popov <[email-masked]>
Date: Mon, 2 Nov 2015 02:05:53 +0000

It sounds like you did the right thing per TBPROTO-03 draft. And saved a few CPU cycles☺.

From: Unbearable [mailto:[email-masked]] On Behalf Of Bill Cox
Sent: Monday, November 2, 2015 10:30 AM
To: Eric Rescorla <[email-masked]>
Cc: [email-masked]
Subject: Re: [Unbearable] Clarification needed on two points in spec

On Sun, Nov 1, 2015 at 4:59 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
Do you have any measurements that show that the SHA-256 has a significant impact here, given that the message this is being embedded in probably has n the order of 20-50 AES-GCM blocks.

-Ekr

I did some "openssl speed" tests on my corp laptop.  SHA256 of a 64-byte value only takes 0.6us.  Not bad!  Encrypting 256 bytes with aes-128-cbc takes 0.35us, so it is actually faster to encrypt a TokenBindingMessage than to call SHA256 once.

Signing and verification, assuming my laptop is the client, and my workstation at work is the server, take about 250us.  However, we expect to be able to use Ed25519 in the future, and I expect these totals to drop to closer to 100us.  This decision seems to have about a 1% latency impact overall for the cost of Token Binding.

I guess I care more about 1% than most people, but even I have trouble getting too bent out of shape over it.

Bill