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

Michael Thomas <> Mon, 08 June 2020 18:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F3B243A0EFA for <>; Mon, 8 Jun 2020 11:23:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.651
X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id da6A-yGlekR8 for <>; Mon, 8 Jun 2020 11:23:13 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::534]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A44E93A0EF6 for <>; Mon, 8 Jun 2020 11:23:13 -0700 (PDT)
Received: by with SMTP id o6so9139541pgh.2 for <>; Mon, 08 Jun 2020 11:23:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=0Yf6/WxCjyWzZRButNNBfJVSojSmo3RO78kGYoOqwwE=; b=An+45mVA48FdKrsMRJ6vYlXpRs4lOBe+fHRCNYNA8v0SxR7PDJ8Fm/mgbrDzy4J3wD P6CXR/Fn3ryKQn5M2YlH1hYm/Pz2yTWcL/+Pixdj4afjpnySrNjDBaljqQhpwRpzpuMR 37n3ICavAy3cMWNgSKRgPj01jWwGfxa+c5+icM6KljJv2JCaIyDtBy0tEg+y+Nu1MmZe 3GE8FVbxb+GuXXXckCHjHtpbPT9u0HcktF9EoqHfSGOLCqLPIXo0F8iXUyd3iK77rqJA Vk3plg79J6/OVx2wlAFYBJcm13fX0UVdpqglCK4QiaUxNR5SVYdhObWJFIGVk+cpa7Qk 8JIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=0Yf6/WxCjyWzZRButNNBfJVSojSmo3RO78kGYoOqwwE=; b=IMSTVgU4rOcNoSPFhjLwfh2Ed2abqtgBj5wOS6JdZ+hXv0wK2qi2b/2iQvCmnsrBMw Qap1B9pENU0ACLWehrULRV45vtV4Y9w/1kNjqySHCAu3jzp4Hq8Ma8OBeSzI7Bt55kqt BZ3ePP0rIfWQKq1jTnnfve9p4bsIg4KV1iy1isj6J3wIlK1KIV4AXVu4WA+RXsTFfQ4i QnGBtMeVGPKzDz25Ewgvwm0tCuPRX0AxQbG7JtaJiP/vJDJK2xpIgLAjfqpV0JN9iebs I4DyAN9hueMsRe3dDsnGFnVKl9bh81+3vECdO2t6wKlXR4NETMNR6Fz+/5ilWEFDCwoP ETJg==
X-Gm-Message-State: AOAM532KgdQN0dqpSeFGhHL8CtiB6IqDi7zJnFwv2KKdUpro022EySJU MXVvgOFwHCpvwhAfncnIjzog1EbEbDI=
X-Google-Smtp-Source: ABdhPJyRtSDQiHsQ98hDy5Ibln5BJDv3TSNfDFBk7ilRkBbmy9FeU1lxLA8uSK26hVFi9nB3op2W6Q==
X-Received: by 2002:a62:6d85:: with SMTP id i127mr11663775pfc.270.1591640592072; Mon, 08 Jun 2020 11:23:12 -0700 (PDT)
Received: from MichaelsMacBook.lan ( []) by with ESMTPSA id h20sm7655554pfo.105.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2020 11:23:11 -0700 (PDT)
Subject: Re: The TCP and UDP checksum algorithm may soon need updating
To: Nick Hilliard <>
Cc: "" <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Michael Thomas <>
Message-ID: <>
Date: Mon, 8 Jun 2020 11:23:09 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.8.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
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:23:15 -0000

On 6/8/20 11:12 AM, Nick Hilliard wrote:
> 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.

ssl had the advantage that it 1) beat ipsec to market, and 2) wasn't 
subject to API differences from OS layer calls like IPsec was, and with 
quite a bit of churn as i recall too. it's really too bad, imo. we 
wouldn't have had to do the contortions of dtls, for example. and now 
there's this problem. none of them are earth shattering, but it would 
have been cleaner.