Watson Ladd <watsonbl...@gmail.com> writes: >Then use a padding extension that solves all problems, instead of relying on >a side effect of CBC mode.
It's not a "side-effect of CBC mode", CBC mode allows padding packets, GCM doesn't, see Colm MacCárthaigh's recent post on the topic. >Why do we want this to look different from TLS, instead of a subset of widely >deployed things ala UTA? CBC mode ciphers have been part of TLS since SSL 2.0 (AFAIK) in 1994, I don't know if SSL2 allowed for packet padding but 3.0 certainly did, so it's hardly a major change. >What is your master secret change solving? Preventing manipulation of DH/ECDH parameters. >Your draft claims that verifying signatures before sending will address an >ECC security threat. I don't see what threat that addresses The fact that ECC algorithms are extremely vulnerable to fault attacks, and a single faulty signature can leak the private key, at which point its game over. I don't really know how to say the following without it sounding like an ad hominem attack, but how much do you really know about real-world deployment issues for this stuff? You seem to be arguing for all sorts of personal preferences based on, I dunno, abstract theorising, but you appear to be totally unaware of actual real-world issues. What I'm trying to figure out is, how seriously am I supposed to take your comments? Do you actually have any real-world deployment experience with using this stuff in the field? Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
