Hi Kathleen, (Al,) First, I think that my comments have been misinterpreted - albeit understandably - as meaning that I am opposed to the existence of this document. That's not the case, I believe that there is valuable content here and I would like to see this published. As observed separately, writing RFC 3234 was difficult, but ultimately valuable. I think that there are some structural issues and some unnecessary making-of-statements. The former needs some fairly major editing work; the latter: I'd advocate for excision. I believe that your assertion is that the latter have been excised; I found several places where that is clearly not the case. I'll try to highlight those I find, but I can't afford the time to do another full review just yet. It would be a mistake to simply say that because someone requested publication that this document is ready to publish. The main cost of taking another pass at this is the not-inconsiderable time and effort that requires. So far the main argument against doing that is that it is hard, and I can't really disagree with that. I happen to think that the extra effort is more likely to produce a more valuable product. I've tried to trim this mail; it's long. I noted quite a few issues that you didn't address in -11 or respond to in the process, but I'm just cutting them for the sanity of all involved. On 11 April 2017 at 13:54, Kathleen Moriarty <kathleen.moriarty.ietf@xxxxxxxxx> wrote: >> Perhaps you have additional language suggestions for context setting? I have a suggestion, below. >>> 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. I don't think that argument is so easily dismissed. When we create a statement, we have to consider how it might be read from multiple perspectives. In this case, it's not that much of a stretch to believe that someone might read some of the statements here as license to try to undermine TLS (for example, based on a reading of the text from Section 2.4). >>> 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". Actually, I don't question the fact that people believe these to be requirements. But I see a lot of cases where it's less clear, for example in Section 2.3.1 (I'm moving to -11 now): This [referring to traffic analysis] technique may be used with clear text or encrypted sessions. Thinking about an adversarial reading of this, is that a permissive "may"? > 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. The abstract could be better I think. How about? Pervasive monitoring attacks on the privacy of Internet users is of serious concern to both the user and operator community. RFC 7258 established the need to protect user privacy when developing IETF specifications. This encourages reducing the information that is made available to passive observers, which affects some security and network management practices. This document describes those practices and examines the effect of increased use of encryption on those practices. On a second read, I think that the bulk of the problem is with 1.1, section 1 is largely OK. The second-to-last paragraph of Section 1.1 is critical, but I actually think that the remainder of that section is more of a liability than an asset. The discussion of OS is weak, creating good citations for the statistics is hard, and the discussion of non-web cases isn't adding much value. You could simply take it as read that there will be increased encryption and this document would work well. Even if you didn't want to assume that encryption is increasing in volume, you could have a fine document that explored the management impacts of encrypted sessions. Also, it would help if there was a clearer statement regarding lack of endorsement. If you are going to say "lawful intercept exists" - a true statement, almost a truism - it's prudent to also say that this isn't an endorsement of those practices. Explicitly. > 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.). Yep, and that's a valuable goal. It would be nice to have a document that allowed someone with a need (or requirement) to be redirected to an architecturally sound solution. The challenge is that these problems don't all have simple solutions. In its current form, I don't see this draft as providing that service well because the goals/use cases aren't particularly well-organized. Also, it's probably best to avoid developing solutions as part of this. A simple catalogue of needs and practices works. > Can you give specific sections where it sounds like we are weakening > RFC 7258 so we can change that specific wording? See above. > 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. I don't think that the superficial change really worked. See above regarding "may". > Apparently, RFC 7754 goes further than our scope. We are not describing: > "... the different practices that might be employed to achieve that goal." Agreed. I am more interested in the structure of that document. How it breaks down the problem carefully and explores the various options. You don't have to offer solutions here, but the treatment could be more methodical (like in RFC 7754). >>> 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 understand that's true. Though it's also a little sad, I'm speaking from a position of privilege, so I won't make too much of an issue of it. What interests me here is the operational challenges that arise from this. The need to modify multiple applications for instance. > QUESTION: Would it help to add some text like the first paragraph into > the introduction? - This document aims to... If that is actually the aim of the document, sure. It seemed less clear to me what the intent was from reading it. >>> 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. I don't think that this is exactly the question you ask, it's a broader one that you are trying to attack. You are laying the groundwork for asking that question: which is, what are those practices and why do they exist? The question of legitimacy isn't one that you want to tackle here (not enough space, too hard, etc...) and designing solutions is best left to individual protocol designs. >>> 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. It's very easy to lose track of that 40 pages in when the text that you are reading says something else. >>> 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. I think that you missed my point here. The point is that the document declares various outcomes as virtuous, rather than simply describing the practice. Section 2.3.2.1: The features and efficiency of some Internet services can be augmented through analysis of user flows and the applications they provide. That's an statement that ascribes a virtue to a particular practice without qualification. The ensuing text only doubles down on that. > 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. See above. >>> 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. The first two paragraphs of Section 1.1 talk about OS. In the context of this document OS is maybe relevant for a few reasons: 1. it can be removed trivially (see the STARTTLS attack by operators) 2. it can be deployed more easily (debatable) 3. it is encryption Of these, the last is the only thing that is relevant. For the reasons I cite above, I would restrict discussion of it to those sections that talk about stripping opportunistic security (striptls, the STARTTLS attack). >> 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? Well, my first suggestion is removal. Failing that, create citations for the statistics. If you can't - the Dell EMC stats, for example - then at least describe what they mean. I don't know if 78% applies to connections, packets, or requests (probably not requests). >>> 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. I think that you should include a section on intercept. It happens; encryption largely prevents it, though OS doesn't. > 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 would prefer that the document doesn't mention that at all. Talk about disabling OS as a practice that happens. >>> 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? See above. That is, acknowledge that some methods exist for "breaking" encryption, that those are largely limited to striptls and its ilk, though attackers with significant resources might be able to perform other sorts of attacks (cite the attacks on TLS doc here). > 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. I think that Mirja responded here, I'll follow-up there. > 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. It's existence seems assured, but not its form. Google are tracking the IETF work. >>> 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. Here's a structural suggestion then: * Use Cases ** Common Use Cases - those for more than one type of network operator (e.g., troubleshooting) ** Enterprise Use Cases - those unique to enterprise (e.g., DLP) ** Network Operator Use Cases - e.g., capacity modelling ** Hosted Service Use Cases * Practices ** DPI ** Traffic Analysis ** Removing Encryption ** Repacketization ** TCP Termination ** ... Description of use cases can list practices used in support of them, or the practices can list the use cases they support, or both. >>> 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 has an effect on applications in addition to network operations. By removing the ability of an intermediary to compress content, the responsibility for adapting to network conditions moves to the endpoints. Applications that are able to compress content, or reduce bandwidth use to suit network conditions will gain better performance." >>> 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. "Compression employed by middleboxes can have an effect on performance. In addition to latency costs, compression can require additional computational resources. Use of lossy compress degrades the quality of content." >>> 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. Ahh, I hate putting you in that position. I would prefer if this be removed. >>> 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. I see a reference to Section 7 here, but no text on zero rating in that section. Zero rating is a use case in its own right. I would make a new section, or simply repurpose Section 2.6.2 for that (remove paragraph 1). Section 2.6.2. Zero Rating and Preferential Treatment Some network operators sell tariffs that allow access to certain content without cost to users, a practice known as 'zero rating'. More generally, users might be charged differently based on the content they are viewing. Or, packets related to the access of certain content might be given different priority. Identification of content is critical to providing this differentiation, because web content is often distributed across multiple servers. Use of encryption hides details about content, preventing the use of those specifics from being used in providing preferential treatment. This expands the scope of the section considerably, but I think that it's what you want to say. I have restrained myself in not making any statement about the virtue or otherwise of these practices. I think that this is a bad trend, but we don't need to say that in an RFC (unless we create one with that purpose, that is). >>> 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. "The widespread use of encrypted HTTP means that TCP port 443 is being used for a large variety of use cases with sometimes very different performance requirements. Some uses are latency-sensitive, others need to send lots of bytes. In some cases, mixed uses appear on the same connection; which is possible with both WebSockets [RFC6455] and HTTP/2 multiplexing [RFC7540]. A network operator is unable to provide differential treatment using the information that is available to them." Now that I look at this, this is a more general and useful statement. Hiding it in the bottom of a section about something else doesn't make a lot of sense. It's also not general enough to surface in an introduction, so I recognize the difficulty in finding it a home. >>> 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. This short explanation is much easier to digest. Is there any way that might be said up front? Though even with that, I would still find this section very difficult to read. >>> 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. If that is indeed an issue (I've heard the same asserted, it's probably true), then it needs to be said. >>> 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. Well, to preface this, I don't think that this is the right section to put text like this. It's more appropriate in a section that talks about the specific techniques (Section 4.2 is another grab bag of practices duplicating text from other sections). I think that it is entirely appropriate to say: ``` Encryption can be disadvantageous to the goals of the operator of a middlebox. Removal of encryption without the consent of endpoints is an attack. Attackers can and have removed attempts by endpoints to use opportunistic security (see [SSLSTRIP -- https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf], [STARTTLS -- Section 5.1 of DOI.10.1145/2815675.2815695]). More resourceful attackers might use attacks or weaknesses in deployed protocols (see [RFC7457]) or flaws in implementations to remove or attack uses of encryption. ``` That's a stronger statement than I think you are looking to make though. It doesn't invalidate the cases where endpoints are owned and trust anchors are installed. I would put that down in a different section. ```One method for intermediating encrypted sessions is to install a trust anchor on an endpoint and then use the associated keys to create authentication credentials that will be accepted by the endpoint. In this way, a middlebox can terminate a session in a way that the endpoint will accept as legitimate, thereby impersonating the intended peer. This technique rarely works for mutually authenticated communications, because the middlebox is usually unable to exert control over both intended endpoints in a way that would allow it to impersonate both peers to each other. It also causes the modified endpoint to become entirely reliant on the methods the middlebox uses for correctly authenticating the intended peer. For example, a web client typically implements authentication checks that exceed those listed in RFC 5280 [cite]. This might include key pinning [RFC7469], OCSP stapling [https://www.iab.org/documents/correspondence-reports-documents/2017-2/iab-statement-on-ocsp-stapling/], and other checks. A middlebox that impersonates a web server that does not perform the same checks could be vulnerable to the attacks that these additional checks are intended to protect against. Impersonation of a web server also hides the true status of the connection from the web client. ``` >>> Section 6.1 ... > Please suggest text if this should be included. Here's a rewrite... ``` A TLS client that initiates a connection to a server can provide a server_name extension (server name indication, or SNI) [RFC6066] which indicates the name of the server to which it is attempting to connect. SNI allows servers to select between multiple certificates when handling a TLS handshake. This enables the use of multiple domain names at the same IP address, also known as virtual hosting. Although SNI is an optional extension, it is today supported by all modern browsers, web servers and developer libraries. Akamai [Nygren] report that many of their customers see client TLS SNI usage over 99%. HTTP/2 [RFC7540] mandates the use of SNI. When present, the server_name extension that is included in the TLS handshake is not encrypted. This allows a passive observer to identify the domain name to which a connection SNI is being made. Other information about the application, such as the URL of an HTTP request or the type of content being requested, is not visible, only the domain name of the server. Relying on SNI to identify a host has several limitations. It is not present in a small number of cases where clients do not support the feature, or where protocols that don't mandate or rely on its use. In addition, HTTP/2 connection coalescing (see Section 9.1.1 of [RFC7540]) can mean that a connection originally established for one name is used for requests to other names. ``` I've dropped Alt-Svc mentions (they aren't relevant in this context - even with HTTP OS, SNI is still shown in the clear). I tried to keep the text about the type of content >>> Section 6.2 >>> >>> ALPN will be encrypted in TLS 1.3. > > Noted. Thanks. Hmm, I should have been clearer, the server's choice of application protocol will be encrypted. The client's set of options will not be. >>> 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? ``` Information about the content of encrypted communications is often available through traffic analysis. For instance, the size and timing of packets can reveal considerable information about the contents of data [NETFLIX][CLINIC]. Applications can implement traffic analysis strategies, usually by padding content to obscure its true length. This can be achieved in a limited fashion in block ciphers in TLS, and various features of other protocols can be exploited to add padding. Explicit support for padding is included in HTTP/2, TLS 1.3, and some other protocols. Use of multiplexed protocols can confound traffic analysis by combining data from multiple discrete events. However, multiplexed protocols depend on flow control, which can be exploited to reveal information (see [HEIST]). ``` Citations for the above (sorry, rough): NETFLIX=DOI.10.1145/3029806.3029821 CLINIC: title: "I Know Why You Went to the Clinic: Risks and Realization of HTTPS Traffic Analysis" author: - ins: B. Miller - ins: L. Huang - ins: A. D. Joseph - ins: J. D. Tygar date: 2014-03-03 target: "https://arxiv.org/abs/1403.0297"; HEIST: https://www.blackhat.com/docs/us-16/materials/us-16-VanGoethem-HEIST-HTTP-Encrypted-Information-Can-Be-Stolen-Through-TCP-Windows-wp.pdf >>> 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 valuable information, sure, but hard to use. I can see why the IESG thought that it needed to be in the body, as there are quite a few new use cases. >>> 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? The bit about surveillance programs and lawful intercept really need to be in the relevant sections of the body (that was the "new information" I referred to). I agree that it would be good to promote the first statement to the introductory material. >>> 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. Yeah, as before, when it comes to discussion of lawful intercept, I would prefer to have that in the body of the document. Preferably without mentioning why it happens, because that avoids the emotive topics.