[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: ADFU+vs8Py3iKsnkdiZfXeSxOGNormDDwD/AzuSkoEv5Nm/yQmmBKseGH5PQQU9DtIVjs7+W+XLpIm4CZKL/R84svt8=
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
- [tsvwg] Comment on draft-ietf-tsvwg-transport-enc… Tom Herbert
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Joseph Touch
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Black, David
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Joseph Touch
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Tom Herbert
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Joseph Touch
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Black, David
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Tom Herbert
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Joseph Touch
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Gorry Fairhurst
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Ruediger.Geib
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Gorry Fairhurst
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Tom Herbert
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Black, David
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Tom Herbert
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Gorry Fairhurst
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Tom Herbert
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Gorry Fairhurst
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Ruediger.Geib
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Tom Herbert
- Re: [tsvwg] Comment on draft-ietf-tsvwg-transport… Spencer Dawkins at IETF