Thanks a lot for your responses, they addressed my concerns. BR, Daniel On Fri, May 27, 2016 at 5:58 PM, Eric Rescorla <e...@rtfm.com> wrote:
> > > On Fri, May 27, 2016 at 1:17 PM, Daniel Migault < > daniel.miga...@ericsson.com> 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 >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
