New algorithms and protocols, etc. (was Re: replay & integrity)

[Perry E. Metzger]

Ian Grigg <iang at systemics.com> 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 already built into
> > SSL and shouldn't be reinvented.
> 
> Welcome to the applications world!
> 
> Integrity:  Financial protocols that use crypto
[more examples of protocols that have their own replay, integrity,
etc. protection elided.]

> 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 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

This is the security world. We survive because of making cautious
assumptions. Adding anti-replay and integrity to your protocol is
cheap, and once you've done it and analyzed it well, you have a solid
component on which to build. Rolling your own non-protected protocol
that has not been analyzed because you think that you don't need the
feature buys you essentially nothing at all and endangers you.

There is nothing wrong with several layers in your communication
system all doing similar kinds of protection. It is fine that you're
sending S/MIME signed and encrypted messages over TLSified SMTP.  The
cost is merely speed, and since hardware is used for most of the
instances where speed is a problem, it isn't an issue at all for the
most part. Besides, you often find you've gained something by
providing the redundant protections.

The truth is that people don't propose new algorithms and protocols
because there is a great unmet need they are trying to fill or because
a tiny bit of speed is lost through redundant safety measures. If they
aren't snake oil peddlers (a large category, sadly) they propose them
because they haven't read the literature and/or they enjoy
tinkering.

Now, tinkering is a fine and wonderful thing, and I'm a big advocate
of tinkering. It is fun building things, and the pleasure of doing so
is its own reward. It is also very educational. Just because you like
building your own cars from scratch, though, doesn't mean that they're
safe for the general public to drive, or that they'd be in any way
cheaper or better than cars built by professionals. Likely what you
build will be a clunker and have no advantages, and be unsafe
besides. Even if you had some slight advantages, the mere fact that
your parts are non-standard will make it impossible for others to
analyze or maintain your car design. The same is true in cryptography
and security.

Of course, this makes the world kind of boring and unpleasant for
tinkerers who want to go pro. The most obvious cryptographic algorithm
needs and cryptographic protocol needs have been essentially filled
already -- AES, RSA, TLS and other components are all just fine and
more or less span the whole space of requirements. All that is left is
the comparative drudgery of implementing well known protocols and
(since most of them have been implemented) using them. No fun at all!

This is not to say that we don't need people inventing new algorithms
and protocols, because we do -- in an academic context. After all,
someday AES will seem too weak, or someone will find a yet cleverer
way to factor large composites, and besides, we still don't have ideal
protocols for many sorts of distributed problems. Furthermore as I
said, there is nothing wrong with good clean fun. What we don't need
is people mistaking the sort of play and research of academia for
things that should be released as software to the public.

The shame of it all is, as people have noted, there is substantial
demand for better implementations of things like SSL, and even more
importantly, for better applications and infrastructures. It is too
hard to use the tools we have now, but not because AES is somehow hard
to use or because SSL is a bad component. The problems we have
deploying, both because of things that are difficult for programmers
to use and because of things that are inconvenient for users, are a
massive problem, and one that cries out for lots of work.

Unfortunately, it is the sort of work that isn't glamorous. In
engineering, one often finds a distinction between the personalities
of innovators and "finishers" -- the guy who's great at coming up with
a new car engine idea vs. the guy who's really good at cleaning up the
new engine idea for manufacturability and simplicity but who would not
have thought of the idea in the first place. It is the distinction
between implementing the neat prototype of a fantastic new idea and
polishing it into something your grandmother can use. Being a
"finisher" is, unfortunately, not seen as being as glamorous as being
the trailblazer. Even more unfortunately, we seem to have a lack of
them in the security community.


Perry
-- 
Perry E. Metzger		perry at piermont.com

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