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

Nico Williams <nico@cryptonector.com> Mon, 08 June 2020 19:08 UTC

Return-Path: <nico@cryptonector.com>
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 306A93A0F43 for <ietf@ietfa.amsl.com>; Mon, 8 Jun 2020 12:08:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 kBjBH045fZDJ for <ietf@ietfa.amsl.com>; Mon, 8 Jun 2020 12:08:36 -0700 (PDT)
Received: from black.elm.relay.mailchannels.net (black.elm.relay.mailchannels.net [23.83.212.19]) (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 BE0403A0F23 for <ietf@ietf.org>; Mon, 8 Jun 2020 12:08:35 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id D27371206F6; Mon, 8 Jun 2020 19:08:34 +0000 (UTC)
Received: from pdx1-sub0-mail-a99.g.dreamhost.com (100-96-21-80.trex.outbound.svc.cluster.local [100.96.21.80]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 59E7112164D; Mon, 8 Jun 2020 19:08:34 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a99.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.8); Mon, 08 Jun 2020 19:08:34 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Whimsical-White: 07d9bff659d46200_1591643314646_487243869
X-MC-Loop-Signature: 1591643314646:3673741713
X-MC-Ingress-Time: 1591643314645
Received: from pdx1-sub0-mail-a99.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a99.g.dreamhost.com (Postfix) with ESMTP id F1E5E7F0E2; Mon, 8 Jun 2020 12:08:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Q4f+k8kveEY1tM r6OJArzSzDpU0=; b=KCOq91Y6LGIUPzcapxN8BbofZAa/IbnTWsqr631BpZ+dS2 aMuEC5aM1me6gQngzDBBz6LjfeEnTMm2xe9CAXIP6iiWrxvBX87yass7/RWmG+4P 9ONRp/zWuUX0KCsjBANWnISoGp9eTpAZVuNNAu5gKJuq5GzsjvrwG65bp63FY=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a99.g.dreamhost.com (Postfix) with ESMTPSA id B29AF7F0DA; Mon, 8 Jun 2020 12:08:30 -0700 (PDT)
Date: Mon, 8 Jun 2020 14:08:26 -0500
X-DH-BACKEND: pdx1-sub0-mail-a99
From: Nico Williams <nico@cryptonector.com>
To: Michael Thomas <mike@mtcc.com>
Cc: Joe Touch <touch@strayalpha.com>, "ietf@ietf.org" <ietf@ietf.org>
Subject: Re: The TCP and UDP checksum algorithm may soon need updating
Message-ID: <20200608190825.GB18021@localhost>
References: <8946c5bf-0f6b-7a52-6326-dda59a78a798@mtcc.com> <AF28EDA6-0402-4578-A6C4-B3136F6C8650@strayalpha.com> <20200608171628.GX18021@localhost> <909178cc-c1b6-2dce-09eb-f8d28b63968c@mtcc.com> <20200608184543.GZ18021@localhost> <3265e498-a384-efed-2087-502b296d33cb@mtcc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3265e498-a384-efed-2087-502b296d33cb@mtcc.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: -100
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduhedrudehvddgjeefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhepfffhvffukfhfgggtuggjfgesthdtredttdervdenucfhrhhomheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqeenucggtffrrghtthgvrhhnpefftdektefhueetveeigfefgeejteejvdfhhefgvddtfeeujeehleeguefhgffhgfenucfkphepvdegrddvkedruddtkedrudekfeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhm
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/fszaamCToFYhGqj-y7RndROGPO4>
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: Mon, 08 Jun 2020 19:08:43 -0000

On Mon, Jun 08, 2020 at 11:52:04AM -0700, Michael Thomas wrote:
> On 6/8/20 11:45 AM, Nico Williams wrote:
> > The idea with RFCs 5387 and 5660 is that there is no need for an IPsec
> > PKI for IPsec to be useful, and, indeed, that IPsec for authentication
> > is tricky because -after all- it deals in... IP addresses, which are not
> > useful for authentication.
> > 
> > Instead, use IPsec for session crypto and use channel binding to bind
> > IPsec channels to higher-layer protocols where authentication can and
> > does happen.
> 
> Sorry for being lazy and not skimming them, but does this imply sort of like
> a naked public key kind of auth like ssh? Or maybe a DNS based one like
> DKIM?

Bare public keys, certified public keys -- either way.

You just wouldn't bother with RFC 4301 style Peer Authentication
Database (PAD, which also deals in authorization), and instead construct
a guarantee of protection and SA peer continuity at the TCP (and even
UDP!, for "connected" UDP sockets) layer.  Then you'd let the app use
channel binding to IPsec, thus binding authentication at the app layer
to session crypto at the lowest end-to-end layer.

That was the idea.  A good idea, IMO, but it didn't happen.  It was too
late.

> I mean, mitm is always a consideration so auth is always needed, right?

See channel binding, RFC 5056.

Nico
--