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

Nick Hilliard <> Mon, 08 June 2020 18:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 489793A00B2 for <>; Mon, 8 Jun 2020 11:12:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ee-hqZ0cdMpM for <>; Mon, 8 Jun 2020 11:12:15 -0700 (PDT)
Received: from ( [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6BA333A00B0 for <>; Mon, 8 Jun 2020 11:12:15 -0700 (PDT)
Received: from crumpet.local ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id 058ICB1D000358 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 8 Jun 2020 19:12:12 +0100 (IST) (envelope-from
X-Authentication-Warning: Host [] claimed to be crumpet.local
Subject: Re: The TCP and UDP checksum algorithm may soon need updating
To: Michael Thomas <>
Cc: "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Nick Hilliard <>
Message-ID: <>
Date: Mon, 8 Jun 2020 19:12:10 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:52.0) Gecko/20100101 PostboxApp/7.0.18
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-GB
Content-Transfer-Encoding: 7bit
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 18:12:17 -0000

Michael Thomas wrote on 08/06/2020 18:37:
> Uh, why are you selling apps so short? An app is capable of making 
> library calls for TLS but incapable of making the OS calls for IPsec? 
> That's just silly.

Difficult to see how this was inferred? :-)

> The only reason, imo, that tls took hold is because it beat ipsec to the 
> market. By the time ipsec was well supported, nobody cared any more.

ssl, then later tls, took hold because it was designed for, and 
therefore easily applied to tcp sessions and because there was a lot of 
effort put into creating ancillary frameworks, e.g. the pki, sensible 
APIs, etc.  This push towards application usability made it transparent 
to the protocol consumer, whether that be granny, or 14yo whizz-kid, or 
someone trying to do some online shopping.

Obviously you're technically correct that an app can call any library 
function and that it matters little to a CPU or the data, or the network 
layer whether it's rsa, aes or sha - or ipsec, or tls or whatever.  But 
the success of tls came down to usability, or more specifically 
use-transparency: security could be implemented without people even 
being aware of it and shifting people from unencrypted to encrypted data 
transfer was a easy as configuring a server-side redirect.  Conversely 
configuring and managing ipsec still creates thundering headaches even 
for experienced operators.

There are plenty of reasons that security protocols in particular end up 
being unusable in practice - usually for sound reasons, none of which 
were individually wrong, but the outcome is invariably byzantine.  It's 
often the usability of a system which determines success, not the 
systems' other technical merits.