replay & integrity

[Jeroen C. van Gelderen]

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 at 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 at metzdowd.com