IETF Logo Mail Archive

Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt

Joseph Touch <touch@strayalpha.com> Sat, 29 February 2020 04:15 UTC

Return-Path: <touch@strayalpha.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 4B2F33A0B2C for <tsvwg@ietfa.amsl.com>; Fri, 28 Feb 2020 20:15:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.318
X-Spam-Level:
X-Spam-Status: No, score=-1.318 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 OIkuUQdTb094 for <tsvwg@ietfa.amsl.com>; Fri, 28 Feb 2020 20:15:12 -0800 (PST)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (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 3CFA83A0B27 for <tsvwg@ietf.org>; Fri, 28 Feb 2020 20:15:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=0NvpJA5qQa/hZGwpjjzab6ra6m881HP8ot8AAQsYnV8=; b=ktnSLvSpVBdNOu/Zj9T/ilEfC YJIUYVOtwo5813vqkXVdAHejpLNCK8em7ZEVKpzKbHb5Z+OFwKQbt7FNuvv4PHAJer8ZtC6V56RJ4 OVtZIJIHHKRLgfDPA3irJkAYBofnbugKr+H/gnQ1C/3MNpuNRXDnGPrx/awQtdTE6iEbYH4y+z1YG dR5rTxYOkqQML2b6yIZIUvWvWpofhSq02LVPnLGIz51T+ANk3Hl2SAU1UUj2Ur+o/AMAx6ZJKhpdC 93Mi34wTCFkwJUROLsjdxzT1VwujOTS36kdnLEfY/04RQZvDLowqvgV3h+lhwmuljv8qwYQMtqX2e dLn5MmzMQ==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:59926 helo=[192.168.1.10]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <touch@strayalpha.com>) id 1j7tWt-0036Fm-16; Fri, 28 Feb 2020 23:15:11 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_055FA85A-2086-43E6-BA13-83F276FBA876"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <CAMGpriWGREvyvimycP0FrT5BM2r1q3uaGSDC6L+QQ8wVS4_RCw@mail.gmail.com>
Date: Fri, 28 Feb 2020 20:15:06 -0800
Cc: "C. M. Heard" <heard@pobox.com>, tsvwg <tsvwg@ietf.org>
Message-Id: <C4386F14-4F73-4785-AE39-C5FF8A927ABE@strayalpha.com>
References: <CALx6S37iBDc7KxOL60=HC_QkWH06-5MU2rqrK=w+mqiKkSdc0w@mail.gmail.com> <CAKKJt-cznw56bimFtqt5Z1Wg_vOKy=id-uD5BWurHDYSQzuPRw@mail.gmail.com> <CAMGpriXDBWxwEXCwqPXX+QPhtQ0Z5NeVMEiEEQRjudR3ZZXW6g@mail.gmail.com> <CALx6S37XFh7Ph2oBjfsiYu0gq=a7yAD+zWHPi5fGHY6T94N-bg@mail.gmail.com> <CACL_3VEM1rbNMRtFn2MBXorqcOAiNXR2xWaOHQDZhm=tin3CEA@mail.gmail.com> <CAMGpriWGREvyvimycP0FrT5BM2r1q3uaGSDC6L+QQ8wVS4_RCw@mail.gmail.com>
To: Erik Kline <ek.ietf@gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/PEQu89bvjjNueKniw--HkA6X03g>
Subject: Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt
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: Sat, 29 Feb 2020 04:15:15 -0000


> On Feb 28, 2020, at 7:27 PM, Erik Kline <ek.ietf@gmail.com> wrote:
> 
> 
> 
> On Fri, Feb 28, 2020 at 6:06 PM C. M. Heard <heard@pobox.com <mailto:heard@pobox.com>> wrote:
> On Fri, Feb 28, 2020 at 4:18 PM Tom Herbert <tom@herbertland.com <mailto:tom@herbertland.com>> wrote:
> On Fri, Feb 28, 2020, 4:10 PM Erik Kline <ek.ietf@gmail.com <mailto:ek.ietf@gmail.com>> wrote:
> It also seems possible that some UDP options (https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options <https://tools.ietf.org/html/draft-ietf-tsvwg-udp-options>) might come along that could help things like QUIC effectively have a path-modifiable portion that (a) isn't a HbH extension header and (b) isn't covered by something cryptographic that would break if it were modified in-flight.
> 
> "things like QUIC" would mean protocols encapsulated in UDP. The point of HBH is that it works transparently for _all_ transport protocols whether they are encrypted. Besides, UDP options hasn't yet been proven deployable, so good chance it would just be trading one set of problems for another...
> 
> Also, UDP options as specified in the current WG draft are not intended to be modifiable in flight:
> 
>    >> Options MUST NOT be modified in transit. This includes those
>    already defined as well as new options. New options MUST NOT require
>    or intend optionally for modification of any UDP options, including
>    their new areas, in transit.
> 
> I find that a little sad, actually.  I would expect UDP MSS clamping to be a thing (in the absence of an AH it should be fine).

As discussed on the UDP options draft, the option is more relevant to signal end host reassembly limits, which are not affected by the effects of on-path tunnels.

(That’s actually how MSS is defined for TCP as well, FWIW; the fact that it’s used for something else seems to be an error that hasn’t been consistently noted).

Joe

v2.23.0 | Report a Bug | By Email