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

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Wed, 25 March 2020 19:46 UTC

Return-Path: <spencerdawkins.ietf@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 126653A0A47 for <tsvwg@ietfa.amsl.com>; Wed, 25 Mar 2020 12:46:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, URIBL_BLOCKED=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 Cl3U0Hlqy-sN for <tsvwg@ietfa.amsl.com>; Wed, 25 Mar 2020 12:46:10 -0700 (PDT)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 44BA73A0A46 for <tsvwg@ietf.org>; Wed, 25 Mar 2020 12:46:09 -0700 (PDT)
Received: by mail-lj1-x22c.google.com with SMTP id w1so3871394ljh.5 for <tsvwg@ietf.org>; Wed, 25 Mar 2020 12:46:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=g7EJ2yV8j2Yyj7jTNniITVt4ve4jGt0G7aN9OC81Yls=; b=qZ8p3TeLC3a/nr23NXuW9gNJDkAgxOQfVsypW75j7No9mdfHad4GaweLMlIk4x9N/J GYkBTidv+LpkuzeG3I2J6Zo98zstiQtJogMuYUJfwYiM5t4EjdaFmarXNO6J98Ghy2ro kf+pjwkO+bxUfwHiJw0Syx23PzQIWtqMRPo1wrWIQddThx7MOlQh2YWxNGyAKbwg05LS U9qq402UeI+1Rxd73ZoptqaGIwVomS0lLi1tex+qZJiYwiK6IWFTV2K2AXuR4u3BwtQ9 /x76DU5fg9SoqRczX1/nTm//IlTE/LA/6kXt8KxQgOkFoJ6PMzyfHRM0a9FAJY0HstcN bLeA==
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; bh=g7EJ2yV8j2Yyj7jTNniITVt4ve4jGt0G7aN9OC81Yls=; b=FmGl9SrXoHWGb+xMtGVbOfLEqgLhQq9eJ31+xkwu1ZxYiMVEZ+R5FWUopnM6hHayxM svooKfnfA751jm0Hgo+ZHYtYS7khquv5FTJ7zE2Xiqq7+hdqRNXsBwwemXkPZXeVTTpO Zpyu/GCQZGAUQfGMQBD/2pktc9MnyzdruPcdSik49apeFIadl9+syQjXwHQqIqxUgvJs nKPQNN194a+/cUXUGTEKRhOtgklJ6QSluPUSj2nmq7R+JoaPbHDnsoOqn6po8azl0/iL krYBWPsXOQBC2wByYBjOu8c7x9sQVSwlX5auNGFIGpToVgd7C0GKPwKXITmWoUvnjb5o 5d+w==
X-Gm-Message-State: AGi0PubJ9Ls8wpZtF/Yexqzi2V8lmCItyh6sE7e1EOehweauOgvbOTjV 2fhIgW6u2FJnpW3AFTNq1uTFA0lcMznkYnoIUTs=
X-Google-Smtp-Source: APiQypKjT88GeZ70itY37WwDZW0etYdRXD4XVLYgyeG+x1XQxQ6481PXiikU4QA5MT5FszL/uozTn9Ki8ypWqdebRoE=
X-Received: by 2002:a05:651c:85:: with SMTP id 5mr3082047ljq.60.1585165565992; Wed, 25 Mar 2020 12:46:05 -0700 (PDT)
MIME-Version: 1.0
References: <CALx6S349SE2Ho0V2bJPSE7dh3+2f5Wiw1AofMke0RY4FwF=ebw@mail.gmail.com> <679FAA73-401E-499D-87CB-10F973E05DD6@strayalpha.com> <MN2PR19MB40455E00DB52880A38EB494C83F00@MN2PR19MB4045.namprd19.prod.outlook.com> <4FA8060E-C661-42FB-BCA1-43F32E5FA1F5@strayalpha.com> <MN2PR19MB40458C69C9C91C70AD889D3A83F10@MN2PR19MB4045.namprd19.prod.outlook.com> <CALx6S35J8K0bAmPp72svv+BuOKc1ZdrK_odfcJsPujmQz-iyyA@mail.gmail.com> <MN2PR19MB4045877E00DB58216A58A45883F10@MN2PR19MB4045.namprd19.prod.outlook.com> <CALx6S36eY1mv-US5sajO62wXGqPr=So3RJCedOT9rZU74Q2ZdQ@mail.gmail.com> <571ab190-858f-47f3-1ef4-883d3d1287b1@erg.abdn.ac.uk>
In-Reply-To: <571ab190-858f-47f3-1ef4-883d3d1287b1@erg.abdn.ac.uk>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Wed, 25 Mar 2020 14:45:40 -0500
Message-ID: <CAKKJt-fDSs_KaoQ9ZYA7Wndy-2n7un9tiHLZQsTjWj6Vahb5ZQ@mail.gmail.com>
To: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Cc: Tom Herbert <tom@herbertland.com>, "Black, David" <David.Black@dell.com>, tsvwg <tsvwg@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000078a17a05a1b31e76"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/9_1vFev_F4dE7Ko00LHhDaZooDM>
Subject: Re: [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: Wed, 25 Mar 2020 19:46:13 -0000

On Tue, Mar 24, 2020 at 11:43 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk>
wrote:

>
> On 24/03/2020 16:31, Tom Herbert wrote:
> > On Tue, Mar 24, 2020 at 9:17 AM Black, David <David.Black@dell.com>
> wrote:
> >> Dell Customer Communication - Confidential
> >>
> >> Tom,
> >>
> >> In 20/20 hindsight, I've clearly not fully understood your original
> comment.
> >>
> >> Could you propose specific text changes that would address it?
> >>
> > David,
> >
> > My original comment was that the following text in the draft is not
> > relevant for the reasons I mentioned. The change I suggest would be to
> > simply remove the paragraph:
> >
> > "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."
>
> Why do you think this is not a view held by some people?
>

I have some concern that one of the reasons
https://datatracker.ietf.org/doc/rfc8404/ and
https://datatracker.ietf.org/doc/rfc8462/ were such three-ring circuses was
because "view held by some people" was the criteria for opinions to be
included in the drafts. My hope for this draft was that it would be a
catalog of what unencrypted transport protocols were exposing, and not very
much more (and especially not including opinions about whether they should
be exposing it, or what the best way to expose it if the original transport
information was encrypted).

This discussion hasn't sunken into the depths that Last Call
for draft-mm-wg-effect-encrypt plumbed yet, but it certainly can.

Do The Right Thing, of course ...

Spencer


> This is a point that has been included in the draft for some
> considerable time, and consideration of incentives to lie has been a
> recurrent theme in understanding deployment stories. The present text
> simply notes this point, and then says it should be "considered".  The
> story of why TOS was extremely difficult to deploy outside of controlled
> environments is a nice example of this.
>
> This is part of a two-part construction. I see this point as balanced in
> the second part (which I assume you would agree with), and I chose this
> re-ordering so that the second point was mentioned last
>
> Gorry
>
> > Tom
> >
> >
> >> Thanks, --David
> >>
> >>> -----Original Message-----
> >>> From: Tom Herbert <tom@herbertland.com>
> >>> Sent: Monday, March 23, 2020 11:22 PM
> >>> To: Black, David
> >>> Cc: Joseph Touch; tsvwg
> >>> Subject: Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-13
> >>>
> >>>
> >>> [EXTERNAL EMAIL]
> >>>
> >>> On Mon, Mar 23, 2020 at 6:48 PM Black, David <David.Black@dell.com>
> >>> wrote:
> >>>>> That sounds like it’s leaning towards extortion - the kind we have
> now, in
> >>> which
> >>>>> “if you don’t let us see your ports and we don’t like them, we’ll
> block you”.
> >>>> That sounds like a networking version of turning Spinal Tap’s amps up
> to 11 ...
> >>>>
> >>>>
> >>>>
> >>>>> I’d lean the other way - that the network really shouldn’t be doing
> anything
> >>> based on information
> >>>>> gleaned from transports - explicitly given or not - because it only
> serves to
> >>> create mutual escalation of misinformation.
> >>>> ... and that looks like other end of the spectrum.
> >>>>
> >>>>
> >>>>
> >>>> What I had in mind was something more balanced about benefits to
> exposing
> >>> some information to the network that motivate endpoints and endpoint
> >>> implementers to do so ... where motivate is not intended to imply
> extortion-like
> >>> threats, and the benefits aren’t necessarily the network doing
> something
> >>> immediate based on the exposed information (there are several examples
> in
> >>> Section 2.3 of the draft).
> >>>>
> >>>>
> >>>> To be concrete, here’s one possible text change, based on taking out
> the
> >>> words that seems to be the focus of this discussion:
> >>>>
> >>>>
> >>>> OLD
> >>>>
> >>>>     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.
> >>>>
> >>>> NEW
> >>>>
> >>>>     o  On the one hand, protocols do not necessarily have an
> incentive to
> >>>>
> >>>>        expose information that is used by the protocol.  The incentive
> >>>>
> >>>>        to expose transport header information has to be considered
> when
> >>>>
> >>>>        proposing a method to do so.
> >>>>
> >>> David,
> >>>
> >>> That's changing the meaning of the text. The original text was making
> >>> a point that if transport layer information is exposed there needs to
> >>> be an incentive for the host to set the information honestly and
> >>> correctly. This is true, not just for transport layer information but
> >>> for everything the host tells the network. An obvious example is TOS
> >>> in IPv4-- left to their own devices everyone would just request the
> >>> highest level of service of traffic for all packets. So we need some
> >>> tangible incentive for user to be honest and correct. For instance,
> >>> TOS might have worked if the user were explicitly charged for the
> >>> higher level of service, but that would imply a contract between the
> >>> network and the host is established and a whole bunch of mechanisms
> >>> that require far more than just anonymously volunteering some
> >>> arbitrary amount of transport layer information.
> >>>
> >>> Tom
> >>>
> >>>>
> >>>> Which leaves room to argue that there is no incentive, or there is
> insufficient
> >>> incentive, or the risks outweigh the benefits, etc.
> >>>>
> >>>>
> >>>> Thanks, --David
> >>>>
> >>>>
> >>>>
> >>>> From: Joseph Touch <touch@strayalpha.com>
> >>>> Sent: Monday, March 23, 2020 7:08 PM
> >>>> To: Black, David
> >>>> Cc: Tom Herbert; tsvwg
> >>>> Subject: Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-13
> >>>>
> >>>>
> >>>>
> >>>> [EXTERNAL EMAIL]
> >>>>
> >>>>
> >>>>
> >>>> On Mar 23, 2020, at 3:19 PM, Black, David <David.Black@dell.com>
> wrote:
> >>>>
> >>>>
> >>>>
> >>>> [writing as draft shepherd]
> >>>>
> >>>>
> >>>>
> >>>> Point taken – would it be reasonable to rework that paragraph to
> observe
> >>> that there should be incentives for endpoints to expose transport
> information,
> >>> e.g., otherwise implementers may simply not bother?
> >>>>
> >>>>
> >>>> That sounds like it’s leaning towards extortion - the kind we have
> now, in
> >>> which “if you don’t let us see your ports and we don’t like them,
> we’ll block
> >>> you”.
> >>>>
> >>>>
> >>>> I’d lean the other way - that the network really shouldn’t be doing
> anything
> >>> based on information gleaned from transports - explicitly given or not
> -
> >>> because it only serves to create mutual escalation of misinformation.
> >>>>
> >>>>
> >>>> Joe
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Thanks, --David
> >>>>
> >>>>
> >>>>
> >>>> From: tsvwg <tsvwg-bounces@ietf.org> On Behalf Of Joseph Touch
> >>>> Sent: Monday, March 23, 2020 11:20 AM
> >>>> To: Tom Herbert
> >>>> Cc: tsvwg
> >>>> Subject: Re: [tsvwg] Comment on draft-ietf-tsvwg-transport-encrypt-13
> >>>>
> >>>>
> >>>>
> >>>> [EXTERNAL EMAIL]
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Mar 23, 2020, at 7:58 AM, Tom Herbert <tom@herbertland.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>> 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.
> >>>>
> >>>>
> >>>>
> >>>> +1
> >>>>
> >>>>
> >>>>
> >>>> Another point worth mentioning:
> >>>>
> >>>>
> >>>>
> >>>> - if endpoints can lie or mislead about transport info to get their
> way, they
> >>> can, will, and IMO *SHOULD*.
> >>>>
> >>>>
> >>>> That goes for using port 53 for nearly anything anyone wants to.
> Transport
> >>> info isn’t there to make things nice for network operators - that’s
> what the
> >>> network layer is for.
> >>>>
> >>>>
> >>>> Oh, yeah, I know - network operators don’t want “heavy” stuff in
> *their*
> >>> headers because it slows them down when they don’t want it. Too bad,
> IMO. If
> >>> they want the info, they need to deal with the pain.
> >>>>
> >>>>
> >>>> Joe
> >>>>
> >>>>
>
>