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 ar
On Wednesday, Jul 9, 2003, at 14:19 US/Eastern, Zooko wrote:
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 with
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 re
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 poi
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 c
> 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 vulner
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 go
> 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.
[ .
Ian Grigg <[EMAIL PROTECTED]> writes:
> Eric Rescorla wrote:
> > 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 a
