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

Behcet Sarikaya <sarikaya2012@gmail.com> Wed, 01 July 2020 20:33 UTC

Return-Path: <sarikaya2012@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 288753A0D41; Wed, 1 Jul 2020 13:33:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.847
X-Spam-Level:
X-Spam-Status: No, score=-1.847 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_ENVFROM_END_DIGIT=0.25, 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 bhpxuGgxvDqB; Wed, 1 Jul 2020 13:33:27 -0700 (PDT)
Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) (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 976C23A0D3F; Wed, 1 Jul 2020 13:33:27 -0700 (PDT)
Received: by mail-yb1-xb33.google.com with SMTP id e197so8592538yba.5; Wed, 01 Jul 2020 13:33:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=FzkA0YeePX3Sc0YD/6msNCy577TqplZnpWOJfvjYMMI=; b=M3qefjN7MuLs+0txrjDlw71iskx7sumy+BQQ/KelPykSMWr8GN58ALC3Es77TqrFIw vSnt2V52u/hyp/sB6S7MVsM44eh9IrNszGkpKGQ549kstEpOIj9y51ZiadHeiy9XE/Ob HgDRxVFRh0XMCkXrxaqpf2s+z55QihdIj8YsUvk+1rDhtHNpSqTL8/OHTkunlfA4DB9c vVx8wKx4VQ1lFDyQD9XG9I66P1U5rK82uHKORnD/gZJ9sMitTDMbsXi6pM9xdv9uGAVZ EHFE70K8ZCfBsk6iimK8tGI9zf7yETAenzsQR2/SOaJNO40wcdhjpbgeYKWmXixK0urp w0ig==
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:reply-to :from:date:message-id:subject:to:cc; bh=FzkA0YeePX3Sc0YD/6msNCy577TqplZnpWOJfvjYMMI=; b=WyErZgOqLjD0+WT0wjXWGFfLLteY1A+++gs73GfqUf+Ino4Q4GVVDKp6XTJ7MT28nW WuI4OmkzChVt5e8x799oF+A1VxL4cp48r0RYFXNxHaoWPCqO1c8Nj5+yVTeSU+zV0/XF FK2pfUODjXsGi+rPPEyKrS1T9GGVyr9MhQLaJtK+6/J9C1RyFzPbG9DVkkE96DVrt+5L dSYXkLZqr1shUg6Qe4/X1T8Ap0NHwC0ndwsXSDZ6YL9Sbe043N0b8sFbrYQugXfSGIsf 7N1xhke4y8Vy8f34l8Q21CfjWCmoULP+YGrvjveJztNNflsObNedUBO+rcHQHb70pPqF fYtQ==
X-Gm-Message-State: AOAM531RVU2CQQAHAK0GY9Nfi1HDS/yNVzbAC2D02E15VNUhS2ZhCM+K b6XUsWeiE7jF/egn87mkiDysAEFBwiSgN8gYAq8=
X-Google-Smtp-Source: ABdhPJz4aNTcWofgb0WmJyO/2Ue2xDjlRYjFbrzoH2JKAU6USpuuHw146YgtmazEwtrnwTv/Vv/+i/OhfXuIwr3Ns78=
X-Received: by 2002:a25:3bca:: with SMTP id i193mr42390533yba.327.1593635606769; Wed, 01 Jul 2020 13:33:26 -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> <CAJU8_nXR_FOhNrSatf_pHke7QRrzGjEKjeFvUAeH9ijgLzJnpw@mail.gmail.com> <FRAPR01MB04015215AF32FC06B8A7184BD16C0@FRAPR01MB0401.DEUPRD01.PROD.OUTLOOK.DE> <CD43CB69-5F96-4E4A-950F-0E5BD2B5EAC8@strayalpha.com>
In-Reply-To: <CD43CB69-5F96-4E4A-950F-0E5BD2B5EAC8@strayalpha.com>
Reply-To: sarikaya@ieee.org
From: Behcet Sarikaya <sarikaya2012@gmail.com>
Date: Wed, 1 Jul 2020 15:33:15 -0500
Message-ID: <CAC8QAccWhiYAJTq2SZ7Aa3XoRK5P7A35YxycSvdL+mFCZJOnRg@mail.gmail.com>
To: Joseph Touch <touch@strayalpha.com>
Cc: "<Dirk.von-Hugo@telekom.de>" <Dirk.von-Hugo@telekom.de>, Internet Area <int-area@ietf.org>, tsvwg@ietf.org, saag@ietf.org
Content-Type: multipart/alternative; boundary="0000000000003e36a805a9673480"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsvwg/KcBlFVsKKdH4hJMgle2rgFbyZ6Y>
Subject: Re: [tsvwg] [saag] [Int-area] 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 20:33:30 -0000

+1

I think it is a good draft, out of very hard work, a lot of sweat.

Behcet

On Wed, Jul 1, 2020 at 10:10 AM Joseph Touch <touch@strayalpha.com> wrote:

> -1
>
> Although it’s understandable to describe “what operators do”, the IETF
> isn’t a news service. We typically summarize these behaviors to take a
> position on them.
>
> The draft provides a good description of the tradeoff between the privacy
> rights of endpoints and the rights of operators and the impact of both on
> protocol design on that tradeoff.
>
> What I seem to be seeing is increasing “rough consensus” that the summary
> position should be closer to endpoint privacy than in the current form.
>
> Although I don’t feel strongly that the text absolutely needs revision in
> that direction, I would oppose changes to relax or shift in the other
> direct.
>
> Joe
>
> On Jul 1, 2020, at 7:11 AM, Dirk.von-Hugo@telekom.de wrote:
>
> +1
> Thanks, Kyle!
> Kind regards
> Dirk
>
> *From:* Int-area <int-area-bounces@ietf.org> *On Behalf Of *Kyle Rose
> *Sent:* Mittwoch, 1. Juli 2020 15:57
> *To:* Hannes Tschofenig <Hannes.Tschofenig@arm.com>
> *Cc:* int-area <int-area@ietf.org>rg>; tsvwg@ietf.org; IETF SAAG <
> saag@ietf.org>
> *Subject:* Re: [Int-area] [saag] 3rd WGLC (limited-scope):
> draft-ietf-tsvwg-transport-encrypt-15, closes 29 June 2020
>
> 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
> _______________________________________________
> Int-area mailing list
> Int-area@ietf.org
> https://www.ietf.org/mailman/listinfo/int-area
>
>
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag
>