replay & integrity

[Anton Stiglic]

> Integrity:  Financial protocols that use crypto
> (as opposed to ones abused by crypto) generally
> include signed messages.  The signature provides
> for its own integrity, as well as a few other
> things.

I don't believe that is enough.  Take for example
the SSL 2.0 ciphersuite rollback vulnerability or the 
SSL 3.0 key-exchange algorithm vulnerability . Any kind
of rollback attack is serious, and won't be protected
by signatures in the bulk data (and those signature might
be weakened by forcing a rollback to a possible weaker
version/implementation).

> 
> Replay:  One of the commonest problems in HTTPS
> sites is replay failure.  The solution is well
> known out in the real world - you have to have
> replay prevention at the higher layers.
> 
> (Credit card processors have replay prevention
> too!)
> 
> So, some protocols don't need replay prevention
> from lower layers because they have sufficient
> checks built in.  This would apply to any protocols
> that have financial significance;  in general, no
> protocol should be without its own unique Ids.

So maybe I can't replay a complete financial transaction, 
because at some high layer there is replay prevention,
what about replaying some init protocol request?
Is that not annoying?  Would a bank not care that 
their ATMs are not working for a day because someone
is executing a DoS attack on the lower layers of the 
protocols of their system? I think not, you need replay 
protection on both levels. 

How can a secure socket be dubbed secure if it doesn't
protect against these basic attacks?

To quote from Wagner and Schneier`s paper, Analysis
of the SSL 3.0 protocol:

"Replay attacks are a legitimate concern, and as they are
so easy to protect against, it would be irresponsible to fail
to address these threats."

--Anton

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com