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

Carsten Bormann <> Mon, 08 June 2020 09:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 887AB3A082D for <>; Mon, 8 Jun 2020 02:54:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 V21GFHvhdnVv for <>; Mon, 8 Jun 2020 02:54:18 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5B2003A0826 for <>; Mon, 8 Jun 2020 02:54:18 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 49gT9g52z2zyVk; Mon, 8 Jun 2020 11:54:15 +0200 (CEST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.\))
Subject: Re: The TCP and UDP checksum algorithm may soon need updating
From: Carsten Bormann <>
In-Reply-To: <>
Date: Mon, 8 Jun 2020 11:54:15 +0200
Cc: Michael Thomas <>, Joseph Touch <>, "" <>
X-Mao-Original-Outgoing-Id: 613302855.15607-1496134d16cbdecda492c6e11a818aee
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <> <> <> <> <> <> <>
To: "Salz, Rich" <>
X-Mailer: Apple Mail (2.3608.
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: Mon, 08 Jun 2020 09:54:22 -0000

On 2020-06-08, at 01:52, Salz, Rich <> wrote:
>>   Because the TCP headers aren't part of the hmac digest? Am I missing 
>    something?
> And how does that affect the application data?  What corruption of TCP headers would not end up being noticed at the application layer and therefore TLS?

Noticed, sure.
It is still a performance bug if transfers need to be redone from scratch just because the TCP checksum failed to catch corruption.
As the transfers get longer, the probability of some corruption approaches one, so the number of transfer attempts needed before one goes through goes through the roof.

(Literally the first thing I did on the IP network of this university, when I came here in 1993, was to find the reason for random file corruption in the network.  Of course, it was a Sun NFS server with a failing Ethernet card.  At the time, UDP checksums were generally switched off for NFS, but even if they would have been switched on, we’d just seen the corruption ~ 2**-16 as often.  Security protocols used right would have protected us from this and would have made the bit errors a performance statistic…)

TL;DR: Don’t use the network without security.  
But if the secure protocols fail to recover, you still have a problem.
QUIC completely solves this particular problem; only TLS/TCP has it, DTLS doesn’t.

Grüße, Carsten