Subject: [tcpinc] CertificateVerify

From: Kyle Rose <[email-masked]>
Date: Thu, 5 Nov 2015 10:54:23 +0900

I didn't want to waste time in a huge argument over this point
yesterday, so I figured I'd save it for the list. Heh.

The contention that HTTPS is the only protocol that generates enough
load for unnecessary RSA signings to be problematic isn't really true:
even with Let's Encrypt (which, BTW, thank you), it is likely that
there will be a substantive amount of HTTP traffic for years. I would
hope that we'd want to use TCPINC to protect those flows against
passive surveillance: to me, legacy HTTP is the killer app for OE.

For a company at Akamai's scale, the COGS impact of an extra RSA
signing for every session is substantial; and for that signature to be
unnecessary is like adding insult to injury. Even if we use ECDSA,
which has ¼ of the impact of security-equivalent RSA on servers,
capacity is still reduced by an amount easily impacting the bottom
line.

I would have no qualms if this added security, but that isn't the
case. If it has to be there for reasons inherent to the protocol
(still unclear to me), how about making it a token 128-bit modulus so
at least the impact is minimized?

Kyle