On Fri, Mar 18, 2016 at 4:31 PM, Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote: > 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.
GnuTLS is the only implementation that pads to more than 16 byte boundaries > >>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. It's not the CBC modes that's the change, but the EtM extension. > >>What is your master secret change solving? > > Preventing manipulation of DH/ECDH parameters. It's not immediately clear that it does so correctly. All data that affects the interpretation must be in the master secret, and I think that includes some data you haven't yet hashed. EMS we know gets this right. > >>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. The same fault attack commonly works on embedded implementations for ECDH. Except here the attacker just sends a point off the curve, instead of inducing a fault in the signature routine. RSA signatures with CRT optimization (commonly used on embedded devices) is also vulnerable to similar fault attacks. I'm really not sure why you're ignoring wrong-curve attacks on cached ephemerals: just add a recommendation to not cache ephemerals. > > 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? Given that I'm proposing subsetting what existing implementations already do, instead of implementing new extensions, I find it remarkable you're arguing that my proposal is harder to deploy. As for what I know, I'm listed in the release notes of several TLS implementations. > > Peter. -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
