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

-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 <mailto:int-area-bounces@ietf.org>> On Behalf Of Kyle Rose
> Sent: Mittwoch, 1. Juli 2020 15:57
> To: Hannes Tschofenig <Hannes.Tschofenig@arm.com <mailto:Hannes.Tschofenig@arm.com>>
> Cc: int-area <int-area@ietf.org <mailto:int-area@ietf.org>>; tsvwg@ietf.org <mailto:tsvwg@ietf.org>; IETF SAAG <saag@ietf.org <mailto: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 <mailto: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 <mailto:Int-area@ietf.org>
> https://www.ietf.org/mailman/listinfo/int-area <https://www.ietf.org/mailman/listinfo/int-area>