Tinc's response to "Linux's answer to MS-PPTP"

[Guus Sliepen]

On Fri, Sep 26, 2003 at 06:26:16PM -0700, Joseph Ashwood wrote:

> I would have CC'd the author of the response page, but it fails to mention
> an author, in spite of the "Comments are welcome" statement at the
> beginning.

There is a "Contact" link left of it. You could've replied to me as
well.

> > Truncated MAC
> > tinc will continue to use only the first 32 bits by default.
> Simply put this is unacceptable from a security standpoint. The view taken
> is that the extra 128 bits represents a significant overhead in the
> communication. So I did the math, sending the extra 128 bits over a 52kbs
> would take 0.002 seconds, and over a T1 the time cost is an absolutely
> enormous 0.00008 seconds.

It is not the delay that matters, it is the bandwidth that is reduced.
And by enlarging the packets, the chance that they will be fragmented is
greater, which is also bad for performance. Some people want less
overhead instead of more security, silly as that may sound to you.

> The other consideration is the potentially the
> computation time argument, but SHA-1 is used regardless, the computation
> time is identical. There is no justification in even a dialup environment
> for not using the full HMAC.

For those who can't even spare the computation time, tinc allows you to
disable HMAC completely.

> > A message is sent which has the same length as the RSA key, and is
> > completely filled . . .using real random data (OpenSSL's RAND_bytes()).
> 
> I really wish people would actually read documentation *before* making
> stupid claims like this, in fact to quote the OpenSSL docs "These functions
> implement a cryptographically secure pseudo-random number generator (PRNG).
> " Any claim that OpenSSL implements a "real" random number generator are
> completely false.

Ok, I guess you can read that sentence in that way. But what you cut out
was:

with the output of a PRNG which is seeded

And I meant "that PRNG which is seeded using ..." with RAND_bytes(). And
by seeding it with real random data I mean seeding using /dev/random.

[...]
> What you're missing is that the connection iniator sets all the keys and can
> determine all the keys (assuming the uncontested simplified message flow is
> correct). Mallet can very easily perform a complete man-in-the-middle attack

Your assumption that the connection initiator sets all the keys in tinc
is wrong.

[...]
> > planned for tinc 2.0.
> 
> My guess is that you will once again use it in an insecure method, use
> either signed ephemeral keys, or introduce randomness form both sides,
> otherwise you will have the same problems from slightly different angles.

Finally, some constructive arguments. We are indeed considering the
things you mention. We might even switch to TLS for the TCP connections.

[...]
> >   - Don't act as an oracle for an attacker.
> > Apart from possibly being susceptible to a timing attack, we don't believe,
> > and Peter Gutmann has not convinced us, that tinc can be used as any other
> > kind of oracle.
> You provide all the chosen ciphertext information Mallet could want. You act
> as an oracle.

You can only provide so much ciphertext as an attacker before the
connection is closed. I do not see how this is different from, say,
SSL. What information can be obtained from our alledged oracle (apart
from being a timing oracle)?

> > Furthermore, SSL and SSH are
> > reliable stream based protocols, unsuitable for VPNs
> 
> Someone doesn't pay much attention to what they write. Both SSL and SSH
> _ARE_ VPN protocols, that you don't recognise them as such reflects a great
> deal on lack of knowledge in the area of security.
> 
> > [VPNs] work best with unreliable datagrams
> Ummmm, do you realize how dumb that sounds?

I'm afraid we have totally different views of a VPN here. Anyway,
tunneling traffic over SSH or an SSL connection would give us the awful
performance of TCP-over-TCP, which we want to avoid.

> > Apart from that, there is no reason why people shouldn't create new
> > protocols, which might in time become just as strong or even stronger. Even
> > great names as Ron Rivest didn't get it right the first time.
> 
> Yeah but the "great names" admit they are wrong, and fix things. You have
> instead taken every possible moment to insist that tinc is good, something
> that even the barest educated layperson can see is simply and completely
> false.

When our response says "Will be fixed in 2.0" multiple times, does that
sound like we don't think Peter Gutmann has valid points and that we won't
fix things?

> I think here Gutmann went a bit overboard in his recommendation, but
> regardless the idea that someone should replace SSH/SSL with something
> designed by an amateur without the knowledge necessary to make it correct is
> a bad idea. In fact I have several years of experience and I have a
> potential replacement protocol that I think may in some cases be better than
> SSL/SSH, even with my experience I have held off publishing it for about 4
> years now while I verify that it will in fact stand up to attack. How long
> was it between the inducement of this idea and it's release?

About half a year I guess. But, we didn't design the current protocol as
a replacement of SSL. In fact we replaced something that was worse than
the current protocol.

-- 
Met vriendelijke groet / with kind regards,
    Guus Sliepen <guus at sliepen.eu.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/20030927/d1286fd1/attachment.pgp>