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

[Eric Rescorla <[e-mail]>]

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

> 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."
>

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

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.
>

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.



> 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."
>

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


It would help the reader to add that “Example” is represented in hexa
by 4578616d706c650
> with the end of string character.
>
>
>
>
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>