On Sun, Nov 12, 2017 at 09:02:04PM +0800, Paul Wouters wrote:
>
>
> I concur with most of Stephane’s comments. And I find the use of the term “pervasive encryption” very problematic. Pervasive means:
>
> “(especially of an unwelcome influence or physical effect) spreading widely throughout an area or a group of people.”
>
> More encryption is never unwelcome to the enduser.
As the originator of the "pervasive encryption" term, I suppose I am obligated
to respond. Though first I must note that absolute statements such as
"is never unwelcome" are risky positions to take, seeing as they are
undermined by even a single counterexample.
The idea for the "pervasive encryption" phrase stems from the use of
widespread encryption as a countermeasure against pervasive monitoring.
The somewhat negative ("unwelcome") connotation is not a primary motivator
for the use of the term, but does provide a secondary effect of making the
reader consider whether seeking ubiquitous encryption might have some downsides.
Alternatives such as "ubiquitous" or "widespread" encryption were not necessarily
appropriate, given that they could be seen as making claims about a current
state of affairs that would not be borne out by the facts.
I do not claim to have a solid, concrete, answer to the question of whether
there are downsides to seeking ever-increasing levels of encryption, but
am willing to admit the possibility of at least some localized downsides.
That said, please do not take my statements as an endorsement of the
current document overall.
> If this document listed these practises, along with valid methods for operators to switch to, i could be convinced the document is useful. But as Stephane pointed out, a lot of these problems are desired features. That the operator has less networking debugging tools is an unavoidable side effect, but should not be used as an argument against more encryption.
>
> But in its current form, it seems this document would be prime candidate for operator misbehaviour justification “sanctioned” by the IETF.
>
> Note that I _do_ believe in the authors’ good intention of just documenting the new problems operators face. But the IETF will have taken these issues into consideration already before it published the RFCs.
I do sympathize with your concerns here.
-Ben
> This documents feels (unintentionally) that we need to go back to be drawing board to reconsider these operator issues.