I received a correction... Sent from my iPhone > On Apr 10, 2017, at 11:54 PM, Kathleen Moriarty <kathleen.moriarty.ietf@xxxxxxxxx> wrote: > > Hi Martin, > > We went through your comments one more time to make sure any > technical/substantive comments are addressed. Please see the > discussion inline. > > > On Mon, Apr 10, 2017 at 5:05 PM, Martin Thomson > <martin.thomson@xxxxxxxxx> wrote: >> I most certainly reviewed 09. I haven't reviewed the diff. I doubt that it >> would change my opinion on the macro - level problems. > > My mistake, I thought the acronym you corrected was in version 9. > >> >> On 8 Apr. 2017 3:34 am, "Kathleen Moriarty" >> <kathleen.moriarty.ietf@xxxxxxxxx> wrote: >> >> Hello Martin, >> >> Thanks for your review. It seems that you have read version 8 or >> earlier and not the current version, 9, from some of your suggestions >> that have been corrected already. Your review also reads to me that >> additional context setting may help, but please note that some context >> setting was improved in version 9. We re-arranged some of the >> sections per IESG review recommendations in the latest version as >> well. >> >> Perhaps you have additional language suggestions for context setting? >> >> The abstract states: >> >> Increased use of encryption impacts operations for security and >> network management causing a shift in how these functions are >> performed. In some cases, new methods to both monitor and protect >> data will evolve. In other cases, the ability to monitor and >> troubleshoot could be eliminated. This draft includes a collection >> of current security and network management functions that may be >> impacted by the shift to increased use of encryption. This draft >> does not attempt to solve these problems, but rather document the >> current state to assist in the development of alternate options to >> achieve the intended purpose of the documented practices. >> >> which is repeated again in the introduction, but slightly reworded. >> The introduction also includes statements on the existing publications >> related to encryption and I read them as not having any bias, but >> rather supporting the existing documents that also had consensus. >> >> A couple of comments and one question inline. >> >> On Thu, Apr 6, 2017 at 11:24 PM, Martin Thomson >> <martin.thomson@xxxxxxxxx> wrote: >>> Draft: draft-mm-wg-effect-encrypt-09 >>> Date: 2017-04-07 >>> >>> Overall >>> >>> This document is unfocused and unclear in its intent. It is filled with >>> unsubstantiated claims, misleading statements, bias, and implied >>> recommendations >>> for bad practices. I would oppose its publication in the current form. >>> Furthermore, I don't believe that small scale or editorial changes would >>> be >>> sufficient to correct these problems. >>> >>> >>> Aside from weakening its utility and/or arguments, the lack of focus will >>> allow >>> this document to be abused in various ways. For instance, it might imply >>> IETF >>> endorsement of the practices described in the document. Given that the >>> IETF has >>> published positions that in some cases reject these practices, this >>> document >>> needs to be very precise with its claims. In its current form, it is not >>> nearly >>> careful enough. > > This paragraph is all speculation about an unfortunate future. > We could speculate that the operator, security and app communities > come together to work out solutions after reading this doc, > which is part of our intent. > >>> >>> If this document is going to be published as an RFC, then it needs to be >>> very >>> clear about its intent and its position - or lack thereof - toward these >>> practices. It might be possible to say that these practices were employed >>> in >>> networks in the past and that encryption is reducing the viability of >>> those >>> practices. A value-neutral statement like that might be acceptable as >>> long as >>> it were framed carefully. > > The document conveys that message everywhere. The words contributed were > changed in many places to remove any implication that the current practices > are "requirements" or even "needs". > > The abstract and introduction contain value neutral statements like > what you are suggesting already. We actually say the practices may be > eliminated, going further than your request as that may be the case. > > The only change I could see in the abstract would be the following: > > Increased use of encryption impacts operations for security and > network management causing a shift in how these functions are > performed. In some cases, new methods to both monitor and protect > data will evolve. In other cases, the ability to monitor and > troubleshoot could be eliminated. This draft includes a collection > of current security and network management functions that may be > impacted by the shift to increased use of encryption and encryption > that is designed prevent interception. This draft > does not attempt to solve these problems, but rather document the > current state to assist in the development of alternate options to > achieve the intended purpose of the documented practices when possible. > > Do you have additional suggestions? Or is the phrasing read > differently than we intended by stating functions may be eliminated? > We thought that was very clear to your points. > >>> >>> What is problematic is the implicit argument that is presented. This >>> document >>> could easily be construed as the IETF legitimizing these practices. This >>> includes things on which the IETF has published statements (see for >>> example RFC >>> 2804). >> >> See the abstract and introduction and summary. >> >>> >>> This steps firmly into to sticky mess that is the politics of encryption >>> policy. >>> If the IETF is going to make a political statement with this document, >>> then that >>> statement needs to be a lot better than this. > > The intent of this document is to help operators as these changes > continue. It is to make sure we are not ignoring the impact of the > changes the IETF has with our decision (which are supported in this > document). This document is intended to assist operators. By > explaining the functions being performed, some have already been > provided alternate methods to achieve their goals. We have also > received quite a bit of positive feedback from operators - that this > document helped them come back to the discussion and to approach a > world with more encryption or sessions that can't be intercepted (TLS > 1.3, TCPinc, QUIC, etc.). > >>> >>> Furthermore, any statement needs to be consistent with previous >>> statements, >>> where in this case that primarily means RFC 7258. Right now it reads as >>> an >>> attempt to dilute RFC 7258. >> >> Not at all. > > It does not read that way to many people who strongly support RFC > 7258, including Stephen who was our sponsoring AD (and was for 7258). Stephen was the co-author. I should have checked that, but it was late when I hit send. Kathleen > Can you give specific sections where it sounds like we are weakening > RFC 7258 so we can change that specific wording? > >> >>> >>> If this document were more clearly formulated as an even-handed treatment >>> of >>> what happens today - without judgment - then it could be useful. Here the >>> model >>> of RFC 7754 is a good one. It describes the different facets of a use >>> case, >>> then the different practices that might be employed to achieve that goal. >>> For >>> each practice the pros, cons, and technical limitations are covered with >>> an eye >>> to all involved parties. >>> > > Version 8 to 9 had some edits to remove statements with used terms > like 'need'. We may have missed a couple, we'll check the ones you > pointed out. There are also numerous statements that are explicitly > in support of RFC7258. These are in the abstract, introduction, > summary and sprinkled throughout the document. > > Apparently, RFC 7754 goes further than our scope. We are not describing: > "... the different practices that might be employed to achieve that goal." > >>> >>> The Real Purpose of this Document >>> >>> I think that this is the real question that this document wants to ask is: >>> >>> In a world where we are forced to defend against pervasive monitoring >>> by >>> motivated and malicious actors, can we find a role for less pervasive >>> monitoring by well-intentioned entities? > > The document aims to help operators by giving them a chance to discuss > the impact. It opens the > door to conversation so they can find new ways to achieve the same > goals (better performance for customers for instance or monitoring > services that have been requested - web content, DLP), which may mean > endpoint solutions are needed or filtering limited to hostnames for > now until other mechanisms are developed (likely at the application > layer). > > For enterprises, application and host level solutions are > fine as many organizations have employees sign away their rights to > privacy. I would never check FaceBook from work for instance or > access any site of a personal nature. This is why we broke out the > sections by the type of network or SP, their options are different > with and without encryption. > > QUESTION: Would it help to add some text like the first paragraph into > the introduction? - This document aims to... > >>> >>> There is an interesting discussion to be had here, but I'm convinced after >>> my >>> review that this document is the wrong vehicle for that discussion. > > RFCs are the vehicles the IETF has found most useful in talking to the world. > >>> I'm >>> also >>> inclined to suggest that this is the wrong question to ask in the first >>> place. > > We can't ignore the problems resulting from the changes, we the IETF > make, to improve privacy and security. While we agree it is a positive > thing to improve these functions, we (the IETF) should also help with > the wake we > leave in our path. Otherwise, we can't expect people to play along > with the protocol specifications the IETF publishes. > > It's much more than an "interesting discussion" to many operators. > Some are required by law to use these practices to protect privacy. > > There are many questions to ask, some of which have already been > answered. For example, RFC 7258 asked 'How can we deal with > pervasive monitoring' and answered it through the same IETF > consensus process this document has already gone through. > >>> >>> To the extent that we have the tools necessary to protect against >>> pervasive >>> monitoring, we have to accept that more-legitimate uses of monitoring are >>> collateral. Mostly, that's just a function of the limitations of the >>> imperfect >>> tools we have. >>> >>> The value in this document is in the rather comprehensive collection of >>> use >>> cases. Sure, some we might not attribute much weight to, like >>> wiretapping. >>> Others are frankly frightening and not just in the Orwellian sense. >>> >>> The problems that are implied by the current practices of network >>> operators is a >>> large vein of unexplored work for the community. Spending effort on >>> finding >>> better solutions to legitimate problems is worthwhile. > > Right, so we started by documenting them *before* the collateral damage appears. > >>> >>> In other words, the right question might be: >>> >>> For each of these practices that we see today, are the use cases that >>> motivate them legitimate and how might be implement alternative >>> techniques >>> that properly respect privacy and security? >>> > > Yes, this is the point of the document and it's stated in several places. > >>> >>> Two- and Three- Party Interactions >>> >>> A great many sections of the document are unclear about the relationships >>> between different actors. It seems like many of the activities describe, >>> which >>> are presented here as being beneficial, are performed by a third party >>> without >>> the consent or involvement of the two communicating peers. After all, >>> those are >>> the cases where encryption most often interferes. >>> > > As the draft says, some of the methods will be eliminated. > >>> The assertion that some benefit is accrued to communicating peers as a >>> result of >>> these actions is the constant subject of the text. I observe that in most >>> of >>> the cases listed in this document, the benefit is accrued primarily to the >>> third >>> party. > > Operators by their nature have different privacy concerns than their end > users. Operators by their nature want to accrue benefits. This document > doesn't change the balance; instead, it tells them how to deal with privacy > that has already been applied. While we agree with your statement and think > it's important to build privacy and privacy options into IETF protocols, > operators often don't care, despite the many RFCs we have published > telling them that they should care. We still need to engage them so we can > have this discussion. > > The "third party" is likely the only one receiving a trouble call, > and there is benefit for all parties when the trouble is cleared. > >>> >>> Clarity around the arguments that the document makes with respect to >>> benefits to >>> each of the involved parties is sorely lacking. >>> >>> In addition to this, where benefits truly do accrue to communicating >>> peers, >>> technical options that don't rely on privacy-invasive techniques are >>> routinely >>> dismissed in an offhand fashion. In this way, any moral imprimatur >>> attributed >>> to the use case is used to justify the privacy-invasive method. >>> > > Without specific comments, the above are all subjective statements and > we have responded to them. > >>> >>> Document Structure >>> >>> This document is very hard to read (and review). Probably my biggest >>> complaint >>> is that the sections are haphazardly organized. They contain a mixture of >>> use >>> cases (what does SP X want to do) and techniques (how do they do these >>> things). >>> Material is duplicated between sections. Sections cover 10 different use >>> cases >>> while talking about techniques, then other sections talk about different >>> techniques whiles talking about a scenario. This leads to a lot of >>> repetition. >>> >>> There are three axes that this document contemplates: >>> >>> - the techniques that are currently used in networks >>> - the use cases that motivate these techniques >>> - the deployment scenarios in which these use cases manifest >>> >>> It would appear that the document attemps to start from the deployment >>> scenarios. However, this causes use cases and techniques to be mixed. >>> Judicious use of cross-referencing might have made this arrangement >>> tractable, >>> but there are virtually no cross references. >>> > > The above is stylistic in nature. We've already made changes to the > format to address specific comments in IESG review. A complete > re-write is not appropriate at this point in the draft lifecycle. > That's not the point of IESG review. > >>> >>> Section 1 >>> >>> I find the introduction of this document difficult to parse. I think that >>> what >>> it wants to say is pretty straightforward, but it manages this in quite an >>> obtuse way. Here's what I think that it is trying to say: >>> >>> 1. The IETF (and the larger community) has reacted to revelations of >>> pervasive >>> monitoring by increasing the use of encryption. >>> 2. That has been somewhat successful. >>> 3. More encryption has an impact on some practices that network operators >>> have >>> become accustomed to employing. >>> >>> Expressed in this way, you can see how you could make a value-neutral >>> statement. >>> >>> On the first, you can definitely make an argument based on the documents >>> that >>> the IETF have published. However, it is a mistake here in assuming that >>> the >>> IETF - or the revelations of global-scale surveillance - is directly >>> responsible >>> for the uptick in adoption of cryptographic protection for Internet >>> traffic. > > The abstract is value neutral right now. > > The increase or changes are not just about PM. We are making > TLS 1.3 so that it cannot be intercepted (I agree with this move of > course as we should make our protocols strong and adhere to > established IETF principles)? Or the efforts of TCPInc and > QUIC? We do directly affect the use of encryption and the types of > encryption that are deployed. We work with the vendor communities in > publishing deprecation drafts as well. All of these efforts got > additional energy from the PM work and that's a good thing. Events > trigger increases in security and it's fine to acknowledge that. The > introduction states: > > In response to pervasive monitoring revelations and the IETF > consensus that Pervasive Monitoring is an Attack [RFC7258], efforts > are underway to increase encryption of Internet traffic. Session > encryption helps to prevent both passive and active attacks on > transport protocols; > > We could change it to say: > > In response to pervasive monitoring revelations and the IETF > consensus that Pervasive Monitoring is an Attack [RFC7258], efforts > are underway to improve and increase encryption of Internet traffic. Session > encryption helps to prevent both passive and active attacks on > transport protocols; > > The second sentence mentions passive and active attacks here as that > hits on the prevention of active attacks - improving session > encryption protocols helps with this. > >>> This is something that the community as a whole has been working towards >>> for >>> many years; these trends predate the actions this draft focuses on. This >>> is >>> particularly true for the hosted provider cases in Section 3, where >>> business >>> motivations for protection are far stronger than any concerns over >>> government >>> surveillance. Yeah, that's a subjective view, but I'm just reviewing, I >>> don't >>> have to write a statement that will be labelled as having IETF consensus. > > Section 3 already makes this point very clear (full text for the intro > to that section): > > 3. Encryption in Hosting SP Environments > > Hosted environments have had varied requirements in the past for > encryption, with many businesses choosing to use these services > primarily for data and applications that are not business or privacy > sensitive. A shift prior to the revelations on surveillance/passive > monitoring began where businesses were asking for hosted environments > to provide higher levels of security so that additional applications > and service could be hosted externally. Businesses understanding the > threats of monitoring in hosted environments only increased that > pressure to provide more secure access and session encryption to > protect the management of hosted environments as well as for the data > and applications. > >>> >>> The immediate focus on opportunistic security is highly misleading, >>> especially >>> in the web case. The amount of opportunistically secured web traffic is >>> miniscule by global standards. Since Firefox is the only browser to >>> support OS >>> for the web, so adjust the following by market share: >>> <https://mzl.la/2oc46ch>. > > You'll need to cite text that is leading you to this conclusion as I > don't read it as being specific to OS, rather that OS is explained so > operators understand it in the mix of encryption options. > >>> >>> I understand that mail is more often opportunistically secured, and you >>> will >>> hear the virtues of OS sung from the rooftops, but all evidence suggests >>> that >>> this is just a transitory state. Instant messaging is closer to the web >>> case, >>> with the trend toward strong protections that include authentication. Of >>> course, I don't believe that mail or instant messaging represent any >>> significant >>> traffic volume, so you need to be very careful about the nature of the >>> claims >>> that are being made. It has to be that the volume of mail has to be a >>> rounding >>> error when it comes to capacity planning for networks. >>> >>> On the second point, when making claims about prevalence of encryption, I >>> would >>> advise caution when citing statistics. Here's the graph for the Mozilla >>> figures >>> that I think are being cited <https://mzl.la/2obZjrb>. Here's a different >>> graph >>> with a different number <https://mzl.la/2oc263J>. This highlights the >>> point >>> that statistics need to be carefully cited, because bare claims are >>> difficult to >>> assess. Methodology matters when it comes to these sorts of claims - are >>> we >>> talking proportions of packets, requests, flows, or something else? >>> Furthermore, the citations in the document are made more difficult to >>> assess by >>> being measured at very different times (where the two I cite here were >>> made at >>> roughly the same point in time). >> >> For the Mozilla statistics, Richard Barnes had reviewed the text after >> providing the statistic as he wanted to make sure it was stated >> clearly raising the same concerns you do about statistics. Do you >> have further text suggestions to clarify this statistic? >> > >> >>> >>> The statistics do support the notion that there is a significant amount of >>> encryption in use, but it would appear that the claim is that the amount >>> of >>> encryption is *increasing*. This is not an extraordinary claim, but no >>> evidence >>> is offered in support of the claim. It isn't a certain thing either. >>> From the >>> statistics that I have access to, there was a definite uptick in October >>> of >>> 2015, but the rate appears to be stable since then. >>> >>> It appears that the remainder of the document is intended to address the >>> third >>> of my points in some detail. That's a good structure in theory, but see >>> above. >>> >>> I don't think that the "service provider" taxonomy works for this >>> document. >>> Based solely on the structure of the document, the only service provider >>> that >>> this document concerns itself with is the one who forwards the packets. >>> That >>> application service providers are involved as one of the endpoints is >>> relevant >>> in some cases, but not all. For that reason, I prefer "network operator" >>> and to >>> use specific terms like "mail host" or "web server" as appropriate to the >>> context. >>> > > Those are subjective comments, so we'll put those aside. > >>> >>> Section 2 (top section) >>> >>> I like that the attacks on SMTP by network operators is highlighted here. > > We tried to have balance and had other attacks by operators in > previous versions, but only articles that are not stable references > for them and were asked to remove them in AD review. > >>> >>> There's an implicit argument here that runs counter to established IETF >>> consensus. >>> >>> Some methods used by service providers are impacted by the use of >>> encryption >>> where middle boxes were in use to perform functions that range from >>> load >>> balancing techniques to monitoring for attacks or enabling "lawful >>> intercept", such that described in [ETSI101331] and [CALEA] in the US. >>> >>> This fails to remain neutral. > > The functions are impacted, so how would you suggest we word this > text? It doesn't endorse the functions, just says they are impacted. > We are open to suggested text. Similar to how we describe 'attacks' > by operators to break encryption or use RSA private keys. We do have > text in both directions on this and your review is complimentary of > the ones that fit your dialog, but are also not value neutral. Mind > you, I am constantly reviewing RFCs and making sure TLS best practices > are considered and questioning the use of deprecated crypto or not-yet > but should be deprecated crypto. > >>> This implicitly makes a value-judgment >>> about >>> relative morality/acceptability/value of certain practices. > > We have statements in both directions in the document as you point out > above with one of them. > >>> What is >>> particularly insidious about this particular form is that it invites >>> interpretation that is subjectively coloured. For instance, as a non-EU >>> and >>> non-US citizen, I might consider the use of the particular lawful >>> intercept >>> techniques offensive; thus I might interpret this as a spectrum between >>> inoffensive to offensive. An employee of the US government might view >>> this >>> somewhat differently and interpret this as a scale between low-value to >>> high-value. I'm guessing here, but this is really just to highlight my >>> point >>> about care. >>> >>> A more serious concern is this statement: >>> >>> The loss of access to these fields may prompt undesirable security >>> practices >>> in order to gain access to the fields in unencrypted data flows. >>> > > But this is true and we've seen operators do things like prevent > STARTTLS. This isn't a good thing and we need to ack that this has > happened. We need to help operators figure out how they help users in > new ways and understand that some of the functions they perform > currently (TLS 1.2) won't work in the future. > > This text got re-worded during AD review, I believe. The intent is to > say that this is not good - the practices are called out as > undesirable. How would you suggest it be re-phrased and we can check > back with Stephen to see if he agrees. > >>> I've read this argument before (see >>> https://queue.acm.org/detail.cfm?id=2508864 >>> for the long form), and it might even have an element of truth to it. >>> However, >>> it's not a statement that I personally attribute any real credibility to, >>> and >>> nor do I think that it needs to be credited with any amount of >>> seriousness. I >>> certainly disagree with the IETF making any such statement. It says that >>> we are >>> collectively willing to bow in response to (anticipated) threats of >>> violence. > > Prior to AD review, there was a reference in the text to the practices > being bad and stating that regulators and the media helped to correct > this behavior. The problem here may be the evolution of the > text and lack of reference now since we couldn't find a stable > reference. Do you have a wording suggestion? > >>> >>> Section 2.1 >>> >>> This is one of the few sections that talk about what it means to operate a >>> service as opposed to operate a network. >>> >>> Overall, this section doesn't work particularly well. The distinction >>> between >>> integrated and standalone load balancing is an interesting division, but >>> it >>> doesn't leverage this distinction well. What causes a standalone >>> load-balancer >>> to be necessary? Is this something a network operator uses? I see text >>> on NFV >>> later, but it's far removed from the original text and it seems >>> aspirational >>> rather than concrete. On the other hand, many of the concerns in this >>> document >>> simply don't apply to an integrated load balancer. >>> >>> The amount of text on QUIC here is surprising. Given how much of QUIC is >>> changing right now, we shouldn't publish a document that attempts to make >>> claims >>> about what QUIC is or how it is operated. This attempts to dive into the >>> details of QUIC connection migration in a way that presumes much about the >>> outcome of issues that the QUIC working group is still struggling with. >>> >>> I would strongly recommend removing QUIC-specific language from this >>> section and >>> the document as a whole. We have an operational document in the QUIC >>> working >>> group that would be a good venue to discuss some of these concerns. > > While we read this as more of a substantive remark, the text on > load balancers and QUIC were added per Mirja's IESG review. We would > need to check with her about making any changes here. They were > specific additions that were requested. > > Further, it is only IETF QUIC that is in active development. > Google QUIC (referred to as GQUIC in IETF discussions) is a more > stable experiment now. > >>> >>> Is this an oblique reference to (the much-loved) RFC 7974? >>> >>> Current protocols, such as TCP, allow the development of stateless >>> integrated >>> load balancers by availing such load balancers of additional plain text >>> information in client-to-server packets. >>> >>> Otherwise, I don't know what it means. >>> >>> BTW, I like this parenthetical: >>> >>> (That said, care must be exercised to make sure that the information >>> encoded >>> by the endpoints is not sufficient to identify unique flows and >>> facilitate >>> Persistent Surveillance attack vector.) >>> >>> I'm going to take this to the QUIC working group, because QUIC certainly >>> doesn't >>> meet that bar right now. It fully facilitates Persistent Surveillance in >>> its >>> current form (proper noun? I haven't really seen that term before, even >>> though >>> it draws a neat parallel with Pervasive Surveillance). >>> > > OK, let us know what you hear back. These changes were in response to > the sponsoring AD's request of that work. > >>> Editorial: >>> * "pop" is a term of art that needs explanation. >>> * "QUIC?s", "network?s" - avoid smart quotes, and - more generally - the >>> possessive form for the inanimate. >>> * "QUIC's server-generated flow IDs" -> "QUIC's connection IDs". > > Thanks for the nit corrections. > >>> >>> Section 2.2 >>> >>> I think that this sums the situation up reasonably well. It fails the >>> value-neutral test in a few ways though. As I understand the situation, >>> surveying operates at many levels. For accurate planning, models of >>> endpoint >>> behaviour are used to determine things like whether loss or congestion is >>> affecting throughput. Really good models require knowledge of what users >>> are >>> attempting to do and the applications they are using (as mentioned, things >>> like >>> browser version matter in these models). For instance, it isn't enough to >>> understand that the user is trying to receive 720p video, you also have to >>> know >>> that a 4k stream for the same content is available. > > Sure, that's why we broke the draft down by operator type. Some > functions are shifting and the responsibilities for operators will > shift with these changes. > >>> >>> The degree to which these models are privacy-invasive is not even >>> acknowledged. > > Suggest text please. The abstract and intro were meant to set the > context for the document. Some of the functions will be eliminated - > and that's fine, it is what it is, but operators need to adapt and > deal with the change. We should help them so we all get to a better > place with improved privacy for users and increased security. By not > helping them, we do not get closer to solving these problems. > > Try to consider the operators perspective here. They are used to knowing > what SI has been exposed by knowing video format > or browser type that has been in the clear for years. Understanding > the practices > helps make it possible for apps/ops/security/transport to come together to > reach better solutions. > >>> >>> Nit: Did you realize that "well-intentioned" is a euphemism? I'd expect >>> that >>> subtlety to be lost on many readers though. >>> >>> Section 2.3.1 >>> >>> I find this sad, even if I can recognize the truth of it: >>> >>> A monitoring system could easily identify a specific browser, >>> and by correlating other information, identify a specific user. >>> >>> As a browser vendor, we don't consider this to be a feature, it's a bug. >>> >>> Section 2.3.2.1 >>> >>> This is a strange section under which to put caching. Caching is a use >>> case >>> akin to compression. I don't see it as belonging to the class of things >>> that >>> rely on DPI. You just intermediate the cleartext HTTP in the way that RFC >>> 7230 >>> recognizes. Note that RFC 7230 explicitly does not endorse the practice >>> of >>> transparent proxying for a range of reasons, not the least of which is the >>> complete lack of transparency (yep). > > > This was organized per IESG review. > >>> >>> Section 2.3.2.2 >>> >>> Again, it's strange to see differential treatment under DPI. I was fairly >>> sure >>> that fingerprinting was used here as well. >>> >>> Section 2.4 >>> >>> This section doesn't even attempt to recognize that applications are much >>> better >>> now at scaling content to suit the device on which that content is >>> intended to >>> be consumed. It should. > > The reason for that is that there has been a useful dialog between application > designers and network providers over time, beginning with app designers > saying "what do you mean the network has errors and delay? this works > fine in my lab...". The contributors viewed that as well understood > and far back > in time, so not necessary to mention. > > If you think there should be text to this point, please suggest some. > >>> >>> This section should not represent compression as an unmitigated good. I'm >>> told >>> that significant damage can be done to video streams by "well-intentioned" >>> compression middleboxes. > > Please suggest text. > >>> >>> Yet again I see a call back to the implicit threat of violence in "they >>> will >>> adopt undesirable security practices". Statements in that form have no >>> place in >>> IETF RFCs. > > This was edited text per review and agreed upon (I think in the AD > review). Suggest alternate > text and we'll go back to the other person. > >>> >>> Section 2.5 >>> >>> This mentions RFC 7754 then blithely ignores its primary conclusion. >>> Generally, >>> The treatment in RFC 7754 of this subject is more even-handed. >>> >>> The use of particular examples (betting, gambling, dating) shows cultural >>> bias. > > subjective review again, but 7754 cites examples too. > >>> >>> Jargon warning: "core network", "the mobile network" ("the"?) >>> >>> Section 2.5.2 >>> >>> This type of granular filtering could occur at the endpoint, however >>> the >>> ability to efficiently provide this as a service without new efficient >>> management solutions for end point solutions impacts providers. >>> >>> The initial premise here (up to the first comma) is the conclusion of RFC >>> 7754. >>> I disagree with the conclusion, and I suspect so does RFC 7754. In >>> scenarios >>> where this matters, endpoints are routinely managed centrally. The range >>> of >>> options for this sort of management are plentiful and diverse. > > Sure, but there is an impact and it's okay to ack that and assist with > these alternate options. If you have text to suggest, please do so. > >>> >>> Section 2.5.3 >>> >>> This describes a captive portal, which in the case where the service >>> provider >>> has a relationship with their customers, seems like a poor solution. See >>> the >>> CAPPORT working group for ways in which people are actually working on a >>> solution to this problem. >>> >>> Section 2.6 >>> >>> The capitalization of section headings is inconsistent here (and >>> throughout). >>> >>> Section 2.6.1 >>> >>> Isn't this a duplicate of Section 2.1? >>> >>> Section 2.6.2 >>> >>> I can't parse this statement: >>> >>> Approved access to a network is a prerequisite to requests for Internet >>> traffic - hence network access, including any authentication and >>> authorization, is not impacted by encryption. >>> >>> And then we get into zero rating, which is a hot-button topic. No >>> acknowledgment given to the sensitivities on the subject, or even a >>> superficial >>> exploration of the technical options that are available. > > Please suggest text. This was updated in IESG review. > >>> >>> This text references a non-existent Appendix. > > > Fixed. It's section 7 now. > >>> >>> Section 2.6.5 >>> >>> This paragraph is strange. It starts by describing what appears to be use >>> cases >>> (are those scare quotes?). It finishes by implying that these are attacks >>> on >>> privacy (which they are). >>> >>> What is "Non-Customer Proprietary Network Information"? I hope that this >>> isn't >>> an attempt to somehow privilege the information so that it seems less than >>> privacy-invasive. >>> >>> Section 2.7 >>> >>> This is one of the areas that is most legitimately affected by increased >>> adoption of encryption. I have no doubt that having detailed information >>> about >>> the application and its use makes the process of troubleshooting easier. >>> >>> This is the first mention in the document of network-based optimization. >>> Was >>> the section describing that cut from an earlier draft? >>> >>> The use of websockets as a primary example is an odd one. It's just not >>> that >>> common. For reference, we see >20% failure rates on encrypted websockets >>> and >>>> 50% failures in the clear; no one in their right mind would rely on >>>> websockets. >>> If the point is that HTTP is carrying more traffic (see >>> http://conferences.sigcomm.org/hotnets/2010/papers/a6-popa.pdf) saying >>> just that >>> would be more effective. > > "in their right mind" . That isn't helpful. Operators submitted text > to explain what they are doing and how it's impacted. How about > proposing text to help in that vein. > >>> >>> Section 3 >>> >>> It would help if "hosted environments" was defined before diving in. >>> >>> Section 3.1 >>> >>> The paragraph on DLP is ironically amusing. Encryption exists to prevent >>> private information leakage, but the assertion here is that encryption is >>> hampering DLP attempts. >>> >>> It's true that protection of intellectual property is an important >>> business >>> goal, but this handling suggests an architecture that I'm fairly sure is >>> counter >>> to established wisdom (see "SSL added and removed here :-)": >>> >>> https://www.washingtonpost.com/rf/image_404h/2010-2019/WashingtonPost/2013/10/30/Local/Images/GOOGLE-CLOUD-EXPLOITATION1383148810.jpg). >>> Worse, this casually dismisses a model that is actually more likely to >>> work. >>> Malware encrypts too (https://arxiv.org/abs/1607.01639). > > The section talks about the end points being the better place for this already. > >>> >>> Section 3.1.1 >>> >>> Who is the customer here? >>> >>> Why does the hosting provider need to monitor access? They have the >>> ability to >>> limit accesses, but this is suggesting that what happens within the >>> envelope of >>> what they permit is important for them to know. I'd be surprised if you >>> could >>> show that this is true. Hosting providers - in my experience - value >>> their >>> ongoing business and would not jeapardize it by snooping on their >>> customers. >>> It's different if the customer opts in to a security service, but that >>> demonstrates a cooperative situation, where the rest of this document is >>> largely >>> concerned with adversarial uses of encryption. > > This is describing the cooperative scenario. The service is hosted, > so maybe the definition of hosted would have helped you. > >>> >>> Section 3.1.2 >>> >>> This is another example where the organization of the document could >>> be improved. >>> >>> Again with the "SSL added and removed here :-)" recommendation. PCI don't >>> permit that for good reason. > > I don't read the following text in this section as a recommendation or > endorsement. Is there a tweak you think that should be made as I'm > not seeing the problem your describing. This is just describing what > they do and stating that it will be impacted and then the truth that > the functions may no longer be possible - not stating that it is good > or bad, just the fact that it won't be possible. > > The use of tools that > perform SSL/TLS decryption are impacted by the increased use of > encryption that prevents interception. Alternate methods to acheive > the goals of these functions may be necessary and in some cases, the > functions may no longer persist in a pervasively encrypted Internet. > >>> >>> Section 3.2.1 >>> >>> I don't believe that monitoring of these types of application require >>> cleartext >>> access. There are two parties involved: the provider of the application >>> and the >>> user of it. The provider has most of the power here and can theoretically >>> design the system to allow whatever level of access they require. To the >>> extent >>> that the user needs protection from the application provider, that is a >>> matter >>> of negotiation between them. >>> >>> I don't see how the adversarial three-party situation presented in the >>> rest of >>> the document applies in this situation. > > Sure, there is a shift in how many functions will be performed > happening and this is documenting that shift. Much moves to the > application. We are helping to document the changes. > >>> >>> Section 3.2.2 >>> >>> No real mention of the effect of encryption here, or is this just saying >>> that >>> there is no issue here? >>> >>> I don't see the point of the PGP/Dark Mail paragraph. I'd be leery of the >>> IETF >>> saying things like "PGP may be a front runner" though. >>> > > This was added per EKR in IESG review. > >>> Section 3.3 >>> >>> There's certainly a lot of detail here, but I had a really hard time >>> extracting >>> value from this section. I can't see how data storage is fundamentally >>> different to the general case of an application provider. > > They figured out how to increase encryption and manage their hosted > environments. There were adjustments made and they've been > successful. > >>> >>> Section 4.1.1 >>> >>> I appreciate the recognition that endpoint-based techniques work. The >>> implication that this isn't the obvious solution, much less so. > > This isn't a technical comment, but we'll revisit the text to see if a > wording change can help. > >>> >>> Section 4.1.2 >>> >>> I'm confused about the purpose of this section. This seems to be talking >>> about >>> the sort of network-based methodologies an application provider might >>> employ to >>> ensure that their application is working as intended. Why would the >>> application >>> provider not have access to detailed logging and usage metrics? > > The problem cited to us is that logging is sorely lacking. This needs > to be pointed out and fixed as it is too much for the operator to deal > with given the large number of applications running in their > environments. > >>> >>> As an aside, I skimmed through ietf-ippm-6man-pdm-option, since it is >>> cited no >>> fewer than three times in the same paragraph. It makes some fairly bold >>> claims >>> about its effect on privacy that I don't believe will hold up to analysis. >>> >>> Section 4.1.3.1 >>> >>> This section correctly identifies the issue as one of shortcomings in >>> logging, >>> not increased use of encryption. > > Right, a key point in this document - other methods will have to be > used and an obvious one is logging. However, logging needs to improve > for that to be possible. > >>> >>> I would have stopped there, but the section persists and ultimately >>> references >>> RFC 7974, which is widely recognized as a monstrously bad idea (the IESG >>> note is >>> fairly clear on this point). > > Thanks for catching that. We can drop this text. > >>> >>> Section 4.1.3.2 >>> >>> "HTTP/2", not "HTTP2". > > Fixed. > >>> >>> I don't see how this section belongs in this document. The 1:1 >>> correlation >>> between actions and flows in HTTP was a mistake of the 1980s that we've >>> spent a >>> lot of time on correcting (sometimes unsuccessfully, see pipelining). >>> >>> Section 4.1.3.3 >>> >>> It's not a "service call" it's just a request. >>> >>> Section 4.2 >>> >>> If the inclusion of a reference to RFC 7457 is to support a claim that TLS >>> is >>> attacked, that's sailing far too close to an endorsement of attacks than I >>> am >>> comfortable with. However, I don't believe that any of the listed attacks >>> remain viable in modern applications. What is most often the case is that >>> a >>> trust anchor is installed on enterprise users' machines and new >>> certificates are >>> minted as needed. In other words, the host that is accessing the HTTPS >>> site is >>> owned by the enterprise and modified so that it can comply with its >>> policies. >>> >>> When you recommend attack like this (to be clear, I would oppose >>> publication of >>> text that does this), you need to acknowledge the downsides. For example, >>> MitM >>> devices routinely break connections, they hide the true security status of >>> communications from endpoints and users, they frequently implement weaker >>> versions of protocols, they often don't include the same degree of rigor >>> in >>> things like certificate validation, and probably many more things that I >>> can't >>> casually list off the cuff. > > Please suggest text. > >>> >>> The discussion of caching here warrants a new section. >>> >>> Section 5.1 >>> >>> s/effect/affect >>> > > Thanks, we'll fix this. > >>> No complaint here, just an advertisement for technical solutions that >>> aren't >>> affected by increases in encryption. Good, though I'm not sure if the >>> section >>> meets the document's criteria for inclusion. >>> >>> Section 5.3 >>> >>> No cititation for APWG. Not an IETF working group from what I can see. > > We'll add that, thanks. > >>> >>> There's a presumption here that administrators need to perform these >>> tasks. Why >>> can't endpoints do this? It would certainly be a whole lot less invasive >>> that >>> way. Take a look at how browsers implement checks for "bad" sites (which >>> include phishing sites). These methods have some fairly significant >>> privacy >>> safeguards without compromising on performance. > > A lot will move to the endpoints, but things like logging need to > improve and we need to get application developers to do a better job > so that there is no reason for someone to want to try to intercept > traffic for troubleshooting. Operators see this as an insurmountable > problem. We need to help. > >>> >>> Section 5.5 >>> >>> See my comment about about endpoint-based methods. > > Already agree with this point. > >>> >>> Section 5.6 >>> >>> I believe that the spoofed source address problem is not relevant to this >>> document. It's a fairly well understood problem. That said, if we could >>> wave a >>> magic wand and get BCP 38 deployed, that might be nice. >>> >>> Section 6.1 >>> >>> As this says, it's fairly well understood that - for HTTP - SNI is used. >>> The >>> point that it is optional is interesting, but doesn't deserve the amount >>> of >>> attention this section devotes to it. The clients that don't include SNI >>> are in >>> a diminishing minority. > > Text was aded per EKR's review. > >>> >>> That said, this doesn't pay any attention to another feature in HTTP/2: >>> connection coalescing. > > Please suggest text if this should be included. > >>> >>> Section 6.2 >>> >>> ALPN will be encrypted in TLS 1.3. > > Noted. Thanks. > >>> >>> Section 6.3 >>> >>> This reads as a invitation to perform traffic analysis (a statement that I >>> oppose). Note that we have added padding to most recent protocols (HTTP/2 >>> and >>> TLS 1.3 in particular) to give endpoints the ability to resist this sort >>> of >>> attack. >>> >>> Note that block ciphers can add ~240 octets of discretionary padding per >>> record. >>> That can be pretty effective if you are careful. > > I believe this text was added through the IESG review. I don't see > the problem with the text you are citing, so could you suggest > alternate text? > >>> >>> Section 7 >>> >>> This section is duplicative of much of the rest of the document. I >>> realize that >>> editing is hard, but see my earlier comments about structure. > > This text was the appendix, but moved to section 7 per IESG review and > discuss. It was the mobile operator view. > >>> >>> It's obvious that this section is about QUIC. That shows in several ways. >>> It's >>> nice how it doesn't say so out loud, but it leaks through in several >>> confusing >>> ways. See below. >>> >>> Section 7.1 >>> >>> This section is purportedly about encrypted ACKs, which won't happen until >>> we >>> get to QUIC. But the points regarding proxies (b, c, d) are not prevented >>> by >>> encrypted ACKs, they are prevented by encryption more generally. Point e >>> is >>> defeated by integrity protection of ACKs, not confidentiality protection. >>> >>> I hope that the IETF never publishes draft-dolson-plus-middlebox-benefits; >>> it >>> makes claims about the benefits of specific solutions for different use >>> cases >>> with the goal of justifying those solutions. At the same time, it fails >>> to >>> recognize the existence of alternative, often superior, solutions for >>> those use >>> cases. In other words, it has many of the same issues as this document. > > I think this is an early document and expect it will get some > revision. This was added into our document per Mirja's IESG review. > They are documenting middle boxes that use 5-tuples. That point isn't > clear until the summary. I provided some light feedback, but could > provide more to help them improve the document. I think it's fine to > document these things and then figure out how we can do better with > IETF agreed upon protocol design intentions (end-to-end and assisting > to improve user's privacy as well as the security of sessions. > >>> >>> FWIW, also be OK if draft-thomson-http-bc never went anywhere as well; I >>> don't >>> know how to close the gap between the privacy assurances I wish it had and >>> the >>> privacy weaknesses it has. >>> >>> The phrase "trusted proxies" is a dangerously misleading phrase. The >>> concept of >>> trust is - particularly in this context - frequently abused. > > That's why the quotes were there, but this has been re-phrased in 10 - > see the SecDir review. > >>> >>> Sections 7.2 and 7.3 >>> >>> I'd be interested in learning about the justification for these features >>> (again, >>> go back to my comment about to whom the benefit accrues, and I'd advise >>> caution >>> not to make the trickle-down economics mistake of using second-order >>> effects). >>> Personally, I'm not that sad that they are going to be negatively >>> affected. >>> >>> Section 7.2, Point d seems to be saying something about a multiplexed >>> protocol, >>> not one that has an encrypted transport header (see above regarding QUIC). >>> >>> All these points equally apply to HTTPS, which suggest that encrypted >>> transport >>> headers is not the issue (unless by transport we mean HTTP). > > Again, section 7 was changed in IESG review and added into the body of > the document per Mirja's discuss since the mobile operator is > important to include. > >>> >>> Section 7.4 >>> >>> s/GPSR/GPRS/ ? > > Fixed. I thought this was fixed in 9, hence me thinking you read the > wrong version. > >>> >>> Section 8 >>> >>> I generally agree with the first statement here, but after having read the >>> document, I could take away some very different views on what the >>> "problems at >>> hand" actually are. I suspect that different people will have very >>> different >>> takeaways. >>> >>> The conclusion section of a document is not the right place to start >>> introducing >>> new information, particularly information relevant to RFC 2804. > > Should we move this to the introduction perhaps to help with context setting? > >>> >>> Not sure where this is going: >>> >>> Terrorists and criminals have been using encryption for many years. >>> >>> Because it's disconnected from the remainder of the paragraph. If you are >>> going >>> to invoke the T-word, you had better have a strong argument to make. On >>> the >>> final sentence of that paragraph, the subject ("This") is unclear. >>> > > Sure, the point was that their use of encryption is not a > justification argue any of the improvements to crypto for the general > population. Incident handlers know full well that encryption has been > in place for a long time by these users. Essentially, it's not an argument that > hold muster. > >> >> >> >> -- >> >> Best regards, >> Kathleen >> >> > > > > -- > > Best regards, > Kathleen & Al
