[Cryptography] Killing two IV related birds with one stone

Perry E. Metzger perry at piermont.com
Thu Sep 12 11:25:04 EDT 2013


On Thu, 12 Sep 2013 17:41:56 +0300 Yaron Sheffer
<yaronf.ietf at 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
> > <leichter at 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		perry at piermont.com


More information about the cryptography mailing list