[14320] in cryptography@c2.net mail archive

home help back first fref pref prev next nref lref last post

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

daemon@ATHENA.MIT.EDU (Guus Sliepen)
Sun Sep 28 12:20:57 2003

X-Original-To: cryptography@metzdowd.com
X-Original-To: cryptography@metzdowd.com
Date: Sun, 28 Sep 2003 11:05:18 +0200
From: Guus Sliepen <guus@sliepen.eu.org>
To: Cryptography list <cryptography@metzdowd.com>
In-Reply-To: <20030927195814.A13877@pull.privacy.nb.ca>


--6lXr1rPCNTf1w0X8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Sep 27, 2003 at 07:58:14PM +0100, M Taylor wrote:

> Perhaps a HMAC per "chunk", rather than per the payload of a single UDP
> datagram. I suspect per every 5 UDP datagrams, roughly ~7000 bytes of=20
> payload may work. This will increase latency.

That would not work either. It would have the same problems as a packet
that has been split into 5 fragments: if one of the fragments gets lost,
the whole packet will be discarded. Fragment reassembly is also
something that is not completely trivial, in the past there have been
some simple DoS attacks for various operating systems that did not
implement IP fragment reassembly correctly.

Each UDP packet must stand on its own, just like the network packet that has
been encapsulated within it.

> This should be redone from scratch, I would look at either using
> Diffie Hellman Key Exchange combined with digital signatures or the updat=
ed
> Needham Schroeder Public Key Protocol. Exchange two symmetric keys,
> one used for bulk data encryption, the other used for the HMAC
> authentication.=20

I think I prefer the Diffie-Hellman key exchange; the Needham Schroeder
public key protocol needs more round trips and one more RSA
encryption/decryption step.

> I expect this is a reference to "Why TCP Over TCP Is A Bad Idea"
> <http://sites.inka.de/~bigred/devel/tcp-tcp.html>

Yes.

> If Guus Sliepen and Ivo Timmermans are willing to seriously rethink their
> high tolerance for unncessary weakness, I think tinc 2.0 could end up bei=
ng
> a secure piece of software. I hope Guus and Ivo circulate their version 2=
=2E0=20
> protocol before they do any coding, so that any remaining flaws can be ea=
sily=20
> fixed in the paper design without changing a single line of code, saving =
time=20
> and effort.

Those are the first encouraging words I've heard since Peter Gutmann's
writeup was posted on Slashdot, thank you! We do plan to get rid of all
the weaknesses, and once we know what we want and we have a draft, I'll
post it in this mailing list.

--=20
Met vriendelijke groet / with kind regards,
    Guus Sliepen <guus@sliepen.eu.org>

--6lXr1rPCNTf1w0X8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/dqRNAxLow12M2nsRAsyKAKCR1N2f7MlSYv59uYBysU7Vc04XTACfedWH
8iz/63Iv7lWuOdLprFMrpbI=
=SkID
-----END PGP SIGNATURE-----

--6lXr1rPCNTf1w0X8--

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

home help back first fref pref prev next nref lref last post