LibTomNet [v0.01]

[Eric Rescorla]

Ian Grigg <iang at systemics.com> writes:

> Eric Rescorla wrote:
> 
> > My logic is that if you're going to create something new, it should
> > be better than what already exists.
> 
> Right.  But better is not a binary choice in real
> life.  SSL is only "better" if it exceeds all
> requirements when compared against a product
> that has only those requirements.
> 
> One needs to look at the requirements.  Tom's
> requirements didn't include message integrity,
> if I saw correctly, because he had something
> in there at a higher layer that covered him
> there.  That's good.
That's certainly not true. He had a message integrity
construct. It just didn't include anti-replay measures.

> Does he require replay protection?  Is he worried
> about MITM?  What about authenticity?  These all
> need to be established before you can compare any
> protocol.
>
> The whole world doesn't want or need perfect
> channel security.  That's because some parts of
> the world have different needs.
Actually, I think this attitude is generally unproductive.

All else being equal, a protocol which provides more security
is better than a protocol which provides less. Now, all things
aren't equal, but if you can offer substantially more security
with only a modest increase in code complexity, that's generally
a good thing. Where hard tradeoffs have to be made is when
the users are inconvenienced. A little additional programming
doesn't seem like a high cost at all.

I don't find this sort of "sure, it's nowhere near as secure as
secure as SSL, but it takes up a little less space" argument
very compelling at all.

-Ekr

-- 
[Eric Rescorla                                   ekr at rtfm.com]
                http://www.rtfm.com/

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com