Internet Engineering Task Force A. Taddei, Ed. Internet-Draft S. Edwards, Ed. Intended status: Informational Broadcom Expires: 12 January 2023 11 July 2022 ECH for Enterprises and Organizations draft-taddei-ech4ent-introduction-00 Abstract This paper reviews some of the Enterprises and Organizations requirements and constraints and tests the current Encrypted Client Hello (ECH) proposal in these environments. In particular it highlights the need for several clarifications as well as highlights known attack vectors which will become easier with the current ECH proposal. The current ECH drafts should consider how they want to include enterprises operational security capabilities to mitigate these attacks. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 12 January 2023. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. Taddei & Edwards Expires 12 January 2023 [Page 1] Internet-Draft ech4ent July 2022 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Need for clarification on the ECH proposal . . . . . . . . . 3 2.1. DNS impact . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Client Facing vs Backend Servers need a lot of clarification . . . . . . . . . . . . . . . . . . . . . . 3 3. Enterprises and Organizations need for Operational security . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Threat landscape . . . . . . . . . . . . . . . . . . . . 4 3.2. Implications to Enterprises and Organizations . . . . . . 4 3.3. The main requirements . . . . . . . . . . . . . . . . . . 4 3.4. Evolution of defence approaches . . . . . . . . . . . . . 5 3.5. The need for Network based security . . . . . . . . . . . 5 3.6. Network Security deployment . . . . . . . . . . . . . . . 8 4. Client Complications . . . . . . . . . . . . . . . . . . . . 8 4.1. Devices are not trustable . . . . . . . . . . . . . . . . 8 4.2. Attacks targeting the web browser . . . . . . . . . . . . 8 4.3. Defence in Depth . . . . . . . . . . . . . . . . . . . . 9 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 11 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 12 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction This document aims to contribute to section 5 of [CAMPLING]. Enterprises and Organizations are both offering online services to their customers and support their own digital organization. As such: * On one hand, they have the requirement that their customers receive their services with a good level of Confidentiality, Integrity and Availability Taddei & Edwards Expires 12 January 2023 [Page 2] Internet-Draft ech4ent July 2022 * On the other hand, they need to reduce their risks, protect their reputation (and all associated aspects), while at the same time complying with a diverse and growing list of policies, regulations, certification, labelling and guidelines. The current ECH proposal is calling for attention on both aspects with the need for clarification on how ECH (and DNS) will really work in these production environemtns and at the same time how ECH will affect operational security. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Need for clarification on the ECH proposal The current ECH proposal shows a very complex setup requiring a new Hybrid Cryptography, a significant change in the DNS with new Record Resources (RRs) and the introduction of splitting the backend servers into client facing server and backend servers (in shared or split mode). 2.1. DNS impact The current mechanism of the ECH vector needs a way that the client can retrieve that vector and a choice was made to use the DNS for this purpose. Yet this requires to add new RRs with a substantial amount of new data. It seems like this proposal is definitely moving the DNS as it is today into a 'Directory Service for Domains'. What would be the consequences of making such a radical direction change into the DNS? Was there any study that shows potential impacts on the overall DNS service from various design criteria perspective? 2.2. Client Facing vs Backend Servers need a lot of clarification It is understood that ECH needs to establish the split of the targeted servers into a Client Facing and a Backend server (whether in shared or split architecture). However it is extremely unclear on how these should be setup and how they will communicate. Even if this is to be left to "implementation", this interaction requires clarification and at minimum a more pedagogic explaination and step by step approach in the different cases. Some additional questions: * Are these Client Facing servers meant to be hosted only by CDNs? Taddei & Edwards Expires 12 January 2023 [Page 3] Internet-Draft ech4ent July 2022 * Are these Client Facing servers a new middlebox model where a number of auxiliary services (e.g. security services) could be provided? * How will these changes affect the way network security and monitoring is carried out by companies and organisations today, to protect their own employees and data ? 3. Enterprises and Organizations need for Operational security 3.1. Threat landscape The general threat landscape which was already very large (see [SMART]), has significantly increased since the COVID crisis. Indeed as the crisis forced many enterprises and organizations to accelerate their digital transformation, it increased the opportunity for the cyber criminals and nation states to launch more attacks, leverage innovations to their advantages, better select their targets, increase their efficiency and increase their rewards, in particular with Ransomware based attacks. 3.2. Implications to Enterprises and Organizations Attacks are now damaging Enterprises and Organizations in increasing severity: * Loss of revenue with an average between 11-24% * Loss in capitalisation between 1-5% * Degradation by credit notation agencies Since the damage is so high, some cyber insurances companies in some countries prefer to pay the ransom to mitigate the damage which has the unfortunate side effect of funding and encouraging cybercriminals to increase their attacks! 3.3. The main requirements Enterprises and Organizations need to protect themselves for a vast number of reasons, mainly: * Reduce their Risks. And in particular as part of any Cyber Resilience strategy. * Protect their Reputation. The term Reputation includes many aspects way beyond the traditional enterprises and organization assets (data, etc.). Taddei & Edwards Expires 12 January 2023 [Page 4] Internet-Draft ech4ent July 2022 * Comply to a growing diverse set of Policies, Regulations, Certifications, Labelling and Guidelines. This set of artefacts is increasing by countries and regions in the world, by the nature of the object of the artefact (just in the EU: NIS, EBAG, DORA, NIS2, etc.), by the changes of roles (e.g. the ENISA is now carrying a Certification Mandate), etc. 3.4. Evolution of defence approaches The defence approaches evolved in the past decades with a few milestones: several key formal work on security were developed in the 70s and the 80s and ended up in X.800 being apparently the last formal, international consensus based security architecture. Then several works moved security from a pure on premise perimeter defence model, to a tiered/layered defence, to defence in depth, to Jericho Forum, to Beyond corp, to Zero Trust and to Secure Access Service Edge (SASE). On the way, the community and the operational security practioners across all the enterprises and organizations on any size and any vertical, incrementaly recognized: * Security cannot rely on just one solution. Just like in other areas such aircraft safety, an aircraft would have multiple alternative components, systems and methods to decrease the probability of hiting a unique point of failure. Several measures are used in conjunction with each other to provide defence in depth safety so if one layer fails a another layer can provide coverage * Compartmenting perimeters (regardless on how big or small their granularity is), like in a submarine, is a good approach to resiliency * Not trusting anyone, anything, neither the device, nor the network, nor the service endpoints (servers, clouds, etc.), nor the application, nor the logs, etc. is a good practice * The acceptance that breaches will occur; and that minimising the impact of such a breach (through developing a strong Cyber Resiliance) and through the adoption of Zero Trust is best practice 3.5. The need for Network based security In general [OPSECNSIMPACT] covered several aspects of the impacts of pervasive encryption to Operational Network Security Practices. We will remind some of aspects in the following way: Taddei & Edwards Expires 12 January 2023 [Page 5] Internet-Draft ech4ent July 2022 The history of network based attack detection is a long one, dating back to the mid-1990's with the first Intrusion Detection Systems (IDS) and Proxies. These started off being fairly simple systems which would look in the network traffic for certain string types and then alert when seen. As such they tended to simply look at Layer 4 traffic and did not understand the behaviours of certain protocols, and so was highly prone to false positives. Over time the technologies developed and became more protocol aware and as the accuracy improved so did the confidence to actually block attacks before they reached the targeted endpoint; IDS became Intrusion Prevention. At a higher protocol level Proxies have fundamentally not changed much at all, in essence they look at the HTTP connection and extract the Server Name Identification (SNI) and then check that against a list of known good or bad sites and then block or allow. But they have evolved to allow integration with other security products, such as sandboxes, to extract the payload and analyse for malware embedded in that content. In all cases these 'boundary controls' have been essential to organisations in trying to protect their users from malicious attacks coming in from the Internet. But this only considers the inbound traffic, what about what users are sending out of an organisation ? This is where Data Loss Prevention (DLP) controls come in; allowing organisations to look for company confidential data, Personal Identifiable Information (PII), and financial data (such as credit card data) and stop it egressing the organisation. Not only are these controls used to protect the organisation, but they are also essential from a legal and compliance point of view due to legislation such as GDPR and PCI. Taddei & Edwards Expires 12 January 2023 [Page 6] Internet-Draft ech4ent July 2022 Increasingly the need for network centric security controls has grown, but counter to this has been the ever increasing use of encryption. In the 1990's the amount of internet traffic that was encrypted was very small, which easily allowed the traffic and its content to be checked. But today almost all communication is encrypted and so the job of monitoring it has also become harder to achieve. From a Proxy perspective, simply looking at the SNI address of where the traffic is destined allows for malicious traffic (such as malware talking to a Command and Control (C&C) server) to be blocked on the Proxy or Firewall. But in order to read deeper into the traffic Deep Packet Inspection (DPI) relies on using a network intermediary to sit between the client and the server it is connecting to, to decrypt the traffic, analyse it and then re-encrypt and send on to the destination. Again, being able to analyse the SNI allows these systems to only decrypt the traffic that the organisation is interested in, which is called 'selective decrypt'. So normal user activity such as connecting to a news site or social media can be ignored while traffic destined for an online email system can be decrypted and inspected for malware and DLP controls. So why can all this essential analysis not be carried out on the endpoint? In theory it can, but there are several problems and limitations with this approach. One problem is that this endpoint software can be turned off and disabled. Even today, most endpoint security software (be it DLP or antimalware based) does not have Tamper Controls built into it. And as can be seen from many high profile attacks, such as the recent Sunburst attack that targeted the [SOLARWIND] supply chain, the first thing that malware did was disable the anti-malware system so that attack would succeed. So, the need for network security as a Mandatory security control is much more effective than having endpoint based controls which can be turned on and off (and as such can be seen as a Discretionary control). The second problem arise because more and more organisations are moving applications and services to the cloud and the web browser has become the ubiquitous method to connect to these applications. An increasing focus for security is on protecting the web browser from being the initial attack vector and so ensuring the content is clean and trusted by the time it arrives at the browser adds significant security benefit. The third problem is that to truly run the full set of defence in depth analysis on the endpoint will cripple many endpoints due to compute and memory required for the full analysis. Adding security in the network mitigates all of these difficulties. Taddei & Edwards Expires 12 January 2023 [Page 7] Internet-Draft ech4ent July 2022 3.6. Network Security deployment To our knowledge, all fortune 500, fortune 2000, and likely the vast majority of enterprise customers deployed a network security solution for decades. This is both motivated by the nature of the attacks, the compliancy requirements, but as well by costs as it is easier to manage security from the network vs the endpoint (see below). 4. Client Complications 4.1. Devices are not trustable As [CLESS] showed before its work was stopped, is that a strategy pushing security to only the two endpoints of a communication is doomed to a lot of trouble as the spectrum of limits affecting endpoint security solutions is a very big gap that has not been resolved in the past decades and won't be in any short term. 4.2. Attacks targeting the web browser As discussed, the web browser has now become the primary method used by users to access applications and services on the internet. Hackers know this and so increasingly use attacks that aim to compromise the browser including by performing and enabling a Man in the Browser [MITB] attack, codified at T1185 in MITRE ATT&CK framework [MITB-MITRE]. In the first instance we have Phishing attacks, which trick the user into clicking on a malicious link or opening a malicious file. Hackers create domains that look like legitimate websites which often are related to delivery companies or tax offices (and these can be blocked at the network level through analysing the SNI to understand the age of a domain or whether it is known bad). To evade this hackers, have become more stealthy by using legitimate domains (such as aws.amazon.com or other similar internet hosting sites) but then embedding the malware in the website code itself (i.e. HTML or Java). In these cases, knowing the SNI is necessary but not sufficient (because it is essentially legitimate), so proper analysis on the whole page itself is much more important. In this case the web browser will not protect the user as it requires proper analysis, which can be done in transit from analysing the network traffic. Taddei & Edwards Expires 12 January 2023 [Page 8] Internet-Draft ech4ent July 2022 Other attacks work by compromising the legitimate website itself. [MALVERTISING] (malicious advertising) attacks work by creating fake adverts that then get displayed on legitimate websites. In many cases the user can get infected by simply viewing the advert and again it is not always possible to stop these attacks with simply the SNI data; The SNI is necessary but it is only when the specific code hidden in the advert is analysed that the attack is detected and stopped. This, again, cannot be done in the browser alone. [MAGECART], or Web Skimming is a common form of attack which is intended to steal PII and credit card data. Hackers compromise legitimate websites, typically ecommerce related, and add JavaScripts which skim the credit card data used by a customer and send that data to the hacker. Other attacks will distribute the malware loaders to the user so again they get compromised by simply viewing the otherwise legitimate website. In both cases simply looking at the SNI server data is necessary but insufficient; and that the whole page needs to be analysed to detect the malicious code. Users themselves can also be targeted directly through Social Engineering. A common technique is to use legitimate social networks, like LinkedIn, to lure targeted users to open malicious files or links. So the hacker would appear to be a legitimate job recruiter with news of a new job opportunity, 'please read this job description' is the lure, the user clicks on the link or opens the document and the host is compromised. These communications are almost always encrypted and may use specific chat channels to send the malware through; the site itself is good and so it is only through analysing every object being received on the host, can the malware be detected. Finally the browser itself can be compromised by the user themselves, by installing what looks to be legitimate plug-ins for the browser, but in fact they collect browsing habits or may log keyboard activity. 4.3. Defence in Depth The concept of Defence in Depth is not a new one [NIST-DID], but it is still highly relevant today. Put simply, Defence in Depth is about creating multiple layers of defence to stop hackers. Normal internet traffic relies first on the DNS resolution and as discussed this can be a simple and effective way to block know bad sites i.e. check the domain name against a list of bad sites, or analyse the age of the domain and return a zero value if the site is known bad or has only existed for a short period of time. Taddei & Edwards Expires 12 January 2023 [Page 9] Internet-Draft ech4ent July 2022 Next as the HTTPS connection is made, checking the SNI, decrypting the traffic, and analying its content will ensure nothing sensitive is being sent or anything malicious is being received. Again, if anything is detected as bad, then block the request/response. This therefore forms the first levels of defence, it should also be noted that this network analysis no longer must be down on-premise or as a traditional boundary defence, but can also be routed through an online service in the model of SASE (Secure Access Service Edge) allowing for greater flexibility for remote users and users working from home. On the endpoint, deploy anti-malware and DLP agents which can analyse the data and activity on the endpoint (remembering to make sure there are controls in place to stop the software from being deactivated!) and this forms the final line of defence. And this really is the point, there will always be a need to deploy agents on the endpoint of devices managed by the organisation; but these should only be thought of as that last line of defence, and not the only line of defence! It is also worth considering the increase in devices that are not managed by the organisation - Bring Your own Device (BYOD); how can an organisation protect these devices and ensure that data is not being leaked? The only way to really protect these devices relies again on network based analysis for malware and DLP etc. 5. Conclusions This document reminds on the Enterprises and Organizations environments, constraints and requirements. It shows too that the current ECH drafts will implicitly: * Leave the security responsibility to the browser and the client facing server * The browser cannot be judge and jury as if it is compromised, it cannot act properly to protect end users * The client facing server is becoming a new middlebox which is creating a number of problems * There is a need for a 3rd party security to add credentials to the solution This leaves a few questions to the the current ECH drafts: * Can the impacts of ECH on DNS and on the Client Facing vs Backend servers be clarified? * Can the problems of enterprises and organizations be acknowledged? Taddei & Edwards Expires 12 January 2023 [Page 10] Internet-Draft ech4ent July 2022 * If not, then this will leave little choices to the defenders to use a protocol based clean solution * If yes, then what could be the suggestions to include operational security in the ECH design 6. IANA Considerations This memo includes no request to IANA. 7. Security Considerations This document should improve the security of the Internet. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 8.2. Informative References [CAMPLING] Campling, A., Vixie, P., and D. Wright, "Encrypted Client Hello Deployment Considerations", 7 March 2022, . [CLESS] Taddei, A., Wueest, C., Roundy, K., and D. Lazanski, "Capabilities and Limitations of Endpoint Security Solutions", 13 July 2020, . [MAGECART] Wikipedia, "Magecart", 3 April 2022, . [MALVERTISING] Wikipedia, "Malvertising", 2 June 2022, . Taddei & Edwards Expires 12 January 2023 [Page 11] Internet-Draft ech4ent July 2022 [MITB] OWASP, "Man-in-the-browser attack", n.d., . [MITB-MITRE] MITRE, "Browser Session Hijacking - T1185", 25 February 2022, . [NIST-DID] NIST, "Glossary - defense-in-depth", n.d., . [OPSECNSIMPACT] Cam-Winget, N., Wang, E., Danyliw, R., and R. DuToit, "Impact of TLS 1.3 to Operational Network Security Practices", 26 January 2021, . [SMART] McFadden, M., "BCP72 - A Problem Statement", 21 January 2022, . [SOLARWIND] Symantec, a Division of Broadcom Software Group, "SolarWinds (Sunburst) Attack What You Need to Know", December 2020, . Acknowledgements This internet draft wants to recognize the systematic efforts of Andrew Campling who provides the so-called DNS call every Monday at 5pm CEST. Contributors Eric Chien Broadcom Email: Eric.Chien@broadcom.com URI: https://www.linkedin.com/in/eric-chien-66b4b258/ Eric contributed to the analysis of the Man in the Browser attacks. Authors' Addresses Taddei & Edwards Expires 12 January 2023 [Page 12] Internet-Draft ech4ent July 2022 Arnaud Taddei (editor) Broadcom 1320 Ridder Park Dr San Jose, CA 95131 United States of America Phone: 41795061129 Email: Arnaud.Taddei@broadcom.com URI: https://www.linkedin.com/in/arnaudtaddei/ Simon Edwards (editor) Broadcom 1320 Ridder Park Dr San Jose, CA 95131 United States of America Email: Simon.Edwards@broadcom.com URI: https://www.linkedin.com/in/simononsecurity/ Taddei & Edwards Expires 12 January 2023 [Page 13]