On Mon, Nov 13, 2017 at 12:40 AM, Kathleen Moriarty <kathleen.moriarty.ietf@xxxxxxxxx> wrote: > Hello, > > Thanks for your comments on the draft. We will respond to all > comments, but it may take time as it's a busy week and this message > seemed like one that I could respond to more quickly than the prior. > > On Sun, Nov 12, 2017 at 8:02 AM, Paul Wouters <paul@xxxxxxxxx> 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. > > Could you propose an alternate title? We used the term ubiquitous > previously, and it was changed in a prior IETF list discussion to the > current title. > >> >> 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. > > The purpose was to document the effects of increased encryption, not > to solve any of the problems. As the document states, there are cases > where the feature/function may just be eliminated with no way to > perform the desired feature (desired by some operators). If you don't > look at the impacts as a first step, they will be an impediment to the > adoption of E2E protocols and the evolution that is happening with TLS > 1.3 and QUIC for example. By opening up the conversation, and having > both sides look at the problems, we are more likely to achieve E2E in > deployment scenarios. Continuing an arms race is not effective - > rather stepping back to document impacts is a first step toward > removing obstacles to deployment for E2E. This was my understanding as well and seems like a very rational and healthy way of achieving the overall desires stated in RFC7258. Documenting the realities of production networks is needed. > > I thought this point was fairly clear in the introduction, so if it is > not and you have wording suggestions, please provide them. It seems clear to me. > >> >> But in its current form, it seems this document would be prime candidate for operator misbehaviour justification “sanctioned” by the IETF. > > The introduction makes it quite clear that it is not the case and > states the documented effects are not IETF sanctioned. > >> >> 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. > > Operators have responded very positively to this draft that has let > them open up the conversation, so I don't think the problems have been > looked at by the developers of protocols like TLS 1.3 and QUIC. > Operators were unaware of the changes. Now it's time to have the > discussions and see how we can work together so that deployment of e2e > encryption happens. Just because we release protocols does not ensure > their adoption. These are very important points. If we want to to see our efforts on E2E encryption realized, ensuring deployability is important. Ignoring the operator side of the equation (which effectively connects the user to the Internet) would seem like a problematic approach. If we want happy end users, then performance along with encryption (among other things) are needed (not one in exclusion of the others). The Internet is a complex place (with its massive collection of distinctive networks, users, and applications). Introducing changes is not a simple task and oversimplifying what we need to do to affect the right change will not equate to the end goals we want to achieve. The draft is documenting challenges we should consider as we conduct our work. I don't see how this is a problem. regards, Victor K