On Thu, 12 Sep 2013 17:41:56 +0300 Yaron Sheffer <yaronf.i...@gmail.com> wrote: > On 09/12/2013 03:15 AM, Perry E. Metzger wrote: > > On Wed, 11 Sep 2013 20:01:28 -0400 Jerry Leichter > > <leich...@lrw.com> wrote: > >>> ...Note that if you still transmit the IVs, a misimplemented > >>> client could still interoperate with a malicious counterparty > >>> that did not use the enforced method for IV calculation. If you > >>> don't transmit the IVs at all but calculate them, the system > >>> will not interoperate if the implicit IVs aren't calculated the > >>> same way by both sides, thus ensuring that the covert channel is > >>> closed. > > IMO going through hoops to try to avoid covert channels is not > worth our time. Both IPsec and TLS have a huge capacity for covert > channels at the handshake (or key exchange) level, certainly enough > to leak the *previous* session state. So plugging the per-record > (per packet) holes is not interesting.
I think that's being overly pessimistic. Again, plugging most holes means that you get to examine less of the implementation (including hardware) to gain assurance. Further, there are protocols and uses for these algorithms in the world other than IPsec and TLS. > These are living protocols, and extensions create an infinite > amount of redundancy. "Infinite" is a big number. I'd say, again, that if you can lower the number of side channels down to a couple, it helps someone having to do the auditing later. Just because it is hard to eliminate everything a priori is no reason to throw up your hands and make a protocol less verifiable to someone who has to walk through the implementation carefully later on. > If you try to eliminate covert channels you need to freeze the > protocol and engineer it specifically for that purpose. This may be > right for a project like Tor, but not for a general purpose > protocol. We no longer have the luxury of saying "this protocol isn't important enough to secure well", especially for TLS and IPsec. If the last few weeks have taught us anything, it is that we have not been exercising enough care in doing our work here, and as security engineers I think we have a duty to be better than that. Indeed, especially in the face of the knowledge that we have saboteurs working in protocol standardization who would discourage us from taking enough care, we need to be far more careful. -- Perry E. Metzger pe...@piermont.com _______________________________________________ The cryptography mailing list cryptography@metzdowd.com http://www.metzdowd.com/mailman/listinfo/cryptography