[147068] in cryptography@c2.net mail archive
Re: [Cryptography] Killing two IV related birds with one stone
daemon@ATHENA.MIT.EDU (Yaron Sheffer)
Thu Sep 12 10:54:10 2013
X-Original-To: cryptography@metzdowd.com
Date: Thu, 12 Sep 2013 17:41:56 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
To: "Perry E. Metzger" <perry@piermont.com>
In-Reply-To: <20130911201530.3e7ecef3@jabberwock.cb.piermont.com>
Cc: Jerry Leichter <leichter@lrw.com>, cryptography@metzdowd.com
Errors-To: cryptography-bounces+crypto.discuss=bloom-picayune.mit.edu@metzdowd.com
On 09/12/2013 03:15 AM, Perry E. Metzger wrote:
> On Wed, 11 Sep 2013 20:01:28 -0400 Jerry Leichter <leichter@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.
These are living protocols, and extensions create an infinite amount of
redundancy. 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.
Thanks,
Yaron
_______________________________________________
The cryptography mailing list
cryptography@metzdowd.com
http://www.metzdowd.com/mailman/listinfo/cryptography
