Transforming Information Security

Optimizing Five Concurrent Trends to Reduce Resource Drain

Kathleen M. Moriarty

• Publisher: Emerald Publishing Limited
• Year: 2020
• Print ISBN: 9781839099311
• eBook ISBN: 9781839099304
• Topic: Informatica
• Subtopic: Crittografia

The information security industry is undergoing a major change, forced by the rise of end-to-end encryption, encryption that cannot be intercepted, transport protocol stack evolution, "zero trust networks", and distributed computing. While we understand the logical connections between these trends, there is little analysis of all of these trends in combination. Examination of all five trends uncovers opportunities that not only improve the state of information security and the general posture, but also lead to resource reductions necessary for information security to be sustainable.

In this exciting new book from security expert Kathleen M. Moriarty, the examination of all five trends uncovers opportunities to change the state of information security. Providing a unique perspective from the center of the debates on end-to-end encryption, Moriarty explores emerging trends in both information security and transport protocol evolution, going beyond simply pointing out today's problems to providing solutions for the future of our product space.

1

Interconnected Trends

There are at least five trends, when interconnected, that have the potential to result in a dramatic shift in how information security is managed today, for the better. Within each trend, there are some inevitable outcomes as well as interdependencies with other trends that are not often considered together to better map out a forward path. The trends include:

• increased deployment of encryption,
• strong session encryption, preventing interception,
• transport protocol stack evolution,
• data-centric security models, and
• users control of data.

While much work is happening within each trend, these trends are not typically all considered together. To realize positive change and reduce the overall threat space, it is imperative that we do just that. This chapter will explore each of the trends and how they interconnect to set the stage for the proposed changes and deeper technical considerations discussed in the book as the trends are embraced. The increased deployment of strong encryption supports data-centric architectures and is contributing to the transport protocol stack evolution. User control of data is a desired outcome for those looking to protect user’s privacy; however, work to support this trend is at an early stage. The general theme of the inability to manage information security as it is architected today, due to insufficient resources, will be explained detailing how embracing these trends and new architectural patterns improve efficiency and reduce resource requirements.

1.1 Increased Deployment of Encryption

While the Snowden revelations (Gidda, 2013) starting in June 2013 led to an immediate increase in deployed session encryption, trends in standards development also shifted. The fundamental shift in standards was driven by the acceptance of less-than-perfect security in favor of deployability, leading to a sharper increase in deployed encryption starting around 2017. Examples of this include Opportunistic Security (Dukhovni, 2014) and the Internet Engineering Task Force (IETF) Automated Certificate Management Environment (ACME) (Internet Engineering Task Force, 2020h). Opportunistic security enables an upgrade path from clear text sessions to sessions encrypted without authentication, to authenticated session encryption. It is important to note that opportunistic security is breakable, but allows for easy automated configuration without knowledge of the other endpoint. Prior to this shift, such efforts would not have gone anywhere since the unauthenticated session could be intercepted, leaving you with no security. From a purist point of view, that was not acceptable in the past, but now there's a justification. Opportunistic security raises the cost for pervasive monitoring, resulting in an in-feasibility to monitor all sessions passively. If nation states or malicious actors want to monitor traffic in this model, specific sessions would be targeted for decryption and observation.

While we haven't seen much deployment outside of opportunistic security use with IPsec (Internet Engineering Task Force, 2020d), automated certificate management is enjoying huge success via the Let's Encrypt project. Sessions not previously encrypted have used ACME via Let's Encrypt to automate the management of certificates, improving privacy protections for end users. While Let's Encrypt offers certificates for free, the ACME protocol can be used by other certificate providers who are interested in automating maintenance of certificates, including any type of certificate. An out-of-band process may be required for identity proofing of individuals and organizations for Extended Validation (EV) certificates or other certificate types. If you are not already using ACME, it should be considered a way to ease certificate management and say goodbye to the days where an expiring certificate causes extensive server outages without anyone realizing the root cause. Now, with automation needless downtime due to certificate management problems can be avoided.

The initial increase of deployed encryption on the web rose to around 30% in 2014, the year following Snowden revelations. ACME's automation and free certificates from the Let's Encrypt project helped that number climb to 85% in 2020 (Let's Encrypt, 2020) (Fig. 1.1).

Source: https://letsencrypt.org/stats/

Fig. 1.1. Percentage of Page Loads Over HTTPS by Region.

This trend of pervasive encryption will continue now that session encryption is easier to deploy and there's ample motivation.

1.2 Strong Encryption

End user privacy, human rights protections, and prevention of protocol ossification are the primary drivers for the trend strengthening transport protocol encryption. Encryption is being designed to prevent interception and limit the exposure of previously exposed meta-data. When considering end user privacy, it's not only session content that can reveal sensitive information, but also meta-data. Meta-data and session signaling information may enable tracking of user sessions across the network with any identifier or combined set of unique data that can identify the communicating parties. The meta-data of the communication session may provide insight as to the two parties communicating (hostname and Internet protocol information), length of the session, amount of data exchanged, possibility of identifying encapsulated protocols, and types of data exchanged.

Privacy considerations for the end user have been a major driver for the increased deployment of strong encryption and a reduction in availability of session meta-data. Transport architects and engineers are grappling with the go forward options to manage networks in an encrypted world. There has been some work to catalog the usage of data and meta-data and the goals of the monitoring performed prior to this shift in encryption (Moriarty & Morton, 2018). This impact is felt more by the enterprise than service providers as shown with a slower move toward adoption of strong encryption.

Transport layer protocols using provably secure strong encryption began to emerge in 2018. Deployment may have more limited success in environments where data is expected for monitoring (e.g., within the enterprise) near-term, the research from the cited survey indicates that deployment of these protocols should not suffer on Internet bound connections. The reason for this is that service provider monitoring is typically limited to the available protocol header information at the transport protocol, network, and link layer. These header fields will continue to be available with the current set of emerging transport encryption protocols including Transport Layer Security (TLS) version 1.3 (Rescorla, 2018), QUIC (Internet Engineering Task Force, 2020e), and TCPcrypt (Internet Engineering Task Force, 2020g).

A goal for an end-to-end encryption protocol is that the session initiates at the client application (web browser, streaming video application, etc.) and terminates at the server destination, thereby protecting the session across the entire transit of the network. In reality, the session likely terminates at a load balancer instead of a web server and may include some inspection at this point of termination. The load balancer termination point may be considered the server end point in today's web server architecture schemes. If there are additional servers, including application servers, content servers, databases, etc. used to deliver the return session content to the end user or client, there may be additional encrypted streams established from the terminating load balancer to these other systems and applications. The subsequent sessions may or may not use the same encryption protocol as the initiating transport encryption protocol of the client. A simplified illustration is provided in Fig. 1.2.

Fig. 1.2. Edge Termination to Data Center.

Internet bound sessions have different security and privacy considerations from those within a data center, hence the possible variance on protocol selection for sessions within a data center from Internet bound sessions. For instance, human rights considerations in protocols (ten Oever & Cath, 2017) include many existing security and privacy controls, but add anonymity and pseudonymity as important to the design for end user protection. Users shouldn't have to fear for their safety when performing research on health-related or other similar queries that may be restricted or prohibited in some regions. When speaking on a panel in Geneva, organized by the Internet Society in 2015, another panelist told his story where he wanted to do research on the pros and cons of circumcision in his country in Africa, but was fearful for his life due to regional beliefs on this practice. This is just one of hundreds of examples where human rights considerations are sometimes factored into protocol design. The drivers are important as is the trend of increasing design and deployment of strong transport encryption. The threat landscape has evolved beyond basic confidentiality for information security to include protection from session interception (passive or active hijacking), user privacy, and human rights considerations partly due to pervasive monitoring of governments.

1.3 Transport Protocol Stack Evolution

It seems to me that we're morphing into a really interesting protocol stack, where UDP is the transport protocol but QUIC is the REAL transport protocol, and IPv6 is the networking protocol, but GENEVE is the REAL networking protocol.

Spencer Dawkins, IETF Transport Area Director 2018.

The transport stack is evolving, partially a result of the need to develop and innovate Internet transport in response to the proliferation of middle-boxes that intercept and sometimes modify existing well-deployed protocols. End-to-end transport encryption helps toward this goal. Application developers are highly motivated in this push for strong encryption to allow for innovation in protocols supporting their applications. This is one reason why the protocol stack evolution starts from the application layer encryption protocols in addition to that being the point in the stack to protect end user data in transit. To be explicit, TLSv1.3 and QUIC are a couple of protocols driving the work of transport and routing engineers at lower layers for this now necessary protocol stack evolution.

The use of UDP and strong transport encryption is an attempt to address the ossification of existing network protocols and allow for innovative end-to-end protocol development.

TCP based applications are often intercepted and sometimes modified by middle-boxes. UDP has not been intercepted in general, having been deployed for connectionless query/response applications like DNS in the past,

Spencer Dawkins.

Performance benefits have been noted with applications using UDP and QUIC as a result. Through research, instances where UDP has been rate limited has been discovered as high usage may be interpreted by a middle-box as a DoS attack. Simply phrased, if traffic is not intercepted, the end points are free to evolve the protocol without fear that any update could cause the protocol to be blocked in its path. If the use of UDP is fully encrypted, including signaling information, packets cannot be modified in transit.

This all sounds very positive in that protocols may continue to evolve and protocol designers can be innovative in their solutions while protecting the privacy of end users. While those are both laudable goals, this leaves open questions for transport protocol engineers who focus on congestion control, performance, availability, and other traffic and operations management tasks that rely upon header information that has been available in transport protocols to date. Herein lies the tussle that has become a bit of an arms race between application developers who can evolve their protocols more easily if transport remains intact and the management of networks that has relied on visibility into packet streams to perform network and security management. For service providers, the visibility has been limited to publicly available transport, network, and link layer packet header data (Moriarty & Morton, 2018).

In terms of active development in transport protocols, development has been limited to UDP for transport in recent years in an effort to prevent protocol ossification. QUIC is one example that uses UDP as a substrate. QUIC is an encrypted transport protocol, using TLSv1.3 secure handshake for authenticated key exchange intended for real-time or latency sensitive applications (e.g., streaming media, gaming, and VoIP services). Google runs QUIC between Google services and Chrome browsers and is gaining adoption elsewhere (Jan, 2018). For the enterprise, the business justification to allow QUIC into networks has not yet been made. While deployments like that at Google exist and are likely to expand, the use cases for the QUIC protocol are limited at the moment. When speaking at RSA Conference and Dell Technologies World 2018, attendees said who were aware of QUIC were outright blocking it from their enterprise networks. There was no perceived business imperative for many enterprises to allow QUIC, limiting deployment. Increased use of streaming protocols to facilitate business calls may tip the balance in the near future for the performance gains, improving call quality. Having said that, QUIC does allow for protocol innovation and evolution and we will continue to see standard efforts pushing for increased encryption of signaling information as well as packet payloads to combat the protocol ossification problem.

Transport engineers, operators, and network managers are looking for options lower in the stack to ensure the monitoring functions performed to manage traffic may continue. There are a few paths in exploration right now with no clear winner. In my opinion, the simplest and most likely to be deployed option is IPv6 (Deering & Hinden, 2017) with packet header information such as the Flow Label (Amante, Carpenter, Jiang, & Rajahalme 2011) and the Destination Options Header extension (Elkins, Hamilton, & Ackermann, 2017). The challenge with this option is that global deployment of IPv6 was at about 25% in 2018 (Internet Society, 2018), although increasing, more work needs to be done. This is a viable option because many systems now support IPv6 without any work needed by the end user, including mobile devices. Another challenge with IPv6 is that the header extensions are sometimes dropped by middle-boxes (Gont, Linkova, Chown, & Liu, 2016). Interoperability testing on the recent IPv6 revision in RFC8200 (Deering & Hinden, 2017) should help to close this gap. This update, an interoperability testing, ensures header extensions are an expected part of the standard, reducing the rate packets are dropped since the results posted in 2016 [RFC7827]. While the Hop-by-Hop header extension may seem like another possibility, it has some issues as cited in RFC8200 Section 4.8. This extension may be modified at hops along the path, unlike the Destination Options header that is meant for end-to-end usage that may trigger the use of a slow processing path.

Alternatively, there has been a proposal from several well-respected transport engineers in the IETF to add a layer to the stack for measurement. “A Path Layer for the Internet: Enabling Network Operations on Encrypted Protocols” (Kuhlewind et al., 2017) describes the network ossification that has led to the increased use of encryption along with their solution to add a path layer called, Path Layer UDP Substrates (PLUS).

The obstacles to implement and deploy this additional protocol layer with useful packet headers for measurement may be quite high. Considering IPv6 headers have experienced difficulty at middle-boxes after 20 years of existence as a standard, it is likely that the path to deployment for something like PLUS would be quite difficult.

The PLUS work has been presented at IETF meetings and has failed to move forward due to privacy concerns and the possibility of revealing information about the end user. While some of the same concerns may apply to the IPv6 options for traffic management, the format for the Flow label and extension headers is already standardized. The flexibility to use the extension headers is also standardized.

Routing overlay protocols also add back in visibility, but apply only to an administrative domain, whereas IPv6 is end-to-end. Their application and use for management will depend on the network.

The ability to evolve the protocol stack to ensure traffic and other management functions can be performed may impact the rate of deployment for transport encryption protocols like QUIC, where signaling information is no longer accessible. These are important intertwined trends. Migration to IPv6, which encompasses many more benefits to be discussed later, could be an essential component to the wide adoption of TLSv1.3, QUIC, and other transport encryption protocols. These encryption protocols in turn are critical to successful deployment of data-centric security wh...

Table of contents

• Cover
• Title
• Copyright
• Contents
• Preface
• Acknowledgments
• 1 Interconnected Trends
• 2 Board-level Program Evaluation and Guidance
• 3 Architect a Secure Network with Less
• 4 Encryption
• 5 Transport Evolution: The Encrypted Stack
• 6 Authentication and Authorization
• 7 The End Point
• 8 Incident Prevention, Detection, and Response
• 9 Looking Forward
• References
• Index