On Fri, May 27, 2016 at 1:17 PM, Daniel Migault <[email protected] > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
