Re: [tsvwg] [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020

Kyle Rose <krose@krose.org> Wed, 01 July 2020 13:57 UTC

Return-Path: <krose@krose.org>
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 CB26E3A0BA6 for <tsvwg@ietfa.amsl.com>; Wed, 1 Jul 2020 06:57:42 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.org
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 8jF1is8HKsOO for <tsvwg@ietfa.amsl.com>; Wed, 1 Jul 2020 06:57:40 -0700 (PDT)
Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (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 C70643A0BC4 for <tsvwg@ietf.org>; Wed, 1 Jul 2020 06:57:39 -0700 (PDT)
Received: by mail-ua1-x933.google.com with SMTP id g14so7728241ual.11 for <tsvwg@ietf.org>; Wed, 01 Jul 2020 06:57:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=d5sewHoVOc/a2tOp9qDeMoczKwl/q1FM8/0GEPwNCzA=; b=FjIpy42qrnTUwfwjrqswzd+eBOz1Qz7B1ClFJZmQjhN8XMGBAlOh1kZ1Of0SJaRLf0 LoFRAdeO5gGTGKi8Vefi1pCt7xYuD+j9TdjiJn+62k4r3ORkd78nz5mTBblK+IK69T/3 v+fDGuEH/c59MhL5brw/JM3sQBotFAFrB/bJQ=
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=d5sewHoVOc/a2tOp9qDeMoczKwl/q1FM8/0GEPwNCzA=; b=StJs3h1CzaIHqVcN8rpcrFrpyGO+DKbePIb7cqzY0vxLe4afrolYxzYcD/CIB1uC/p nj1ZudTF2A3CnoU7c8FJWKDdpKyarPvenwq242XdG0wqBf0P/uZl5WazqCssK3Ht0ksF cFGxYL72O+QKTdgDtFFe1FmmpACdu/TOXq8boMrByT5FC2YNURP9zcaJnWQ2dlnYDh1Y h4AVVuX08fYB/DtTd3sliVWkTgXrtvabzMpb4MacCKc9E5zO+/WcHC9I+nHKIwizKYDh yDKbXAxjm4+AOTTIay/s6FtNVlQVAvNYUtttAYnT2MySaCaMmqXvRQaco74mGH1SKMMF +F6A==
X-Gm-Message-State: AOAM532jXbi/mAoWamn1Rk/zaRmaHEeqVNUdIf2YANTwX5v+mYRxSsV+ jFmGjv6Q9hpu9qr1a8OxEDjZqvJiFsu5KeXFGTINEQ==
X-Google-Smtp-Source: ABdhPJysicxq5idDc9dpr2qRJFugvhELlC2eaja6zyqGcnNsqYhd/kMXtlIX0MXJ6Zsxjwm4NTQMjlLXnu7dwD+YtAU=
X-Received: by 2002:ab0:65c7:: with SMTP id n7mr18874872uaq.30.1593611858816; Wed, 01 Jul 2020 06:57:38 -0700 (PDT)
MIME-Version: 1.0
References: <MN2PR19MB40450EE357BEECD723AB06F183820@MN2PR19MB4045.namprd19.prod.outlook.com> <CABcZeBM9A1RxOiHGZdBznTb7zzArG5GTQs=bhNtBy90tSXs3Pg@mail.gmail.com> <AM0PR08MB3716528B48BCF9447002B551FA6F0@AM0PR08MB3716.eurprd08.prod.outlook.com> <21886_1593608278_5EFC8856_21886_470_1_787AE7BB302AE849A7480A190F8B9330314EBA5C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <AM0PR08MB371604E04179C212341100EEFA6C0@AM0PR08MB3716.eurprd08.prod.outlook.com>
In-Reply-To: <AM0PR08MB371604E04179C212341100EEFA6C0@AM0PR08MB3716.eurprd08.prod.outlook.com>
From: Kyle Rose <krose@krose.org>
Date: Wed, 1 Jul 2020 09:57:27 -0400
Message-ID: <CAJU8_nXR_FOhNrSatf_pHke7QRrzGjEKjeFvUAeH9ijgLzJnpw@mail.gmail.com>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Cc: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "Black, David" <David.Black@dell.com>, int-area <int-area@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>, IETF SAAG <saag@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c1479605a961ac89"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/Wit_xaIQr0jh2Lz7cZUETfDLAi8>
Subject: Re: [tsvwg] [saag] 3rd WGLC (limited-scope): draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020
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, 01 Jul 2020 13:57:51 -0000

On Wed, Jul 1, 2020 at 9:20 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com>
wrote:

> I noticed this in various IETF discussions and so I will describe it in
> the abstract.
>
>
>
> A group of people propose an idea. Those who do not like the idea are then
> asked to convince the original contributors that their idea is not sound or
> contribute text so make it look nicer.
>
> Not only is this requiring me to spend my time on something I don’t agree
> with but it turns out that no discussions will change the mind of the
> original contributors. They just strongly believe in their ideas. They will
> keep proposing the same idea over and over again (for years) till it gets
> published as an RFC.
>

I don't understand why so many are opposed to publishing a document that
merely describes how operators manage protocols in the absence of header
encryption, and how header encryption interferes with those practices. That
is, at least, in its original form, before this WG decided it needed to
incorporate pro-encryption advocacy, greatly complicating the document and
the resulting analysis.

For the OG version, I ask myself the following questions:

Does the document describe reality? Yes: it tells us what practices
operators employ today.
Is the document useful? Yes: see above, plus it makes clear that there will
be an impact to operators and/or protocol users from this evolution.
Does the document establish an IETF position on encryption? No. There are
plenty of other published RFCs that embody the spirit "encrypt all the
things". This document does not change that.
Does the document make normative statements about future protocol
development? No.

On what basis would I therefore oppose publication?

I may or may not have opinions about prioritization of user privacy over
manageability, the tussle between manageability and deployability, and what
alternatives are available to operators for managing protocols with
encrypted headers. I would be happy to help express those in a follow-on
document. But this document describing where those conflicts lie is a
*prerequisite* to developing those alternatives. And frankly those opinions
are irrelevant to the intended content of *this* document.

Kyle