Hello Martin, Thanks for your review and clarification. On Wed, Apr 19, 2017 at 1:26 AM, Martin Thomson <martin.thomson@xxxxxxxxx> wrote: > 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. Thanks, this is very helpful. > > 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. That's good that you haven't had time for a full review yet as we are working on a revision. Alissa . Cooper has been providing extensive input on the latter. We are waiting on some comments from her and I will be taking a couple of days off, so there may be a slight delay in posting the next version. As for structural issues, it is tough with this document as there are many opinions on what the layout should be, having said that, we are looking at that as well. We'll likely figure out what to do with section 7 as a first step. > > 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. We are working on it already. > > 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. We've worked on the context setting more since this last message with input from the IESG reviews. I'll just put a bit of the text here and the rest will be in version 12. We can let you know when the updated version gets posted. 1. Introduction 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. Pervasive Monitoring (PM) is of serious concern to users, operators, and application providers. RFC7258 discussed the critical need to protect users' privacy when developing IETF specifications and also recognized that making networks unmanageable to mitigate PM is not an acceptable outcome, but rather an appropriate balance would emerge over time. ... Seeing the rest in the next version and getting your comments would be helpful. > > 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. Good then I'll update that to, more of a statement that this occurs: This technique is sometimes 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. We've updated the abstract in IESG review and have the text as follows in the running version. The full scope of RFC7258 is important for this draft as it discuses finding a balance with network management and the importance of user privacy. The following is similar to your proposed text, but includes that as well. We want to make sure the document is helpful to operators and keeps the conversation open for each side of the discussion - so it happens. Abstract Pervasive Monitoring (PM) attacks on the privacy of Internet users is of serious concern to both the user and operator community. RFC7258 discussed the critical need to protect users' privacy when developing IETF specifications and also recognized making networks unmanageable to mitigate PM is not an acceptable outcome, an appropriate balance is needed. This document discusses current security and network management practices that may be impacted by the shift to increased use of encryption to help guide protocol development in support of manageable, secure networks. > > 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. In reviewing this text again, I see we jumped right into TLS and DTLS with no discussion of OS used in IPsec. I'll think about this a bit more. IPsec has had OS in place for a while and we have a few documents published showing implementation work: RFC4322 - Linux FreeS/WAN project and RFC7619 -specifying IPsec without authentication. The latter was implemented by RedHat. RedHat put it in the OS and had intended to have it enabled by default, that hasn't happened yet. There are many uses for OS between servers or Linux systems, where you can't authenticate the other party in advance. I actually posted a review to the DHCPv6 mailing list yesterday pointing to these RFCs to consider including int heir work to make it easier to implement end-to-end encryption for DHCP for the coffee shop use case. Storage uses IPsec and I'm sure there are other use cases where OS is/will be very helpful. We'll play with the text a bit to make this clear. > > 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. OK, some of this text got cut, but we'll look through it again. We've also gotten comments to not have text throughout that restates such things as the context setting is enough. I think considering this with the full updates is needed and we'll look at that. > >> 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. Agreed. > >> 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". Yes, we are working on this and if you find any problems in a later version, that would be helpful. We are trying to catch all of them. > >> 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. OK, hopefully much of what you are looking to see will be in one of the next versions. We may need to do a couple as we work through the rest of the comments. > > >>>> 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. Agreed and yes, this might be input to include in conversations on individual protocol design. At that point interested parties should dig deeper and determine what make sense and what is possible considering the balance that is desired for that protocol. > >>>> 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. Fair enough. > >>>> 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) I think the IPsec uses of this may change the argument (meaning the deployment ease improves for that), think DHCP or connections between servers. In the RedHat case, their plan was to implement tunnel mode IPsec and have it enabled by default for use between other systems on the same operating system. > 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). I'm going to think about your points more, but just an initial thought... For follow on work, wouldn't individual protocol designs consider OS in the balance between management and privacy? I would think the conversation would be part of the discussion and wouldn't go as far as saying (for the purpose of this thread, not the draft) that management would tip a balance to OS > >>> 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). For Dell EMC, it was firewall logs. This would be URL accessed (many for single pages) I suspect. We'll think more about this and possible removal. > >>>> 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. OK, we'll consider doing that. I think some of this text has been removed in the current version and I don't want to see a head in sand approach, so maybe a section on interception is the best way forward. > >> 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. We'll think about this more in an intercept section. There are steps to this, TLS 1.2 to TLS 1.3, use of OS in TLS and IPsec, known attacks possible in TLS 1.2, things you can do if you own the server and keys for TLS, as well as ACME work - setup easier, but not quite as secure since we are accepting tradeoffs to increase the use of encryption. > >>>> 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). Noted, thanks. > >> 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. Great and her suggestions have been taken into account in the working copy of the draft. > >> 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. This was removed, per Mirja. > >>>> 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. Thanks, we'll consider this structure. > > >>>> 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." > Thanks for the text to add. > >>>> 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." Thanks for the suggested 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. > > Ahh, I hate putting you in that position. I would prefer if this be removed. It was edited again in the meantime. One instance seems to be removed (there were 2) and we have: In response to increased encryption of these fields, some network service providers may be inspired to undertake undesirable security practices in order to gain access to the fields in unencrypted data flows. > >>>> 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). Thanks, this is helpful. Al will need to take a look at this as well and then we can integrate it. > >>>> 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. Thanks for the text, we'll figure out what to do with it then. Structure isn't easy in this draft. > >>>> 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. OK, We'll think about this more. > >>>> 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. I'm pretty sure we've inserted more text on logging, but will make sure with a sweep of the full draft to make sure it was put in appropriately. This might not be perfect in -12. > >>>> 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. > ``` We'll think about this more as section 4 is part of the enterprise text with the disclaimer at the start of the section that provides the caveat that users have signed away their privacy rights (essentially). > > 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. This goes to our current division of sections for text and what's okay in an enterprise is by no means okay anywhere else. > > ```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. > ``` Thanks for the text, it's helpful and we'll also consider placement. I'm not sure of the extent of structural changes for the document, but this is text that we'd have to consider where it makes the most sense. > >>>> 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. > ``` Thanks for the text. This is good, but we also have to include the point that this is a change for operators and an impact as they were using more information than just the server/hostname in the past and we need to make that change clear in the text for operator impact. > > 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 OK, thank you. > >>>> 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. Thanks that's helpful. > >>>> 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]). Thanks is good text to have as part of the changes and problem statement. > ``` > > 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 > Thanks. > >>>> 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. We'll be working on this soon, maybe in -13, maybe -12, not sure yet. > >>>> 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. Noted, thanks. > >>>> 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. OK, l think about this more. Thanks for your review and proposed text. -- Best regards, Kathleen