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

John C Klensin <> Tue, 09 June 2020 02:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3CB713A0929 for <>; Mon, 8 Jun 2020 19:18:46 -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, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bMRIzBfmMXMc for <>; Mon, 8 Jun 2020 19:18:43 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8AFCC3A092B for <>; Mon, 8 Jun 2020 19:18:43 -0700 (PDT)
Received: from [] (helo=PSB) by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1jiTqP-0007A9-Oc; Mon, 08 Jun 2020 22:18:29 -0400
Date: Mon, 08 Jun 2020 22:18:21 -0400
From: John C Klensin <>
To: Richard Barnes <>
cc: Carsten Bormann <>, Nick Hilliard <>, IETF discussion list <>
Subject: Re: The TCP and UDP checksum algorithm may soon need updating
Message-ID: <FFC7A18141B2178321D89DB0@PSB>
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <701D43E2D4CCEC304A935A92@PSB> <>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
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: Tue, 09 Jun 2020 02:18:47 -0000


I interpreted Craig's  message a little differently.  As Russ
put it, this is a message integrity problem, not a
confidentiality one.  Yet, unless I have completely
misunderstood, much of the conversation has been about methods
that were designed for privacy protection using encryption with
integrity protection being nothing but a necessary side-effect.
Carsten spoke of a window of opportunity.  While I can see lots
of reasons for addressing the issues that Craig raised and doing
so sooner rather than later (especially if they are real, which
several people seem to doubt), I don't see that window closing
on us in the near future.  I do see a risk, one that I think
others have mentioned in this thread but that is certainly under
discussion in other fora, of our losing the battle, at least in
some places, to keep encryption available across the Internet
and I assumed that was the window Carsten was referring to (and
that set me off).


--On Monday, June 8, 2020 15:29 -0400 Richard Barnes
<> wrote:

> The upshot of the message that started this thread is that if
> you don't put your eggs in that basket, then the Internet
> doesn't work.
> On Mon, Jun 8, 2020 at 3:09 PM John C Klensin
> <> wrote:
>> --On Monday, June 8, 2020 20:39 +0200 Carsten Bormann
>> <> wrote:
>> > ...
>> > We now have the opportunity to make pervasive use of
>> > security; nobody knows how long that window of opportunity
>> > will stay open.  Instead of working on changing checksums,
>> > we should go for it.
>> <mini-rant>
>> While you are going for it just be sure that if the window
>> closes again, and closes sufficiently hard in some places to
>> ban the use of encrypted message flows entirely, the
>> community is not faced with a choice among no Internet, a
>> highly fractionated Internet with no communications between
>> "crypto ok" and "crypto prohibited" countries, or trying to
>> limp along using protocols that are known to be defective
>> because we decided to ignore the problems with them in favor
>> of putting all of our proverbial eggs in the pervasive
>> security and encryption basket. </mini-rant>
>>     john