SM, thanks for your review of this draft. On Sun, Nov 12, 2017 at 4:43 PM, S Moonesamy <sm+ietf@xxxxxxxxxxxx> wrote: > Hello, > At 06:06 AM 06-11-2017, The IESG wrote: >> >> The IESG has received a request from an individual submitter to consider >> the >> following document: - 'Effect of Pervasive Encryption on Operators' >> <draft-mm-wg-effect-encrypt-13.txt> as Informational RFC >> >> The IESG plans to make a decision in the next few weeks, and solicits >> final >> comments on this action. Please send substantive comments to the >> ietf@xxxxxxxx mailing lists by 2017-12-04. Exceptionally, comments may be > > > On reading the draft, I wondered whether the authors of the draft have an > opinion about "responsible encryption". The authors are concerned with user privacy and obstacles to deploying encryption. If the obstacles are not documented and discussed, adoption of encryption could suffer. There is a statement in the introduction about operators being interested to protect end user privacy and this has been repeated by a number of contributing operators. The desire to document the impacts to their current operations is a positive one as they need help to figure out if there are other ways to achieve the goal of the described functions in new ways or if it just won't be possible. > > In Section 1.1: > > "OS has been implemented as NULL Authentication with IPsec [RFC7619] > and there are a number of infrastructure use cases such as server > to server encryption, where this mode is deployed." > > It is possible to find use cases of deployment. That does not mean that it > is always a good idea. I'd be hesitant to add text that says it doesn't mean it's a good idea as that would feed into the assumptions being made in this thread that this draft is trying to prevent the deployment of encryption, when it is just the opposite. Unless you mean that there should be a statement that authenticated encryption is preferred? > > In Section 2: > > "This and other increases in the use of encryption had the immediate > effect of helping protect the privacy of users' data, but created a > problem for some network management functions." > > Is this about privacy or is it about a security loophole? That could depend on the content of data exposed. Are you suggesting a text change? > > In Section 2.1.2: > > "The ability to identify the problem application's traffic is > important and deep packet inspection (DPI) is often used for > this purpose." > > Is debugging choppy video the main purpose of DPI? Why should perversive > surveillance software/hardware be used to debug application issues? If you break this sentence apart, the "import" part is the ability to identify problems in application traffic. Many applications do a poor job of logging, so DPI is sometimes used. A solution would be to improve logging and debugging in applications, which is suggested in the draft as an answer to many of the documented effects. I'm not sure I follow your second question or what text led you to the question? I read this sentence as saying it is one way it is done today, because it is not working to do this directly with debug information from the application. I read this as documenting what is done and it leads me to think that applications need to improve their debugging and logging capabilities. > > In Section 2.3: > > "These regulations include Lawful Intercept, adherence to Codes of > Practice on content filtering, and application of court order filters." > > Are the "Codes of Practices" part of regulations? Are there references to > those Codes of Practices? > > In Section 3.2.2: > > "STARTTLS ought have zero effect on anti-SPAM efforts for SMTP traffic." > > I doubt that STARTTLS cause any significant problem as the receiver has the > ability to inspect emails. So you agree with this statement? Or are you asking a question? If you could clarify, I would appreciate it. > > In Section 4.1.1: > > "detect and defend against Internet DDoS attacks, including both > volumetric and layer 7 attacks." > > Does the IETF use the OSI layer (re. layer 7)? > > As an overall comment, there are many uses of "many" in the document. I > read the entire document. I understand that the authors may have put a lot > of effort in this work. However, I preferred to reduce the effort as it was > a bit tedious to do a detailed review. The title of the document is "Effect > of Pervasive Encryption on Operators". Is this document about making the > case against RFC 7258? You may want to take another read of RFC7258. This is a early step in one of the stated goals of that document - to find a balance between protections and the ability to perform network management by documenting the impacts to serve as a start to that conversation. > > Regards, > S. Moonesamy -- Best regards, Kathleen