Ian Grigg wrote:
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'll try to make this
Zooko, I don't think you actually need to worry about the At-Most-Once
semantics you example below. This sort of stuff has been around for
decades and there are a number of open source programs available. Don't
confuse what TLS does - transport messages securely end-to-end - to what
the end
At 02:19 PM 7/9/2003 -0400, Zooko wrote:
I'll try to make this concrete. My thesis is different than Ian's -- rather
than saying that those apps need less than what TLS offers, I say that they
need more! (So that each app need no longer implement the added features
itself.)
we did two kinds of
IanG and Zooko are making an end-to-end
argument: if one requires end-to-end replay (integrity/confidentiality)
protection, one does not necessarily benefit from the corresponding
point-to-point mechanisms that SSL provides.
IIRC SSL provides secure, point-to-point, ordered byte streams.
Systemics
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
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
tom st denis [EMAIL PROTECTED] writes:
--- Eric Rescorla [EMAIL PROTECTED] wrote:
This is all fine, but irrelevant to my point, which is that
if you're designing a channel security protocol it should
provide channel level integrity and anti-replay unless there's
some really good reason
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
