[13818] in cryptography@c2.net mail archive
Re: replay & integrity
daemon@ATHENA.MIT.EDU (Jeroen C. van Gelderen)
Thu Jul 10 15:37:05 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Thu, 10 Jul 2003 14:43:41 -0400
Cc: "'iang@systemics.com'" <iang@systemics.com>, EKR <ekr@rtfm.com>,
tom st denis <tomstdenis@yahoo.com>, cryptography@metzdowd.com
To: "Whyte, William" <WWhyte@ntru.com>
From: "Jeroen C. van Gelderen" <jeroen@vangelderen.org>
In-Reply-To: <30F37C4533D8564FB1D58BFDAF6687C1EA70E2@ohthree.jjj-i.com>
On Wednesday, Jul 9, 2003, at 13:31 US/Eastern, Whyte, William wrote:
>> I wouldn't say that this is a good reason to take
>> these features out of SSL. But assuming they are
>> "needed" is a cautious assumption, and assuming
>> that SSL meets the needs for replay & integrity
>> makes even less sense when we are dealing with a
>> serious top-to-bottom security model.
>
> [ ... ]
>
>> SSL just doesn't address the security needs of
>> protocols as well as all that. Where I've seen
>> it used, the core need for it is privacy of the
>> data stream, not anything else.
>
> Maybe so, but if you don't have integrity checking,
> so that an attacker can inject packets into the stream,
> this can often compromise privacy too. For example,
> consider Serge Vaudenay's CBC padding attack.
This would be a side-channel problem in the protocol which needs to be
fixed, not obfuscated by an integrity mechanism. Worse, the integrity
protection didn't even work in TLS 1.0: "TLS v1.0 also provides an
optional MAC which failed to thwart the attack..." [Vau02a].
[Vau02a]
http://lasecwww.epfl.ch/php_code/publications/search.php?ref=Vau02a
-J
--
Jeroen C. van Gelderen - jeroen@vangelderen.org
"Be precise in the use of words and expect precision from others"
-- Pierre Abelard
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
