I think HTTP/2 and HTTP/3 are unnecessarily complex and offer little benefit for most web users and websites.<p>We need our technology to be secure against criminals and spies. To accomplish that, we must reduce complexity. Moving from HTTP/1.1 to HTTP/3 adds a lot of complexity:<p>- TCP -> UDP. Applications, proxies, and servers must implement complicated request stream processing logic. In TCP, this is handled by the OS kernel. The switch to UDP will bring many exploits and privacy leaks due to the huge amount of new code written for stream processing. Application performance will likely go down due to bugs and misconfiguration.<p>- Text -> Protocol Buffers. Protocol buffer parsing requires a large amount of new code. Applications & servers must either increase the complexity of their build systems by adding code generation or increase the complexity of their codebase by adding hand-coded parsing and serde (serializing & deserializing). There are plenty of ways to achieve the precision of protobufs with text-based protocols. Even JSON would be better. Debugging protobuf-based applications is difficult, increasing the costs of deploying applications. These costs disproportionately affect startups and small organizations.<p>- Uniplex -> Multiplex. With HTTP/1.1, application servers are straightforward to code: read a request from the stream, process it, and write a response. With multi-plexing, servers must handle concurrent requests over a single stream. This is an order of magnitude increase in complexity. It affects all aspects of the server. There will be many exploits and privacy leaks due to bugs in this new concurrent request processing code. Many production systems are more difficult to implement for multiplex protocols: firewalls, monitoring, bandwidth controls, DoS mitigation, and logging. For Google, these are not new costs since they already use Stubby (gRPC) internally for everything. But for the rest of the world, especially startups and small organizations, the switch to multiplex adds huge development and operational complexity for negligible benefit.<p>I think we need a better text-based HTTP protocol. HTTP group is solving Google's problems. We need it to solve our problems. Here's what we should do:<p>- Remove the unused features from HTTP/1.1. For example, multi-line headers.<p>- Eliminate ambiguity (and several classes of exploits):<p><pre><code> - Make header names case-sensitive. Define all well-known headers with lower-case names.
- Forbid duplicate headers.
- Forbid leading zeros and sign indicators on numeric fields.
- Allow only lowercase hexadecimal.
- Require content-type header and forbid user-agents from inferring content-type.
</code></pre>
- Make parsing simpler:<p><pre><code> - Make standard header values mandatory and move them to the request/status line: content-length, content-encoding, content-type, transfer-encoding, and server name.
- Put the target path on its own line, encoded in UTF-8. Remove percent-encoding.
- Separate header names and values with a character that cannot occur in header names or values, like '\t'.
- Use UTF-8 for header values.
- Specify maximum sizes for request/response (sans body), request/status line, method name, content-type, server name, content-length field, target path, header key, header value, total header length, and number of headers.
- Use only one transfer encoding: chunked.
- Require content-length. Do not support uploads or responses of indeterminate length.
- Represent numeric values (content-length, chunk-length) using one format, either decimal or hex.
</code></pre>
- Allow clients to detect tampering and corruption:<p><pre><code> - Replace 'etag' header with a 'digest-sha-256' header.
- Add 'checksum-xxhash' and 'checksum-xxhash' headers for bodies and chunks. Pick an excellent hash function like xxHash.
</code></pre>
- Allow browsers to control authentication:<p><pre><code> - All connections are anonymous by default
- Forbid the "cookie" header. Replace it with a single-valued auth token that is part of the request line. Or even better, use the client authentication protocol described below. Browsers can now add a "log out" button which switches back to anonymous mode.
- Servers can request authentication (401).
- Support password-less challenge & response. This prevents phishing. It supports hardware tokens.
- Add a way for browsers to enroll a new "identity" with the server. This could be stored on a hardware token or just software. The browser creates a new identity for each website the user logs into. When the user wants to log in to a site for the first time, they click the "Login" button next to the URL bar. The browser re-requests the page with the enrollment header. The server can either accept the new identity (2xx) or show a form asking for a security code. The server returns the form with a 4xx status so it can get the enrollment headers again. The "Logout" button appears next to the Login button. It switches back to anonymous mode for that site.
- Remove HTTP Basic authentication (cleartext password).
- Remove HTTP Digest authentication (passwords).
</code></pre>
- Replace TLS. It is mind-numbingly complex. Because of that, there are only a handful of implementations and most are buggy. TLS leaks private data. Replace it with three new protocols:<p><pre><code> - An unauthenticated privacy protocol. This does not protect against MITM. Signs every data block with session key.
- Server authentication protocol. Client requests certificate by name. Server sends its certificate and signature of client-generated nonce. Every sent data block gets signed. Server sends another message with its certificate and signature of the privacy protocol session key and a nonce. Corporate MITM firewalls replace this message with their own certificate, which clients are configured to accept.
- Client authentication protocol. Every sent data block gets signed. A browser can generate a new identity with a new key pair and send the public key to the server in the 'enroll-rsa-2048' header. The server generates a certificate for the public key and returns it to the browser in the 'certificate' header. The browser uses this certificate in the client authn protocol.
- Do not support resuming sessions.
- All three protocols get a new version every 3 months with updated lists of supported algorithms, parameters, and features. No "extension" data fields. Public internet hosts must support only the eight latest versions. This means that unmaintained software will stop working after 2 years. This will prevent many data thefts, ransomware attacks, malicious hacks, and Internet worms.
- Encode certificates with human-readable JSON instead of ASN.1 DER. JER is not human-readable since it encodes DNS names in Base64. The ASN.1 format specification and DER encoding are unnecessarily complex.
- Provide test servers and clients that exercise all of the edge cases of the algorithms and try known attacks.</code></pre>