Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt

Tom Herbert <tom@herbertland.com> Mon, 04 November 2019 18:34 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 7AE69120112 for <tsvwg@ietfa.amsl.com>; Mon, 4 Nov 2019 10:34:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, 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 L-HDOCZveryJ for <tsvwg@ietfa.amsl.com>; Mon, 4 Nov 2019 10:34:43 -0800 (PST)
Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) (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 AD1F3120044 for <tsvwg@ietf.org>; Mon, 4 Nov 2019 10:34:42 -0800 (PST)
Received: by mail-ed1-x536.google.com with SMTP id m13so7634209edv.9 for <tsvwg@ietf.org>; Mon, 04 Nov 2019 10:34:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xZOp6dkrLqeNUuUJxc1F5y/4QXrTINhSYiWOLsB/zf4=; b=yK5NrsmO/G4rKx0duMXevJbRR3oE0ba/YzAY+o/ieQ4klglq6FhjagS/YMHEFYKfCL tz2kfeCNwbgeRopUoF1FHwj4guBJ50F2B+eYsuAwCXGmI8KXs1YquM+AG3QIh3TpAFSZ Z7HXUNN1Gr6kW2+hp2Qo9u1z1eqArtA6o6rncjSDTLoFNZXCeWNmFsXWQrGvq8oNEx3t hMETopCtCUQu8EYDkZKC+g5hMgtf4tx5tJ5IFk4NPav3vEiOI7SPluGrbSnqiWvCoIXg q2/BUiWc63nyVKF+jH4v0PYWYnk3DKi/TDYbHQNPOTGhUCX/Iu8s18sSXd5R3J3RJldQ 0Svg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xZOp6dkrLqeNUuUJxc1F5y/4QXrTINhSYiWOLsB/zf4=; b=nFFRNztg/jM6xVj12qNDPP+3kL6ucl/wMymBp7mIEivEJFX+Rmtb/S5qO2N22sPAbx kx6mgmeRGlmCEciVayDCqPlubnC9MCzTOwlBwaGstcE2mm02eOQYjBFcmGK0NasmKQ58 UNx1jjWSAUBIr5uWhwIm2BEidjdUUtdUWJPkObpIfuChiRdTnaGXZ2NhvFNjaYLs6XR0 f6yzzuQr4ghrqHyZb6CBrmu0DpJhkYn9JyWYqzp1WvkXyPHJC91zvBnI8Lj+S4pWJtAN RjNeYJ3xzvvQSsMRXIVHsDsf03rSNWk9w/bylne0aPPlmphhdy4/SkiJxdkP9kwmSvfM LYPA==
X-Gm-Message-State: APjAAAVrZYpbkSBUrF9kJRAHYoLmHrFuE5zbBEU/0ro/UY9A4BUXRLBb Pyv1MPnAYtNgxi2BkvFT8JylFpCLrH6GQaXLP8rmCA==
X-Google-Smtp-Source: APXvYqwLbyGn6egaToyCvHv5AONDrEUcCbvu1aGGS+vBX6TsR8sCBz6KXN9I09pFehKpf0gV2s7RtGQwkhyAVGfcJ6c=
X-Received: by 2002:a50:cd14:: with SMTP id z20mr30401342edi.226.1572892480852; Mon, 04 Nov 2019 10:34:40 -0800 (PST)
MIME-Version: 1.0
References: <CABcZeBPajzuEdw8=M1g1i-TAniJ9O+H5dEMxv8c6N3tD=7mSvw@mail.gmail.com> <CALx6S35bSAa_zq=HsF-3e9qC-vRNFRu6dn+O4ak4Hi+c=Tmz5A@mail.gmail.com> <79E407F2-13D8-4F64-9A42-ED6BF6141DE9@ericsson.com> <CABcZeBPfT=B+fOXAkPuoEQQHAtJrefXSgnjOpPC7-4zC_myRsA@mail.gmail.com> <D36061F0-F872-4054-ACF0-C9A88FCEC572@ericsson.com> <2d3c909f-b21c-3916-1eb9-db6de5c661e3@huitema.net> <5DC063F2.8040502@erg.abdn.ac.uk>
In-Reply-To: <5DC063F2.8040502@erg.abdn.ac.uk>
From: Tom Herbert <tom@herbertland.com>
Date: Mon, 4 Nov 2019 10:34:29 -0800
Message-ID: <CALx6S36E4wRc8d0BHdybWdWgOxAzPH7avHiZhjyyjNtV3NN1sA@mail.gmail.com>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Cc: Christian Huitema <huitema@huitema.net>, "saag@ietf.org" <saag@ietf.org>, Mirja Kuehlewind <mirja.kuehlewind=40ericsson.com@dmarc.ietf.org>, tsvwg IETF list <tsvwg@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/x_wCBoCp2kQBgr7S9JJ0CsX9Hd4>
Subject: Re: [tsvwg] [saag] Comments on draft-ietf-tsvwg-transport-encrypt-08.txt
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, 04 Nov 2019 18:34:44 -0000

On Mon, Nov 4, 2019 at 9:47 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
>
> Just focussing on the end...
>
> On 04/11/2019, 16:29, Christian Huitema wrote:
> >>
> >> [MK] That’s not the intention here. But we also need to consider ways
> >> to interact with the network where this brings benefit to both the
> >> network and the performance of the end-to-end traffic. There are
> >> situation where this is the case. And I don’t think one makes sense
> >> without the other.
> >>
> > You seem to be arguing for something like "performance enhancing
> > proxies". End-to-end encryption is indeed a way to opt out of such
> > proxying. Measurements so far indicate that opting out has very little
> > impact on actual performance, and that whatever impact there is could
> > be reduced by improvements in end-to-end algorithms. In fact, in many
> > cases, end to end performance is better without such proxies. But the
> > real reason for the opposition to the concept is ossification.
> > Enabling such proxies would quickly ossify the new transports, and a
> > such there is a strong consensus in the end-to-end transport designers
> > to use encryption and prevent interference by such devices.
> >
> On PEPs: The current case for many of the network segments I see is that
> QUIC is quite good, but it is considerably worse (currently) than a PEP
> using Split-TCP. That's not to say it can't improve - but that's not
> true yet. However: It's curious that people keep going back to PEPs,
> because network devices that change the transport header were
> specifically out-of-scope for this ID!
> >
> > This does not mean that network level deployment have no role in the
> > future. I could see for example tunnels deployed that use FEC or local
> > retransmission to mask the poor performance of a particular subnet. Or
> > I could see end-to-end devices opting into some kinds of application
> > level caching services in order to improve performance. But the draft
> > should be clear: transport protocols do not have to enable
> > interference with the transport bits.
> >
> There are also many operators - e.g., enterprise who rely on the methods
> currently mentioned in this draft. In this case, they also actually *do*
> care about the performance of the networks they operate. They also do
> care about the topics, which matters most depends on which organisation.
> >

Gorry,

"Many" is not "all". And even if all operators cared about this, they
will be all over the board about what information they need. If the
draft were to say that items X, Y, and Z are needed to be exposed in
the transport layer then that might be something we can work with and
this would be a different conversation. But, I don't believe you'll
ever get agreement on that. This is _exactly_ the same quandy we got
into we asked the operators what information they needed out of
transport payload when discussing encrypting transport payloads.

So basically what we're left with is plain text transport layer
information _may_ be important for some use case and _may_ have
legitimate reason to be read in the network, but we _can't_ describe
the exact circumstances when the information is required, we _don't_
know what a priori what transport protocols the network can even parse
so it can extract the information, the set of required information is
_undefined_, and we _don't_ have a good assessment of what the
security and privacy risks are. Given this, I still don't see much of
an argument that transport developers shouldn't encrypt as much a
possible-- to me it's clear the benefits outweigh the cost.

> > My take is that this draft should not be published as is. It should be
> > rewritten to actually reflect the consensus of the transport area,
> > which has to reflect in particular the work in the QUIC working group.
> >
> I suspect the information you wish to see about QUIC's design is
> actually available. I'm not sure documenting QUIC is helpful here, if
> the QUIC WG wants to so that, can't it be added to the manageability draft?
>
> I dispute the claim that the entire transport area has the same
> priorities as that voiced at the QUIC WG. I think this discussion needs
> to look outside the QUIC working group and examine other transports and
> WGs. As far as I know the RTP people are still doing specs in the IETF,
> as are various other transport working groups. Also, this draft has been
> presented at OPsec, and has contributors from other areas outside
> transport...
>
> My assertion is that *current* practice is using transport header
> information & header authentication/encryption is becoming common, let's
> set out what the current facts are. I'm also going to oppose documenting
> new ideas for how we can go forward - as Spencer insisted when this was
> chartered: Proposing new methods belong in a different draft - paraphrased.
>
Then I suggest to remove any discussion along those lines including
the references to alternatives include the discussion about and the
inherently negative comments about their potential use.

Tom

> Gorry
>