Hi SM, Thanks for your additional comments, inline. On Tue, Nov 14, 2017 at 1:12 PM, S Moonesamy <sm+ietf@xxxxxxxxxxxx> wrote: > Hi Kathleen, > At 09:54 PM 12-11-2017, Kathleen Moriarty wrote: >> >> 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. > > > Thanks for that comment. > >> 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? > > > Sorry for not being clear. The draft states that "NULL Authentication with > IPsec" has been implemented and deployed. Given that it is a practice, is > it a good idea? That was my point. The document is length as it is. I > don't think that adding more text would make it better. We have tried not to comment on what's a good idea or not in the document, so I'd rather not start. If you have read something that sounds like we have, please let us know and we'll make sure to edit to just document the practice. Text is always welcome with such suggestions. > > Stepping back, I'd say that the authors should decide what the document is > about. Is it about documenting what is in use by operators? Is it a > discussion of the practices? Is it about telling the reader what the IETF > recommends? Just the first and that's stated in the document introduction and abstract. > >> > 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? > > > There was a news article in the Washington Post about such an issue. From > what I recall, it was considered as a security issue. I suggest looking at > this from a security perspective. Fair point, deploying encryption assists with confidentiality and integrity and isn't necessarily in regard to privacy. Thanks for highlighting this text. NEW: "This and other increases in the use of encryption had the immediate effect of providing confidentiality and intergity for protected data, but created a problem for some network management functions." > >> 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. > > > The text which led me to the question is the second paragraph in Section > 2.1.2. The DPI specification (Y.2770) references RFC 3871; it's related to > logging capabilities (please see the paragraph quoted above). DPI is about > inspecting the traffic (including content) passing through the network. The > primary function of the DPI device is not troubleshooting. Nowadays, the > function is supposed to be DLP. > > Why does an encrypted stream prevent the the network from being excluded as > "the problem"? If I understood the arguments in that section, the IETF > might as well recommend "cleartext" to make "the internet work better". We'll have to look at this a bit closer, thank you for pointing out the section that led you to that conclusion. We'll work on it. > >> > 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. > > > I don't understand why the document is discussing about spam. Anyway, > STARTTLS does not have any effect on spam filtering. The sentence, as > written, sounds like: in theory, STARTTLS has zero effect ... This was requested by the sponsoring AD at the time in his review. It seemed like a reasonable addition to state that there is no impact in this instance, so we added it. > > The last paragraph in Section 3.2.2 gets into "user-to-user encryption" and > provides a reference to a vendor. What does that have to do with the > heading for that section? Are you referring to DarkMail as a vendor? It seems they are a technical alliance and had presented at SAAG a few years back. user-to-user encryption will impact any mail service and could make them irrelevant depending on the parts of the message encrypted. There have been discussions about encrypting the header of mail in addition to the body. This was in earlier versions of the draft, but I think got cut. Do you think additional text is needed here? > >> 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. > > > I read RFC 7258 and the draft once again. Thanks for taking the time to do that and for your review and comments. > > Regards, > S. Moonesamy -- Best regards, Kathleen