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

Christian Huitema <huitema@huitema.net> Fri, 05 June 2020 00:35 UTC

Return-Path: <huitema@huitema.net>
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 0FAB23A10D4 for <ietf@ietfa.amsl.com>; Thu, 4 Jun 2020 17:35:12 -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, RCVD_IN_MSPIKE_BL=0.001, RCVD_IN_MSPIKE_L4=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 G0uh3u_yA3Co for <ietf@ietfa.amsl.com>; Thu, 4 Jun 2020 17:35:10 -0700 (PDT)
Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9494B3A10D2 for <ietf@ietf.org>; Thu, 4 Jun 2020 17:34:57 -0700 (PDT)
Received: from xse132.mail2web.com ([66.113.196.132] helo=xse.mail2web.com) by mx170.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1jh0Jw-0012uP-6a for ietf@ietf.org; Fri, 05 Jun 2020 02:34:54 +0200
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 49dN8D1KvTz4jqk for <ietf@ietf.org>; Thu, 4 Jun 2020 17:00:44 -0700 (PDT)
Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1jgzmu-0002na-2K for ietf@ietf.org; Thu, 04 Jun 2020 17:00:44 -0700
Received: (qmail 23744 invoked from network); 5 Jun 2020 00:00:43 -0000
Received: from unknown (HELO [192.168.1.107]) (Authenticated-user:_huitema@huitema.net@[172.58.43.64]) (envelope-sender <huitema@huitema.net>) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for <ietf@ietf.org>; 5 Jun 2020 00:00:43 -0000
From: Christian Huitema <huitema@huitema.net>
To: Craig Partridge <craig@tereschau.net>
Cc: IETF discussion list <ietf@ietf.org>
References: <CAHQj4Cem6YdTXKFPW6Mk6gK9Yt_2qD=M7PAE6nxFEdJrD==ZVA@mail.gmail.com> <8CDB0383-41B9-4D10-BCA8-FF6FC7AFF2DD@huitema.net>
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mDMEXtavGxYJKwYBBAHaRw8BAQdA1ou9A5MHTP9N3jfsWzlDZ+jPnQkusmc7sfLmWVz1Rmu0 J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PoiWBBMWCAA+FiEEw3G4 Nwi4QEpAAXUUELAmqKBYtJQFAl7WrxsCGwMFCQlmAYAFCwkIBwIGFQoJCAsCBBYCAwECHgEC F4AACgkQELAmqKBYtJQbMwD/ebj/qnSbthC/5kD5DxZ/Ip0CGJw5QBz/+fJp3R8iAlsBAMjK r2tmyWyJz0CUkVG24WaR5EAJDvgwDv8h22U6QVkAuDgEXtavGxIKKwYBBAGXVQEFAQEHQJoM 6MUAIqpoqdCIiACiEynZf7nlJg2Eu0pXIhbUGONdAwEIB4h+BBgWCAAmFiEEw3G4Nwi4QEpA AXUUELAmqKBYtJQFAl7WrxsCGwwFCQlmAYAACgkQELAmqKBYtJRm2wD7BzeK5gEXSmBcBf0j BYdSaJcXNzx4yPLbP4GnUMAyl2cBAJzcsR4RkwO4dCRqM9CHpVJCwHtbUDJaa55//E0kp+gH
Subject: Re: The TCP and UDP checksum algorithm may soon need updating
Message-ID: <db8943fc-5cd3-9ea7-2876-a5468216d86f@huitema.net>
Date: Thu, 4 Jun 2020 17:00:43 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <8CDB0383-41B9-4D10-BCA8-FF6FC7AFF2DD@huitema.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 66.113.196.132
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.196.132/32
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.132/32@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0T32zu7lnXf5JHTxKFqDV/OpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDAzc5Jb/eaE0k3pqeq35lKbgN zB/4Jkrw1eDLcif59ft8ccWQR7+c3Br11WUZO2qjU7Tmz6iKnkQL9gqsxD347235Nhqq+/HvroPq 8GSPg+60/QPNqXybIny9WGhadIo/0w0RB5vhZeNQMVT8ptSkfLyme9ldZJ7uNXfg/GfS8fUvP/L5 rCqHDsKZM+xa1iwJX+gRCHfMVnsAk591zk0uilUI+ZL4xWiN8NS6C+dmX6OEdA4u1aThyWrQ/ou2 +v/lmX4Em37yFgrCB6NHRn1g+f3uncIqYSL3lhh5c81YyJqFoLZMmkWsaurVZfvqROaDnDtHb8z5 dpPkEuJ8Snwqla7jUnW3hy14Yji8fo+4xCnSRo4Rcu5Z37rMuDjCny5fE9ykbJ7I9co1MAEE3ruN Xsm8UJsAPvDcVSKtDCYkioPY5Qx4fJOk03R5fJtf/Dv/dkIzS7m4GUpXCY1Y3j3ilQ8EW2aDkYIa 2M5pALviQranAWRfft7O67lvSj/BJ2SQFsi4jEJaqHgDC5WsxPrdVo/oDPI9UM+EvmnG5WohIKUn dLDoft3gQzSYknam2p7RQuavv2gmXRAax8u+OMalCKzNjLvclnGzlTC8ZgkR3laIWqvAxiBHuIuS y5fCAlEk1L9RSSbLrR9kRvRG6IiE4VACVO3tx78u0bG7If2TCVTvPBPmCWGjVvyWTz8/ASw39wrD vPnK/Bc/gkr3Ltem+TnzSXChKWk/itcbicJsIPcnBmMoyjcnQlOKTHkpiKe0fqb5R4VemuUI6bcE ARsm0De6PaZO6/JToEyx4tmc5OljkPSpPXAVjl2oMr8a1xm0wfXUFMjTH2DyD8i5kO5bZlYFvf25 LVONYbYifH5OzZCwIgD/xDehea09OpnwSuobZrrGExMR7eTbBjMGDKI3ijhhJn7Muv/NHXl0o++8 3wM=
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/DA6c4V9okT4gAasUTGQHHZ-NhUU>
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: Fri, 05 Jun 2020 00:35:12 -0000

On 6/4/2020 2:54 PM, Christian Huitema wrote:
>> On Jun 4, 2020, at 2:26 PM, Craig Partridge <craig@tereschau.net> wrote:
>>
>> 
>> The SSH spec says terminate on failure and that it requires a reliable underpinning.
>>
>> Termination on error is no good.  One of the studies shows huge failure rates (over 50%) for large file transfers.  One guess is that's due to security protocols terminating when TCP hands up something with an error.
> Good thing that the IETF is nearing completion of the work on QUIC version 1.. I don't know whether you followed that, Craig, but QUIC plus UDP provides pretty much the same services as TLS plus TCP, including protection of every packet using AEAD encryption and checksum. Error not detected by the UDP checksum will most probably be detected by the 16 bits AEAD checksum.
Oops. 16 bytes AEAD checksum, not bits, of course.
>
> Your note mentions that errors are so frequent that some might not be detected by the MD5 checksum. That's a tall claim. MD5 provides a 128 bit cryptographic checksum, so the chances of not detecting an error are something like 1/2^128, something like 1.0E-38.
>
> There are attacks against MD5, which is why it is now deprecated. But these are cryptographic attacks, requiring significant computations to obtain two packets that would get the same checksum. We are speaking here of randomly flipping a few bits, which is completely different. Any robust 128 checksum will detect that.

I understand now that Craig was referring to environments in which the
TCP checksum is complemented by an MD5 checksum truncated to 32 bits.
That combination will let an error pass through for every 4 billion
errors not detected by the TCP checksum, which could very well be a
practical problem. When a full MD5 128 bit checksum used to check the
validity of a file, the residual TCP errors will be reliably detected.

-- Christian Huitema