[tsvwg] transport-encrypt-14 review, pt 1

Martin Duke <martin.h.duke@gmail.com> Thu, 09 April 2020 19:44 UTC

Return-Path: <martin.h.duke@gmail.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 254F33A0CF5; Thu, 9 Apr 2020 12:44:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 vF3e_aeNRYGh; Thu, 9 Apr 2020 12:44:21 -0700 (PDT)
Received: from mail-il1-x12e.google.com (mail-il1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (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 950D83A0CF3; Thu, 9 Apr 2020 12:44:18 -0700 (PDT)
Received: by mail-il1-x12e.google.com with SMTP id t6so840888ilj.8; Thu, 09 Apr 2020 12:44:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=nDYhDpS+QONdjiUroYg01Qn3sqc00bRkQiVb+kuvKCU=; b=nlcCFjsEuWUk3Ss2DTmAQJ1kKAU11l7D6/6GZOBeaMFXqa68O+iw9CmF9EKYuGn5ZU 78Le3tpPge86dxxAlI8cYQPh60ZDRiq6hEMV4mhI47a8CylxqmuODr4nH4BVVg3wSmNe FeJ8BsfJeKyAEEIY53fl+3EH1OnwheYud5wyCzw8NddsOoEJhoz9uQKEN+ks/uysJysn 5PZtVEcWWXwQJ3sXmZDdXiksZHnfmohS61N0bn+TmKga1HtvX/Hqq1e/pYH7vd2SgC2L D2QG3oN303BTKoOX9t54+gySXb/rkS/afOZxTJXW+XRDxqWWx7YKxb5fJf8bRWqDHF8Z v6sw==
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=nDYhDpS+QONdjiUroYg01Qn3sqc00bRkQiVb+kuvKCU=; b=AF0MfhFKGE7+u4ZXsQfuz2Pgr0GWn6PMpiwBrr4Hd2tU1Pi714YWEbkDZvRzvIDOm+ oea/KcU9UtsNcE4+Ao209lUIoIG0qfwOJhkXKN5EVQz99mIBkm3jLfeNdq2UBwWwkpoZ ox9U3OpJSI208hTzE97fEau+AK8Z3qb8hi9H3W2x/sZWjHnzfOPZOScVWFyP8ukDR3nj Jdji16vsTfCt+uCQphKDc16mL5rCI8JncY77UUvmO6s+UhV5iPiHR1ePhzks0EhqyID/ rEv6b4wuY0+wrE7T8x3LJKyZV7mA5ySm/l54VDLFoPqKi/qQuqu/g1VYgRykdCIeMmhu MgZg==
X-Gm-Message-State: AGi0Pua76O5Ig456G3h5UbogDT/hrKITeZ8w2FkkYUWEWsmg+7e5q7s/ CpiKZIvbXe2ITmrchSl88IHjrlcKnxmLFJoJc85ydU/g
X-Google-Smtp-Source: APiQypIca5Ux6z7secac3fhZLwESqU0L4ygJZJS0o8o8B1QJUZG35I+p2Z5l//ZRcZu0kcAp2NEiWRDBKcUIjPTfauM=
X-Received: by 2002:a05:6e02:894:: with SMTP id z20mr1597495ils.204.1586461457386; Thu, 09 Apr 2020 12:44:17 -0700 (PDT)
MIME-Version: 1.0
From: Martin Duke <martin.h.duke@gmail.com>
Date: Thu, 9 Apr 2020 12:44:06 -0700
Message-ID: <CAM4esxTbVSX1voJjzyt3YdapPuv7+K4EpU35SWYC3Y0rmo7Tww@mail.gmail.com>
To: draft-ietf-tsvwg-transport-encrypt.all@ietf.org, tsvwg <tsvwg@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000009e134805a2e0d705"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/j9xTFuij-nXd0eT74wbSQpBNXEQ>
Subject: [tsvwg] transport-encrypt-14 review, pt 1
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: Thu, 09 Apr 2020 19:44:23 -0000

Getting through this draft is not going as quickly as I'd hoped. Before my
notes get unmanageably long, I thought I'd send a few comments through
section 3.

The comments might invite some WG discussion, but the nits are purely
typos. Consider this a down payment on AD review.

*Comments* (if these are addressed later in the document, I apologize):
- I think this is missing an important reason for header encryption, or at
least header authentication -- to foil a large number of attacks like TCP
RST injection.

- Conversely, middlebox interference with headers does enable performance
enhancing proxies for extraordinary link types like satellite.

- Sec 2.3 explains that transport information is useful in detecting
various network pathologies. While true, the range of possible pathologies
is only as large as the control surface the transport protocol offers.

For example, in TCP networks can affect (and measure) packet loss and
latency. They also can also modify packets or drop them based on transport
layer information, meaning there are more failure modes to detect.

In QUIC, the latter is almost impossible. Aside from Initial Packets, the
only possible actions are (1) drop the packet, (2) accelerate or decelerate
the packet, (3) change bits that will cause authentication failure at the
receiver, or (4) modify the packet at UDP or below. All of these are still
measurable over a network segment, though with different techniques from
today. Most trivially but perhaps impractically, a complete inventory of
bits at the network ingress and egress point will reveal all of this
information.

Put more simply, everything that QUIC conceals from the network can be
ruled out as a cause of the network’s treatment of a packet.

*Nits:*
Section 1
p.2. para 1. comma after RFC 8548.

p.3, para 2. s/This include/This includes

p 3 para 2. "observe a specific information" - remove 'a'

p 3 para 2. "whether it is intended that a network device can
   modify the field, whether the devices are able to modify that field;" is
this accidentally repeated?

Sec 2.1. Para 3. “Header compression depends [on] understanding

Please add an informational reference for TCP fast Open.

Sec 2.3 s/transport headers fields/transport header fields

Sec 3.1.1 1st para: "Denial of Service, DOS, prevention." (?)

Sec 3.2, p.20 : s/easy to manage, a device/easy to manage, but a device

Martin