Re: The TCP and UDP checksum algorithm may soon need updating

Christian Huitema <> Thu, 04 June 2020 22:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CE3923A0F86 for <>; Thu, 4 Jun 2020 15:30:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JbvJrn2jh5-X for <>; Thu, 4 Jun 2020 15:30:17 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B8F093A0FEE for <>; Thu, 4 Jun 2020 15:30:14 -0700 (PDT)
Received: from ([] by with esmtp (Exim 4.92) (envelope-from <>) id 1jgyN9-000pIT-6N for; Fri, 05 Jun 2020 00:30:09 +0200
Received: from (unknown []) by (Postfix) with ESMTPS id 49dKLV2YSkz22gX for <>; Thu, 4 Jun 2020 14:54:26 -0700 (PDT)
Received: from [] ( by with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <>) id 1jgxog-0003uC-7q for; Thu, 04 Jun 2020 14:54:26 -0700
Received: (qmail 5612 invoked from network); 4 Jun 2020 21:54:25 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 4 Jun 2020 21:54:25 -0000
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
From: Christian Huitema <>
Mime-Version: 1.0 (1.0)
Subject: Re: The TCP and UDP checksum algorithm may soon need updating
Date: Thu, 4 Jun 2020 14:54:24 -0700
Message-Id: <>
References: <>
Cc: Richard Barnes <>, IETF discussion list <>
In-Reply-To: <>
To: Craig Partridge <>
X-Mailer: iPhone Mail (17E262)
Authentication-Results:; auth=pass smtp.auth=
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0T32zu7lnXf5JHTxKFqDV/OpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDAzc5Jb/eaE0k3pqeq35lKbgN zB/4Jkrw1eDLcif59ftKnW1wJNrq7r+v59vnUNc2U7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+60/QPNqXybIny9WGhadIo/YxFBjiwvt8YGG8KnqhbQXbyme9ldZJ7uNXfg/GfS8fUvP/L5 rCqHDsKZM+xa1iwJX+gRCHfMVnsAk591zk0uilUI+ZL4xWiN8NS6C+dmX6OEdA4u1aThyWrQ/ou2 +v/lmX4Em37yFgrCB6NHRn1g+f3uncIqYSL3lhh5c81YyJqFoLZMmkWsaurVZfvqROaDnDtHb8z5 dpPkEuJ8Snwqla7jUnW3hy14Yji8fo+4xCnSRo4Rcu5Z37rMuDjCny5fE9ykbJ7I9co1MAEE3ruN Xsm8UJsAPvDcVSKtDCYkioPY5Qx4fJOk03R5fJtf/Dv/dkIzS7m4GUpXCY1Y3j3ilZpnfSx1WjM8 Y221ho/pD3/YTgm/NnC/c8YEQ5zoBxO0GiKEd1IVossh7M0wcrtvaBF8Fc1stLBPZkoe/eBeS1RU PVcmx1QL+XiKf76y/BgKgeKd7vxpplmCSU/jtfA9aPKY2AXNZGS5G93aGyH8MqMlOQRMVMd0HCeT skOZ5TL8MiDx2tc8EbmfieEEBi/rEzXg724gFzhHYUe+7aKm0vXMWwerVn2LjNgYaINnWbwbTi+J 2sBvM/O0p+zizleC4va6FPcpDHjXMKZJK8+chiY5EW1DBqyLl5qhWPqC0KSL7cTs80/2FnZg/IMs IAdedSzLrjsyfTPCYbMCLdmf5h2vfxw3Qvb2Glio5Cia/9Kfg4kJ0WtAYbrpe3OOAtQNb87OBHCz Hbokiue7PjVB1S6AQRz4SqXhOP5fdiQt7lu5Jm5nk4BSgYHOJJgUtm67rBRli6kULE5BQDZnPvvF VsQ=
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 04 Jun 2020 22:30:19 -0000

> On Jun 4, 2020, at 2:26 PM, Craig Partridge <> wrote:
> The SSH spec says terminate on failure and that it requires a reliable underpinning.
> Termination on error is no good.  One of the studies shows huge failure rates (over 50%) for large file transfers.  One guess is that's due to security protocols terminating when TCP hands up something with an error.

Good thing that the IETF is nearing completion of the work on QUIC version 1. I don't know whether you followed that, Craig, but QUIC plus UDP provides pretty much the same services as TLS plus TCP, including protection of every packet using AEAD encryption and checksum. Error not detected by the UDP checksum will most probably be detected by the 16 bits AEAD checksum.

Your note mentions that errors are so frequent that some might not be detected by the MD5 checksum. That's a tall claim. MD5 provides a 128 bit cryptographic checksum, so the chances of not detecting an error are something like 1/2^128, something like 1.0E-38.

There are attacks against MD5, which is why it is now deprecated. But these are cryptographic attacks, requiring significant computations to obtain two packets that would get the same checksum. We are speaking here of randomly flipping a few bits, which is completely different. Any robust 128 checksum will detect that.

-- Christian Huitema