Subject: [TLS] draft-tls-tls13 - comments on section 4.8.1 Digital Signature

From: Daniel Migault <[email-masked]>
Date: Fri, 27 May 2016 16:17:57 -0400

Hi,

I have a few comments while reading 4.8.1 Digital Signature of
draft-tls-tls13.Hope it helps.

BR,
Daniel

Comment a)
"In previous versions of TLS, the ServerKeyExchange format meant that
attackers can obtain a signature of a message with a chosen, 32-byte prefix.
"

My understanding is that the ServeKeyExchange format defines the bits
exchanged between the TLS Client and the TLS Server. I think the attack
vector is more coming from how the signatures are computed. I would rather
propose something like:

"In previous version of TLS, the signature of the ECDH or EDH public key is
performed by concatenating the client random, the server random to the
public keys. The concatenation is hash and then signed. As the client
random is chosen by the TLS CLient, such design allows an attacker to
obtain a signature of a message with a chosen 32-byte prefix."

Comment b)

"Because TLS 1.3 servers are likely to also implement prior versions, the
contents of the element always start with 64 bytes of octet 32 in order to
clear that chosen-prefix.

I think some additional steps need to be explicitly specified. I am not
completely sure of what is being signed.
    a) padding + context + H(client.random + server + random + ECDHE/DHE
Params)
OR
    b) padding + context + client.random + server + random + ECDHE/DHE
Params
OR
    c) padding + context + ECDHE/DHE Params
OR
   d) something else

I assume that is a) in which case, the reason for choosing this format is
to constraint changes between TLS versions at the signing module. In
addition, if the correct scheme is a) maybe some additional text or
reference could explain why the padding and context solves this problem. By
prepending a fixed padding and some context, to the output of the hash
function, the TLS Client does not control the input that is signed as
cryptographic hash function are expected to be non-invertible.

Comment c)

"A single 0 byte is appended to the context to act as a separator."

When describing how the input to be signed is built, it may be clearer to
emphasize that string ends with 0, whihc leads to a "00" separator. I would
propose to add something like: "As the string ends with a "0" byte, the
binary representation will results in two zero bytes."

Comment d)

It would help the reader to add that “Example” is represented in hexa
by 4578616d706c650
with the end of string character.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 May 2016 14:58:19 -0700

On Fri, May 27, 2016 at 1:17 PM, Daniel Migault <[email-masked]
> wrote:

> "In previous version of TLS, the signature of the ECDH or EDH public key
> is performed by concatenating the client random, the server random to the

Hmm... I'm not sure this makes it much clearer. How about "The computation
of the signature in the ServerKeyExchange...."

Comment b)
> cryptographic hash function are expected to be non-invertible.

None of these. The specific structs are indicated with digitally-signed,
but generally the thing being signed is the concatenation of the handshake
hashes and the hash of the resumption ctx.

> binary representation will results in two zero bytes."

It's just one zero. TLS strings don't have trailing zeros. The 00 is 0x00.

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

---

From: Daniel Migault <[email-masked]>
Date: Mon, 30 May 2016 09:14:06 -0400

Thanks a lot for your responses, they addressed my concerns.
BR,
Daniel

On Fri, May 27, 2016 at 5:58 PM, Eric Rescorla <[email-masked]> wrote:

>
>
> On Fri, May 27, 2016 at 1:17 PM, Daniel Migault <
> [email-masked]> wrote:
>
>> Hi,
>>
> It would help the reader to add that “Example” is represented in hexa by 4578616d706c650