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

Michael Thomas <> Mon, 08 June 2020 16:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4BBDD3A0D4D for <>; Mon, 8 Jun 2020 09:59:25 -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 3BZTmS8aLvdq for <>; Mon, 8 Jun 2020 09:59:24 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::62f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 657CB3A0D6D for <>; Mon, 8 Jun 2020 09:59:23 -0700 (PDT)
Received: by with SMTP id n9so6903874plk.1 for <>; Mon, 08 Jun 2020 09:59:23 -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=x1fg+RDPTjHL+O8ZJA3WGw7zUYJNjh6yJoQ92C865mI=; b=CTrnbSJl6ypSaovb+zcC18ks1A9m8KbRf919NJvPZxuoqcZq68Lra8ZdBzPjHZR9T1 LaAHLVgvql4ojRSW2hFylsA/pK68zSpbPv6/376vqL5rW0Nc78DjR1K3daOx2R/I0A0a E5fuG3PigGY8UDOEuouxIcTFImY7QwcLLwCrsXsQo0/gN0v9lfVFzM633tFaJJou7UqZ dMxt0SJK9IuWlKy56omwNPj+c0mTXRm9zOPqf/Fk48IYkWVMAABy1UY/PbQswNsDDAes 6gQydqIQxtRE+mvLyNaaZQ5mCUjqiHmMUwtdqm7yVj59gThL/ZaUMm3KknX74yx4j9pl GiWw==
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=x1fg+RDPTjHL+O8ZJA3WGw7zUYJNjh6yJoQ92C865mI=; b=Sm5lliLr2sfUSUwRqZKhaESvYc1uwQKcNcp+75iHxuhzFSWNWfgho+hNez7PIw5465 mNKTDbjH/555gIPHBgG3CypE419cDAYH9pMahCqfTg+1OgWNNAUODL/OkqDKjU69M7ai Gg5j9I1DgAn27J5VhRIrvXFlX8UCddgHUIwsu4iAYgrxrGI+1EUtwMGs+gfzCxDZ747a PTEgh3KAKJyZhXwY1tzCaxotYGsmQk1ux1GH//2zgIrpXnaRX35Jjlq0ohtUA4FubgOG 8Oqgj1quVtFcTyOf0KEDTK0xtcAf6cORSOq+xBwFXbbds5FbLIqIx+3iSkuGd6Ssj9Y6 Vjkg==
X-Gm-Message-State: AOAM533A2eN0bAHlrmHIZOuxWzF357bQgXEwgHPbhagYMCBC+/Cm7/UO rkBwu+LSNN5qJ2ra/CMbH3pcrQC/mKo=
X-Google-Smtp-Source: ABdhPJxjUQ6pWOz6jZ/B4Eg1QGVExTNu1UV5SUAKA22DgcC/hPFewXmDZRnHp3oSHdPoUqc/QJiQUA==
X-Received: by 2002:a17:90a:aa8f:: with SMTP id l15mr245071pjq.211.1591635561642; Mon, 08 Jun 2020 09:59:21 -0700 (PDT)
Received: from MichaelsMacBook.lan ( []) by with ESMTPSA id j186sm7650963pfb.220.2020. (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Jun 2020 09:59:20 -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 09:59:19 -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 16:59:25 -0000

On 6/8/20 2:09 AM, Nick Hilliard wrote:
> Michael Thomas wrote on 08/06/2020 01:21:
>> well, it could send it to the wrong port, but i'll guess that tls is 
>> on to that problem. i mean, it kind of sounds like you're saying the 
>> transport checksum failing isn't a big deal? creating a gigantic 
>> window would certainly not be a good thing in the face of congestion. 
>> transport mode ipsec wouldn't suffer those kinds of problems.
> in their current incarnations, transport mode ipsec and tcp-ao aren't 
> deployable at scale in the same way that tls is.
why would you say that? what layer the crypto is performed seems sort of 
irrelevant: rsa, aes and sha don't care who calls them. i assume that 
you can hack ipsec to emulate clients not having certs. what's left?
> Regarding transport layer integrity, there are distant echoes of the 
> old circuit-switched vs packet-switched arguments going on here.  
> tcp/ip made circuit switching redundant by loosening its assumptions 
> about transport layer reliability.  I wonder are we now seeing 
> something similar with TLS, which no longer depends on either 
> underlying transport or ip header integrity by pushing data stream 
> integrity management higher up the stack.
Quic seems to have done the opposite by moving it down. But do I trust 
higher levels to deal with congestion avoidance correctly? Not at all. 
That's a tragedy of the commons waiting to melt down.