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

John C Klensin <john-ietf@jck.com> Tue, 09 June 2020 05:04 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1D483A0912 for <ietf@ietfa.amsl.com>; Mon, 8 Jun 2020 22:04:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEQ6P4XXhTUr for <ietf@ietfa.amsl.com>; Mon, 8 Jun 2020 22:04:50 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B1C33A090F for <ietf@ietf.org>; Mon, 8 Jun 2020 22:04:50 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1jiWRK-0007L8-SI; Tue, 09 Jun 2020 01:04:46 -0400
Date: Tue, 09 Jun 2020 01:04:41 -0400
From: John C Klensin <john-ietf@jck.com>
To: Christian Huitema <huitema@huitema.net>
cc: Carsten Bormann <cabo@tzi.org>, IETF discussion list <ietf@ietf.org>
Subject: Re: The TCP and UDP checksum algorithm may soon need updating
Message-ID: <E5456D253C5DBD2393F48E7A@PSB>
In-Reply-To: <BB6A192C-3B93-4082-9E4C-34DE84FA02FB@huitema.net>
References: <FFC7A18141B2178321D89DB0@PSB> <BB6A192C-3B93-4082-9E4C-34DE84FA02FB@huitema.net>
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-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/kMvK_f5WSA2HD63tBwcZRzPwUyk>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jun 2020 05:04:52 -0000


--On Monday, June 8, 2020 19:39 -0700 Christian Huitema
<huitema@huitema.net> wrote:

> 
>> On Jun 8, 2020, at 7:18 PM, John C Klensin
>> <john-ietf@jck.com> wrote:
>> 
>>  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.
> 
> Encryption without authentication is subject to a variety of
> attacks such as truncating messages, splicing them, or
> changing the encrypted text. That's why most modern encryption
> systems provide authentication at the same time as encryption.
> So it is much more than "a side effect"...

Christian, 

Perhaps a poor choice of words.  While it feels to me as if we
are quibbling about fine points of terminology, most likely I'm
missing something important, so let me try again, noting your
"most" and skipping over the question as to whether "integrity
protection" and "authentication" are the same thing and using
more words than many people seem to prefer.

Because integrity protection comes with most modern encryption
systems, there are two ways to approach integrity protection for
data transmission.  One is to encrypt the transmission, thereby
getting the benefits of the associated integrity protection as
well as privacy protection.  The other is to concentrate on
integrity protection methods that leave the transmission payload
in clear (at least as far as the data transmission system is
concerned [1]).

Historical experience going back centuries indicates that, from
time to time, some governments --often driven by law enforcement
or national security agencies and considerations -- have become
anxious about encryption methods strong enough to impede their
access to the encrypted data.  Their proposed mechanisms for
dealing with those concerns have including laws and regulations
requiring parties with access to the cleartext versions of those
data on request, government-accessible backdoors into encryption
technologies, government access to decryption keys, and outright
bans on the use of strong encryption at least under selected
circumstances or by selected parties.  Demands for access to
encrypted data or restrictions on the use of encryption have
occurred in several countries in recent years.  Even while
resisting such demands as hostile to, among other things,
personal privacy and secure commercial transactions over
communications networks, it is sensible for us to make
thoughtful and considered decisions about network design that
include, at least, fallback strategies against the possibility
of bans or several restrictions on cryptography that would
affect non-trivial portions of the Internet.

By contrast, mechanisms that merely provide integrity protection
without resort to encryption have never faced the same level of
government scrutiny as encryption.

Is that better?

thanks,
   john


[1] Information encrypted prior to transmission and decrypted
only subsequent to receipt are not discussed here.