[13816] in cryptography@c2.net mail archive
Re: replay & integrity
daemon@ATHENA.MIT.EDU (Jeroen C. van Gelderen)
Thu Jul 10 15:35:37 2003
X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Thu, 10 Jul 2003 14:52:17 -0400
Cc: iang@systemics.com, "EKR" <ekr@rtfm.com>,
"tom st denis" <tomstdenis@yahoo.com>, cryptography@metzdowd.com
To: "Zooko" <zooko@zooko.com>
From: "Jeroen C. van Gelderen" <jeroen@vangelderen.org>
In-Reply-To: <E19aJXk-0007bw-00@localhost>
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 without its own unique Ids.
>
> 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.)
[...]
From what I can see, both 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' SOX tries to provide secure, end-to-end, (partially)
offline, non-repudiable, unordered, at-most-once transactions.
(Roughly.)
There is no benefit in using SSL underneath SOX: if SOX is insecure,
using SSL won't help (except perhaps of obfuscate the problems) and if
SOX is indeed secure, it provides all the security functionality that
is required.
There are plenty other situations in which use of SSL is
counterproductive or impossible. Various group communication and
replication algorithms (BFT) come to mind, as well as various UDP-based
applications.
Reinventing SSL is not such a good idea (although -having studied the
SSL spec a few years ago- I can see why the SSH designers went that
route). Blindly assuming everyone can or should use SSL is an equally
bad idea.
> [Disclaimer: My understanding of SSL/TLS is incomplete. Eric
> Rescorla's book
> is on my amazon wishlist. Please be polite when correcting my errors,
> and
> I'll do the same for you.]
That is fine, my understanding isn't perfect either. You should not
need a book to be able to use or discuss an open protocol like SSL/TLS.
As Eric Rescorla said: "What makes developer's lives simple is simple
APIs".
[good stuff elided]
> P.S. I am aware that TLS encompasses the notion of stored or cached
> sessions,
> originally conceived for performance reasons. Perhaps a higher-level
> abstraction could be built by requiring each party to use that
> facility in a
> specific way...
It might get you from per-session protection to across-all-session
protection. But it can never protect against injecting two messages
with identical meaning (replay) into the SSL layer twice.
-J
--
Jeroen C. van Gelderen - jeroen@vangelderen.org
War prosperity is like the prosperity that an earthquake or a plague
brings. The earthquake means good business for construction workers,
and cholera improves the business of physicians, pharmacists, and
undertakers; but no one has for that reason yet sought to celebrate
earthquakes and cholera as stimulators of the productive forces in
the general interest. -- Ludwig von Mises
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo@metzdowd.com
