Hi Eric, A quick update per the discussion on a TLS draft.
On Mon, Feb 19, 2018 at 3:11 PM, Kathleen Moriarty <kathleen.moriarty.i...@gmail.com> wrote: > Hi Eric, > > Thanks for your feedback, responses are inline. > > FYI - I posted another version, but expect at least one more iteration > after this version with additional comments and the ones we haven't > gotten to yet. > > On Thu, Feb 8, 2018 at 12:04 AM, Eric Rescorla <e...@rtfm.com> wrote: >> Eric Rescorla has entered the following ballot position for >> draft-mm-wg-effect-encrypt-17: Discuss >> >> When responding, please keep the subject line intact and reply to all >> email addresses included in the To and CC lines. (Feel free to cut this >> introductory paragraph, however.) >> >> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html >> for more information about IESG DISCUSS and COMMENT positions. >> >> >> The document, along with other ballot positions, can be found here: >> https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> I have completely re-reviewed the latest version. First, I want to >> thank you for toning down some of the material that I was concerned >> about. >> >> Unfortunately, the fundamental concern that motivated my DISCUSS >> remains: I do not believe that this document matches the consensus >> of the IETF community. >> >> Specifically, this document takes at face value a large number of >> claims about the necessity/value of certain practices that either are >> controversial within the IETF or that there is, I believe, rough >> consensus to be actively bad, and that in many cases, encryption is >> specifically designed to prevent. I have noted a number of these >> below, but I do not believe that this is an exhaustive list (going >> through my previous DISCUSS, I see that I noted a number of these but >> that still appear to be unaddressed.) > > In the previous round of IESG reviews, the IESG concluded that framing > upfront was the preferred approach to make it clear that not all cited > practices are ones the IETF consider valid. This was done in the > updated introduction. > > Please respond to the discussion points as I believe your additional > points have been addressed to also make these points again in the > document. In a couple of places, we have questions to make sure your > concern is understood. > >> >> >> DISCUSS >> session encryption that deployed more easily instead of no >> encryption. >> >> I think I understand what you are saying here, but the term >> "breakable" seems very unfortunate, especially in the context of this >> document. The only such shift I am aware of that has received >> acceptance in IETF is one from always requiring fully authenticated >> encryption to allowing unauthenticated encryption, which you document >> in the next paragraph. I recognize that there are other perspectives >> (e.g., those in draft-rhrd) but those are pretty far from IETF >> consenus. Accordingly, I think you should remove this sentence. > > Opportunistic security was well discussed, so that was likely top of > mind for you when reading this draft. However there are other areas > where the IETF decided breakable encryption was better than none in > recent years. Another adopted and published example is in the mail > community. Deprecating MD5 was deemed to be too hard because of > support in a particular library. We had lengthy discussions about > this for RFC7627 (see sect 6.2) and related drafts, now published > RFCs. > > This sentence had nothing to do with the drafts that are not WG drafts > in the TLS WG, but real use cases of published RFCs where deprecated > crypto is still accepted despite efforts to correct that in addition > to the acceptance of the OS approach in multiple session encryption > protocols. The support tools and use cases don't always drive the > best solution where we have strong crypto everywhere as you have also > noted on recent draft reviews, now published RFCs. > >> >> >> motivation outside of privacy and pervasive monitoring that are >> driving end-to-end encryption for these content providers. >> >> This section seems kind of confusing, at least as applied to >> HTTP. There are three kinds of cache in HTTP: >> >> - Reverse proxy caches (the kind CDNs run) >> - Explicit forward proxy caches >> - "Transparent" intercepting caches >> >> The first of these move to HTTPS just fine and that's typically how >> CDNs do it. Explicit forward proxy caches are largely going away, but >> part of the point of this kind of end-to-end encryption is to hide >> data from those caches. > > Sure, that point was made in the draft and cleared up a little further > from Benjamin K's review. The business risk associated with not > controlling your content was more explicitly stated for CDNs who have > moved to an e2e approach. > > Here's the updated sentence: > The business risk of losing control of content is a motivation outside > of privacy and pervasive monitoring that are driving end-to-end > encryption for these content providers. > >> Transparent intercepting caches that the user >> didn't opt into are a bad thing, so having them go away is a positive. > > The text says authorized parties, so this is referring to caches where > there is an agreement in place for this usage. CDN's that wish to > block this behavior have the option to require e2e. That trend alone > may be enough to kill this type of service offering. I don't see why > it shouldn't be mentioned in terms of it's current use. What change > are you looking to see here? > >> >> document existing practices, the development of IETF protocols >> follows the guiding principles of [RFC1984] and [RFC2804]. >> >> This is pretty opaque in this context. It should explicitly state that >> the IETF's position is that we do not engineer for these use cases, >> not just to cite the RFCs. > > We can add the following (or suggest something else): > > "and explicitly do not support tools and methods that could be used > for wiretapping and censorship." > >> >> >> based billing, or for other reasons, possibly considered >> inappropriate by some. See RFC7754 [RFC7754] for a survey of >> Internet filtering techniques and motivations. This section is >> >> I don't think this accurately represents the RFC, which makes clear >> that the IAB consensus is that filtering is bad: >> >> " From a technical perspective, there are no perfect or even good >> solutions -- there is only least bad. On that front, we posit that a >> hybrid approach that combines endpoint-based filtering with network >> filtering may prove least damaging. An endpoint may choose to >> participate in a filtering regime in exchange for the network >> providing broader unfiltered access." > > I've added the following to the end of the sentence as the RFC is too > long to repeat what is already in 7754: > > "and the IAB consensus on those mechanisms." > > But I'll note that this cherry picks one part of the conclusion > section of 7754 and even this text acknowledges that some network > filtering is needed in the suggested hybrid approach. > > The first paragraph of this section says: > "Filtering will continue to occur on the Internet. We conclude that, > whenever possible, filtering should be done on the endpoint. > Cooperative endpoints are most likely to have sufficient contextual > knowledge to effectively target blocking; hence, such blocking > minimizes unintended consequences. It is realistic to expect that at > times filtering will not be done on the endpoints. In these cases, > promptly informing the endpoint that blocking has occurred provides > necessary transparency to redress any errors, particularly as they > relate to any collateral damage introduced by errant filters." > > This text does not say it is bad, it says that it should occur when > possible on the endpoint and that in cases where it is not possible, > the end points should be notified of this filtering. That's different > from saying filtering is bad as there are a number of cases why the > IAB agreed on a hybrid approach. > > DDoS mitigation requires the use of SP filtering to be effective. > This is a clear example of where filtering must be done on the network > and is very important and hard to argue that it isn't good. You may > have to step back toward the source of the traffic, iteratively > setting up filters to block traffic through cooperation of SPs until > you get close to the source. > > Filtering recommended in BCP38 certainly has had a positive impact. > > SPs also use filtering to protect their own infrastructure. > > This was just a quick response, I am sure there are other good > examples that supported the hybrid recommendation. > >> >> >> detect or prevent attacks as well as to guarantee service level >> expectations. In some cases, alternate options are available when >> encryption is in use, but techniques like that of data leakage >> >> These certainly are use cases, but you really need to acknowledge that >> it's also a form of user surveillance. >> > > This is referring to corporate networks. The rules are a bit > different since you get a paycheck and agree to monitoring, sign an > acknowledgement as an employee then operate on their equipment and > network. > > To help make this point more clear, I've added text into section 4.1, > let us know if this does not address your concern: > > OLD: > Large corporate enterprises are the owners of the platforms, data, and > network infrastructure that provide critical business services to > their user communities. As such, these enterprises are responsible for > all aspects of the performance, availability, security, and quality of > experience for all user sessions. These responsibilities break down > into three basic areas: > > NEW: > Large corporate enterprises are the owners of the platforms, data, and > network infrastructure that provide critical business services to > their user communities. As such, these enterprises are responsible for > all aspects of the performance, availability, security, and quality of > experience for all user sessions. Users typically sign agreements > acknowledging that they are subject to monitoring while operating on > corporate networks. Subsections of 4. Encryption for Enterprises may > discuss techniques that access data beyond the data-link, network, and > transport level headers typically used in SP networks since the > corporate enterprise owns the data. These responsibilities break down > into three basic areas: > > This was one of the reasons why we felt it was important to keep > section 4 separate. > >> >> Some DLP tools intercept traffic at the Internet gateway or proxy >> services with the ability to man-in-the-middle (MiTM) encrypted >> session traffic (HTTP/TLS). These tools may use key words important >> to the enterprise including business sensitive information such as >> trade secrets, financial data, personally identifiable information >> (PII), or personal health information (PHI). Various techniques are >> used to intercept HTTP/TLS sessions for DLP and other purposes, and >> are described in "Summarizing Known Attacks on TLS and DTLS" >> [RFC7457]. >> >> As far as I know, the MITM techniques used by middleboxes are not >> described in 7457. > > The use of an RSA static key is discussed in terms of the danger of > using this approach in Section 2.8. I updated the text slightly to > make this point more clear and added the section reference: > > Various techniques are used to intercept HTTP/TLS sessions for DLP and > other purposes, and can be misused as described in "Summarizing Known > Attacks on TLS and DTLS [RFC7457] Section 2.8. > >> >> You also need to cover the fact that these MITM are a threat to user >> security because they are often so badly implemented. > > I think 7457 does a good job of that. Let us know if you have > proposed text if the above fix isn't enough for you coupled with this > being in the Enterprise section. > >> >> >> S 5.4. >> It's pretty odd to talk about phishing without acknowledging that by >> far the largest anti-phishing platform (Safe Browsing) operates in the >> client, not be network interception. > > We responded on this previously pointing out that this is mentioned in > section 5.3 on phishing. Here's the text: > > Administrators might also add URLs contained in > messages to block lists locally or this may also be done by browser > vendors through larger scales efforts like that of the Anti-Phishing > Working Group (APWG). See the Coordinating Attack Response at > Internet Scale (CARIS) workshop Report [RFC8073] for additional > information and pointers to the APWG's efforts on anti- phishing. > > The CARIS report goes a bit deeper as well. The approach is broader > than just the browser vendors and that should be acknowledged. > Cooperation of many other players is involved in updating the block > lists and working with law enforcement to take down the offending > sites. Safe Browsing is just one piece of the larger puzzle and the > browser block lists are already mentioned. > >> >> >> The transport header encryption prevents trusted transit proxies. It >> may be that the benefits of such proxies could be achieved by end to >> >> You don't define a "trusted transit proxy" so I don't know what this >> means, and whether they provide any benefit, but this certainly sounds >> euphemistic. Generally, "trusted" is not an adjective we associate >> with network proxies operated by third parties. > > We added a little more text on this per Benjamin's comment. I'm > including the full text of the paragraph so this is not taken out of > context as endorsing such mechanisms as the text goes on to say other > ways it could be addressed in an encrypted Internet. Here is the > text. > > Transport header encryption prevents the use of transit proxies > in center of the network and the use of some edge proxies by preventing > the proxies from taking action on the stream. It may be that the benefits > of such proxies could be achieved by end-to-end client and server > optimizations, distribution using CDNs, plus the ability to continue > connections across different access technologies (across dynamic > user IP addresses). > >> >> >> In the best case scenario, engineers and other innovators would work >> to solve the problems at hand in new ways rather than prevent the use >> of encryption. As stated in [RFC7258], "an appropriate balance >> (between network management and PM mitigations) will emerge over time >> as real instances of this tension are considered." >> >> Much of the context of this debate is about whether operators not >> being able to do the things in this document is a problem, and this >> seems to presume the answer. > > Section 8 has been overhauled in response to Deborah's comments. I see > what you mean in the wording and that was not intended. The goal of > the draft is to help improve adoption by talking about the issues and > bringing them to the surface for discussion (tough discussions that > need to happen). Here is the current text. > > "As stated in [RFC7258] an appropriate balance (between network > management and PM mitigations) will emerge over time as real instances > of this tension are considered." Numerous operators made it clear in > their response to this document that they fully support strong > encryption and providing privacy for end users, this is a common goal. > Operators recognize not all the practices documented need to be > supported going forward, either because of the risk to end user > privacy or alternate technologies and tools have already emerged. This > document is intended to support network engineers and other innovators > to work toward solving network and security management problems with > protocol designers and application developers in new ways that > facilitate adoption of strong encryption rather than preventing the > use of encryption. By having the discussions on network and security > management practices with application developers and protocol > designers, each side of the debate can understand each others goals, > work toward alternate solutions, and disband with practices that > should no longer be supported. A goal of this document is to assist > the IETF to understand some of the current practices so as to identify > new work items for IETF-related use cases which can help facilitate > the adoption of strong session encryption and support network and > security management." > >> >> >> This optimization at network edges measurably improves real-time >> transmission over long delay Internet paths or networks with large >> >> Do you have a citation for this claim? > > The draft that this text refers to in the previous paragraph has a > section on performance enhancing proxies, section 3.5 and is referred > to right before this text. David Dolson was the contributor. > >> >> >> Web proxies are sometimes used to filter traffic, allowing only >> access to well-known sites found to be legitimate and free of malware >> on last check by a proxy service company. This type of restriction >> is usually not noticeable in a corporate setting as the typical >> corporate user does not access sites that are not well-known to these >> tools, but may be noticeable to those in research who are unable to >> access colleague's individual sites or new web sites that have not >> yet been screened. In situations where new sites are required for >> access, they can typically be added after notification by the user or >> proxy log alerts and review. Home mail account access may be blocked >> in corporate settings to prevent another vector for malware to enter >> as well as for intellectual property to leak out of the network. >> This method remains functional with increased use of encryption and >> may be more effective at preventing malware from entering the >> network. Web proxy solutions monitor and potentially restrict access >> based on the destination URL or the DNS name. A complete URL may be >> used in cases where access restrictions vary for content on a >> particular site or for the sites hosted on a particular server. >> >> If you are filtering on URL and there is HTTPS involved, then you are >> a MITM, and this is potentially noticeable to end-users. We encounter >> this regularly when MITM proxies make mistakes in getting into our >> trust anchor store. > > This is in the enterprise section where monitoring is accepted by end > users. What is your proposal here? I don't see an issue with > describing this usage. Are you okay with this text since you also see > this as an issue and perhaps it needs more discussion? > >> >> >> Re: 0-rating. >> user. This feature is impacted if encryption hides the details of >> the content domain from the network. >> >> Well, maybe. Facebook's zero rating, for instance, is IP-based. >> https://info.internet.org/en/blog/2015/09/24/enhancing-security-and-privacy-of-free-basics/ > > It seems the providers or applications offering 0-rating all operate > differently. > https://arstechnica.com/information-technology/2016/02/verizons-mobile-video-wont-count-against-data-caps-but-netflix-will/ > > I had more of an issue with the word feature here, so I believe I > addressed your comment and my concern with the following: > > For some implementations, zero rating is impacted if encryption > hides the details of the content domain from the network. > >> >> S 2.2.2. >> The presentation here seems biased given that it does not acknowledge >> that one of the reasons that ISPs do traffic class discrimination is >> to prioritize favored rather than disfavored traffic, regardless of >> user preferences. I don't believe that the IETF has taken a position >> for net neutrality, but I'm also pretty sure we don't have consensus >> against it. > > How about the following text: > This section does not consider traffic discrimination by service > providers related to NetNeutrality, where traffic may be favored > according to the service provider preference as opposed to the user's > preference. These use cases are considered out-of-scope for this > document as controversial practices. > >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> Pervasive Monitoring (PM) attacks on the privacy of Internet users is >> of serious concern to both the user and the operator communities. >> are of serious concern > > Thanks. >> >> Traditional network management, planning, security operations, and >> performance optimization have been developed in an Internet where a >> large majority of data traffic flows without encryption. While >> you have a plural/singular mismatch here. >> >> Authentication with IPsec [RFC7619] and there are a number of >> infrastructure use cases such as server to server encryption, where >> this mode is deployed. While OS is helpful in reducing pervassive >> Nit, no comma before "where" > > Done, thanks. >> >> recommendations from these documents were were built upon for TLS 1.3 >> to provide a more inherently secure end-to-end protocol. >> "were were" > > Already fixed, thanks. >> >> to-user content encryption schemes, such as S/MIME and PGP for email >> and encryption (e.g. Off-the-Record (OTR)) for XMPP are used by >> those interested to protect their data as it crosses intermediary >> Not, "e.g.," > > Fixed, thanks. >> >> been impacted by increases in encrypted traffic. Only methods >> keeping with the goal of balancing network management and PM >> mitigation in [RFC7258] should be considered in solution work >> resulting from this document. >> I don't understand what the normative content of this was. > > There is no normative content. Are you asking because the lowercase > should was used? > >> >> upgrades before user experience declines. For example, findings of >> loss and jitter in VoIP traffic can be a predictor of future customer >> dissatisfaction (supported by metadata from the RTP/RTCP protocol ) >> [RFC3550], or increases in DNS response time can generally make >> interactive web browsing appear sluggish. But to detect such >> problems, the application or service stream must first be >> distinguished from others. >> >> This is a little hard to read, but generally this information is not >> encrypted for SRTP/SRTCP. > > In looking at the text, the Secure version of RTP/RTCP isn't mentioned > and isn't cited as an issue. The text (from Dave Dolson, we think) > seems to say that any form of security that obscures the application > or service info of the stream complicates analysis as VoIP, or > analysis as <something else>. > > If this isn't clear enough, would you like to propose text? > >> >> When using increased encryption, operators lose a source of data that >> may be used to debug user issues. Because of this, application >> server operators using increased encryption might be called upon more >> frequently to assist with debugging and troubleshooting, and thus may >> want to consider what tools can be put in the hands of their clients >> or network operators. >> >> This is phrased as hypothetical, but is there any actual data to >> support this? We have a lot of experience now with encrypted voice and >> video as well as Web. Do those providers report any increased level of >> requests. > > This makes perfect sense. If you are troubleshooting and the data is > not available at the endpoint, the network is used. If that goes > away, logging and reporting at the endpoint has to improve. If you > take a look at the feedback from the OPsDir review, it had several > specific types of log improvements added into a paragraph early into > the document. I added a few more to that from other comments. > > In my operational experience as well as work with customers at EMC, > I've heard this comment as well and it was addressed. This is part of > why the increase in encryption with storage platforms is not a big hit > - tools were provided at the endpoint to fill the gap. > >> >> the new flow and would not be able to route it back to the original >> POP. >> >> I'm having a little trouble understanding this paragraph. Why is this >> about mobile operators? It seems like it's an issue for anyone who has >> a service that might have mobile clients. > > If you mean laptops/IP based devices on WiFi access, this works > differently at the routing layer than with cellular mobile phones. > Phones need to be able to transition seamlessly with migrations > (coordinated roaming). Other devices, like laptops on WiFi access, > might need this type of transition within a wireless managed > environment, but this is with APs that don't typically attempt to > preserve connection state. When IP based devices on WiFi access have > traffic traversing POPs, it's at the IP layer and the applications > handle continuity. The key difference between WiFi and cellular is > maintaining connection state. > >> >> effective at providing data offload when there is a network element >> close to the receiver that has access to see all the content. >> This section is also confusing in that it fails to distinguish between >> proxies >> of this type that the user opts into from transparent proxies that just do >> this >> service without the user's consent. Part of the purpose of encryption is to >> preclude that. > > This reads to me as if these are transparent proxies, so I'll add that > in to clarify the text further. Thanks. > >> >> created from the intercepting device to the client's destination, >> this is an opt-in strategy for the client. Changes to TLSv1.3 do not >> impact this more invasive method of interception, where this has the >> I don't understand the cite to TLS 1.3 here. None of this is presently >> affected >> by 1.3. > > This is saying that changes to TLSv1.3 do not impact this more > invasive method of interception explicitly, so I believe the text > already addresses your point. If not, could you please suggest text? > >> >> endpoints as a service reduces providers' ability to offer parental >> control. >> This section makes it seem like there are no other methods that allow for >> parental control, but that's not true. There are parental control mechanisms >> which rely on MITM proxies or application interfacing. > > The section NOW starts off with the following in the first paragraph > that should address your concern: > > This section is intended to document a selection of current > content blocking practices... > > I think this came from Benjamin's review - the section is not > exhaustive (neither is the draft as it was contribution driven). > > This text in the first paragraph should also help with your point: > Content blocking may also happen at endpoints or at the edge > of enterprise networks, but those are not addressed in this section. > > At the edge is a proxy/gateway MiTM solution. > > The next paragraph talks about proxies in the core or edge of a > network, these are also MiTM devices, so I think that's well covered. > > The following sentence in this section calls this out as MiTM behavior > explicitly: > > Changes to TLSv1.3 do not impact this more invasive method of > interception, that has the potential to expose every HTTPS > session to an active man in the middle (MitM). > > I ammended the following sentence in the last paragraph in case that helps > you: > > OLD: > This type of granular filtering could occur at the endpoint. > > NEW: > This type of granular filtering could occur at the endpoint or as a > proxy service. > >> >> HTTP headers and content are encrypted, this prevents mobile carriers >> from intercepting the traffic and performing an HTTP redirect. As a >> result, some mobile carriers block customer's encrypted requests, >> Yes, stopping traffic redirection is actually one of the major design >> purposes >> of HTTPS. > > Sure, there's not an issue other than the practice needs to change and > they need to figure out better ways to notify customers. It's raised > here in case better ideas can be developed and some operator may look > at the reference (RFC6108). Adam and Al were chatting on this as a > result of his review, so hopefully they make a little progress. > > I added the word appropriately as I think that will address your > concern. The operators just want efficient ways to notify their > customers, it doesn't have to be done this way, but they raised the > issue because they don't know what to do and I believe, want help. > > NEW: > When the HTTP headers and content are encrypted, this appropriately > prevents mobile carriers from intercepting the traffic and performing > an HTTP redirect. > >> >> to the customer and additional overhead to the mobile network service >> provider. >> This section is basically a commercial for this practice. It needs to >> acknowledge that it's actually much closer to IETF consensus that it's a bad >> practice. > > This text was already changed as follows: > > The customer may need to call customer care to find out the > reason and/or resolve the issue, possibly extending the time > needed to restore their network access. >> >> headers to accomplish the, sometimes considered controversial, >> functions above. >> Again, this is precisely the form of attack that HTTPS is intended to >> prevent. > > The following paragraph was added per conversations with Christian and > Martin. Hopefully, this also addreses your concern. The paragraph > mentioned was amended as well. > > NEW: > Guidance from the Internet Architecture Board has been provided > in [RFC8165] on Design Considerations for Metadata Insertion. > The guidance asserts that designs that share metadata only by > explicit actions at the host are preferable to designs in which > middleboxes insert metadata. Alternate notification methods that > follow this and other guidance would be helpful to mobile carriers. > >> >> perform SSL/TLS decryption are impacted by the increased use of >> encryption that prevents interception. >> I don't really understand what this text means. What is "use of encryption >> that >> prevents interception" in the context of tools which already do decryption? > > This reads clear enough to me, but would you be happier with: > > s/impacted/no longer functions/ > > It's referring to encryption that prevents interception, not talking > about proxies which still can be used technically. This change has > not been made yet, so please let us know if this helps or if you have > another suggestion. > > >> >> [DarkMail]. Of course, SPAM filtering will not be possible on >> encrypted content. >> This is not strictly correct, as you can still header filter, etc. > > It seems a few words were trimmed in what you have quoted above. > Here's the full sentence: > > Of course, content-based spam filtering will not be possible on > encrypted content. > > I'm not sure what happened there as I don't think this was a recent > fix. The sentence was in context of content-based filtering. > > In much earlier versions of this draft, there was mention of efforts > that would encrypt email header information to protect privacy > discussed a couple of years ago (SAAG and a spin off list) - which is > a good thing to do. If that happens operations are impacted and that > would require discussion to develop new approaches for spam filtering > and other email based attack prevention techniques. > >> >> over the Internet. Options for monitoring will vary with each >> encryption approach described below. In most cases, solution have >> been identified to provide encryption while ensuring management >> Nit: "solutions have" > > Already fixed, thanks. >> >> allow for multiple end user sessions to share the same TCP >> connection. This rasises several points of interest with an >> increased use of encryption. TCP session multiplexing should still >> Typos: rasises > > Fixed, thanks. >> >> be possible when TLS or TCPcrypt is in use since the TCP header >> information is exposed leaving the 5-tuple accessible. The use TCP >> session multiplexing of an IP layer encyption, e.g. IPsec, that only >> I'm not sure if this is correct. What precisely do you mean by "TCP >> session multiplexing"? A cite would be helpful here. > > It's described in section 4.1.3.2: > > TCP pipelining/session multiplexing used mainly by > middleboxes today allows for multiple end user sessions > to share the same TCP connection. > >> >> center. HTTP pipelining requires both the client and server to >> participate; visibilty of packets once encrypted will hide the use of >> HTTP pipelining for any monitoring that takes place outside of the >> Typo: visibility > > Fixed, thanks. >> >> traffic cannot be intercepted, encouraging alternate options such as >> performing these functions at the edge. >> I'm not seeing the relevance of this. Who is proposing solutions in which >> encrypted traffic cannot be intercepted at the outgoing network edge. > > The only option here for this described usage is a proxy where the TLS > 1.3 session is terminated and restarted. If you look back to slides > from Stephen on PM and advancements resulting from PM being considered > an attack, one of the ideas to make TLS stronger was DANE > authentication to provide a way to know you truly have an e2e session > - a very good thing. The draft on the last telechat: > https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ > that should be approved soon is able to do this with some middleboxes, > but I'm not sure what happens with a proxy - so I asked the editors > for clarification. If this just doesn't work and the session proceeds > without this extension, there is nothing to notify on. If this is > something proxies should be aware of to allow through unhampered, it > would be good to include a little more text. For instance, in > corporate networks certain traffic with PII, like financial > transactions, are not proxied and would benefit from using this > extension, giving their users assurance in the security of their > sessions. In some cases, alternate options are available when encryption is in use through a proxy or a shift to monitoring at the endpoint. In both cases, scaling is a concern and advancements to support this shift in monitoring practices will assist the deployment of end-to-end encryption. Best regards, Kathleen > >> >> owing to concealment of critical headers and payloads. Many forms of >> enterprise performance management may be similarly affected. >> Again, this is sort of transparent caching is an anti-pattern, so this >> document >> ought to acknowledge that, > > I added the following text at the end of this paragraph to address your > concern: > It should be noted that transparent caching is considered an anti-pattern. > > If you have alternate text to suggest, please do! > > >> >> parts of the address assignment/management protocols, critical for >> SAVI mechanisms, can result in a dysfunction of the SAVI mechanisms. >> Does anyone actually deploy SAVI? If not, encryption isn't having much of an >> impact. > > It appears to be the case with drafts being published as recent as 2017: > https://tools.ietf.org/html/rfc8074 > > And I'm told it is widely deployed in China. > >> >> network filters look out for seeing a Server Name Indication >> extension, they may not find one. The SNI Encryption in TLS Through >> Tunneling [I-D.ietf-tls-sni-encryption] draft has been adopted by the >> This doesn't really follow. I mean they "may not" but overwhelmingly they >> will > > I'm not sure when the text was changed, but it already has been changed from. > > OLD: > > This information is only visible if the client is populating the > Server Name Indication extension. This need not be done, but may be > done as per TLS standard and as stated above this has been > implemented by all major browsers. Therefore, even if existing > network filters look out for seeing a Server Name Indication > extension, they may not find one. > > NEW: > This information is only available if the client populates the Server > Name Indication extension. Doing so is an optional part of the TLS > standard and as stated above this has been implemented by all major > browsers. Due to its optional nature, though, existing network filters > that examine a TLS ClientHello for a SNI extension cannot expect to > always find one. > >> >> > > > > -- > > Best regards, > Kathleen -- Best regards, Kathleen _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg