HTTP: Recent Events, and What’s Next

background-image: url(image/sand.jpg)
class: middle, right

# .title[HTTP]

### .inverse[Recent Events, and What’s Next]

[Mark Nottingham](https://www.mnot.net)

<br>

---
class: smallp

# HTTP/1 is a Good Protocol

- Simple, well-understood semantics
- Broadly implemented
- Serves the 80% case well
- Extensible
- Scalable

See also: “[Architectural Styles and the Design of Network-based Software Architectures](http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm)”

---

# What’s a _Great_ Web Protocol?

_All of that, plus:_

* **Performance**
  - Minimal amount of data upload
  - Minimal amount of data download
  - Not “chatty”
  - Data can stream into app as it comes in
  - Fair to other users and applications
  - Handles congestion, loss well
* **Security**
  - Authentication
  - Integrity
  - Confidentiality
* **Evolution**
  - Continuing to meet relevant use cases

---
background-image: url(image/wg_japan.jpg)
background-color: black
class: center, inverse

# HTTP/2: For Speed

---

# HTTP/1’s Performance Limits

**Requests are Expensive**, leading us to do some pretty unnatural things:

* CSS Spriting
* CSS Inlining
* Concatenation

_But why are requests expensive?_

---
class: center, middle

# 1. Head of Line Blocking

![](image/hol.svg)

---
background-image: url(image/htracr.png)
class: center

# .inverse[Multiple Connections]

---
background-image: url(image/etsy.png)
class: center

# Interaction with TCP

---

# HTTP/2 Multiplexing

- Multiple requests and responses in flight, interleaved
- No head of line blocking in HTTP!
- **Load a page with one connection**

_Implies **server prioritisation** - clients no longer responsible for figuring out when to send requests._

---
background-image: url(image/waterfall-http.png)

# HTTP/1 looked like this

---
background-image: url(image/waterfall-spdy.png)

# HTTP/2 looks like this

---

# 2. Verbose Headers

``` HTTP
GET /assets/bootstrap/username-suggester.20121001205006.js HTTP/1.1
Host: www.etsy.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2)
  AppleWebKit/536.26.14 (KHTML, like Gecko) Version/6.0.1
  Safari/536.26.14
Accept: */*
DNT: 1
Referer: http://www.etsy.com/
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Cookie: autosuggest_split=1; etala=111461200.1476767743.1349274889.
  1349274889.1349274889.1.0; etalb=111461200.1.10.1349274889;
  last_browse_page=%2F;
  uaid=uaid%3DVdhk5W6sexG-_Y7ZBeQFa3cq7yMQ%26_now%3D1325204464%26
  _slt%3Ds_LCLVpU%26_kid%3D1%26_ver%3D1%26_mac%3DlVnlM3hMdb3Cs3hq
  MVuk_dQEixsqQzUlNYCs9H_Kj8c.;
  user_prefs=1&2596706699&q0tPzMlJLaoEAA==
Connection: keep-alive
```

---
class: smallli

# HTTP/2 Header Compression

GZIP was great for SPDY, but security researchers found a problem - `CRIME`. HPACK was designed from the ground up for compressing headers efficiently and safely.

- Compression context is all headers in one direction on a connection
- Dynamic and static tables for values-by-reference (default: 4k of context)
- Static Huffman coding

.center[![](image/hpack.png)]

---
class: center, middle

# 3. “Chattiness”

![](image/chatty.png)

---

# HTTP/2 Server Push

- Synthetic request/response pair sent to client

.center[![](image/push.svg)]

---
background-image: url(image/caniuse.png)

---
background-image: url(image/run.jpg)
class: center, bottom

# What’s Next*

---

# TLS 1.3

* Improved Handshake Latency
* Simplified Protocol
* Moderised Ciphersuites

.status[in progress]
.spec[[spec](https://tlswg.github.io/tls13-spec/)]

---

# Alternative Services

Load balancing with DNS is suboptimal.

- Relies on HTTP/1’s short connections; can’t assume w/ H2
- Introduces latency while a new connection is spun up

Alternative Services gives servers a way to shift traffic around seamlessly.

``` http
Alt-Svc: h2="alt.example.com:8000" 
```

Also an `ALTSVC` frame type.

Think of as _CNAME inside HTTP_.

.status[RFC soon] 
.logo[![](logo/firefox.png) ![](logo/chrome.png)] 
.spec[[spec](http://httpwg.org/http-extensions/alt-svc.html)] 
.more[[more](https://www.mnot.net/blog/2016/03/09/alt-svc)]

---

# Opportunistic Security

HTTP/2 browsers all require TLS, but in some cases it’s hard to deploy.

* HTTP/2 over TLS for `http://` URLs
* Doesn't require valid cert if it’s on the same host
* Uses Alternative Services
* **No** change to URL, security context, user experience
* Only protects against passive attackers - “pervasive monitoring”
* “Experimental”

``` http
Alt-Svc: h2=":443"
```

.status[RFC soon] 
.logo[![](logo/firefox.png)]
.spec[[spec](http://httpwg.org/http-extensions/draft-ietf-httpbis-http2-encryption.html)]

---
background-image: url(image/cookie.jpg)
class: middle

.pull-left[
# Cookies

* “Leave Secure Cookies Alone”
* Value-less cookies
* Same-site cookies
* Cookies Lifetimes and HTTP
* Cookie Prefixes: <br>
  `__Secure-SID=12345`
]

.status[starting]
.spec[[specs](https://github.com/httpwg/http-extensions#rfc6265bis)]

---

# JSON Headers

Defining new HTTP headers is hard. _Really hard._

- No strong conventions; lots of variation
- Special rules for commas, quoting
- Supposed to be defined in ABNF
- Can’t even assume character encoding!

**JFV** proposes a way to use JSON to define HTTP headers.

```http
attachment; filename*=UTF-8''%e2%82%ac%20rates

{ "attachment": { "filename" : "\u20AC rates" } }
```

_For new headers only._

.status[considering]
.spec[[spec](https://tools.ietf.org/html/draft-reschke-http-jfv)]

---

# `Key` Response Header

The `Vary` response header is limited.

- Considers a request header as a string, unless the cache knows about it.
- Lots of cache misses, duplication.

`Key` proposes a finer-grained secondary cache key for HTTP.

``` http
Key: Cookie;param="SID"
Key: Accept-Encoding;match="gzip"
```

.status[in progress]
.spec[[spec](https://httpwg.github.io/http-extensions/key.html)]

---

# Client Hints

_Responsive Web Design_ has become a core technique for delivering Web sites. The [HTML5 picture element](http://www.html5rocks.com/en/tutorials/responsive/picture-element/) helps, but is difficult to deploy sometimes.

Client Hints allow clients to indicate a list of device and agent specific preferences, for use in content negotiation:

* DPR - Device Pixel Ratio
* Width
* Viewport-Width
* Save-Data
* Downlink

_Helps avoid UA sniffing_

.status[in progress] .logo[![](logo/chrome.png)]
.spec[[spec](https://httpwg.github.io/http-extensions/client-hints.html)]

---

# Payload Encryption

TLS is great for securing data in motion, but not at rest.

* WebPush Messages (store-and-forward)
* “Dropbox” like storage servers

Doing it as a content encoding allows us to have encrypted payloads as part of HTTP. Maybe signatures too.

``` http
HTTP/1.1 200 OK
Content-Type: application/octet-stream
Content-Encoding: aesgcm
Connection: close
Encryption: keyid="http://example.org/bob/keys/123";
            salt="XZwpw6o37R-6qoZjw6KwAw"

[encrypted payload]
```

.status[in progress]
.spec[[spec](http://httpwg.org/http-extensions/draft-ietf-httpbis-encryption-encoding.html)]

---

# Cache Digests

Server Push allows us to avoid a round trip. But what if what it pushes is already in cache?

**Cache Digests** allow a cache to tell a server what they contain, using a **Golumb Compressed Set**.

.status[considering]
.spec[[spec](http://mnot.github.io/I-D/h2-cache-digest/)]

---

# `ORIGIN` Frame

HTTP/2 allows a single connection to be used by more than one origin if:

1. Their hostnames resolve to the same IP address, _and_
2. The TLS certificate returned covers both of them (wildcard, SAN)

... but what if that’s not intentional?

The `ORIGIN` frame allows a server to tell clients what origin(s) a connection is good for.

.status[considering]

---

# *-in-HTTP

Once we have an efficient, multiplexed transport for HTTP, it becomes attractive to start thinking about including other information, like:

* DNS records
* TLS certificates

.status[considering]

---

# “Blind” Caching

Increased use of TLS makes shared proxy caches less useful.

_What if an encrypted copy of content could be stored in a shared cache?_

* Integrity
* Authority
* ~~Confidentiality~~

Limited trust relationship with a privileged network element; it is able to figure out what you're viewing, but not change it.

.status[considering]

---

# Problems with TCP

* TCP has its own form of Head of Line Blocking
* In-order delivery isn’t great for multiplexing
* Congestion Control needs tuning
* Changing TCP is hard

---
class: center, middle

# Fixing TCP: QUIC

<math>
  <mfrac>
   <mfenced>
     <mrow>
      <mi>h2</mi> 
      <mo>+</mo> <mi>dtls1.3</mi> 
      <mo>+</mo> <mi>congestion_control</mi> 
      <mo>+</mo> <mi>reliability</mi> 
    </mrow>
  </mfenced>
  <mrow>
    <mi>udp</mi>
  </mrow>
</math>

.status[considering] 
.logo[![](logo/chrome.png)]
.more[[more](https://www.chromium.org/quic)]

---
class: center, middle

# Get Involved

[![HTTP Working Group](image/http.svg)](https://httpwg.github.io/)
[![The HTTP Workshop](image/http_workshop.svg)](https://httpworkshop.github.io/)

---
class: center, bottom, inverse
background-image: url(image/roos.jpg)

# Discussion