[tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-13

Tom Herbert <tom@herbertland.com> Mon, 23 March 2020 14:58 UTC

Return-Path: <tom@herbertland.com>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDFD3A07C2 for <tsvwg@ietfa.amsl.com>; Mon, 23 Mar 2020 07:58:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Level:
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_NONE=0.001, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.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 s-oakhKX43XS for <tsvwg@ietfa.amsl.com>; Mon, 23 Mar 2020 07:58:21 -0700 (PDT)
Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) (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 0D8653A02C1 for <tsvwg@ietf.org>; Mon, 23 Mar 2020 07:58:20 -0700 (PDT)
Received: by mail-ed1-x52f.google.com with SMTP id i24so16566883eds.1 for <tsvwg@ietf.org>; Mon, 23 Mar 2020 07:58:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=Iok055F4RlnybFNd6wBBUOFiY2OtPezASqx7s1rxVJ8=; b=RhxoQhhf5ZLdwDaZk5vQ/YJfeCiCzKuYfQGR447INOJThAU0oUN9bhoW3cXtRhuAYL Ber+UaP7WgcRRzZfOCU+vOUnH1+3Dj+kNEJgM9hPf/71SQD4pGR6IisbpMyzWNnh62+s qYYDfxtpsJnoMqkDGd4QjpA3iR6/QIySga/u7Kbkd1JjdtY6cKzeC3Gr595OO7j/tKNy LZmyKM9wTBDWze/uSGjqUWzMT3T2XAYmlZlOnfqrOZ0i1moV9VMfhlI26TM5Rf+i35Aa HqdTy0jZpGeN9lWl6O+hozWiG1Vjr9CulIoO3QMbOoaSjgJfcz5xQvaRi0tExNifwO2E p+7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Iok055F4RlnybFNd6wBBUOFiY2OtPezASqx7s1rxVJ8=; b=RO3yufNc+Og3Cy+aLlWpVX5dKGGJ7ZZ6DSjwhsPxCJSIMQfF3K+Ev8VZq6WaVHASmA tzGFykVD5wAPORMkb/2tRTqcqvxBv6bxnGqL2rklJA64xxTx6IrUD43bEMzaSIcadKJQ 3XWdMaU17x2Jms4fEVxfd5qmHfu7xzu0NfVXjh2om5I8zapcqO5LrvaWdiD6BquxELPU T+454eTmHSVmYZtGhzUZJuAzFNKBdu/Exh8v7rCBPpH3xCn5GwWT7Hk7mfBRoRwrmYcx 3ADXXTenuDFG0GEWT81QJhendM+jvwT1+z6yDmIAedfbMGF3yaFPjrZg4LMHvVnmgql5 FF/g==
X-Gm-Message-State: ANhLgQ031fHNpmHjREgtm7qcYBkZAaHDkQa4U4tRVCRMsc+HJbGaLoKh M/5Oh7cqzRsUNvDg2BuzyEaoqG2GlOcPVtvWQ6KUJ33qNdM=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vs8Py3iKsnkdiZfXeSxOGNormDDwD/AzuSkoEv5?= =?utf-8?q?Nm/yQmmBKseGH5PQQU9DtIVjs7+W+XLpIm4CZKL/R84svt8=3D?=
X-Received: by 2002:a05:6402:7c1:: with SMTP id u1mr5998128edy.79.1584975498458; Mon, 23 Mar 2020 07:58:18 -0700 (PDT)
MIME-Version: 1.0
From: Tom Herbert <tom@herbertland.com>
Date: Mon, 23 Mar 2020 07:58:07 -0700
Message-ID: <CALx6S349SE2Ho0V2bJPSE7dh3+2f5Wiw1AofMke0RY4FwF=ebw@mail.gmail.com>
To: tsvwg <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/GpNZIrHQaa-nRLGhGDwX37AJrpI>
Subject: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-13
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 23 Mar 2020 14:58:27 -0000

Regarding new text on Ipv6 extension headers, the draft states:

"o On the one hand, protocols do not necessarily have an incentive to
expose the actual information that is used by the protocol itself and
could therefore manipulate the exposed transport header information to
gain an advantage from the network. The incentive to reflect actual
transport header information has to be considered when proposing a
method."

I think this is a mostly irrelevant argument because:

- The QUIC spin bit, which is touted as the best example of a non-TCP
protocol exposing transport layer information, is not used by the end
protocol hence hosts can set it to try to gain an advantage as the
argument suggests. It's even worse than that, since the spin bit is in
UDP payload it's quite possible that the network misinterprets a
packet that is not QUIC (but uses the same port number), in which case
such packets may be at a disadvantage.
- STT (https://tools.ietf.org/html/draft-davie-stt-08) is an example
of how the TCP protocol itself can be spoofed explicitly for the
purpose of fooling the network into provide TCP-level service for
something not at all TCP (in this case IP tunnels).
- The argument precludes the possibility that the transport layer
information in Hop-by-Hop options could be authenticated by the
network and hence a contract is established between hosts and network
that the information is honest and correct. FAST
(https://tools.ietf.org/html/draft-herbert-fast-04) gives a
description of that.

Fundamentally, transport layer is end-to-end information. There is no
contract between end hosts and the network that hosts have to be
honest or correct in setting information in the transport layer-- the
only contract is between the endpoints. There is incentive for hosts
to set transport information per the networks implicit requirements,
but that's not because we are interested in getting any of the
benefits listed in the draft, it's simply because if we don't abide by
the networks implicit requirements our packets get will likely get
dropped somewhere in the path. Ultimately, this is what has driven
host stacks and applications to the least common denominator, and is
exactly why any new transport protocols will encrypt as much as
possible.

Tom