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.
- The TCP and UDP checksum algorithm may soon need … Craig Partridge
- Re: The TCP and UDP checksum algorithm may soon n… Joe Touch
- Re: The TCP and UDP checksum algorithm may soon n… Michael Thomas
- Re: The TCP and UDP checksum algorithm may soon n… Craig Partridge
- Re: The TCP and UDP checksum algorithm may soon n… Richard Barnes
- Re: The TCP and UDP checksum algorithm may soon n… Craig Partridge
- Re: The TCP and UDP checksum algorithm may soon n… Brian E Carpenter
- Re: The TCP and UDP checksum algorithm may soon n… Nico Williams
- Re: The TCP and UDP checksum algorithm may soon n… Nico Williams
- Re: The TCP and UDP checksum algorithm may soon n… Richard Barnes
- Re: The TCP and UDP checksum algorithm may soon n… Richard Barnes
- Re: The TCP and UDP checksum algorithm may soon n… Christian Huitema
- Re: The TCP and UDP checksum algorithm may soon n… Christian Huitema
- Re: The TCP and UDP checksum algorithm may soon n… Phillip Hallam-Baker
- Re: The TCP and UDP checksum algorithm may soon n… Joseph Touch
- Re: The TCP and UDP checksum algorithm may soon n… Stewart Bryant
- Re: The TCP and UDP checksum algorithm may soon n… Phillip Hallam-Baker
- Re: The TCP and UDP checksum algorithm may soon n… Joseph Touch
- Re: The TCP and UDP checksum algorithm may soon n… Nico Williams
- Re: The TCP and UDP checksum algorithm may soon n… Michael Richardson
- Re: The TCP and UDP checksum algorithm may soon n… Nico Williams
- Re: The TCP and UDP checksum algorithm may soon n… Craig Partridge
- Re: The TCP and UDP checksum algorithm may soon n… Masataka Ohta
- Re: The TCP and UDP checksum algorithm may soon n… John Levine
- Re: The TCP and UDP checksum algorithm may soon n… Phillip Hallam-Baker
- Re: The TCP and UDP checksum algorithm may soon n… Joseph Touch
- Re: The TCP and UDP checksum algorithm may soon n… Christian Huitema
- Re: The TCP and UDP checksum algorithm may soon n… Michael Thomas
- Re: The TCP and UDP checksum algorithm may soon n… Joseph Touch
- Re: The TCP and UDP checksum algorithm may soon n… Michael Thomas
- Re: The TCP and UDP checksum algorithm may soon n… Salz, Rich
- Re: The TCP and UDP checksum algorithm may soon n… Michael Thomas
- Re: The TCP and UDP checksum algorithm may soon n… Salz, Rich
- Re: The TCP and UDP checksum algorithm may soon n… Michael Thomas
- Re: The TCP and UDP checksum algorithm may soon n… Michael Richardson
- Re: The TCP and UDP checksum algorithm may soon n… Benjamin Kaduk
- Re: The TCP and UDP checksum algorithm may soon n… Nick Hilliard
- Re: The TCP and UDP checksum algorithm may soon n… Carsten Bormann
- Re: The TCP and UDP checksum algorithm may soon n… Nick Hilliard
- Re: The TCP and UDP checksum algorithm may soon n… Michael Thomas
- Re: The TCP and UDP checksum algorithm may soon n… Joe Touch
- Re: The TCP and UDP checksum algorithm may soon n… Nico Williams
- Re: The TCP and UDP checksum algorithm may soon n… Nico Williams
- Re: The TCP and UDP checksum algorithm may soon n… Nick Hilliard
- Re: The TCP and UDP checksum algorithm may soon n… Michael Thomas
- Re: The TCP and UDP checksum algorithm may soon n… Michael Thomas
- Re: The TCP and UDP checksum algorithm may soon n… Nick Hilliard
- Re: The TCP and UDP checksum algorithm may soon n… Michael Thomas
- Re: The TCP and UDP checksum algorithm may soon n… Carsten Bormann
- Re: The TCP and UDP checksum algorithm may soon n… Nico Williams
- Re: The TCP and UDP checksum algorithm may soon n… Michael Thomas
- Re: The TCP and UDP checksum algorithm may soon n… Nico Williams
- Re: The TCP and UDP checksum algorithm may soon n… John C Klensin
- Re: The TCP and UDP checksum algorithm may soon n… Nico Williams
- Re: The TCP and UDP checksum algorithm may soon n… Richard Barnes
- Re: The TCP and UDP checksum algorithm may soon n… Russ Housley
- Re: The TCP and UDP checksum algorithm may soon n… Brian E Carpenter
- Re: The TCP and UDP checksum algorithm may soon n… Nico Williams
- Re: The TCP and UDP checksum algorithm may soon n… Warren Kumari
- Re: The TCP and UDP checksum algorithm may soon n… John C Klensin
- Re: The TCP and UDP checksum algorithm may soon n… Christian Huitema
- Re: The TCP and UDP checksum algorithm may soon n… John C Klensin
- Re: The TCP and UDP checksum algorithm may soon n… Craig Partridge
- Re: The TCP and UDP checksum algorithm may soon n… Nico Williams
- Re: The TCP and UDP checksum algorithm may soon n… Eric Rescorla
- Re: The TCP and UDP checksum algorithm may soon n… Craig Partridge
- Re: The TCP and UDP checksum algorithm may soon n… Michael Thomas
- Re: The TCP and UDP checksum algorithm may soon n… Michael Thomas
- Re: The TCP and UDP checksum algorithm may soon n… Nico Williams
- Re: The TCP and UDP checksum algorithm may soon n… Michael Thomas
- Re: The TCP and UDP checksum algorithm may soon n… John Levine
- Re: The TCP and UDP checksum algorithm may soon n… Michael Thomas
- Re: The TCP and UDP checksum algorithm may soon n… Brian E Carpenter
- Re: The TCP and UDP checksum algorithm may soon n… Warren Kumari
- Re: The TCP and UDP checksum algorithm may soon n… John R Levine
- Re: The TCP and UDP checksum algorithm may soon n… tom petch
- Re: The TCP and UDP checksum algorithm may soon n… Salz, Rich
- Re: The TCP and UDP checksum algorithm may soon n… Carsten Bormann
- Re: The TCP and UDP checksum algorithm may soon n… Salz, Rich
- Re: The TCP and UDP checksum algorithm may soon n… Craig Partridge
- Re: The TCP and UDP checksum algorithm may soon n… Michael Thomas