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

Richard Barnes <rlb@ipv.sx> Thu, 04 June 2020 21:42 UTC

Return-Path: <rlb@ipv.sx>
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 EBECF3A0FC5 for <ietf@ietfa.amsl.com>; Thu, 4 Jun 2020 14:42:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.com
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 ntmxKFnELYSb for <ietf@ietfa.amsl.com>; Thu, 4 Jun 2020 14:42:21 -0700 (PDT)
Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14DD83A0FB0 for <ietf@ietf.org>; Thu, 4 Jun 2020 14:42:21 -0700 (PDT)
Received: by mail-qt1-x82d.google.com with SMTP id j32so6639473qte.10 for <ietf@ietf.org>; Thu, 04 Jun 2020 14:42:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=M0zj+V5RPiJGcWmjkNPCWmpWzYEOUMllinyewP4CopE=; b=MXkTY9ZuxN9Vhkb3au0L5Mjdr6jPmaVwWVyDWp7dHS3f0f4bseC/HcYduc0tENWntM CLAHrlxDYPwutNX/AniGOOaMmv35s/vNmAblslvC1NpTBoCrOFVUUyUBlC9jIgj2Q60L BADDvLjscI5kZeyoSQsSQWcUSl90ndcY8NLe5ocT+KPoee+c2wp4lWMCOtBD6Wx+IjIX GixoCHK0NuPzH86pcvFIfv6rFfaWr/7ka0zZPGpvNgWfZmLCF2Xn74jPs3XKWrPXjjP0 2Xw8z48JEwYNQus5cgFxKCi8VxAMRkzVMM3PJKt59K1YDzPINE/J9IRnWZ/XiX66MDsg ZL/Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=M0zj+V5RPiJGcWmjkNPCWmpWzYEOUMllinyewP4CopE=; b=cdG2868QbdO3Km0DK5I4EmEp/o0CbitrqdhtfoTY6CXoLnfSByZTDx45zw/uquw4BH uCpbTUe+x7ruD9Mu9AMN+QAuLl8mNa2O5hMKI5e+VpUw4+RCuezno3nkGQciVAUtETFu jNip7f0RLdJrsdsBe43Y3cWmdfGOhuAkaWmlfwk86rT/kVtXXyKO45u3czaFHibfLt5I qBfRxSXJ5QHQr+vnN/j7hZn97MhswGBRouXliVaGsVxUiMTDH/cR6AfZ0F1vT9XObIgs apiGowWOUGIA5j8S7VJbcoFe+/CfJcy0Cj+s+NrNlNAM5iqT0PTfrs/zWKLFNR0UffAf 2T7g==
X-Gm-Message-State: AOAM533YY/ucq7U/RGA3XujkUF7996sjctzsmh+OUS8lUmUO3RF/n2Or TylIZigbl9o54o8Tpr5bmdchmAbkkCos538MgBiaDQ==
X-Google-Smtp-Source: ABdhPJzTxzSsuOzH9gHs0d5YRQuDId9JLq5poRpCpLta5wJq1A/MIi3Hc9UMV/UnrzJcPqbDRK/e1uSHrkxSlgq5NUs=
X-Received: by 2002:ac8:42c3:: with SMTP id g3mr6561504qtm.313.1591306938414; Thu, 04 Jun 2020 14:42:18 -0700 (PDT)
MIME-Version: 1.0
References: <CAHQj4Cf_vgXYEL=x4DCEnpwNxZpJQSD-h6MWmhMWpYwPF9XFow@mail.gmail.com> <E23EC459-213F-4D19-BC1B-6050EC2CB653@strayalpha.com> <CAHQj4CcOpciujCP9ugegjEjzyT7Oqzv_WtjWyTAGacUxkG9YYg@mail.gmail.com> <CAL02cgRjMQtcYDF04-3FsN1WOg_7H1fpR2_qPUwa-BegkQqp8A@mail.gmail.com> <528f3f54-28ad-a3ec-d693-2126a8397e67@gmail.com>
In-Reply-To: <528f3f54-28ad-a3ec-d693-2126a8397e67@gmail.com>
From: Richard Barnes <rlb@ipv.sx>
Date: Thu, 4 Jun 2020 17:42:06 -0400
Message-ID: <CAL02cgQJuV7_RbD0fLozYG7_GqYFSY9u_JGNpmxyk2REikXN2w@mail.gmail.com>
Subject: Re: The TCP and UDP checksum algorithm may soon need updating
To: Brian E Carpenter <brian.e.carpenter@gmail.com>
Cc: Craig Partridge <craig@tereschau.net>, IETF discussion list <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000cb0dbb05a749047c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/kNnS49uTO-2KJ8oelxmsJhRDVdI>
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: Thu, 04 Jun 2020 21:42:30 -0000

On Thu, Jun 4, 2020 at 5:28 PM Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> Richard,
>
> > On the UDP side, there should be no issue.  Anything above UDP has to
> tolerate loss anyway, so there should be mechanisms that will require from
> corruption-treated-as-loss.
>
> That depends. If a single bit inversion can get through undetected, the
> application layer might never detect an anomalx. (See what I did there?)
>

My point was that you could rely on a security layer in between the
transport and the app, in particular one that applies authenticated
encryption to verify the integrity of incoming data.  And cryptographic
integrity checks are in fact bit-sensitive.

Such a layer is in place for ~92% of HTTP traffic nowadays (depending on
how you measure), all WebRTC traffic, etc.  So like I said before, this
kind of looks like an argument for encrypting everything.

--Richard


>
> Regards
>    Brian Carpenter
>
> On 05-Jun-20 09:18, Richard Barnes wrote:
> > Yeah, secure transports already consider the data from the network
> untrusted, including TLS and DTLS, but also IPsec/ESP, SSH, SRTP and QUIC.
> As long as those protocols are using reasonably modern, AEAD ciphers, the
> worst impact of corruption in the transport is DoS.
> >
> > That said, there might be some pretty hard crashes in cases where the
> security protocol relies on the transport for something..  For example, TLS
> doesn't have a mechanism for requesting that data be re-sent in the event
> of loss/corruption, because it's assumed that TCP provides that.  If
> corruption is only detected at the TLS layer, there's not a way to
> recover.  That said, I wouldn't be surprised if many TLS stacks close the
> connection on bad data anyway.
> >
> > On the UDP side, there should be no issue.  Anything above UDP has to
> tolerate loss anyway, so there should be mechanisms that will require from
> corruption-treated-as-loss.
> >
> > So there may be some feedback loops to close, but that's a more limited,
> host-internal problem.
> >
> > In any case -- one more reason to encrypt everything!
> >
> > --Richard
> >
> > On Thu, Jun 4, 2020 at 4:17 PM Craig Partridge <craig@tereschau.net
> <mailto:craig@tereschau.net>> wrote:
> >
> >     Ah, I somehow had missed that.
> >
> >     Looks like it does the trick if we need it. Not sure if we'd have to
> update the optional checksum to use a new checksum too.
> >
> >     Craig
> >
> >     On Thu, Jun 4, 2020 at 1:33 PM Joe Touch <touch@strayalpha.com
> <mailto:touch@strayalpha..com>> wrote:
> >
> >         See draft-ietf-tsvwg-udp-options
> >
> >         > On Jun 4, 2020, at 12:13 PM, Craig Partridge <
> craig@tereschau.net <mailto:craig@tereschau.net>> wrote:
> >         >
> >         > Then there's UDP.  UDP has no options.
> >
> >
> >
> >     --
> >     *****
> >     Craig Partridge's email account for professional society activities
> and mailing lists.
> >
>
>