Gutmann Soundwave Therapy

Guus Sliepen guus at sliepen.org
Thu Jan 31 10:07:03 EST 2008


On Tue, Jan 29, 2008 at 12:26:21PM -0500, Perry E. Metzger wrote:

> Clearly, more people need to know about "Gutmann Soundwave Therapy".
> 
> Ivan Krstić <krstic at solarsail.hcs.harvard.edu> writes:
[...]
> > [0] Last paragraph, http://diswww.mit.edu/bloom-picayune/crypto/14238
> 
> As it turns out, the central image of Peter's post was popularized
> earlier*.
> 
> However, Peter clearly said this first in a security context, and I
> hope that the term "Gutmann Soundwave Therapy" spreads widely within
> our field as a way of ridiculing the desire to invent your own crypto
> algorithms and protocols. When it gets to the point where salesmen are
> vaguely aware of the phrase and fear it, we will know we have done our
> job successfully.

As one of the main developers of tinc, I have been at the receiving end
of Gutmann's therapy, or "drive-by shooting" as I experienced it at that
time.

Peter sent us his write-up up via private email a few days before he
posted it to this list (which got it on Slashdot). I had little time to
think about the issues he mentioned before his write-up became public.
When it did, I (and others too) felt attacked in a cruel way. Peter
ignored all the reasons *why* we used the kind of crypto we did at
that moment, compared it to a very high standard, and made it feel like
every thing we didn't do or didn't do as well as SSL made our crypto
worthless. 

We had some other people sending us security reviews of tinc, Jerome
Etienne for example. With them, we never had that feeling of being
"attacked". The conversations we had with them encouraged us to improve
tinc.

Peter's write-up was the reason I subscribed to this cryptography
mailing list. After a while the anger/hurt feelings I had disappeared.
I knew then that Peter was right in his arguments. Nowadays I can look
at Peter's write-up more objectively and I can see that it is not as
ad-hominem as it felt back then, although the whole soundwave paragraph
still sounds very childish ;)

When tinc 2.0 will ever come out (unfortunately I don't have a lot of
time to work on it these days), it will probably use the GnuTLS library
and authenticate and connect daemons with TLS. For performance reasons,
you want to tunnel network packets via UDP instead of TCP, so hopefully
there is a working DTLS implementation as well then.

I hope that in the future, if you see an application doing something
wrong, you don't immediately give the developers the soundwave therapy.
Be a little bit more gentle and try to find out why it was written that
way in the first place. It will create a lot more understanding and
willingness from the developers to fix the problems.

Also, from experimenting with a version of tinc that uses TLS, I can
tell you that it not the perfect solution for our problem. The main
issue I see with SSL and TLS is with the credentials. Both X.509 and
OpenPGP are focussed on URLs or email addresses. It is not clear to me
how to store other information (like which subnets a node on the VPN is
authorised to use) in such credentials in a nice way, other than
shoehorning it into a CN (X.509) or uid (OpenPGP) field. Certificate
chain verification is something that often goes wrong; some SSL libraries do
not offer that functionality, or only do it when an application
explicitly requests it. With OpenPGP you can have a web of trust, but
how do you make use of it in an automated way? I expect that the next
round of penis-shaped soundwave therapy will not be focussed on
whether or not an application uses SSL, but on how it (mis)uses SSL.

-- 
Met vriendelijke groet / with kind regards,
      Guus Sliepen <guus at sliepen.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20080131/7dad8362/attachment.pgp>


More information about the cryptography mailing list