Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?)

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

To sum up, are we in agreement that the concatenation will only include:

-          TokenBindingType value contained in the
      TokenBinding.tokenbinding_type field;

-          TokenBindingKeyParameters value contained in the
      TokenBindingID.key_parameters field;

-          Exported keying material (EKM) value obtained from the current TLS
      connection.
… because the label and the ProtocolVersion are presumably already in the EKM?

From: Bill Cox [mailto:[email-masked]]
Sent: Wednesday, August 31, 2016 2:01 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 1:10 PM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:

On Wed, Aug 31, 2016 at 1:35 PM, Bill Cox <[email-masked]<mailto:[email-masked]>> wrote:
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?

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.

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.

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?

I think that's already (or will be) covered with the registration request for "EXPORTER-Token-Binding" in https://tools.ietf.org/html/draft-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.

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.

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?

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

---

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

Works for me.

On Wed, Aug 31, 2016 at 2:20 PM, Andrei Popov <[email-masked]>
wrote:

> *From:* Bill Cox [mailto:[email-masked]]
> *Sent:* Wednesday, August 31, 2016 2:01 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 1:10 PM, Brian Campbell <
> [email-masked]> wrote:
>
>
>
> 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:
>
> 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?
>
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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?
>
>
>
> I think that's already (or will be) covered with the registration request
> for "EXPORTER-Token-Binding" in https://tools.ietf.org/html/
> draft-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.
>
>
>
> 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.
>
>
> 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: Brian Campbell <[email-masked]>
Date: Wed, 31 Aug 2016 15:42:03 -0600

Works for me too (I think).

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

>> for "EXPORTER-Token-Binding" in https://tools.ietf.org/html/dr
>> aft-ietf-tokbind-protocol-09#section-6.4
>>
>>
>>

---

From: Andrei Popov <[email-masked]>
Date: Wed, 31 Aug 2016 21:47:39 +0000

Great.

Then we have 34 bytes we hash with SHA256 and sign.

When we sign with RSA-PSS or RSA-PKCS, we also specify the use of SHA256 in the padding algorithm. For ECDSA, there is no need to pad, and therefore no need (or opportunity) to use padding hash.

Brian, what specifically would you like to change WRT hashing?

From: Brian Campbell [mailto:[email-masked]]
Sent: Wednesday, August 31, 2016 2:42 PM
To: Bill Cox <[email-masked]>
Cc: Andrei Popov <[email-masked]>; Tokbind WG <[email-masked]>; Leif Johansson <[email-masked]>
Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?)

On Wed, Aug 31, 2016 at 3:34 PM, Bill Cox <[email-masked]<mailto:[email-masked]>> wrote:
Works for me.

On Wed, Aug 31, 2016 at 2:20 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:
To sum up, are we in agreement that the concatenation will only include:

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

Bill

---

From: Mike Jones <[email-masked]>
Date: Wed, 31 Aug 2016 22:24:03 +0000

Are all the fields we’re concatenating fixed length?  I ask because a standard kind of attack against crypto systems using concatenation is to make it appear that data from one field belongs in another one by using different field lengths.  If they aren’t fixed length, including field length counts or field delimiters in the concatenation is a standard solution to the problem.

                                                       -- Mike

From: Unbearable [mailto:[email-masked]] On Behalf Of Andrei Popov
Sent: Wednesday, August 31, 2016 2:21 PM
To: Bill Cox <[email-masked]>; Brian Campbell <[email-masked]>
Cc: Tokbind WG <[email-masked]>; Leif Johansson <[email-masked]>
Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?)

Bill

---

From: Andrei Popov <[email-masked]>
Date: Wed, 31 Aug 2016 22:24:50 +0000

They are all fixed length.

From: Mike Jones
Sent: Wednesday, August 31, 2016 3:24 PM
To: Andrei Popov <[email-masked]>; Bill Cox <[email-masked]>; Brian Campbell <[email-masked]>
Cc: Tokbind WG <[email-masked]>; Leif Johansson <[email-masked]>
Subject: RE: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?)

                                                       -- Mike

From: Unbearable [mailto:[email-masked]] On Behalf Of Andrei Popov
Sent: Wednesday, August 31, 2016 2:21 PM
To: Bill Cox <[email-masked]<mailto:[email-masked]>>; Brian Campbell <[email-masked]<mailto:[email-masked]>>
Cc: Tokbind WG <[email-masked]<mailto:[email-masked]>>; Leif Johansson <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?)

Bill

---

From: Brian Campbell <[email-masked]>
Date: Wed, 31 Aug 2016 16:48:01 -0600

My suggestion is to use those 34 bytes directly as the input into the
signature generation/verification. And for ecdsap256 key params, to use
ECDSA using P-256 and SHA-256 as the signature algorithm. Although the
latter is not strictly necessary AFAICT because 'raw' ECDSA using P-256 can
sign 34 bytes okay.

Admittedly, I could be off base here but that's more what I would have
expected to see. We seem to be talking past one another, however, in just
trying to discuss it.

On Wed, Aug 31, 2016 at 3:47 PM, Andrei Popov <[email-masked]>
wrote:

> When we sign with RSA-PSS or RSA-PKCS, we also specify the use of SHA256
> in the padding algorithm. For ECDSA, there is no need to pad, and therefore
> no need (or opportunity) to use padding hash.
>
>
>
> *From:* Brian Campbell [mailto:[email-masked]]
> *Sent:* Wednesday, August 31, 2016 2:42 PM
> *To:* Bill Cox <[email-masked]>
> *Subject:* Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519
> support?)
>
>
>
> _______________________________________________
> Unbearable mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/unbearable
>
>

---

From: Nick Harper <[email-masked]>
Date: Wed, 31 Aug 2016 15:54:33 -0700

My understanding is that P-256 can only sign a 32-byte message (hence why
it makes sense to hash the message with sha-256 first).

I agree with Brian that the hash function (if any) should be part of the
key param, similar to the SignatureScheme combination in TLS 1.3.

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

>> *Subject:* Re: [Unbearable] What Gets Signed (was: Dumb idea: add
>> Ed25519 support?)
>>
>>
>>

---

From: Andrei Popov <[email-masked]>
Date: Wed, 31 Aug 2016 23:02:00 +0000

How about we say something like this:
“When an rsa2048_pkcs1.5, rsa2048_pss or ecdsap256 key is used, the signature is computed over the SHA256 hash of the byte string representing the concatenation of…”?

A new TB key parameters ID specification could describe a different construct.

From: Nick Harper [mailto:[email-masked]]
Sent: Wednesday, August 31, 2016 3:55 PM
To: Brian Campbell <[email-masked]>
Cc: Andrei Popov <[email-masked]>; Tokbind WG <[email-masked]>; Leif Johansson <[email-masked]>; Bill Cox <[email-masked]>
Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?)

My understanding is that P-256 can only sign a 32-byte message (hence why it makes sense to hash the message with sha-256 first).

I agree with Brian that the hash function (if any) should be part of the key param, similar to the SignatureScheme combination in TLS 1.3.

On Wed, Aug 31, 2016 at 3:48 PM, Brian Campbell <[email-masked]<mailto:[email-masked]>> wrote:
My suggestion is to use those 34 bytes directly as the input into the signature generation/verification. And for ecdsap256 key params, to use ECDSA using P-256 and SHA-256 as the signature algorithm. Although the latter is not strictly necessary AFAICT because 'raw' ECDSA using P-256 can sign 34 bytes okay.

Admittedly, I could be off base here but that's more what I would have expected to see. We seem to be talking past one another, however, in just trying to discuss it.

On Wed, Aug 31, 2016 at 3:47 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:
Great.

From: Brian Campbell [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, August 31, 2016 2:42 PM
To: Bill Cox <[email-masked]<mailto:[email-masked]>>
Cc: Andrei Popov <[email-masked]<mailto:[email-masked]>>; Tokbind WG <[email-masked]<mailto:[email-masked]>>; Leif Johansson <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?)

Bill

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

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

---

From: Mike Jones <[email-masked]>
Date: Wed, 31 Aug 2016 23:10:35 +0000

I know I’m getting into this discussion late, but I don’t understand what the SHA-256 hash over the concatenation is for.  It seems like an unnecessary step to me, given that all the signature algorithms being discussed can all sign arbitrary length byte sequences.

Those algorithms, I believe are (using RFC 7518 algorithm descriptions):

·       RSASSA-PKCS1-v1_5 using SHA-256

·       RSASSA-PSS using SHA-256 and MGF1 with SHA-256

·       ECDSA using P-256 and SHA-256

                                                       -- Mike

From: Unbearable [mailto:[email-masked]] On Behalf Of Andrei Popov
Sent: Wednesday, August 31, 2016 4:02 PM
To: Nick Harper <[email-masked]>; Brian Campbell <[email-masked]>
Cc: Tokbind WG <[email-masked]>; Leif Johansson <[email-masked]>; Bill Cox <[email-masked]>
Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?)

Cc: Andrei Popov <[email-masked]<mailto:[email-masked]>>; Tokbind WG <[email-masked]<mailto:[email-masked]>>; Leif Johansson <[email-masked]<mailto:[email-masked]>>; Bill Cox <[email-masked]<mailto:[email-masked]>>

Bill

---

From: Nick Harper <[email-masked]>
Date: Wed, 31 Aug 2016 16:25:44 -0700

I think it depends on how you define the algorithms. If you do it as Mike
lists, then an algorithm takes an arbitrary-length byte sequence (the same
holds true if they're defined like the SignatureSchemes in TLS 1.3). Right
now, I believe Token Binding defines signature algorithms as not containing
a hash algorithm, since before we started concatenating things to the EKM
value, the message to be signed was short enough that it didn't need any
hashing. I think we should go back to the signature algorithm including a
hash algorithm (if relevant - an EdDSA algorithm doesn't need a hash
function).

On Wed, Aug 31, 2016 at 4:10 PM, Mike Jones <[email-masked]>
wrote:

> I know I’m getting into this discussion late, but I don’t understand what
> the SHA-256 hash over the concatenation is for.  It seems like an
> unnecessary step to me, given that all the signature algorithms being
> discussed can all sign arbitrary length byte sequences.
>
>
>
> *From:* Unbearable [mailto:[email-masked]] *On Behalf Of *Andrei
> Popov
> *Sent:* Wednesday, August 31, 2016 4:02 PM
> *To:* Nick Harper <[email-masked]>; Brian Campbell <
> [email-masked]>
> *Cc:* Tokbind WG <[email-masked]>; Leif Johansson <[email-masked]>;
> Bill Cox <[email-masked]>
>
> “When an rsa2048_pkcs1.5, rsa2048_pss or ecdsap256 key is used, the
> signature is computed over the SHA256 hash of the byte string representing
> the concatenation of…”?
>
>
>
> *From:* Nick Harper [mailto:[email-masked] <[email-masked]>]
> *Sent:* Wednesday, August 31, 2016 3:55 PM
> [email-masked]>; Leif Johansson <[email-masked]>; Bill Cox <
> [email-masked]>
> On Wed, Aug 31, 2016 at 3:48 PM, Brian Campbell <

---

From: Andrei Popov <[email-masked]>
Date: Wed, 31 Aug 2016 23:37:36 +0000

Ø  I think it depends on how you define the algorithms.
Correct, if one includes the hash operation in the definition of a signing operation, then one can sign arbitrary-length byte strings☺.

Ø  I think we should go back to the signature algorithm including a hash algorithm (if relevant - an EdDSA algorithm doesn't need a hash function).
Here’s my attempt at doing this: “When an rsa2048_pkcs1.5, rsa2048_pss or ecdsap256 key is used, the signature is computed over the SHA256 hash of the byte string representing the concatenation of…”.
From: Nick Harper [mailto:[email-masked]]
Sent: Wednesday, August 31, 2016 4:26 PM
To: Mike Jones <[email-masked]>
Cc: Andrei Popov <[email-masked]>; Brian Campbell <[email-masked]>; Tokbind WG <[email-masked]>; Leif Johansson <[email-masked]>; Bill Cox <[email-masked]>
Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?)

I think it depends on how you define the algorithms. If you do it as Mike lists, then an algorithm takes an arbitrary-length byte sequence (the same holds true if they're defined like the SignatureSchemes in TLS 1.3). Right now, I believe Token Binding defines signature algorithms as not containing a hash algorithm, since before we started concatenating things to the EKM value, the message to be signed was short enough that it didn't need any hashing. I think we should go back to the signature algorithm including a hash algorithm (if relevant - an EdDSA algorithm doesn't need a hash function).

On Wed, Aug 31, 2016 at 4:10 PM, Mike Jones <[email-masked]<mailto:[email-masked]>> wrote:
I know I’m getting into this discussion late, but I don’t understand what the SHA-256 hash over the concatenation is for.  It seems like an unnecessary step to me, given that all the signature algorithms being discussed can all sign arbitrary length byte sequences.

•       RSASSA-PKCS1-v1_5 using SHA-256

•       RSASSA-PSS using SHA-256 and MGF1 with SHA-256

•       ECDSA using P-256 and SHA-256

                                                       -- Mike

From: Unbearable [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Andrei Popov
Sent: Wednesday, August 31, 2016 4:02 PM
To: Nick Harper <[email-masked]<mailto:[email-masked]>>; Brian Campbell <[email-masked]<mailto:[email-masked]>>
Cc: Tokbind WG <[email-masked]<mailto:[email-masked]>>; Leif Johansson <[email-masked]<mailto:[email-masked]>>; Bill Cox <[email-masked]<mailto:[email-masked]>>

Bill

---

From: Nick Harper <[email-masked]>
Date: Wed, 31 Aug 2016 16:54:11 -0700

On Wed, Aug 31, 2016 at 4:37 PM, Andrei Popov <[email-masked]>
wrote:

> Ø  I think we should go back to the signature algorithm including a hash
> algorithm (if relevant - an EdDSA algorithm doesn't need a hash function).
>
> Here’s my attempt at doing this: “When an rsa2048_pkcs1.5, rsa2048_pss or
> ecdsap256 key is used, the signature is computed over the SHA256 hash of
> the byte string representing the concatenation of…”.
>

I think this wording should be split up, so something defines "the message
to be signed is the concatenation of ...", and then the existing signature
algorithms can specify to hash with sha256 that message (it could be one
statement, like "When an rsa2048_pkcs1.5, rsa2048_pss, or ecdsap256 key is
used, the signature is computed over the SHA256 hash of the message to be
signed", or split into multiple statements, like how we describe rsa and
p256 separately).

---

From: Andrei Popov <[email-masked]>
Date: Wed, 31 Aug 2016 23:58:44 +0000

Sure, this sounds good to me.

From: Nick Harper [mailto:[email-masked]]
Sent: Wednesday, August 31, 2016 4:54 PM
To: Andrei Popov <[email-masked]>
Cc: Mike Jones <[email-masked]>; Brian Campbell <[email-masked]>; Tokbind WG <[email-masked]>; Leif Johansson <[email-masked]>; Bill Cox <[email-masked]>
Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?)

On Wed, Aug 31, 2016 at 4:37 PM, Andrei Popov <[email-masked]<mailto:[email-masked]>> wrote:

>  I think we should go back to the signature algorithm including a hash algorithm (if relevant - an EdDSA algorithm doesn't need a hash function).

I think this wording should be split up, so something defines "the message to be signed is the concatenation of ...", and then the existing signature algorithms can specify to hash with sha256 that message (it could be one statement, like "When an rsa2048_pkcs1.5, rsa2048_pss, or ecdsap256 key is used, the signature is computed over the SHA256 hash of the message to be signed", or split into multiple statements, like how we describe rsa and p256 separately).

---

From: Brian Campbell <[email-masked]>
Date: Wed, 31 Aug 2016 18:16:53 -0600

I'll propose some specific text, if that's okay. Tomorrow though. I'm on
family duty for the rest of the evening.

On Aug 31, 2016 5:58 PM, "Andrei Popov" <[email-masked]> wrote:

> *From:* Nick Harper [mailto:[email-masked]]
> *Sent:* Wednesday, August 31, 2016 4:54 PM
> *To:* Andrei Popov <[email-masked]>
> *Cc:* Mike Jones <[email-masked]>; Brian Campbell <
> [email-masked]>; Tokbind WG <[email-masked]>; Leif
> Johansson <[email-masked]>; Bill Cox <[email-masked]>

---

From: Andrei Popov <[email-masked]>
Date: Thu, 1 Sep 2016 00:18:38 +0000

Please propose the text, it will help a lot.

From: Brian Campbell [mailto:[email-masked]]
Sent: Wednesday, August 31, 2016 5:17 PM
To: Andrei Popov <[email-masked]>
Cc: Mike Jones <[email-masked]>; Bill Cox <[email-masked]>; Nick Harper <[email-masked]>; Leif Johansson <[email-masked]>; Tokbind WG <[email-masked]>
Subject: RE: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?)

I'll propose some specific text, if that's okay. Tomorrow though. I'm on family duty for the rest of the evening.

On Aug 31, 2016 5:58 PM, "Andrei Popov" <[email-masked]<mailto:[email-masked]>> wrote:
Sure, this sounds good to me.

From: Nick Harper [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, August 31, 2016 4:54 PM
To: Andrei Popov <[email-masked]<mailto:[email-masked]>>
Cc: Mike Jones <[email-masked]<mailto:[email-masked]>>; Brian Campbell <[email-masked]<mailto:[email-masked]>>; Tokbind WG <[email-masked]<mailto:[email-masked]>>; Leif Johansson <[email-masked]<mailto:[email-masked]>>; Bill Cox <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Unbearable] What Gets Signed (was: Dumb idea: add Ed25519 support?)