first pass on QUIC/TLS

Author: drbruced12

tls.rst

@@ -375,6 +375,112 @@ discuss below.
 6.4 QUIC, HTTP/3 and TLS
 ------------------------
 
-6.5 User Experience with HTTPS
+Since the invention of the World Wide Web in the 1990s, HTTP has run
+over TCP. HTTP/1.0, the original version, had quite a number of
+performance problems due to the way it used TCP, such as the fact that
+every request for an object required a new TCP connection to be set up
+and then closed after the reply was returned. HTTP/1.1 was proposed at
+an early stage to make better use of TCP. TCP continued to be the
+protocol used by HTTP for another twenty-plus years.
+
+Adding security to HTTP-over-TCP in the form of SSL and TLS further
+exacerbated performance issues, even as advancements to HTTP mitigated
+some of the orginal problems. As noted in the preceding section, it
+takes at least one round trip time to establish a secure TLS
+session. The relatively recent introduction of 0-RTT data reduces the
+latency before the first data can be sent; it also comes with some
+security drawbacks as we observed above.
+
+Of course, the time required to set up a secure session with TLS in
+*in addition* to the time need to set up a TCP connection. TCP needs
+to complete its 3-way handshake before the first TLS handshake
+message-which is just data as far as TCP is concerned-can be sent. So
+the sequence of events was:
+
+- Client initiates TCP 3-way handshake to establish TCP session. 
+
+- TLS handshake establishes security parameters for client-server
+  communication.
+
+- First HTTP message gets sent from client to server.
+
+In other words, in the original TLS-over-TCP model it would take at
+least three RTTs to get a response to a single HTTPS request. In fact
+up until TLS 1.3 arrived it was at least four RTTs due to the use of
+two RTTs to complete the TLS handshake. 
+
+This is not the only problem with running HTTP over TCP. A reliable,
+ordered byte stream as provided by TCP isn't exactly the right model
+for Web traffic. In particular, since most web pages contain many
+objects, it makes sense to be able to request many objects in
+parallel, but TCP only provides a single byte stream. If one packet is
+lost, TCP waits for its retransmission and successful delivery before
+continuing, while HTTP would have been happy to receive other objects
+that were not affected by that single lost packet. Opening multiple
+TCP connections would appear to be a solution to this, but that has
+its own set of drawbacks including a lack of shared information about
+congestion across connections.
+
+Other factors such as the rise of high-latency wireless networks and
+the availability of multiple networks for a single device (e.g., Wi-Fi
+and cellular) contributed to the realization that the transport layer
+for HTTP would benefit from a new approach. The protocol that emerged
+to fill this need was QUIC.
+
+In this section we will focus on how QUIC particularly improves the
+performance of TLS compared to running over TCP. QUIC is quite a
+comprehensive re-working of the transport layer that could fill its
+own book-indeed the set of RFCs that define it run to the hundreds of
+pages. 
+
+
+
+QUIC originated at Google in 2012 and was subsequently developed as a
+proposed standard at the IETF. It has already seen a solid amount of
+deployment—it is in most Web browsers, many popular websites, and is
+even starting to be used for non-HTTP applications. Deployability was
+a key consideration for the designers of the protocol. There are a lot
+of moving parts to QUIC—its specification spans three RFCs—but we
+focus here on how it changes the relationship between TLS and the
+underlying transport.
+
+The single most important change in QUIC from the perspective of TLS
+performance is that it doesn't treat the transport and security
+handshakes as two distinct layers. Insteady, QUIC has build a
+cryptographic handshake based on TLS into the transport. This is
+illustrated by Figure foo.
+
+
+
+
+.. more to come
+   
+
+
+QUIC is a most interesting development in the world of transport
+protocols. Many of the limitations of TCP have been known for decades,
+but QUIC represents one of the most successful efforts to date to
+stake out a different point in the design space. Because QUIC was
+inspired by experience with HTTP, TLS, and the Web—which arose long after
+TCP was well established in the Internet—it presents a fascinating
+case study in the unforeseen consequences of layered designs and in
+the evolution of the Internet. There is a lot more to it that we can
+cover here. The definitive reference for QUIC is RFC 9000, while a
+more readable overview of the protocol and its deployment is reported
+in this paper from SIGCOMM 2017. 
+
+
+.. _reading_quic:
+.. admonition::  Further Reading
+
+   A. Langley *et al.*
+   `The QUIC Transport Protocol: Design and Internet-Scale Deployment
+   <https://research.google/pubs/the-quic-transport-protocol-design-and-internet-scale-deployment/>`__.
+   SIGCOMM 2017.
+
+
+
+6.5 A Systems View of TLS
 ------------------------------
 
+.. talk about how user sees things from browser