Subject: [Unbearable] Dumb idea: add Ed25519 support?

From: Bill Cox <[email-masked]>
Date: Tue, 30 Aug 2016 13:41:41 -0700

I hate to offer yet another possible upgrade to TB, but I really would
prefer to use Ed25519 by default.  I see QUIC is already using it, and it
seems a bit silly not to enable it in TB, when I've already implemented
support for the other three.  Should we add Ed25519-SHA256 as a 4th key
parameters type?

Bill

---

From: Tony Arcieri <[email-masked]>
Date: Tue, 30 Aug 2016 13:57:18 -0700

+1.

In short order draft-irtf-cfrg-eddsa should become an informational RFC. I
think it at least makes sense to at least support the new CFRG
curves/signature algorithm.

On Tue, Aug 30, 2016 at 1:41 PM, Bill Cox <[email-masked]> wrote:

> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>
>

-- 
Tony Arcieri

---

From: Andrei Popov <[email-masked]>
Date: Tue, 30 Aug 2016 21:00:29 +0000

I would not oppose a PR adding this new TokenBindingKeyParameters identifier, although at some point we should freeze the existing 3 specs for LC and put new ideas into new specs.

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Tony Arcieri
Sent: Tuesday, August 30, 2016 1:57 PM
To: Bill Cox <[email-masked]>
Cc: Tokbind WG <[email-masked]>
Subject: Re: [Unbearable] Dumb idea: add Ed25519 support?

+1.

In short order draft-irtf-cfrg-eddsa should become an informational RFC. I think it at least makes sense to at least support the new CFRG curves/signature algorithm.

On Tue, Aug 30, 2016 at 1:41 PM, Bill Cox <[email-masked]<mailto:[email-masked]>> wrote:
I hate to offer yet another possible upgrade to TB, but I really would prefer to use Ed25519 by default.  I see QUIC is already using it, and it seems a bit silly not to enable it in TB, when I've already implemented support for the other three.  Should we add Ed25519-SHA256 as a 4th key parameters type?

Bill

_______________________________________________
Unbearable mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/unbearable

--
Tony Arcieri

---

From: Leif Johansson <[email-masked]>
Date: Tue, 30 Aug 2016 23:18:59 +0200

On 2016-08-30 22:41, Bill Cox wrote:
> prefer to use Ed25519 by default.  I see QUIC is already using it, and
> it seems a bit silly not to enable it in TB, when I've already
> implemented support for the other three.  Should we add Ed25519-SHA256
> as a 4th key parameters type?

We should certainly make sure the specs can swallow something like this
as an extension but in order to hold up the specs at this point with
a substantial addition I would like (with chair hat on) to see pretty
strong statements of support from implementors.

	Cheers Leif

---

From: Bill Cox <[email-masked]>
Date: Tue, 30 Aug 2016 14:27:00 -0700

> strong statements of support from implementors.

That sounds really good to me.  The changes from the -08 to -09 are going
to set me back a week, most likely.  BTW, why do we use SHA256 to hash all
the security parameters together rather than feed them as parameters into
the key export material API?  It already has a "label" and a "context".
This would be a smaller change, and would eliminate a SHA256 hash.

Bill

---

From: Andrei Popov <[email-masked]>
Date: Tue, 30 Aug 2016 21:27:33 +0000

Perhaps this could be a new I-D specifying a new TokenBindingKeyParameters identifier.

Speaking as an implementer, MS has no plans to support Ed25519 TB keys in the foreseeable future.

Cheers,

Andrei

-----Original Message-----
From: Unbearable [mailto:[email-masked]] On Behalf Of Leif Johansson
Sent: Tuesday, August 30, 2016 2:19 PM
To: [email-masked]
Subject: Re: [Unbearable] Dumb idea: add Ed25519 support?

> as a 4th key parameters type?

We should certainly make sure the specs can swallow something like this as an extension but in order to hold up the specs at this point with a substantial addition I would like (with chair hat on) to see pretty strong statements of support from implementors.

	Cheers Leif

---

From: Andrei Popov <[email-masked]>
Date: Tue, 30 Aug 2016 21:33:56 +0000

Are you suggesting that we concatenate:
   o  A ProtocolVersion structure representing the negotiated version of
      the Token Binding protocol, e.g. 0x01 0x00 for Token Binding 1.0;
   o  TokenBindingType value contained in the
      TokenBinding.tokenbinding_type field;
   o  TokenBindingKeyParameters value contained in the
      TokenBindingID.key_parameters field;

And use the result as our EKM context value, and then just sign the resulting EKM?

From: Unbearable [mailto:[email-masked]] On Behalf Of Bill Cox
Sent: Tuesday, August 30, 2016 2:27 PM
To: Leif Johansson <[email-masked]>
Cc: Tokbind WG <[email-masked]>
Subject: Re: [Unbearable] Dumb idea: add Ed25519 support?

On Tue, Aug 30, 2016 at 2:18 PM, Leif Johansson <[email-masked]<mailto:[email-masked]>> wrote:

        Cheers Leif

That sounds really good to me.  The changes from the -08 to -09 are going to set me back a week, most likely.  BTW, why do we use SHA256 to hash all the security parameters together rather than feed them as parameters into the key export material API?  It already has a "label" and a "context".  This would be a smaller change, and would eliminate a SHA256 hash.

Bill

---

From: Bill Cox <[email-masked]>
Date: Tue, 30 Aug 2016 14:37:46 -0700

> And use the result as our EKM context value, and then just sign the

Yes, though I also hate to double-hash values.  The protocol version and
key parameters are already hashed into the handshake hash, which is hashed
into the EKM seed.  This is at least a third level of hashing, and with
repeated parameters.  I've heard mathematicians prefer to analyze a
protocol with everything hashed at once, but in this case, hashing in
parameters from the handshake really is redundant.

Bill

---

From: Andrei Popov <[email-masked]>
Date: Tue, 30 Aug 2016 21:49:04 +0000

The TokenBindingKeyParameters value is not necessarily in the TLS handshake hash (e.g. for referred bindings).

The ProtocolVersion value is only in the TLS handshake if we keep it in the token_binding extension (which I hope we will).

I don’t immediately see why this idea wouldn’t work, and it eliminates one hash operation, but I think we have to supply at least TokenBindingType and TokenBindingKeyParameters as the EKM context.

From: Bill Cox [mailto:[email-masked]]
Sent: Tuesday, August 30, 2016 2:38 PM
To: Andrei Popov <[email-masked]>
Cc: Leif Johansson <[email-masked]>; Tokbind WG <[email-masked]>
Subject: Re: [Unbearable] Dumb idea: add Ed25519 support?

On Tue, Aug 30, 2016 at 2:33 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:

Yes, though I also hate to double-hash values.  The protocol version and key parameters are already hashed into the handshake hash, which is hashed into the EKM seed.  This is at least a third level of hashing, and with repeated parameters.  I've heard mathematicians prefer to analyze a protocol with everything hashed at once, but in this case, hashing in parameters from the handshake really is redundant.

Bill

---

From: Brian Campbell <[email-masked]>
Date: Tue, 30 Aug 2016 16:06:32 -0600

+1 to a new I-D specifying a new TokenBindingKeyParameters identifier for
Ed25519. It'd be a good proof point that the extension hooks in the core
specs are correct.

Likewise as an implementer, I don't envision supporting Ed25519 TB keys in
the reasonably foreseeable future.

On Tue, Aug 30, 2016 at 3:27 PM, Andrei Popov <[email-masked]>
wrote:

> We should certainly make sure the specs can swallow something like this as
> an extension but in order to hold up the specs at this point with a
> substantial addition I would like (with chair hat on) to see pretty strong
> statements of support from implementors.
>
>         Cheers Leif
>
>

---

From: Bill Cox <[email-masked]>
Date: Tue, 30 Aug 2016 15:20:56 -0700

On Tue, Aug 30, 2016 at 2:49 PM, Andrei Popov <[email-masked]>
wrote:

> The TokenBindingKeyParameters value is not necessarily in the TLS
> handshake hash (e.g. for referred bindings).
>
>
>
> The ProtocolVersion value is only in the TLS handshake if we keep it in
> the token_binding extension (which I hope we will).
>
>
>
> I don’t immediately see why this idea wouldn’t work, and it eliminates one
> hash operation, but I think we have to supply at least TokenBindingType
> and TokenBindingKeyParameters as the EKM context.
>

I guess I would prefer this, just for the reduction of one hash operation.

Bill

---

From: Andrei Popov <[email-masked]>
Date: Tue, 30 Aug 2016 22:24:55 +0000

Unless there are objections, I’ll rev TBPROTO once more and eliminate one hash operation. Concatenated TokenBindingType and TokenBindingKeyParameters will be mixed in as EKM context, and the resulting EKM will be signed.

Cheers,

Andrei

Sent: Tuesday, August 30, 2016 3:21 PM

On Tue, Aug 30, 2016 at 2:49 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:
The TokenBindingKeyParameters value is not necessarily in the TLS handshake hash (e.g. for referred bindings).

Bill

---

From: Andrei Popov <[email-masked]>
Date: Wed, 31 Aug 2016 17:18:26 +0000

Thinking more about this, generating EKMs multiple times per connection would be a significant perf issue for us.

EKM is a product of the TLS master secret, and on Windows we keep the TLS master secrets isolated from the TLS client and server applications.
So if we were to go with Bill’s idea, we would have to do extra IPC every time we generate or verify a binding.

On the other hand, a hash function call is in-proc and very cheap, so I’d much rather keep what we have in TBPROTO-09 (perhaps removing the ProtocolVersion from the concatenation, since ProtocolVersion is already mixed in as part of the TLS session hash).

Cheers,

Andrei

From: Andrei Popov
Sent: Tuesday, August 30, 2016 3:25 PM
To: 'Bill Cox' <[email-masked]>
Cc: Leif Johansson <[email-masked]>; Tokbind WG <[email-masked]>
Subject: RE: [Unbearable] Dumb idea: add Ed25519 support?

Cheers,

Andrei

From: Bill Cox [mailto:[email-masked]]
Sent: Tuesday, August 30, 2016 3:21 PM
To: Andrei Popov <[email-masked]<mailto:[email-masked]>>
Cc: Leif Johansson <[email-masked]<mailto:[email-masked]>>; Tokbind WG <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Unbearable] Dumb idea: add Ed25519 support?

Bill

---

From: Brian Campbell <[email-masked]>
Date: Wed, 31 Aug 2016 13:12:42 -0600

In which case I'd again suggest that the signature input be the
concatenated items directly (no hash) and that hashing or not be part of
the signature scheme associated with each key parameters type.

On Wed, Aug 31, 2016 at 11:18 AM, Andrei Popov <[email-masked]>
wrote:

> Thinking more about this, generating EKMs multiple times per connection
> would be a significant perf issue for us.
>
>
>
> EKM is a product of the TLS master secret, and on Windows we keep the TLS
> master secrets isolated from the TLS client and server applications.
>
> On the other hand, a hash function call is in-proc and very cheap, so I’d
> much rather keep what we have in TBPROTO-09 (perhaps removing the
> ProtocolVersion from the concatenation, since ProtocolVersion is already
> mixed in as part of the TLS session hash).
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Andrei Popov
> *Sent:* Tuesday, August 30, 2016 3:25 PM
> *To:* 'Bill Cox' <[email-masked]>
> *Cc:* Leif Johansson <[email-masked]>; Tokbind WG <[email-masked]>
> *Subject:* RE: [Unbearable] Dumb idea: add Ed25519 support?
>
>
>
> Unless there are objections, I’ll rev TBPROTO once more and eliminate one
> hash operation. Concatenated TokenBindingType and TokenBindingKeyParameters
> will be mixed in as EKM context, and the resulting EKM will be signed.
>
>
>
> Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Bill Cox [mailto:[email-masked] <[email-masked]>]
> *Sent:* Tuesday, August 30, 2016 3:21 PM
> *To:* Andrei Popov <[email-masked]>
> *Cc:* Leif Johansson <[email-masked]>; Tokbind WG <[email-masked]>
> *Subject:* Re: [Unbearable] Dumb idea: add Ed25519 support?
>
>
>
> hash operation, but I think we have to supply at least TokenBindingType and
> TokenBindingKeyParameters as the EKM context.
>
>
>

---

From: Bill Cox <[email-masked]>
Date: Wed, 31 Aug 2016 12:35:03 -0700

On Wed, Aug 31, 2016 at 12:12 PM, Brian Campbell <[email-masked]

> the signature scheme associated with each key parameters type.

Sounds good to me.  It fits the standard APIs a bit better.  IIUC, this
result is the same either way, so this is really just a matter of how we
describe it, right?

According to the EKM spec (https://tools.ietf.org/html/rfc5705), a
disambiguating label is required, and we're also supposed to register it so
there are no name collisions.  Is this something we need to worry about?
For some reason, I thought we had already registered "Token Binding" as a
unique EKM label.  If so, we should probably pass the label to the EKM
either in addition to, or instead of, hashing it in the final hash.

Bill

---

From: Brian Campbell <[email-masked]>
Date: Wed, 31 Aug 2016 14:10:44 -0600

On Wed, Aug 31, 2016 at 1:35 PM, Bill Cox <[email-masked]> wrote:

> On Wed, Aug 31, 2016 at 12:12 PM, Brian Campbell <
> [email-masked]> wrote:
>

After playing around with some APIs yesterday, I don't think that the
result is actually the same. At least as far as the actual bytes of the
signature. Conceptually the idea is the same though, AFAIK, and moving the
hash definition to the signature scheme associated with each key parameters
type removes a hardwired dependency on SHA256 and also eliminates a round
of hashing for the RSA key parameters types.

> there are no name collisions.  Is this something we need to worry about?

I think that's already (or will be) covered with the registration request
for "EXPORTER-Token-Binding" in https://tools.ietf.org/html/dr
aft-ietf-tokbind-protocol-09#section-6.4

> either in addition to, or instead of, hashing it in the final hash.

I may have confused things by using the term label for the ASCII string
"Token Binding" that's part of the concatenation of things. It's not a
label in the RFC 5705 sense but more of a disambiguater that is tacked onto
the content that is singed. Andrei can perhaps explain it's purpose better.

But just thinking about that makes me wonder if it's necessary.
""EXPORTER-Token-Binding" is hashed into the EKM which is then under the
signature. Is another "Token Binding" string under the signature needed to
prevent cross protocol attacks? Doesn't the EKM input label already do
that?

---

From: Andrei Popov <[email-masked]>
Date: Wed, 31 Aug 2016 20:11:13 +0000

We’re already registering and passing a label to EKM:
“   The EKM is obtained using the Keying Material Exporters for TLS
   defined in [RFC5705], by supplying the following input values:

   o  Label: The ASCII string "EXPORTER-Token-Binding" with no
      terminating NUL.”

“This document adds a registration for the "EXPORTER-Token-Binding"
   value in the TLS Exporter Label Registry to correspond to this
   specification.”

Cheers,

Andrei

From: Bill Cox [mailto:[email-masked]]
Sent: Wednesday, August 31, 2016 12:35 PM
To: Brian Campbell <[email-masked]>
Cc: Andrei Popov <[email-masked]>; Tokbind WG <[email-masked]>; Leif Johansson <[email-masked]>
Subject: Re: [Unbearable] Dumb idea: add Ed25519 support?

On Wed, Aug 31, 2016 at 12:12 PM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:
In which case I'd again suggest that the signature input be the concatenated items directly (no hash) and that hashing or not be part of the signature scheme associated with each key parameters type.

Sounds good to me.  It fits the standard APIs a bit better.  IIUC, this result is the same either way, so this is really just a matter of how we describe it, right?

According to the EKM spec (https://tools.ietf.org/html/rfc5705), a disambiguating label is required, and we're also supposed to register it so there are no name collisions.  Is this something we need to worry about?  For some reason, I thought we had already registered "Token Binding" as a unique EKM label.  If so, we should probably pass the label to the EKM either in addition to, or instead of, hashing it in the final hash.

Bill

---

From: Bill Cox <[email-masked]>
Date: Wed, 31 Aug 2016 14:01:12 -0700

On Wed, Aug 31, 2016 at 1:10 PM, Brian Campbell <[email-masked]>
wrote:

> hash definition to the signature scheme associated with each key
> parameters type removes a hardwired dependency on SHA256 and also eliminates
> a round of hashing for the RSA key parameters types.
>

The OpenSSL signing APIs are finicky.  They really want to do a digest, and
you have to know how to call them just right to sign the digest, rather
than the hash of the digest.  However, at one point, I was able to verify
that both ways give the same result.  I actually use the normal APIs now
that do the SHA256 while signing.  I do not think this requires a document
change, other than perhaps some clarification.

> aft-ietf-tokbind-protocol-09#section-6.4

OK, great.  In that case, adding "Token Binding" is redundant, but since we
use a 32-byte block hash anyway, I don't think it will make any difference
ins speed, other than the cost of copying the data.

> prevent cross protocol attacks? Doesn't the EKM input label already do

Yes, it does, but so long as it does not cause the data to take up another
32-byte block, I'm OK with it.

So, I'm OK with the -09 version.

Bill