Internet DRAFT - draft-taddei-ech4ent-introduction
draft-taddei-ech4ent-introduction
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,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
8.2. Informative References
[CAMPLING] Campling, A., Vixie, P., and D. Wright, "Encrypted Client
Hello Deployment Considerations", 7 March 2022,
<https://datatracker.ietf.org/doc/draft-campling-ech-
deployment-considerations/>.
[CLESS] Taddei, A., Wueest, C., Roundy, K., and D. Lazanski,
"Capabilities and Limitations of Endpoint Security
Solutions", 13 July 2020,
<https://www.ietf.org/archive/id/draft-taddei-smart-cless-
introduction-03.txt>.
[MAGECART] Wikipedia, "Magecart", 3 April 2022,
<https://en.wikipedia.org/wiki/Web_skimming#Magecart>.
[MALVERTISING]
Wikipedia, "Malvertising", 2 June 2022,
<https://en.wikipedia.org/wiki/Malvertising>.
Taddei & Edwards Expires 12 January 2023 [Page 11]
Internet-Draft ech4ent July 2022
[MITB] OWASP, "Man-in-the-browser attack", n.d.,
<https://owasp.org/www-community/attacks/Man-in-the-
browser_attack>.
[MITB-MITRE]
MITRE, "Browser Session Hijacking - T1185", 25 February
2022, <https://attack.mitre.org/techniques/T1185/>.
[NIST-DID] NIST, "Glossary - defense-in-depth", n.d.,
<https://csrc.nist.gov/glossary/term/defense_in_depth#:~:t
ext=Definition(s)%3A,and%20missions%20of%20the%20organizat
ion.>.
[OPSECNSIMPACT]
Cam-Winget, N., Wang, E., Danyliw, R., and R. DuToit,
"Impact of TLS 1.3 to Operational Network Security
Practices", 26 January 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-opsec-
ns-impact-04>.
[SMART] McFadden, M., "BCP72 - A Problem Statement", 21 January
2022, <https://datatracker.ietf.org/doc/draft-mcfadden-
smart-threat-changes/>.
[SOLARWIND]
Symantec, a Division of Broadcom Software Group,
"SolarWinds (Sunburst) Attack What You Need to Know",
December 2020, <https://symantec.broadcom.com/en/
solarwinds-sunburst-attacks>.
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]
