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

[Daniel Migault <[e-mail]>]

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.