Subject: [Unbearable] Hashing & signatures in TBPROTO-9

From: Brian Campbell <[email-masked]>
Date: Tue, 30 Aug 2016 11:11:13 -0600

Resulting from issues #67
<https://github.com/TokenBinding/Internet-Drafts/issues/67> and #70
<https://github.com/TokenBinding/Internet-Drafts/issues/70> (I think
anyway) are some new rules for calculating the Token Binding signature
(mostly in sec 3.3 of TBPROTO-9
<https://tools.ietf.org/html/draft-ietf-tokbind-protocol-09#section-3.3>).
The signature is now computed over the SHA256 hash of the concatenation of
a few of things (label, version, type, key params, EKM). And both RSA
signature schemes 'MUST use the SHA256 hash algorithm'. While, when an
ecdsap256 key is used, ECDSA with P-256 is used with no hash algorithm.

I guess my question is, now that the signature input is larger than just
the 32 byte EKM and the RSA algs are using SHA256, wouldn't it make sense
and be more consistent to use the concatenation of those items directly as
the input into the signature and, when an ecdsap256 key is used, calculate
the signature with ECDSA using P-256 and SHA256? That'd mean that TBPROTO
wouldn't directly use SHA256 but rather the hashing is pushed into the
definition of how to do the signature for each key parameters type, which
is arguably more cryptographically agile. It'd also be one less round of
hashing for the RSA signature schemes.

Or am I off the rails here?

---

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

Ø  And both RSA signature schemes 'MUST use the SHA256 hash algorithm'. While, when an ecdsap256 key is used, ECDSA with P-256 is used with no hash algorithm.

PSS and PKCS padding schemes are defined with a lot of flexibility, so we have to specify the hash function to be used by these padding schemes.
ECDSA signing does not require padding, so there is no need to specify the hash algorithm.

Ø  The signature is now computed over the SHA256 hash of the concatenation of a few of things (label, version, type, key params, EKM).
Correct, this is to prevent potential attacks that folks have pointed out. This is independent of the signature algorithms and padding schemes that we negotiate via TB key parameters.

Does this make sense?

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]] On Behalf Of Brian Campbell
Sent: Tuesday, August 30, 2016 10:11 AM
To: IETF Tokbind WG <[email-masked]>
Subject: [Unbearable] Hashing & signatures in TBPROTO-9

Resulting from issues #67<https://github.com/TokenBinding/Internet-Drafts/issues/67> and #70<https://github.com/TokenBinding/Internet-Drafts/issues/70> (I think anyway) are some new rules for calculating the Token Binding signature (mostly in sec 3.3 of TBPROTO-9<https://tools.ietf.org/html/draft-ietf-tokbind-protocol-09#section-3.3>). The signature is now computed over the SHA256 hash of the concatenation of a few of things (label, version, type, key params, EKM). And both RSA signature schemes 'MUST use the SHA256 hash algorithm'. While, when an ecdsap256 key is used, ECDSA with P-256 is used with no hash algorithm.
I guess my question is, now that the signature input is larger than just the 32 byte EKM and the RSA algs are using SHA256, wouldn't it make sense and be more consistent to use the concatenation of those items directly as the input into the signature and, when an ecdsap256 key is used, calculate the signature with ECDSA using P-256 and SHA256? That'd mean that TBPROTO wouldn't directly use SHA256 but rather the hashing is pushed into the definition of how to do the signature for each key parameters type, which is arguably more cryptographically agile. It'd also be one less round of hashing for the RSA signature schemes.
Or am I off the rails here?

---

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

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

> Ø  And both RSA signature schemes 'MUST use the SHA256 hash algorithm'.
> While, when an ecdsap256 key is used, ECDSA with P-256 is used with no hash
> algorithm.
>
> PSS and PKCS padding schemes are defined with a lot of flexibility, so we
> have to specify the hash function to be used by these padding schemes.
>

ECDSA can be, and generally is, used with a hash algorithm though (of
similar strength).  Like in JOSE
<https://tools.ietf.org/html/rfc7518#section-3.4> or XML Signatures
<https://www.w3.org/TR/xmldsig-core1/#sec-ECDSA>, for example. From the
prospective of a a silly little Java programmer such as myself, I get a
signature instance from the platform using the names, "SHA256withECDSA",
"SHA384withECDSA", and "SHA512withECDSA" for the JOSE and "NONEwithECDSA"
for TokenBinding (interop tested with Chrome). My understanding is that
hash algorithm is used so that messages larger than the 'raw' signature
scheme would otherwise handle can be used. To be honest, I got confused
about the size ECDSA with P-256 could handle and was thinking that label +
version + type + key params + EKM without hashing would be too large. And
that ECDSA with P-256 with SHA256 would be needed, if the hashing of the
concatenation was removed, which is what I was really aiming for.

>
> Ø  The signature is now computed over the SHA256 hash of the
> concatenation of a few of things (label, version, type, key params, EKM).
>
> Correct, this is to prevent potential attacks that folks have pointed out.
>

Including the various different bits of information in what is singed is
what prevents such attacks, right? What is the hash for?

> This is independent of the signature algorithms and padding schemes that
> we negotiate via TB key parameters.
>
>
>
> Does this make sense?
>

Much of it does, yes. Thanks.

But I don't understand why the hash is applied to the concatenation of the
label, version, type, key params, & EKM rather than using the concatenation
directly as the signing input? Similar maybe to Bill's recent question
<https://mailarchive.ietf.org/arch/msg/unbearable/3Mw8U2jWc7m2ajyETa_tOB_bDQY>
but looking at it a little different I was trying to see if we could get
rid of that hashing step in the core protocol - that would give better
cryto agility to the core spec and have marginally better performance.

Cheers,
>
>
>
> Andrei
>
>
>
> *From:* Unbearable [mailto:[email-masked]] *On Behalf Of *Brian
> Campbell
> *Sent:* Tuesday, August 30, 2016 10:11 AM
> *To:* IETF Tokbind WG <[email-masked]>
> *Subject:* [Unbearable] Hashing & signatures in TBPROTO-9
>
>
>

---

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

Hashing before signing is generally useful, because it brings the data to an acceptable size for the signature algorithm, and also it may be cheaper to hash and then sign.

But this is all moot if we adopt Bill’s proposal and put the concatenated values in the EKM context.

From: Brian Campbell [mailto:[email-masked]]
Sent: Tuesday, August 30, 2016 3:02 PM
To: Andrei Popov <[email-masked]>
Cc: IETF Tokbind WG <[email-masked]>
Subject: Re: [Unbearable] Hashing & signatures in TBPROTO-9

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

>  And both RSA signature schemes 'MUST use the SHA256 hash algorithm'. While, when an ecdsap256 key is used, ECDSA with P-256 is used with no hash algorithm.

ECDSA can be, and generally is, used with a hash algorithm though (of similar strength).  Like in JOSE<https://tools.ietf.org/html/rfc7518#section-3.4> or XML Signatures<https://www.w3.org/TR/xmldsig-core1/#sec-ECDSA>, for example. From the prospective of a a silly little Java programmer such as myself, I get a signature instance from the platform using the names, "SHA256withECDSA", "SHA384withECDSA", and "SHA512withECDSA" for the JOSE and "NONEwithECDSA" for TokenBinding (interop tested with Chrome). My understanding is that hash algorithm is used so that messages larger than the 'raw' signature scheme would otherwise handle can be used. To be honest, I got confused about the size ECDSA with P-256 could handle and was thinking that label + version + type + key params + EKM without hashing would be too large. And that ECDSA with P-256 with SHA256 would be needed, if the hashing of the concatenation was removed, which is what I was really aiming for.

>  The signature is now computed over the SHA256 hash of the concatenation of a few of things (label, version, type, key params, EKM).

Including the various different bits of information in what is singed is what prevents such attacks, right? What is the hash for?

This is independent of the signature algorithms and padding schemes that we negotiate via TB key parameters.

Does this make sense?

But I don't understand why the hash is applied to the concatenation of the label, version, type, key params, & EKM rather than using the concatenation directly as the signing input? Similar maybe to Bill's recent question<https://mailarchive.ietf.org/arch/msg/unbearable/3Mw8U2jWc7m2ajyETa_tOB_bDQY> but looking at it a little different I was trying to see if we could get rid of that hashing step in the core protocol - that would give better cryto agility to the core spec and have marginally better performance.

Cheers,

Andrei

From: Unbearable [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brian Campbell
Sent: Tuesday, August 30, 2016 10:11 AM
To: IETF Tokbind WG <[email-masked]<mailto:[email-masked]>>
Subject: [Unbearable] Hashing & signatures in TBPROTO-9

---

From: Brian Campbell <[email-masked]>
Date: Wed, 31 Aug 2016 07:24:36 -0600

Which is why signature schemes are typically used with a hash function
(rather than the application of the signature doing the hashing and using a
'raw' signature). Also in this case the message size is fixed and not much
larger than the hash output.

But yes, it's moot if we adopt Bill’s proposal. Which I'm good with.

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

> Hashing before signing is generally useful, because it brings the data to
> an acceptable size for the signature algorithm, and also it may be cheaper
> to hash and then sign.
>
>
>
> *From:* Brian Campbell [mailto:[email-masked]]
> *Sent:* Tuesday, August 30, 2016 3:02 PM
> *To:* Andrei Popov <[email-masked]>
> *Cc:* IETF Tokbind WG <[email-masked]>
> *Subject:* Re: [Unbearable] Hashing & signatures in TBPROTO-9
>
>
>
>
>
>
>