replay & integrity

Ian Grigg iang at
Wed Jul 9 13:09:55 EDT 2003

Eric Rescorla wrote:

> You keep harping on certs, but that's fundamentally not relevant to
> the point I was trying to make,


> which is whether or not one provides
> proper message integrity and anti-replay. As far as I'm concerned,
> there are almost no situations in which not providing those services
> is appropriate. That kind of infrastructure is already built into
> SSL and shouldn't be reinvented.

Welcome to the applications world!

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

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

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.

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.

It's simply the case that a serious financial
protocol would have to have its own replay &
integrity, because its threat model and failure
model is so much broader than SSL's.  For example,
a serious payments scenario works across end-to-
end, and assumes that nodes on both end-points
can be compromised and/or faulty.  And, it's not
only just faults, many higher layers actively
replay as part of the protocol.

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.

(As a sort of oxymoron, a payments or similar
protocol that didn't have its own replay & integrity
would not work.  Ideally, a good test of a payments
protocol is to see if it would work over unprotected
UDP or email.  Some do and some don't.)


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at

More information about the cryptography mailing list