replay & integrity

[Jeroen C. van Gelderen]

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 at 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 at metzdowd.com