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 _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
