HTTP/3: From root to tip

<!DOCTYPE html> <html lang="en-us" dir="ltr"> <head><script async src="https://ot.www.cloudflare.com/public/vendor/onetrust/scripttemplates/otSDKStub.js" data-document-language="true" type="text/javascript" data-domain-script="b1e05d49-f072-4bae-9116-bdb78af15448"></script><meta name="HandheldFriendly" content="True"><meta name="viewport" content="width=device-width,minimum-scale=1,initial-scale=1"><meta http-equiv="X-UA-Compatible" content="IE=edge"><meta name="baidu-site-verification" content="KeThzeyMOr"><meta name="baidu-site-verification" content="code-NIlrS7gNhx"><meta charset="UTF-8"><meta name="description" content="Explore HTTP/3 from root to tip and discover the backstory of this new HTTP syntax that works on top of the IETF QUIC transport."><title>HTTP/3: From root to tip</title><meta name="title" content="HTTP/3: From root to tip"><meta name="msvalidate.01" content="CF295E1604697F9CAD18B5A232E871F6"><meta class="swiftype" name="language" data-type="string" content="en"><script src="/static/z/i.js" type="text/javascript" referrerpolicy="origin"></script><meta name="viewport" content="width=device-width, initial-scale=1.0"><link rel="apple-touch-icon" sizes="180x180" href="/images/favicon-32x32.png"><link rel="icon" type="image/png" sizes="32x32" href="/images/favicon-32x32.png"><link rel="icon" type="image/png" sizes="16x16" href="/images/favicon-32x32.png"><link rel="mask-icon" href="/images/favicon-32x32.png" color="#f78100"><link rel="stylesheet" href="/themes/ashes.min.css"><link rel="sitemap" href="/sitemap.xml"><meta name="msapplication-TileColor" content="#da532c"><meta name="theme-color" content="#ffffff"><link rel="canonical" href="https://blog.cloudflare.com/http-3-from-root-to-tip"><link rel="alternate" hreflang="en-us" href="https://blog.cloudflare.com/http-3-from-root-to-tip"><link rel="alternate" hreflang="zh-cn" href="https://blog.cloudflare.com/zh-cn/http-3-from-root-to-tip"><link rel="alternate" hreflang="fr-fr" href="https://blog.cloudflare.com/fr-fr/http-3-from-root-to-tip"><link rel="alternate" hreflang="de-de" href="https://blog.cloudflare.com/de-de/http-3-from-root-to-tip"><link rel="alternate" hreflang="es-es" href="https://blog.cloudflare.com/es-es/http-3-from-root-to-tip"> <meta property="article:published_time" content="2019-01-24T17:57:09.000+00:00"> <meta property="article:modified_time" content="2024-10-09T23:09:40.277Z"> <meta property="article:tag" content="QUIC"><meta property="article:tag" content="TLS"><meta property="article:tag" content="Security"><meta property="article:tag" content="HTTP3"><meta property="article:tag" content="IETF"> <meta property="article:publisher" content="https://www.facebook.com/cloudflare">  <meta property="og:site_name" content="The Cloudflare Blog"> <meta property="og:type" content="article"> <meta property="og:title" content="HTTP/3: From root to tip"> <meta property="og:description" content="Explore HTTP/3 from root to tip and discover the backstory of this new HTTP syntax that works on top of the IETF QUIC transport."> <meta property="og:url" content="https://blog.cloudflare.com/http-3-from-root-to-tip"> <meta property="og:image:width" content="1200"> <meta property="og:image:height" content="628">  <meta name="twitter:title" content="HTTP/3: From root to tip"> <meta name="twitter:description" content="Explore HTTP/3 from root to tip and discover the backstory of this new HTTP syntax that works on top of the IETF QUIC transport."> <meta name="twitter:url" content="https://blog.cloudflare.com/http-3-from-root-to-tip"> <meta name="twitter:card" content="summary_large_image"> <meta name="twitter:label1" content="Written by"> <meta name="twitter:data1" content="Lucas Pardue"> <meta name="twitter:creator" content="@SimmerVigor"><meta name="twitter:label2" content="Filed under"><meta name="twitter:data2" content="QUIC,TLS,Security,HTTP3,IETF"> <meta name="twitter:site" content="@cloudflare"> <meta property="og:image" content=""> <meta name="twitter:image" content=""> <link rel="stylesheet" href="/_astro/index.5BtHvQ-S.css" /><script type="module" src="/_astro/hoisted.Byv_OtGt.js"></script></head><style>astro-island,astro-slot,astro-static-slot{display:contents}</style><script>(()=>{var e=async t=>{await(await t())()};(self.Astro||(self.Astro={})).only=e;window.dispatchEvent(new Event("astro:only"));})();;(()=>{var b=Object.defineProperty;var f=(c,o,i)=>o in c?b(c,o,{enumerable:!0,configurable:!0,writable:!0,value:i}):c[o]=i;var l=(c,o,i)=>(f(c,typeof o!="symbol"?o+"":o,i),i);var p;{let c={0:t=>m(t),1:t=>i(t),2:t=>new RegExp(t),3:t=>new Date(t),4:t=>new Map(i(t)),5:t=>new Set(i(t)),6:t=>BigInt(t),7:t=>new URL(t),8:t=>new Uint8Array(t),9:t=>new Uint16Array(t),10:t=>new Uint32Array(t)},o=t=>{let[e,r]=t;return e in c?c[e](r):void 0},i=t=>t.map(o),m=t=>typeof t!="object"||t===null?t:Object.fromEntries(Object.entries(t).map(([e,r])=>[e,o(r)]));customElements.get("astro-island")||customElements.define("astro-island",(p=class extends HTMLElement{constructor(){super(...arguments);l(this,"Component");l(this,"hydrator");l(this,"hydrate",async()=>{var d;if(!this.hydrator||!this.isConnected)return;let e=(d=this.parentElement)==null?void 0:d.closest("astro-island[ssr]");if(e){e.addEventListener("astro:hydrate",this.hydrate,{once:!0});return}let r=this.querySelectorAll("astro-slot"),a={},h=this.querySelectorAll("template[data-astro-template]");for(let n of h){let s=n.closest(this.tagName);s!=null&&s.isSameNode(this)&&(a[n.getAttribute("data-astro-template")||"default"]=n.innerHTML,n.remove())}for(let n of r){let s=n.closest(this.tagName);s!=null&&s.isSameNode(this)&&(a[n.getAttribute("name")||"default"]=n.innerHTML)}let u;try{u=this.hasAttribute("props")?m(JSON.parse(this.getAttribute("props"))):{}}catch(n){let s=this.getAttribute("component-url")||"<unknown>",y=this.getAttribute("component-export");throw y&&(s+=` (export ${y})`),console.error(`[hydrate] Error parsing props for component ${s}`,this.getAttribute("props"),n),n}await this.hydrator(this)(this.Component,u,a,{client:this.getAttribute("client")}),this.removeAttribute("ssr"),this.dispatchEvent(new CustomEvent("astro:hydrate"))});l(this,"unmount",()=>{this.isConnected||this.dispatchEvent(new CustomEvent("astro:unmount"))})}disconnectedCallback(){document.removeEventListener("astro:after-swap",this.unmount),document.addEventListener("astro:after-swap",this.unmount,{once:!0})}connectedCallback(){if(!this.hasAttribute("await-children")||document.readyState==="interactive"||document.readyState==="complete")this.childrenConnectedCallback();else{let e=()=>{document.removeEventListener("DOMContentLoaded",e),r.disconnect(),this.childrenConnectedCallback()},r=new MutationObserver(()=>{var a;((a=this.lastChild)==null?void 0:a.nodeType)===Node.COMMENT_NODE&&this.lastChild.nodeValue==="astro:end"&&(this.lastChild.remove(),e())});r.observe(this,{childList:!0}),document.addEventListener("DOMContentLoaded",e)}}async childrenConnectedCallback(){let e=this.getAttribute("before-hydration-url");e&&await import(e),this.start()}start(){let e=JSON.parse(this.getAttribute("opts")),r=this.getAttribute("client");if(Astro[r]===void 0){window.addEventListener(`astro:${r}`,()=>this.start(),{once:!0});return}Astro[r](async()=>{let a=this.getAttribute("renderer-url"),[h,{default:u}]=await Promise.all([import(this.getAttribute("component-url")),a?import(a):()=>()=>{}]),d=this.getAttribute("component-export")||"default";if(!d.includes("."))this.Component=h[d];else{this.Component=h;for(let n of d.split("."))this.Component=this.Component[n]}return this.hydrator=u,this.hydrate},e,this)}attributeChangedCallback(){this.hydrate()}},l(p,"observedAttributes",["props"]),p))}})();</script><astro-island uid="ZXcM0W" component-url="/_astro/GoogleAnalytics.DKWYs_Ts.js" component-export="GoogleAnalytics" renderer-url="/_astro/client.BQCS8AJJ.js" props="{"title":[0,"HTTP/3: From root to tip"],"canonical":[0,"https://blog.cloudflare.com/http-3-from-root-to-tip"],"info":[0,{"id":[0,"1upTpaZ3pXyoDXxMvZoEC8"],"title":[0,"HTTP/3: From root to tip"],"slug":[0,"http-3-from-root-to-tip"],"excerpt":[0,"Explore HTTP/3 from root to tip and discover the backstory of this new HTTP syntax that works on top of the IETF QUIC transport."],"featured":[0,false],"html":[0,"<p>HTTP is the application protocol that powers the Web. It began life as the so-called HTTP/0.9 protocol in 1991, and by 1999 had evolved to HTTP/1.1, which was standardised within the IETF (Internet Engineering Task Force). HTTP/1.1 was good enough for a long time but the ever changing needs of the Web called for a better suited protocol, and HTTP/2 emerged in 2015. More recently it was announced that the IETF is intending to deliver a new version - <a href=\"https://www.cloudflare.com/learning/performance/what-is-http3/\">HTTP/3</a>. To some people this is a surprise and has caused a bit of confusion. If you don&#39;t track IETF work closely it might seem that HTTP/3 has come out of the blue. However, we can trace its origins through a lineage of experiments and evolution of Web protocols; specifically the QUIC transport protocol.</p><p>If you&#39;re not familiar with QUIC, my colleagues have done a great job of tackling different angles. John&#39;s <a href=\"/the-quicening/\">blog</a> describes some of the real-world annoyances of today&#39;s HTTP, Alessandro&#39;s <a href=\"/the-road-to-quic/\">blog</a> tackles the nitty-gritty transport layer details, and Nick&#39;s blog covers <a href=\"/head-start-with-quic/\">how to get hands on</a> with some testing. We&#39;ve collected these and more at <a href=\"https://cloudflare-quic.com\">https://cloudflare-quic.com</a>. And if that tickles your fancy, be sure to check out <a href=\"/enjoy-a-slice-of-quic-and-rust/\">quiche</a>, our own open-source implementation of the QUIC protocol written in Rust.</p><p>HTTP/3 is the HTTP application mapping to the QUIC transport layer. This name was made official in the recent draft version 17 (<a href=\"https://tools.ietf.org/html/draft-ietf-quic-http-17\">draft-ietf-quic-http-17</a>), which was proposed in late October 2018, with discussion and rough consensus being formed during the IETF 103 meeting in Bangkok in November. HTTP/3 was previously known as HTTP over QUIC, which itself was previously known as HTTP/2 over QUIC. Before that we had HTTP/2 over gQUIC, and way back we had SPDY over gQUIC. The fact of the matter, however, is that HTTP/3 is just a new HTTP syntax that works on IETF QUIC, a UDP-based multiplexed and secure transport.</p><p>In this blog post we&#39;ll explore the history behind some of HTTP/3&#39;s previous names and present the motivation behind the most recent name change. We&#39;ll go back to the early days of HTTP and touch on all the good work that has happened along the way. If you&#39;re keen to get the full picture you can jump to the end of the article or open this <a href=\"/content/images/2019/01/web_timeline_large1.svg\">highly detailed SVG version</a>.</p>\n <figure class=\"kg-card kg-image-card \">\n \n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/1rKByCE0o19Q1zSD9Huliu/7f3540be1ff8f02da311c4df909def42/http3-stack.png\" alt=\"\" class=\"kg-image\" width=\"1028\" height=\"787\" loading=\"lazy\"/>\n \n </figure><p>An HTTP/3 layer cake</p>\n <div class=\"flex anchor relative\">\n <h2 id=\"setting-the-scene\">Setting the scene</h2>\n <a href=\"#setting-the-scene\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>Just before we focus on HTTP, it is worth reminding ourselves that there are two protocols that share the name QUIC. As we explained <a href=\"/the-road-to-quic/\">previously</a>, gQUIC is commonly used to identify Google QUIC (the original protocol), and QUIC is commonly used to represent the IETF standard-in-progress version that diverges from gQUIC.</p><p>Since its early days in the 90s, the web’s needs have changed. We&#39;ve had new versions of HTTP and added user security in the shape of Transport Layer Security (TLS). We&#39;ll only touch on TLS in this post, our other <a href=\"/tag/tls/\">blog posts</a> are a great resource if you want to explore that area in more detail.</p><p>To help me explain the history of HTTP and TLS, I started to collate details of protocol specifications and dates. This information is usually presented in a textual form such as a list of bullets points stating document titles, ordered by date. However, there are branching standards, each overlapping in time and a simple list cannot express the real complexity of relationships. In HTTP, there has been parallel work that refactors core protocol definitions for easier consumption, extends the protocol for new uses, and redefines how the protocol exchanges data over the Internet for performance. When you&#39;re trying to join the dots over nearly 30 years of Internet history across different branching work streams you need a visualisation. So I made one - the Cloudflare Secure Web Timeline. (NB: Technically it is a <a href=\"https://en.wikipedia.org/wiki/Cladogram\">Cladogram</a>, but the term timeline is more widely known).</p><p>I have applied some artistic license when creating this, choosing to focus on the successful branches in the IETF space. Some of the things not shown include efforts in the W3 Consortium <a href=\"https://www.w3.org/Protocols/HTTP-NG/\">HTTP-NG</a> working group, along with some exotic ideas that their authors are keen on explaining how to pronounce: <a href=\"https://blog.jgc.org/2012/12/speeding-up-http-with-minimal-protocol.html\">HMURR (pronounced &#39;hammer&#39;)</a> and <a href=\"https://github.com/HTTPWorkshop/workshop2017/blob/master/talks/waka.pdf\">WAKA (pronounced “wah-kah”)</a>.</p><p>In the next few sections I&#39;ll walk this timeline to explain critical chapters in the history of HTTP. To enjoy the takeaways from this post, it helps to have an appreciation of why standardisation is beneficial, and how the IETF approaches it. Therefore we&#39;ll start with a very brief overview of that topic before returning to the timeline itself. Feel free to skip the next section if you are already familiar with the IETF.</p>\n <div class=\"flex anchor relative\">\n <h2 id=\"types-of-internet-standard\">Types of Internet standard</h2>\n <a href=\"#types-of-internet-standard\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>Generally, standards define common terms of reference, scope, constraint, applicability, and other considerations. Standards exist in many shapes and sizes, and can be informal (aka de facto) or formal (agreed/published by a Standards Defining Organisation such as IETF, ISO or MPEG). Standards are used in many fields, there is even a formal British Standard for making tea - BS 6008.</p><p>The early Web used HTTP and SSL protocol definitions that were published outside the IETF, these are marked as <b>red lines</b> on the Secure Web Timeline. The uptake of these protocols by clients and servers made them de facto standards.</p><p>At some point, it was decided to formalise these protocols (some motivating reasons are described in a later section). Internet standards are commonly defined in the IETF, which is guided by the informal principle of &quot;rough consensus and running code&quot;. This is grounded in experience of developing and deploying things on the Internet. This is in contrast to a &quot;clean room&quot; approach of trying to develop perfect protocols in a vacuum.</p><p>IETF Internet standards are commonly known as RFCs. This is a complex area to explain so I recommend reading the blog post &quot;<a href=\"https://www.ietf.org/blog/how-read-rfc/\">How to Read an RFC</a>&quot; by the QUIC Working Group Co-chair Mark Nottingham. A Working Group, or WG, is more or less just a mailing list.</p><p>Each year the IETF hold three meetings that provide the time and facilities for all WGs to meet in person if they wish. The agenda for these weeks can become very congested, with limited time available to discuss highly technical areas in depth. To overcome this, some WGs choose to also hold interim meetings in the months between the the general IETF meetings. This can help to maintain momentum on specification development. The QUIC WG has held several interim meetings since 2017, a full list is available on their <a href=\"https://datatracker.ietf.org/wg/quic/meetings/\">meeting page</a>.</p><p>These IETF meetings also provide the opportunity for other IETF-related collections of people to meet, such as the <a href=\"https://www.iab.org/\">Internet Architecture Board</a> or <a href=\"https://irtf.org/\">Internet Research Task Force</a>. In recent years, an <a href=\"https://www.ietf.org/how/runningcode/hackathons/\">IETF Hackathon</a> has been held during the weekend preceding the IETF meeting. This provides an opportunity for the community to develop running code and, importantly, to carry out interoperability testing in the same room with others. This helps to find issues in specifications that can be discussed in the following days.</p><p>For the purposes of this blog, the important thing to understand is that RFCs don&#39;t just spring into existence. Instead, they go through a process that usually starts with an IETF Internet Draft (I-D) format that is submitted for consideration of adoption. In the case where there is already a published specification, preparation of an I-D might just be a simple reformatting exercise. I-Ds have a 6 month active lifetime from the date of publish. To keep them active, new versions need to be published. In practice, there is not much consequence to letting an I-D elapse and it happens quite often. The documents continue to be hosted on the <a href=\"https://datatracker.ietf.org/doc/recent\">IETF document’s website</a> for anyone that wants to read them.</p><p>I-Ds are represented on the Secure Web Timeline as <b>purple lines</b>. Each one has a unique name that takes the form of <i>draft-{author name}-{working group}-{topic}-{version}</i>. The working group field is optional, it might predict IETF WG that will work on the piece and sometimes this changes. If an I-D is adopted by the IETF, or if the I-D was initiated directly within the IETF, the name is <i>draft-ietf-{working group}-{topic}-{version}</i>. I-Ds may branch, merge or die on the vine. The version starts at 00 and increases by 1 each time a new draft is released. For example, the 4th draft of an I-D will have the version 03. Any time that an I-D changes name, its version resets back to 00.</p><p>It is important to note that anyone can submit an I-D to the IETF; you should not consider these as standards. But, if the IETF standardisation process of an I-D does reach consensus, and the final document passes review, we finally get an RFC. The name changes again at this stage. Each RFC gets a unique number e.g. <a href=\"https://tools.ietf.org/html/rfc7230\">RFC 7230</a>. These are represented as <b>blue lines</b> on the Secure Web Timeline.</p><p>RFCs are immutable documents. This means that changes to the RFC require a completely new number. Changes might be done in order to incorporate fixes for errata (editorial or technical errors that were found and reported) or simply to refactor the specification to improve layout. RFCs may <b>obsolete</b> older versions (complete replacement), or just <b>update</b> them (substantively change).</p><p>All IETF documents are openly available on <a href=\"http://tools.ietf.org\">http://tools.ietf.org</a>. Personally I find the <a href=\"https://datatracker.ietf.org\">IETF Datatracker</a> a little more user friendly because it provides a visualisation of a documents progress from I-D to RFC.</p><p>Below is an example that shows the development of <a href=\"https://tools.ietf.org/html/rfc1945\">RFC 1945</a> - HTTP/1.0 and it is a clear source of inspiration for the Secure Web Timeline.</p>\n <figure class=\"kg-card kg-image-card \">\n \n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/5SlEeIaoaU7r9PkklUSIOj/c24f0ba70885244920a29bea1daffd68/RFC-1945-datatracker.png\" alt=\"\" class=\"kg-image\" width=\"522\" height=\"197\" loading=\"lazy\"/>\n \n </figure><p>IETF Datatracker view of RFC 1945</p><p>Interestingly, in the course of my work I found that the above visualisation is incorrect. It is missing <a href=\"https://tools.ietf.org/html/draft-ietf-http-v10-spec-05\">draft-ietf-http-v10-spec-05</a> for some reason. Since the I-D lifetime is 6 months, there appears to be a gap before it became an RFC, whereas in reality draft 05 was still active through until August 1996.</p>\n <div class=\"flex anchor relative\">\n <h2 id=\"exploring-the-secure-web-timeline\">Exploring the Secure Web Timeline</h2>\n <a href=\"#exploring-the-secure-web-timeline\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>With a small appreciation of how Internet standards documents come to fruition, we can start to walk the the Secure Web Timeline. In this section are a number of excerpt diagrams that show an important part of the timeline. Each dot represents the date that a document or capability was made available. For IETF documents, draft numbers are omitted for clarity. However, if you want to see all that detail please check out the <a href=\"/content/images/2019/01/web_timeline_large1.svg\">complete timeline</a>.</p><p>HTTP began life as the so-called HTTP/0.9 protocol in 1991, and in 1994 the I-D <a href=\"https://tools.ietf.org/html/draft-fielding-http-spec-00\">draft-fielding-http-spec-00</a> was published. This was adopted by the IETF soon after, causing the name change to <a href=\"https://tools.ietf.org/html/draft-ietf-http-v10-spec-00\">draft-ietf-http-v10-spec-00</a>. The I-D went through 6 draft versions before being published as <a href=\"https://tools.ietf.org/html/rfc1945\">RFC 1945</a> - HTTP/1.0 in 1996.</p>\n <figure class=\"kg-card kg-image-card \">\n \n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/6fSsHSEtXc1HA38jJorxhO/d1a86966735f27d3b2ccfbcc1c8ec38d/http11-standardisation.png\" alt=\"\" class=\"kg-image\" width=\"504\" height=\"317\" loading=\"lazy\"/>\n \n </figure><p>However, even before the HTTP/1.0 work completed, a separate activity started on HTTP/1.1. The I-D <a href=\"https://tools.ietf.org/html/draft-ietf-http-v11-spec-00\">draft-ietf-http-v11-spec-00</a> was published in November 1995 and was formally published as <a href=\"https://tools.ietf.org/html/rfc2068\">RFC 2068</a> in 1997. The keen eyed will spot that the Secure Web Timeline doesn&#39;t quite capture that sequence of events, this is an unfortunate side effect of the tooling used to generate the visualisation. I tried to minimise such problems where possible.</p><p>An HTTP/1.1 revision exercise was started in mid-1997 in the form of <a href=\"https://tools.ietf.org/html/draft-ietf-http-v11-spec-rev-00\">draft-ietf-http-v11-spec-rev-00</a>. This completed in 1999 with the publication of <a href=\"https://tools.ietf.org/html/rfc2616\">RFC 2616</a>. Things went quiet in the IETF HTTP world until 2007. We&#39;ll come back to that shortly.</p>\n <div class=\"flex anchor relative\">\n <h2 id=\"a-history-of-ssl-and-tls\">A History of SSL and TLS</h2>\n <a href=\"#a-history-of-ssl-and-tls\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n \n <figure class=\"kg-card kg-image-card \">\n \n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/6pnAQiXiXCFpQpSkznYI1T/80a5516f4dafa64d1a5b60733b14c913/ssl-tls-standardisation.png\" alt=\"\" class=\"kg-image\" width=\"1215\" height=\"420\" loading=\"lazy\"/>\n \n </figure><p>Switching tracks to SSL. We see that the SSL 2.0 specification was released sometime around 1995, and that SSL 3.0 was released in November 1996. Interestingly, SSL 3.0 is described by <a href=\"https://tools.ietf.org/html/rfc6101\">RFC 6101</a>, which was released in August 2011. This sits in <b>Historic</b> category, which &quot;is usually done to document ideas that were considered and discarded, or protocols that were already historic when it was decided to document them.&quot; according to the <a href=\"https://www.ietf.org/blog/iesg-statement-designating-rfcs-historic/?primary_topic=7&\">IETF</a>. In this case it is advantageous to have an IETF-owned document that describes SSL 3.0 because it can be used as a canonical reference elsewhere.</p><p>Of more interest to us is how SSL inspired the development of TLS, which began life as <a href=\"https://tools.ietf.org/html/draft-ietf-tls-protocol-00\">draft-ietf-tls-protocol-00</a> in November 1996. This went through 6 draft versions and was published as <a href=\"https://tools.ietf.org/html/rfc2246\">RFC 2246</a> - TLS 1.0 at the start of 1999.</p><p>Between 1995 and 1999, the SSL and TLS protocols were used to secure HTTP communications on the Internet. This worked just fine as a de facto standard. It wasn&#39;t until January 1998 that the formal standardisation process for HTTPS was started with the publication of I-D <a href=\"https://tools.ietf.org/html/draft-ietf-tls-https-00\">draft-ietf-tls-https-00</a>. That work concluded in May 2000 with the publication of <a href=\"https://tools.ietf.org/html/rfc2616\">RFC 2616</a> - HTTP over TLS.</p><p>TLS continued to evolve between 2000 and 2007, with the standardisation of TLS 1.1 and 1.2. There was a gap of 7 years until work began on the next version of TLS, which was adopted as <a href=\"https://tools.ietf.org/html/draft-ietf-tls-tls13-00\">draft-ietf-tls-tls13-00</a> in April 2014 and, after 28 drafts, completed as <a href=\"https://tools.ietf.org/html/rfc8446\">RFC 8446</a> - TLS 1.3 in August 2018.</p>\n <div class=\"flex anchor relative\">\n <h2 id=\"internet-standardisation-process\">Internet standardisation process</h2>\n <a href=\"#internet-standardisation-process\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>After taking a small look at the timeline, I hope you can build a sense of how the IETF works. One generalisation for the way that Internet standards take shape is that researchers or engineers design experimental protocols that suit their specific use case. They experiment with protocols, in public or private, at various levels of scale. The data helps to identify improvements or issues. The work may be published to explain the experiment, to gather wider input or to help find other implementers. Take up of this early work by others may make it a de facto standard; eventually there may be sufficient momentum that formal standardisation becomes an option.</p><p>The status of a protocol can be an important consideration for organisations that may be thinking about implementing, deploying or in some way using it. A formal standardisation process can make a de facto standard more attractive because it tends to provide stability. The stewardship and guidance is provided by an organisation, such as the IETF, that reflects a wider range of experiences. However, it is worth highlighting that not all all formal standards succeed.</p><p>The process of creating a final standard is almost as important as the standard itself. Taking an initial idea and inviting contribution from people with wider knowledge, experience and use cases can to help produce something that will be of more use to a wider population. However, the standardisation process is not always easy. There are pitfalls and hurdles. Sometimes the process takes so long that the output is no longer relevant.</p><p>Each Standards Defining Organisation tends to have its own process that is geared around its field and participants. Explaining all of the details about how the IETF works is well beyond the scope of this blog. The IETF&#39;s &quot;<a href=\"https://www.ietf.org/how/\">How we work</a>&quot; page is an excellent starting point that covers many aspects. The best method to forming understanding, as usual, is to get involved yourself. This can be as easy as joining an email list or adding to discussion on a relevant GitHub repository.</p>\n <div class=\"flex anchor relative\">\n <h2 id=\"cloudflares-running-code\">Cloudflare's running code</h2>\n <a href=\"#cloudflares-running-code\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>Cloudflare is proud to be early an adopter of new and evolving protocols. We have a long record of adopting new standards early, such as <a href=\"/introducing-http2/\">HTTP/2</a>. We also test features that are experimental or yet to be final, like <a href=\"/introducing-tls-1-3/\">TLS 1.3</a> and <a href=\"/introducing-spdy/\">SPDY</a>.</p><p>In relation to the IETF standardisation process, deploying this running code on real networks across a diverse body of websites helps us understand how well the protocol will work in practice. We combine our existing expertise with experimental information to help improve the running code and, where it makes sense, feedback issues or improvements to the WG that is standardising a protocol.</p><p>Testing new things is not the only priority. Part of being an innovator is knowing when it is time to move forward and put older innovations in the rear view mirror. Sometimes this relates to security-oriented protocols, for example, Cloudflare <a href=\"/sslv3-support-disabled-by-default-due-to-vulnerability/\">disabled SSLv3 by default</a> due of the POODLE vulnerability. In other cases, protocols become superseded by a more technologically advanced one; Cloudflare <a href=\"/deprecating-spdy/\">deprecated SPDY</a> support in favour of HTTP/2.</p><p>The introduction and deprecation of relevant protocols are represented on the Secure Web Timeline as <b>orange lines</b>. Dotted vertical lines help correlate Cloudflare events to relevant IETF documents. For example, Cloudflare introduced TLS 1.3 support in September 2016, with the final document, <a href=\"https://tools.ietf.org/html/rfc8446\">RFC 8446</a>, being published almost two years later in August 2018.</p>\n <figure class=\"kg-card kg-image-card \">\n \n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/ptcxVRf8P4wmKMz6uSzAk/4d37f0581a865bc4f120282e7d9d5ebf/cf-events.png\" alt=\"\" class=\"kg-image\" width=\"623\" height=\"463\" loading=\"lazy\"/>\n \n </figure>\n <div class=\"flex anchor relative\">\n <h2 id=\"refactoring-in-httpbis\">Refactoring in HTTPbis</h2>\n <a href=\"#refactoring-in-httpbis\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>HTTP/1.1 is a very successful protocol and the timeline shows that there wasn&#39;t much activity in the IETF after 1999. However, the true reflection is that years of active use gave implementation experience that unearthed latent issues with <a href=\"https://tools.ietf.org/html/rfc2616\">RFC 2616</a>, which caused some interoperability issues. Furthermore, the protocol was extended by other RFCs like 2817 and 2818. It was decided in 2007 to kickstart a new activity to improve the HTTP protocol specification. This was called HTTPbis (where &quot;bis&quot; stems from Latin meaning &quot;two&quot;, &quot;twice&quot; or &quot;repeat&quot;) and it took the form of a new Working Group. The original <a href=\"https://tools.ietf.org/wg/httpbis/charters?item=charter-httpbis-2007-10-23.txt\">charter</a> does a good job of describing the problems that were trying to be solved.</p><p>In short, HTTPbis decided to refactor <a href=\"https://tools.ietf.org/html/rfc2616\">RFC 2616</a>. It would incorporate errata fixes and buy in some aspects of other specifications that had been published in the meantime. It was decided to split the document up into parts. This resulted in 6 I-Ds published in December 2007:</p><ul><li><p>draft-ietf-httpbis-p1-messaging</p></li><li><p>draft-ietf-httpbis-p2-semantics</p></li><li><p>draft-ietf-httpbis-p4-conditional</p></li><li><p>draft-ietf-httpbis-p5-range</p></li><li><p>draft-ietf-httpbis-p6-cache</p></li><li><p>draft-ietf-httpbis-p7-auth</p></li></ul>\n <figure class=\"kg-card kg-image-card \">\n \n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/5cCDzKbc2DBLJgD1cdLCor/c928470939df5acd6112503c41c78db3/http11-refactor.png\" alt=\"\" class=\"kg-image\" width=\"730\" height=\"531\" loading=\"lazy\"/>\n \n </figure><p>The diagram shows how this work progressed through a lengthy drafting process of 7 years, with 27 draft versions being released, before final standardisation. In June 2014, the so-called RFC 723x series was released (where x ranges from 0 to 5). The Chair of the HTTPbis WG celebrated this achievement with the acclimation &quot;<a href=\"https://www.mnot.net/blog/2014/06/07/rfc2616_is_dead\">RFC2616 is Dead</a>&quot;. If it wasn&#39;t clear, these new documents obsoleted the older <a href=\"https://tools.ietf.org/html/rfc2616\">RFC 2616</a>.</p>\n <div class=\"flex anchor relative\">\n <h2 id=\"what-does-any-of-this-have-to-do-with-http-3\">What does any of this have to do with HTTP/3?</h2>\n <a href=\"#what-does-any-of-this-have-to-do-with-http-3\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>While the IETF was busy working on the RFC 723x series the world didn&#39;t stop. People continued to enhance, extend and experiment with HTTP on the Internet. Among them were Google, who had started to experiment with something called SPDY (pronounced speedy). This protocol was touted as improving the performance of web browsing, a principle use case for HTTP. At the end of 2009 SPDY v1 was announced, and it was quickly followed by SPDY v2 in 2010.</p><p>I want to avoid going into the technical details of SPDY. That&#39;s a topic for another day. What is important, is to understand that SPDY took the core paradigms of HTTP and modified the interchange format slightly in order to gain improvements. With hindsight, we can see that HTTP has clearly delimited semantics and syntax. Semantics describe the concept of request and response exchanges including: methods, status codes, header fields (metadata) and bodies (payload). Syntax describe how to map semantics to bytes on the wire.</p><p>HTTP/0.9, 1.0 and 1.1 share many semantics. They also share syntax in the form of character strings that are sent over TCP connections. SPDY took HTTP/1.1 semantics and changed the syntax from strings to binary. This is a really interesting topic but we will go no further down that rabbit hole today.</p><p>Google&#39;s experiments with SPDY showed that there was promise in changing HTTP syntax, and value in keeping the existing HTTP semantics. For example, keeping the format of URLs to use https:// avoided many problems that could have affected adoption.</p><p>Having seen some of the positive outcomes, the IETF decided it was time to consider what HTTP/2.0 might look like. The <a href=\"https://github.com/httpwg/wg-materials/blob/gh-pages/ietf83/HTTP2.pdf\">slides</a> from the HTTPbis session held during IETF 83 in March 2012 show the requirements, goals and measures of success that were set out. It is also clearly states that &quot;HTTP/2.0 only signifies that the wire format isn&#39;t compatible with that of HTTP/1.x&quot;.</p>\n <figure class=\"kg-card kg-image-card \">\n \n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/3EQMui9QKRGR8Vzcu5wMZA/229e6a1cb1cc1fa78da96dc34f59c220/http2-standardisation.png\" alt=\"\" class=\"kg-image\" width=\"489\" height=\"382\" loading=\"lazy\"/>\n \n </figure><p>During that meeting the community was invited to share proposals. I-Ds that were submitted for consideration included <a href=\"https://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00\">draft-mbelshe-httpbis-spdy-00</a>, <a href=\"https://tools.ietf.org/html/draft-montenegro-httpbis-speed-mobility-00\">draft-montenegro-httpbis-speed-mobility-00</a> and <a href=\"https://tools.ietf.org/html/draft-tarreau-httpbis-network-friendly-00\">draft-tarreau-httpbis-network-friendly-00</a>. Ultimately, the SPDY draft was adopted and in November 2012 work began on <a href=\"https://tools.ietf.org/html/draft-ietf-httpbis-http2-00\">draft-ietf-httpbis-http2-00</a>. After 18 drafts across a period of just over 2 years, <a href=\"https://tools.ietf.org/html/rfc7540\">RFC 7540</a> - HTTP/2 was published in 2015. During this specification period, the precise syntax of HTTP/2 diverged just enough to make HTTP/2 and SPDY incompatible.</p><p>These years were a very busy period for the HTTP-related work at the IETF, with the HTTP/1.1 refactor and HTTP/2 standardisation taking place in parallel. This is in stark contrast to the many years of quiet in the early 2000s. Be sure to check out the full timeline to really appreciate the amount of work that took place.</p><p>Although HTTP/2 was in the process of being standardised, there was still benefit to be had from using and experimenting with SPDY. Cloudflare <a href=\"/spdy-now-one-click-simple-for-any-website/\">introduced support for SPDY</a> in August 2012 and only deprecated it in February 2018 when our statistics showed that less than 4% of Web clients continued to want SPDY. Meanwhile, we <a href=\"/introducing-http2/\">introduced HTTP/2</a> support in December 2015, not long after the RFC was published, when our analysis indicated that a meaningful proportion of Web clients could take advantage of it.</p><p>Web client support of the SPDY and HTTP/2 protocols preferred the secure option of using TLS. The introduction of <a href=\"/introducing-universal-ssl/\">Universal SSL</a> in September 2014 helped ensure that all websites signed up to Cloudflare were able to take advantage of these new protocols as we introduced them.</p>\n <div class=\"flex anchor relative\">\n <h3 id=\"gquic\">gQUIC</h3>\n <a href=\"#gquic\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>Google continued to experiment between 2012 and 2015 they released SPDY v3 and v3.1. They also started working on gQUIC (pronounced, at the time, as quick) and the initial public specification was made available in early 2012.</p><p>The early versions of gQUIC made use of the SPDY v3 form of HTTP syntax. This choice made sense because HTTP/2 was not yet finished. The SPDY binary syntax was packaged into QUIC packets that could sent in UDP datagrams. This was a departure from the TCP transport that HTTP traditionally relied on. When stacked up all together this looked like:</p>\n <figure class=\"kg-card kg-image-card \">\n \n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/40oAdMSmePG37lMEb8Odfi/b5cf02bbe9256889bd0cc103a34484a9/gquic-stack.png\" alt=\"\" class=\"kg-image\" width=\"1028\" height=\"753\" loading=\"lazy\"/>\n \n </figure><p>SPDY over gQUIC layer cake</p><p>gQUIC used clever tricks to achieve performance. One of these was to break the clear layering between application and transport. What this meant in practice was that gQUIC only ever supported HTTP. So much so that gQUIC, termed &quot;QUIC&quot; at the time, was synonymous with being the next candidate version of HTTP. Despite the continued changes to QUIC over the last few years, which we&#39;ll touch on momentarily, to this day, the term QUIC is understood by people to mean that initial HTTP-only variant. Unfortunately this is a regular source of confusion when discussing the protocol.</p><p>gQUIC continued to experiment and eventually switched over to a syntax much closer to HTTP/2. So close in fact that most people simply called it &quot;HTTP/2 over QUIC&quot;. However, because of technical constraints there were some very subtle differences. One example relates to how the HTTP headers were serialized and exchanged. It is a minor difference but in effect means that HTTP/2 over gQUIC was incompatible with the IETF&#39;s HTTP/2.</p><p>Last but not least, we always need to consider the security aspects of Internet protocols. gQUIC opted not to use TLS to provide security. Instead Google developed a different approach called QUIC Crypto. One of the interesting aspects of this was a new method for speeding up security handshakes. A client that had previously established a secure session with a server could reuse information to do a &quot;zero <a href=\"https://www.cloudflare.com/learning/cdn/glossary/round-trip-time-rtt/\">round-trip time</a>&quot;, or 0-RTT, handshake. 0-RTT was later incorporated into TLS 1.3.</p>\n <div class=\"flex anchor relative\">\n <h2 id=\"are-we-at-the-point-where-you-can-tell-me-what-http-3-is-yet\">Are we at the point where you can tell me what HTTP/3 is yet?</h2>\n <a href=\"#are-we-at-the-point-where-you-can-tell-me-what-http-3-is-yet\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>Almost.</p><p>By now you should be familiar with how standardisation works and gQUIC is not much different. There was sufficient interest that the Google specifications were written up in I-D format. In June 2015 <a href=\"https://tools.ietf.org/html/draft-tsvwg-quic-protocol-00\">draft-tsvwg-quic-protocol-00</a>, entitled &quot;QUIC: A UDP-based Secure and Reliable Transport for HTTP/2&quot; was submitted. Keep in mind my earlier statement that the syntax was almost-HTTP/2.</p><p>Google <a href=\"https://groups.google.com/a/chromium.org/forum/#!topic/proto-quic/otGKB4ytAyc\">announced</a> that a Bar BoF would be held at IETF 93 in Prague. For those curious about what a &quot;Bar BoF&quot; is, please consult <a href=\"https://tools.ietf.org/html/rfc6771\">RFC 6771</a>. Hint: BoF stands for Birds of a Feather.</p>\n <figure class=\"kg-card kg-image-card \">\n \n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/364tlrFLOtgAYBYxHrOXy8/18f5cebace8c29778e06109fe878c3b8/quic-standardisation.png\" alt=\"\" class=\"kg-image\" width=\"560\" height=\"515\" loading=\"lazy\"/>\n \n </figure><p>The outcome of this engagement with the IETF was, in a nutshell, that QUIC seemed to offer many advantages at the transport layer and that it should be decoupled from HTTP. The clear separation between layers should be re-introduced. Furthermore, there was a preference for returning back to a TLS-based handshake (which wasn&#39;t so bad since TLS 1.3 was underway at this stage, and it was incorporating 0-RTT handshakes).</p><p>About a year later, in 2016, a new set of I-Ds were submitted:</p><ul><li><p><a href=\"https://tools.ietf.org/html/draft-hamilton-quic-transport-protocol-00\">draft-hamilton-quic-transport-protocol-00</a></p></li><li><p><a href=\"https://tools.ietf.org/html/draft-thomson-quic-tls-00\">draft-thomson-quic-tls-00</a></p></li><li><p><a href=\"https://tools.ietf.org/html/draft-iyengar-quic-loss-recovery-00\">draft-iyengar-quic-loss-recovery-00</a></p></li><li><p><a href=\"https://tools.ietf.org/html/draft-shade-quic-http2-mapping-00\">draft-shade-quic-http2-mapping-00</a></p></li></ul><p>Here&#39;s where another source of confusion about HTTP and QUIC enters the fray. <a href=\"https://tools.ietf.org/html/draft-shade-quic-http2-mapping-00\">draft-shade-quic-http2-mapping-00</a> is entitled &quot;HTTP/2 Semantics Using The QUIC Transport Protocol&quot; and it describes itself as &quot;a mapping of HTTP/2 semantics over QUIC&quot;. However, this is a misnomer. HTTP/2 was about changing syntax while maintaining semantics. Furthermore, &quot;HTTP/2 over gQUIC&quot; was never an accurate description of the syntax either, for the reasons I outlined earlier. Hold that thought.</p><p>This IETF version of QUIC was to be an entirely new transport protocol. That&#39;s a large undertaking and before diving head-first into such commitments, the IETF likes to gauge actual interest from its members. To do this, a formal <a href=\"https://www.ietf.org/how/bofs/\">Birds of a Feather</a> meeting was held at the IETF 96 meeting in Berlin in 2016. I was lucky enough to attend the session in person and the <a href=\"https://datatracker.ietf.org/meeting/96/materials/slides-96-quic-0\">slides</a> don&#39;t give it justice. The meeting was attended by hundreds, as shown by Adam Roach&#39;s <a href=\"https://www.flickr.com/photos/adam-roach/28343796722/in/photostream/\">photograph</a>. At the end of the session consensus was reached; QUIC would be adopted and standardised at the IETF.</p><p>The first IETF QUIC I-D for mapping HTTP to QUIC, <a href=\"https://tools.ietf.org/html/draft-ietf-quic-http-00\">draft-ietf-quic-http-00</a>, took the Ronseal approach and simplified its name to &quot;HTTP over QUIC&quot;. Unfortunately, it didn&#39;t finish the job completely and there were many instances of the term HTTP/2 throughout the body. Mike Bishop, the I-Ds new editor, identified this and started to fix the HTTP/2 misnomer. In the 01 draft, the description changed to &quot;a mapping of HTTP semantics over QUIC&quot;.</p><p>Gradually, over time and versions, the use of the term &quot;HTTP/2&quot; decreased and the instances became mere references to parts of <a href=\"https://tools.ietf.org/html/rfc7540\">RFC 7540</a>. Roll forward two years to October 2018 and the I-D is now at version 16. While HTTP over QUIC bares similarity to HTTP/2 it ultimately is an independent, non-backwards compatible HTTP syntax. However, to those that don&#39;t track IETF development very closely (a very very large percentage of the Earth&#39;s population), the document name doesn&#39;t capture this difference. One of the main points of standardisation is to aid communication and interoperability. Yet a simple thing like naming is a major contributor to confusion in the community.</p><p>Recall what was said in 2012, &quot;HTTP/2.0 only signifies that the wire format isn&#39;t compatible with that of HTTP/1.x&quot;. The IETF followed that existing cue. After much deliberation in the lead up to, and during, IETF 103, consensus was reached to rename &quot;HTTP over QUIC&quot; to HTTP/3. The world is now in a better place and we can move on to more important debates.</p>\n <div class=\"flex anchor relative\">\n <h2 id=\"but-rfc-7230-and-7231-disagree-with-your-definition-of-semantics-and-syntax\">But RFC 7230 and 7231 disagree with your definition of semantics and syntax!</h2>\n <a href=\"#but-rfc-7230-and-7231-disagree-with-your-definition-of-semantics-and-syntax\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>Sometimes document titles can be confusing. The present HTTP documents that describe syntax and semantics are:</p><ul><li><p><a href=\"https://tools.ietf.org/html/rfc7230\">RFC 7230</a> - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</p></li><li><p><a href=\"https://tools.ietf.org/html/rfc7231\">RFC 7231</a> - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</p></li></ul><p>It is possible to read too much into these names and believe that fundamental HTTP semantics are specific for versions of HTTP i.e. HTTP/1.1. However, this is an unintended side effect of the HTTP family tree. The good news is that the HTTPbis Working Group are trying to address this. Some brave members are going through another round of document revision, as Roy Fielding put it, &quot;one more time!&quot;. This work is underway right now and is known as the HTTP Core activity (you may also have heard of this under the moniker HTTPtre or HTTPter; naming things is hard). This will condense the six drafts down to three:</p><ul><li><p>HTTP Semantics (draft-ietf-httpbis-semantics)</p></li><li><p>HTTP Caching (draft-ietf-httpbis-caching)</p></li><li><p>HTTP/1.1 Message Syntax and Routing (draft-ietf-httpbis-messaging)</p></li></ul><p>Under this new structure, it becomes more evident that HTTP/2 and HTTP/3 are syntax definitions for the common HTTP semantics. This doesn&#39;t mean they don&#39;t have their own features beyond syntax but it should help frame discussion going forward.</p>\n <div class=\"flex anchor relative\">\n <h2 id=\"pulling-it-all-together\">Pulling it all together</h2>\n <a href=\"#pulling-it-all-together\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>This blog post has taken a shallow look at the standardisation process for HTTP in the IETF across the last three decades. Without touching on many technical details, I&#39;ve tried to explain how we have ended up with HTTP/3 today. If you skipped the good bits in the middle and are looking for a one liner here it is: HTTP/3 is just a new HTTP syntax that works on IETF QUIC, a UDP-based multiplexed and secure transport. There are many interesting technical areas to explore further but that will have to wait for another day.</p><p>In the course of this post, we explored important chapters in the development of HTTP and TLS but did so in isolation. We close out the blog by pulling them all together into the complete Secure Web Timeline presented below. You can use this to investigate the detailed history at your own comfort. And for the super sleuths, be sure to check out the <a href=\"/content/images/2019/01/web_timeline_large1.svg\">full version including draft numbers</a>.</p>\n <figure class=\"kg-card kg-image-card \">\n \n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/3eL8vJkYylVmR4T5Aa1Zdf/2f2929308ee42e450917639874835c1d/cf-secure-web-timeline-1.png\" alt=\"\" class=\"kg-image\" width=\"1303\" height=\"2444\" loading=\"lazy\"/>\n \n </figure>"],"published_at":[0,"2019-01-24T17:57:09.000+00:00"],"updated_at":[0,"2024-10-09T23:09:40.277Z"],"feature_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/4sHg74EBOhB89AyctJUIOV/0147d90b72529c6e60c6b345dd194c83/http-3-from-root-to-tip.png"],"tags":[1,[[0,{"id":[0,"76HSdQ6sNz56VVQXRUhhSw"],"name":[0,"QUIC"],"slug":[0,"quic"]}],[0,{"id":[0,"56vA0Z6hqev6QaJBQmO2J8"],"name":[0,"TLS"],"slug":[0,"tls"]}],[0,{"id":[0,"6Mp7ouACN2rT3YjL1xaXJx"],"name":[0,"Security"],"slug":[0,"security"]}],[0,{"id":[0,"4mFivBDCciYNedwQVKLKAg"],"name":[0,"HTTP3"],"slug":[0,"http3"]}],[0,{"id":[0,"SSoBzzf0KiZJPco6VApIL"],"name":[0,"IETF"],"slug":[0,"ietf"]}]]],"relatedTags":[0],"authors":[1,[[0,{"name":[0,"Lucas Pardue"],"slug":[0,"lucas"],"bio":[0,"HTTP/2, HTTP/3 and QUIC @Cloudflare. IETF QUIC WG Co-Chair. I write some words, some code and occasionally speak."],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/1k0fbniT2p2wjRfMognV4V/dca8d2e3a3e7fa4e24d7ddd9832eff1d/lucas.jpg"],"location":[0,"London"],"website":[0,null],"twitter":[0,"@SimmerVigor"],"facebook":[0,null]}]]],"meta_description":[0,"Explore HTTP/3 from root to tip and discover the backstory of this new HTTP syntax that works on top of the IETF QUIC transport."],"primary_author":[0,{}],"localeList":[0,{"name":[0,"HTTP/3: From root to tip Config"],"enUS":[0,"English for Locale"],"zhCN":[0,"Translated for Locale"],"zhHansCN":[0,"No Page for Locale"],"zhTW":[0,"No Page for Locale"],"frFR":[0,"Translated for Locale"],"deDE":[0,"Translated for Locale"],"itIT":[0,"No Page for Locale"],"jaJP":[0,"No Page for Locale"],"koKR":[0,"No Page for Locale"],"ptBR":[0,"No Page for Locale"],"esLA":[0,"No Page for Locale"],"esES":[0,"Translated for Locale"],"enAU":[0,"No Page for Locale"],"enCA":[0,"No Page for Locale"],"enIN":[0,"No Page for Locale"],"enGB":[0,"No Page for Locale"],"idID":[0,"No Page for Locale"],"ruRU":[0,"No Page for Locale"],"svSE":[0,"No Page for Locale"],"viVN":[0,"No Page for Locale"],"plPL":[0,"No Page for Locale"],"arAR":[0,"No Page for Locale"],"nlNL":[0,"No Page for Locale"],"thTH":[0,"No Page for Locale"],"trTR":[0,"No Page for Locale"],"heIL":[0,"No Page for Locale"],"lvLV":[0,"No Page for Locale"],"etEE":[0,"No Page for Locale"],"ltLT":[0,"No Page for Locale"]}],"url":[0,"https://blog.cloudflare.com/http-3-from-root-to-tip"],"metadata":[0,{"title":[0],"description":[0],"imgPreview":[0,""]}]}],"tagInfo":[0],"authorInfo":[0],"translatedPosts":[1,[]]}" ssr="" client="only" opts="{"name":"GoogleAnalytics","value":"react"}"></astro-island><script>(()=>{var i=t=>{let e=async()=>{await(await t())()};"requestIdleCallback"in window?window.requestIdleCallback(e):setTimeout(e,200)};(self.Astro||(self.Astro={})).idle=i;window.dispatchEvent(new Event("astro:idle"));})();</script><astro-island uid="Z2tAucd" prefix="r3" component-url="/_astro/Navigation.Ha-IvqmS.js" component-export="Navigation" renderer-url="/_astro/client.BQCS8AJJ.js" props="{"title":[0,"The Cloudflare Blog"],"logo":[0,"//images.ctfassets.net/zkvhlag99gkb/69RwBidpiEHCDZ9rFVVk7T/092507edbed698420b89658e5a6d5105/CF_logo_stacked_blktype.png"],"pagesStore":[0,{"page":[0,"Post"],"slug":[0,"http-3-from-root-to-tip"],"translationsAvailable":[1,[[0,"zh-cn"],[0,"fr-fr"],[0,"de-de"],[0,"es-es"]]],"navData":[1,[[0,{"metadata":[0,{"tags":[1,[]],"concepts":[1,[]]}],"sys":[0,{"space":[0,{"sys":[0,{"type":[0,"Link"],"linkType":[0,"Space"],"id":[0,"zkvhlag99gkb"]}]}],"id":[0,"6QktrXeEFcl4e2dZUTZVGl"],"type":[0,"Entry"],"createdAt":[0,"2024-10-09T19:43:20.198Z"],"updatedAt":[0,"2024-10-10T07:31:56.525Z"],"environment":[0,{"sys":[0,{"id":[0,"master"],"type":[0,"Link"],"linkType":[0,"Environment"]}]}],"publishedVersion":[0,5],"revision":[0,3],"contentType":[0,{"sys":[0,{"type":[0,"Link"],"linkType":[0,"ContentType"],"id":[0,"blogTag"]}]}],"locale":[0,"en-US"]}],"fields":[0,{"entryTitle":[0,"Product News"],"name":[0,"Product News"],"slug":[0,"product-news"],"featured":[0,true]}]}],[0,{"metadata":[0,{"tags":[1,[]],"concepts":[1,[]]}],"sys":[0,{"space":[0,{"sys":[0,{"type":[0,"Link"],"linkType":[0,"Space"],"id":[0,"zkvhlag99gkb"]}]}],"id":[0,"48r7QV00gLMWOIcM1CSDRy"],"type":[0,"Entry"],"createdAt":[0,"2024-10-09T19:54:22.790Z"],"updatedAt":[0,"2024-10-10T07:30:18.450Z"],"environment":[0,{"sys":[0,{"id":[0,"master"],"type":[0,"Link"],"linkType":[0,"Environment"]}]}],"publishedVersion":[0,9],"revision":[0,5],"contentType":[0,{"sys":[0,{"type":[0,"Link"],"linkType":[0,"ContentType"],"id":[0,"blogTag"]}]}],"locale":[0,"en-US"]}],"fields":[0,{"entryTitle":[0,"Speed & Reliability"],"name":[0,"Speed & Reliability"],"slug":[0,"speed-and-reliability"],"featured":[0,true]}]}],[0,{"metadata":[0,{"tags":[1,[]],"concepts":[1,[]]}],"sys":[0,{"space":[0,{"sys":[0,{"type":[0,"Link"],"linkType":[0,"Space"],"id":[0,"zkvhlag99gkb"]}]}],"id":[0,"6Mp7ouACN2rT3YjL1xaXJx"],"type":[0,"Entry"],"createdAt":[0,"2024-10-09T19:42:46.231Z"],"updatedAt":[0,"2024-10-10T07:27:43.433Z"],"environment":[0,{"sys":[0,{"id":[0,"master"],"type":[0,"Link"],"linkType":[0,"Environment"]}]}],"publishedVersion":[0,7],"revision":[0,4],"contentType":[0,{"sys":[0,{"type":[0,"Link"],"linkType":[0,"ContentType"],"id":[0,"blogTag"]}]}],"locale":[0,"en-US"]}],"fields":[0,{"entryTitle":[0,"Security"],"name":[0,"Security"],"slug":[0,"security"],"featured":[0,true]}]}],[0,{"metadata":[0,{"tags":[1,[]],"concepts":[1,[]]}],"sys":[0,{"space":[0,{"sys":[0,{"type":[0,"Link"],"linkType":[0,"Space"],"id":[0,"zkvhlag99gkb"]}]}],"id":[0,"J61Eszqn98amrYHq4IhTx"],"type":[0,"Entry"],"createdAt":[0,"2024-10-09T19:43:46.068Z"],"updatedAt":[0,"2024-10-10T07:24:27.531Z"],"environment":[0,{"sys":[0,{"id":[0,"master"],"type":[0,"Link"],"linkType":[0,"Environment"]}]}],"publishedVersion":[0,11],"revision":[0,6],"contentType":[0,{"sys":[0,{"type":[0,"Link"],"linkType":[0,"ContentType"],"id":[0,"blogTag"]}]}],"locale":[0,"en-US"]}],"fields":[0,{"entryTitle":[0,"Zero Trust"],"name":[0,"Zero Trust"],"slug":[0,"zero-trust"],"featured":[0,true]}]}],[0,{"metadata":[0,{"tags":[1,[]],"concepts":[1,[]]}],"sys":[0,{"space":[0,{"sys":[0,{"type":[0,"Link"],"linkType":[0,"Space"],"id":[0,"zkvhlag99gkb"]}]}],"id":[0,"4HIPcb68qM0e26fIxyfzwQ"],"type":[0,"Entry"],"createdAt":[0,"2024-10-09T19:43:21.536Z"],"updatedAt":[0,"2024-10-10T07:19:10.215Z"],"environment":[0,{"sys":[0,{"id":[0,"master"],"type":[0,"Link"],"linkType":[0,"Environment"]}]}],"publishedVersion":[0,9],"revision":[0,5],"contentType":[0,{"sys":[0,{"type":[0,"Link"],"linkType":[0,"ContentType"],"id":[0,"blogTag"]}]}],"locale":[0,"en-US"]}],"fields":[0,{"entryTitle":[0,"Developers"],"name":[0,"Developers"],"slug":[0,"developers"],"featured":[0,true]}]}],[0,{"metadata":[0,{"tags":[1,[]],"concepts":[1,[]]}],"sys":[0,{"space":[0,{"sys":[0,{"type":[0,"Link"],"linkType":[0,"Space"],"id":[0,"zkvhlag99gkb"]}]}],"id":[0,"6Foe3R8of95cWVnQwe5Toi"],"type":[0,"Entry"],"createdAt":[0,"2024-10-09T22:44:28.803Z"],"updatedAt":[0,"2024-10-10T07:14:33.876Z"],"environment":[0,{"sys":[0,{"id":[0,"master"],"type":[0,"Link"],"linkType":[0,"Environment"]}]}],"publishedVersion":[0,13],"revision":[0,7],"contentType":[0,{"sys":[0,{"type":[0,"Link"],"linkType":[0,"ContentType"],"id":[0,"blogTag"]}]}],"locale":[0,"en-US"]}],"fields":[0,{"entryTitle":[0,"AI"],"name":[0,"AI"],"slug":[0,"ai"],"featured":[0,true]}]}],[0,{"metadata":[0,{"tags":[1,[]],"concepts":[1,[]]}],"sys":[0,{"space":[0,{"sys":[0,{"type":[0,"Link"],"linkType":[0,"Space"],"id":[0,"zkvhlag99gkb"]}]}],"id":[0,"7ibnRrkJ2kfMuo3JOo0Y69"],"type":[0,"Entry"],"createdAt":[0,"2024-10-09T19:47:23.765Z"],"updatedAt":[0,"2024-10-10T07:12:33.734Z"],"environment":[0,{"sys":[0,{"id":[0,"master"],"type":[0,"Link"],"linkType":[0,"Environment"]}]}],"publishedVersion":[0,5],"revision":[0,3],"contentType":[0,{"sys":[0,{"type":[0,"Link"],"linkType":[0,"ContentType"],"id":[0,"blogTag"]}]}],"locale":[0,"en-US"]}],"fields":[0,{"entryTitle":[0,"Policy"],"name":[0,"Policy"],"slug":[0,"policy"],"featured":[0,true]}]}],[0,{"metadata":[0,{"tags":[1,[]],"concepts":[1,[]]}],"sys":[0,{"space":[0,{"sys":[0,{"type":[0,"Link"],"linkType":[0,"Space"],"id":[0,"zkvhlag99gkb"]}]}],"id":[0,"V86khSc459Yi1AhTlvtY7"],"type":[0,"Entry"],"createdAt":[0,"2024-10-09T19:46:53.657Z"],"updatedAt":[0,"2024-10-10T07:08:03.099Z"],"environment":[0,{"sys":[0,{"id":[0,"master"],"type":[0,"Link"],"linkType":[0,"Environment"]}]}],"publishedVersion":[0,10],"revision":[0,5],"contentType":[0,{"sys":[0,{"type":[0,"Link"],"linkType":[0,"ContentType"],"id":[0,"blogTag"]}]}],"locale":[0,"en-US"]}],"fields":[0,{"entryTitle":[0,"Partners"],"name":[0,"Partners"],"slug":[0,"partners"],"featured":[0,true]}]}],[0,{"metadata":[0,{"tags":[1,[]],"concepts":[1,[]]}],"sys":[0,{"space":[0,{"sys":[0,{"type":[0,"Link"],"linkType":[0,"Space"],"id":[0,"zkvhlag99gkb"]}]}],"id":[0,"4g8tPriKOAUwdUT4jNPebe"],"type":[0,"Entry"],"createdAt":[0,"2024-10-09T19:46:40.927Z"],"updatedAt":[0,"2024-10-10T07:05:21.343Z"],"environment":[0,{"sys":[0,{"id":[0,"master"],"type":[0,"Link"],"linkType":[0,"Environment"]}]}],"publishedVersion":[0,9],"revision":[0,5],"contentType":[0,{"sys":[0,{"type":[0,"Link"],"linkType":[0,"ContentType"],"id":[0,"blogTag"]}]}],"locale":[0,"en-US"]}],"fields":[0,{"entryTitle":[0,"Life at Cloudflare"],"name":[0,"Life at Cloudflare"],"slug":[0,"life-at-cloudflare"],"featured":[0,true]}]}]]]}],"locale":[0,"en-us"],"translations":[0,{"posts.by":[0,"By"],"footer.gdpr":[0,"GDPR"],"lang_blurb1":[0,"This post is also available in {lang1}."],"lang_blurb2":[0,"This post is also available in {lang1} and {lang2}."],"lang_blurb3":[0,"This post is also available in {lang1}, {lang2} and {lang3}."],"footer.press":[0,"Press"],"header.title":[0,"The Cloudflare Blog"],"search.clear":[0,"Clear"],"search.filter":[0,"Filter"],"search.source":[0,"Source"],"footer.careers":[0,"Careers"],"footer.company":[0,"Company"],"footer.support":[0,"Support"],"footer.the_net":[0,"theNet"],"search.filters":[0,"Filters"],"footer.our_team":[0,"Our team"],"footer.webinars":[0,"Webinars"],"page.more_posts":[0,"More posts"],"posts.time_read":[0,"{time} min read"],"search.language":[0,"Language"],"footer.community":[0,"Community"],"footer.resources":[0,"Resources"],"footer.solutions":[0,"Solutions"],"footer.trademark":[0,"Trademark"],"header.subscribe":[0,"Subscribe"],"footer.compliance":[0,"Compliance"],"footer.free_plans":[0,"Free plans"],"footer.impact_ESG":[0,"Impact/ESG"],"posts.follow_on_X":[0,"Follow on X"],"footer.help_center":[0,"Help center"],"footer.network_map":[0,"Network Map"],"header.please_wait":[0,"Please Wait"],"page.related_posts":[0,"Related posts"],"search.result_stat":[0,"Results <strong>{search_range}</strong> of <strong>{search_total}</strong> for <strong>{search_keyword}</strong>"],"footer.case_studies":[0,"Case Studies"],"footer.connect_2024":[0,"Connect 2024"],"footer.terms_of_use":[0,"Terms of Use"],"footer.white_papers":[0,"White Papers"],"footer.cloudflare_tv":[0,"Cloudflare TV"],"footer.community_hub":[0,"Community Hub"],"footer.compare_plans":[0,"Compare plans"],"footer.contact_sales":[0,"Contact Sales"],"header.contact_sales":[0,"Contact Sales"],"header.email_address":[0,"Email Address"],"page.error.not_found":[0,"Page not found"],"footer.developer_docs":[0,"Developer docs"],"footer.privacy_policy":[0,"Privacy Policy"],"footer.request_a_demo":[0,"Request a demo"],"page.continue_reading":[0,"Continue reading"],"footer.analysts_report":[0,"Analyst reports"],"footer.for_enterprises":[0,"For enterprises"],"footer.getting_started":[0,"Getting Started"],"footer.learning_center":[0,"Learning Center"],"footer.project_galileo":[0,"Project Galileo"],"pagination.newer_posts":[0,"Newer Posts"],"pagination.older_posts":[0,"Older Posts"],"posts.social_buttons.x":[0,"Discuss on X"],"search.source_location":[0,"Source/Location"],"footer.about_cloudflare":[0,"About Cloudflare"],"footer.athenian_project":[0,"Athenian Project"],"footer.become_a_partner":[0,"Become a partner"],"footer.cloudflare_radar":[0,"Cloudflare Radar"],"footer.network_services":[0,"Network services"],"footer.trust_and_safety":[0,"Trust & Safety"],"header.get_started_free":[0,"Get Started Free"],"page.search.placeholder":[0,"Search Cloudflare"],"footer.cloudflare_status":[0,"Cloudflare Status"],"footer.cookie_preference":[0,"Cookie Preferences"],"header.valid_email_error":[0,"Must be valid email."],"footer.connectivity_cloud":[0,"Connectivity cloud"],"footer.developer_services":[0,"Developer services"],"footer.investor_relations":[0,"Investor relations"],"page.not_found.error_code":[0,"Error Code: 404"],"footer.logos_and_press_kit":[0,"Logos & press kit"],"footer.application_services":[0,"Application services"],"footer.get_a_recommendation":[0,"Get a recommendation"],"posts.social_buttons.reddit":[0,"Discuss on Reddit"],"footer.sse_and_sase_services":[0,"SSE and SASE services"],"page.not_found.outdated_link":[0,"You may have used an outdated link, or you may have typed the address incorrectly."],"footer.report_security_issues":[0,"Report Security Issues"],"page.error.error_message_page":[0,"Sorry, we can't find the page you are looking for."],"header.subscribe_notifications":[0,"Subscribe to receive notifications of new posts:"],"footer.cloudflare_for_campaigns":[0,"Cloudflare for Campaigns"],"header.subscription_confimation":[0,"Subscription confirmed. Thank you for subscribing!"],"posts.social_buttons.hackernews":[0,"Discuss on Hacker News"],"footer.diversity_equity_inclusion":[0,"Diversity, equity & inclusion"],"footer.critical_infrastructure_defense_project":[0,"Critical Infrastructure Defense Project"]}]}" ssr="" client="idle" opts="{"name":"NavigationComponent","value":true}" await-children=""><header class="flex flex-row flex-wrap justify-between items-flex-end mw8 center mv3 pl3 pr1"><div class="w-100 flex items-flex-end justify-between justify-start-l"><div class="w-100 tr flex justify-end"><div class="flex justify-between items-center"><span class="dn di-l pr1"><a href="https://dash.cloudflare.com/sign-up" class="f1 blue1 dn di-l b no-underline underline-hover" target="_blank" rel="noreferrer">Get Started Free</a></span><span class="f1 gray4 dn di-l pr1">|</span><span class="dn di-l"><a target="_blank" href="https://www.cloudflare.com/plans/enterprise/contact/" class="f1 gray4 no-underline underline-hover pr1" rel="noreferrer">Contact Sales</a></span><span class="f1 gray4 dn di-l pr1">|</span><div class="relative flex cf-dropdown"><div class="flex items-center" dir="ltr"><button type="button" class="f1 gray4 no-underline language-picker js-language-picker" style="background:transparent;border:none;padding:0"><span class="language-picker__globe-icon"></span><span class="language-picker__caret-icon ph1">▼</span></button></div></div></div></div></div><div class="w-100 w-50-l flex items-end nb5 nb1-l"><a href="/" class="header-logo mr4 dn db-l"><img class="header-logo" src="https://cf-assets.www.cloudflare.com/zkvhlag99gkb/69RwBidpiEHCDZ9rFVVk7T/092507edbed698420b89658e5a6d5105/CF_logo_stacked_blktype.png" alt="The Cloudflare Blog" width="170" height="57"/></a><h2 class="mt0 mb1 dn di-l"><a href="/" class="fw5 f5 gray3 no-underline"><span class="dn di-l">The Cloudflare Blog</span></a></h2></div><div class="w-100 w-50-l dn db-l"><div class="w-100 tr mkto-sub-message"><p class="f2">Subscribe to receive notifications of new posts:</p></div><div class="w-100 tr"><div class="marketo-form-container"><form id="mktoForm_1653"><div class="top-subscribe-form-container"><div class="top-subscribe-form-field"><input placeholder="Email Address" class="top-subscribe-form-input" name="email" type="email" title="Must be valid email."/></div><button class="top-subscribe-form-button" type="button">Subscribe</button></div></form></div></div></div></header><nav dir="ltr" class="bb b--black-10 db dn-l w-100 ph3 "><div class=" flex justify-between items-center" style="height:44px"><a href="/search"><img class="h-6 w-6" src="/images/magnifier.svg" alt="magnifier icon"/></a><button type="button" style="background:transparent;border:none"><img src="/images/hamburger.svg" alt="hamburger menu"/></button></div><div class="js-mobile-nav-container dn"><div class="flex flex-column flex-wrap bg-gray9 o-95 absolute w-90 ph3 z-1"><div class="pv3 ph2 tl"><a href="/tag/product-news" class="no-underline gray1 f4 fw7">Product News</a></div><div class="pv3 ph2 tl"><a href="/tag/speed-and-reliability" class="no-underline gray1 f4 fw7">Speed & Reliability</a></div><div class="pv3 ph2 tl"><a href="/tag/security" class="no-underline gray1 f4 fw7">Security</a></div><div class="pv3 ph2 tl"><a href="/tag/zero-trust" class="no-underline gray1 f4 fw7">Zero Trust</a></div><div class="pv3 ph2 tl"><a href="/tag/developers" class="no-underline gray1 f4 fw7">Developers</a></div><div class="pv3 ph2 tl"><a href="/tag/ai" class="no-underline gray1 f4 fw7">AI</a></div><div class="pv3 ph2 tl"><a href="/tag/policy" class="no-underline gray1 f4 fw7">Policy</a></div><div class="pv3 ph2 tl"><a href="/tag/partners" class="no-underline gray1 f4 fw7">Partners</a></div><div class="pv3 ph2 tl"><a href="/tag/life-at-cloudflare" class="no-underline gray1 f4 fw7">Life at Cloudflare</a></div></div></div></nav><nav id="nav" class="w-100 bb-0 bb-l b--black-10 z-1"><div id="desktop-nav-items-container" class="flex flex-wrap justify-between items-center mw8 center mv3 mv0-l"><div data-tag="product-news" class="nav-item nav-item-desktop ml3 mr2 dn db-l pv3"><a href="/tag/product-news" class="no-underline gray1 f2 fw5 pv3">Product News</a></div><div data-tag="speed-and-reliability" class="nav-item nav-item-desktop ml3 mr2 dn db-l pv3"><a href="/tag/speed-and-reliability" class="no-underline gray1 f2 fw5 pv3">Speed & Reliability</a></div><div data-tag="security" class="nav-item nav-item-desktop ml3 mr2 dn db-l pv3"><a href="/tag/security" class="no-underline gray1 f2 fw5 pv3">Security</a></div><div data-tag="zero-trust" class="nav-item nav-item-desktop ml3 mr2 dn db-l pv3"><a href="/tag/zero-trust" class="no-underline gray1 f2 fw5 pv3">Zero Trust</a></div><div data-tag="developers" class="nav-item nav-item-desktop ml3 mr2 dn db-l pv3"><a href="/tag/developers" class="no-underline gray1 f2 fw5 pv3">Developers</a></div><div data-tag="ai" class="nav-item nav-item-desktop ml3 mr2 dn db-l pv3"><a href="/tag/ai" class="no-underline gray1 f2 fw5 pv3">AI</a></div><div data-tag="policy" class="nav-item nav-item-desktop ml3 mr2 dn db-l pv3"><a href="/tag/policy" class="no-underline gray1 f2 fw5 pv3">Policy</a></div><div data-tag="partners" class="nav-item nav-item-desktop ml3 mr2 dn db-l pv3"><a href="/tag/partners" class="no-underline gray1 f2 fw5 pv3">Partners</a></div><div data-tag="life-at-cloudflare" class="nav-item nav-item-desktop ml3 mr2 dn db-l pv3"><a href="/tag/life-at-cloudflare" class="no-underline gray1 f2 fw5 pv3">Life at Cloudflare</a></div><div class="nav-item ml2 mr3 dn db-l pv3" data-tag="search icon"><a href="/search/"><img id="search-icon" class="h-6 w-6" src="/images/magnifier.svg" alt="magnifier icon"/></a></div></div></nav></astro-island><progress class="reading-progress" value="0" max="100" aria-label="Reading progress"></progress><script>(()=>{var e=async t=>{await(await t())()};(self.Astro||(self.Astro={})).load=e;window.dispatchEvent(new Event("astro:load"));})();</script><astro-island uid="2q0RFh" prefix="r1" component-url="/_astro/Post.CntyhspV.js" component-export="Post" renderer-url="/_astro/client.BQCS8AJJ.js" props="{"post":[0,{"id":[0,"1upTpaZ3pXyoDXxMvZoEC8"],"title":[0,"HTTP/3: From root to tip"],"slug":[0,"http-3-from-root-to-tip"],"excerpt":[0,"Explore HTTP/3 from root to tip and discover the backstory of this new HTTP syntax that works on top of the IETF QUIC transport."],"featured":[0,false],"html":[0,"<p>HTTP is the application protocol that powers the Web. It began life as the so-called HTTP/0.9 protocol in 1991, and by 1999 had evolved to HTTP/1.1, which was standardised within the IETF (Internet Engineering Task Force). HTTP/1.1 was good enough for a long time but the ever changing needs of the Web called for a better suited protocol, and HTTP/2 emerged in 2015. More recently it was announced that the IETF is intending to deliver a new version - <a href=\"https://www.cloudflare.com/learning/performance/what-is-http3/\">HTTP/3</a>. To some people this is a surprise and has caused a bit of confusion. If you don&#39;t track IETF work closely it might seem that HTTP/3 has come out of the blue. However, we can trace its origins through a lineage of experiments and evolution of Web protocols; specifically the QUIC transport protocol.</p><p>If you&#39;re not familiar with QUIC, my colleagues have done a great job of tackling different angles. John&#39;s <a href=\"/the-quicening/\">blog</a> describes some of the real-world annoyances of today&#39;s HTTP, Alessandro&#39;s <a href=\"/the-road-to-quic/\">blog</a> tackles the nitty-gritty transport layer details, and Nick&#39;s blog covers <a href=\"/head-start-with-quic/\">how to get hands on</a> with some testing. We&#39;ve collected these and more at <a href=\"https://cloudflare-quic.com\">https://cloudflare-quic.com</a>. And if that tickles your fancy, be sure to check out <a href=\"/enjoy-a-slice-of-quic-and-rust/\">quiche</a>, our own open-source implementation of the QUIC protocol written in Rust.</p><p>HTTP/3 is the HTTP application mapping to the QUIC transport layer. This name was made official in the recent draft version 17 (<a href=\"https://tools.ietf.org/html/draft-ietf-quic-http-17\">draft-ietf-quic-http-17</a>), which was proposed in late October 2018, with discussion and rough consensus being formed during the IETF 103 meeting in Bangkok in November. HTTP/3 was previously known as HTTP over QUIC, which itself was previously known as HTTP/2 over QUIC. Before that we had HTTP/2 over gQUIC, and way back we had SPDY over gQUIC. The fact of the matter, however, is that HTTP/3 is just a new HTTP syntax that works on IETF QUIC, a UDP-based multiplexed and secure transport.</p><p>In this blog post we&#39;ll explore the history behind some of HTTP/3&#39;s previous names and present the motivation behind the most recent name change. We&#39;ll go back to the early days of HTTP and touch on all the good work that has happened along the way. If you&#39;re keen to get the full picture you can jump to the end of the article or open this <a href=\"/content/images/2019/01/web_timeline_large1.svg\">highly detailed SVG version</a>.</p>\n <figure class=\"kg-card kg-image-card \">\n \n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/1rKByCE0o19Q1zSD9Huliu/7f3540be1ff8f02da311c4df909def42/http3-stack.png\" alt=\"\" class=\"kg-image\" width=\"1028\" height=\"787\" loading=\"lazy\"/>\n \n </figure><p>An HTTP/3 layer cake</p>\n <div class=\"flex anchor relative\">\n <h2 id=\"setting-the-scene\">Setting the scene</h2>\n <a href=\"#setting-the-scene\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>Just before we focus on HTTP, it is worth reminding ourselves that there are two protocols that share the name QUIC. As we explained <a href=\"/the-road-to-quic/\">previously</a>, gQUIC is commonly used to identify Google QUIC (the original protocol), and QUIC is commonly used to represent the IETF standard-in-progress version that diverges from gQUIC.</p><p>Since its early days in the 90s, the web’s needs have changed. We&#39;ve had new versions of HTTP and added user security in the shape of Transport Layer Security (TLS). We&#39;ll only touch on TLS in this post, our other <a href=\"/tag/tls/\">blog posts</a> are a great resource if you want to explore that area in more detail.</p><p>To help me explain the history of HTTP and TLS, I started to collate details of protocol specifications and dates. This information is usually presented in a textual form such as a list of bullets points stating document titles, ordered by date. However, there are branching standards, each overlapping in time and a simple list cannot express the real complexity of relationships. In HTTP, there has been parallel work that refactors core protocol definitions for easier consumption, extends the protocol for new uses, and redefines how the protocol exchanges data over the Internet for performance. When you&#39;re trying to join the dots over nearly 30 years of Internet history across different branching work streams you need a visualisation. So I made one - the Cloudflare Secure Web Timeline. (NB: Technically it is a <a href=\"https://en.wikipedia.org/wiki/Cladogram\">Cladogram</a>, but the term timeline is more widely known).</p><p>I have applied some artistic license when creating this, choosing to focus on the successful branches in the IETF space. Some of the things not shown include efforts in the W3 Consortium <a href=\"https://www.w3.org/Protocols/HTTP-NG/\">HTTP-NG</a> working group, along with some exotic ideas that their authors are keen on explaining how to pronounce: <a href=\"https://blog.jgc.org/2012/12/speeding-up-http-with-minimal-protocol.html\">HMURR (pronounced &#39;hammer&#39;)</a> and <a href=\"https://github.com/HTTPWorkshop/workshop2017/blob/master/talks/waka.pdf\">WAKA (pronounced “wah-kah”)</a>.</p><p>In the next few sections I&#39;ll walk this timeline to explain critical chapters in the history of HTTP. To enjoy the takeaways from this post, it helps to have an appreciation of why standardisation is beneficial, and how the IETF approaches it. Therefore we&#39;ll start with a very brief overview of that topic before returning to the timeline itself. Feel free to skip the next section if you are already familiar with the IETF.</p>\n <div class=\"flex anchor relative\">\n <h2 id=\"types-of-internet-standard\">Types of Internet standard</h2>\n <a href=\"#types-of-internet-standard\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>Generally, standards define common terms of reference, scope, constraint, applicability, and other considerations. Standards exist in many shapes and sizes, and can be informal (aka de facto) or formal (agreed/published by a Standards Defining Organisation such as IETF, ISO or MPEG). Standards are used in many fields, there is even a formal British Standard for making tea - BS 6008.</p><p>The early Web used HTTP and SSL protocol definitions that were published outside the IETF, these are marked as <b>red lines</b> on the Secure Web Timeline. The uptake of these protocols by clients and servers made them de facto standards.</p><p>At some point, it was decided to formalise these protocols (some motivating reasons are described in a later section). Internet standards are commonly defined in the IETF, which is guided by the informal principle of &quot;rough consensus and running code&quot;. This is grounded in experience of developing and deploying things on the Internet. This is in contrast to a &quot;clean room&quot; approach of trying to develop perfect protocols in a vacuum.</p><p>IETF Internet standards are commonly known as RFCs. This is a complex area to explain so I recommend reading the blog post &quot;<a href=\"https://www.ietf.org/blog/how-read-rfc/\">How to Read an RFC</a>&quot; by the QUIC Working Group Co-chair Mark Nottingham. A Working Group, or WG, is more or less just a mailing list.</p><p>Each year the IETF hold three meetings that provide the time and facilities for all WGs to meet in person if they wish. The agenda for these weeks can become very congested, with limited time available to discuss highly technical areas in depth. To overcome this, some WGs choose to also hold interim meetings in the months between the the general IETF meetings. This can help to maintain momentum on specification development. The QUIC WG has held several interim meetings since 2017, a full list is available on their <a href=\"https://datatracker.ietf.org/wg/quic/meetings/\">meeting page</a>.</p><p>These IETF meetings also provide the opportunity for other IETF-related collections of people to meet, such as the <a href=\"https://www.iab.org/\">Internet Architecture Board</a> or <a href=\"https://irtf.org/\">Internet Research Task Force</a>. In recent years, an <a href=\"https://www.ietf.org/how/runningcode/hackathons/\">IETF Hackathon</a> has been held during the weekend preceding the IETF meeting. This provides an opportunity for the community to develop running code and, importantly, to carry out interoperability testing in the same room with others. This helps to find issues in specifications that can be discussed in the following days.</p><p>For the purposes of this blog, the important thing to understand is that RFCs don&#39;t just spring into existence. Instead, they go through a process that usually starts with an IETF Internet Draft (I-D) format that is submitted for consideration of adoption. In the case where there is already a published specification, preparation of an I-D might just be a simple reformatting exercise. I-Ds have a 6 month active lifetime from the date of publish. To keep them active, new versions need to be published. In practice, there is not much consequence to letting an I-D elapse and it happens quite often. The documents continue to be hosted on the <a href=\"https://datatracker.ietf.org/doc/recent\">IETF document’s website</a> for anyone that wants to read them.</p><p>I-Ds are represented on the Secure Web Timeline as <b>purple lines</b>. Each one has a unique name that takes the form of <i>draft-{author name}-{working group}-{topic}-{version}</i>. The working group field is optional, it might predict IETF WG that will work on the piece and sometimes this changes. If an I-D is adopted by the IETF, or if the I-D was initiated directly within the IETF, the name is <i>draft-ietf-{working group}-{topic}-{version}</i>. I-Ds may branch, merge or die on the vine. The version starts at 00 and increases by 1 each time a new draft is released. For example, the 4th draft of an I-D will have the version 03. Any time that an I-D changes name, its version resets back to 00.</p><p>It is important to note that anyone can submit an I-D to the IETF; you should not consider these as standards. But, if the IETF standardisation process of an I-D does reach consensus, and the final document passes review, we finally get an RFC. The name changes again at this stage. Each RFC gets a unique number e.g. <a href=\"https://tools.ietf.org/html/rfc7230\">RFC 7230</a>. These are represented as <b>blue lines</b> on the Secure Web Timeline.</p><p>RFCs are immutable documents. This means that changes to the RFC require a completely new number. Changes might be done in order to incorporate fixes for errata (editorial or technical errors that were found and reported) or simply to refactor the specification to improve layout. RFCs may <b>obsolete</b> older versions (complete replacement), or just <b>update</b> them (substantively change).</p><p>All IETF documents are openly available on <a href=\"http://tools.ietf.org\">http://tools.ietf.org</a>. Personally I find the <a href=\"https://datatracker.ietf.org\">IETF Datatracker</a> a little more user friendly because it provides a visualisation of a documents progress from I-D to RFC.</p><p>Below is an example that shows the development of <a href=\"https://tools.ietf.org/html/rfc1945\">RFC 1945</a> - HTTP/1.0 and it is a clear source of inspiration for the Secure Web Timeline.</p>\n <figure class=\"kg-card kg-image-card \">\n \n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/5SlEeIaoaU7r9PkklUSIOj/c24f0ba70885244920a29bea1daffd68/RFC-1945-datatracker.png\" alt=\"\" class=\"kg-image\" width=\"522\" height=\"197\" loading=\"lazy\"/>\n \n </figure><p>IETF Datatracker view of RFC 1945</p><p>Interestingly, in the course of my work I found that the above visualisation is incorrect. It is missing <a href=\"https://tools.ietf.org/html/draft-ietf-http-v10-spec-05\">draft-ietf-http-v10-spec-05</a> for some reason. Since the I-D lifetime is 6 months, there appears to be a gap before it became an RFC, whereas in reality draft 05 was still active through until August 1996.</p>\n <div class=\"flex anchor relative\">\n <h2 id=\"exploring-the-secure-web-timeline\">Exploring the Secure Web Timeline</h2>\n <a href=\"#exploring-the-secure-web-timeline\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>With a small appreciation of how Internet standards documents come to fruition, we can start to walk the the Secure Web Timeline. In this section are a number of excerpt diagrams that show an important part of the timeline. Each dot represents the date that a document or capability was made available. For IETF documents, draft numbers are omitted for clarity. However, if you want to see all that detail please check out the <a href=\"/content/images/2019/01/web_timeline_large1.svg\">complete timeline</a>.</p><p>HTTP began life as the so-called HTTP/0.9 protocol in 1991, and in 1994 the I-D <a href=\"https://tools.ietf.org/html/draft-fielding-http-spec-00\">draft-fielding-http-spec-00</a> was published. This was adopted by the IETF soon after, causing the name change to <a href=\"https://tools.ietf.org/html/draft-ietf-http-v10-spec-00\">draft-ietf-http-v10-spec-00</a>. The I-D went through 6 draft versions before being published as <a href=\"https://tools.ietf.org/html/rfc1945\">RFC 1945</a> - HTTP/1.0 in 1996.</p>\n <figure class=\"kg-card kg-image-card \">\n \n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/6fSsHSEtXc1HA38jJorxhO/d1a86966735f27d3b2ccfbcc1c8ec38d/http11-standardisation.png\" alt=\"\" class=\"kg-image\" width=\"504\" height=\"317\" loading=\"lazy\"/>\n \n </figure><p>However, even before the HTTP/1.0 work completed, a separate activity started on HTTP/1.1. The I-D <a href=\"https://tools.ietf.org/html/draft-ietf-http-v11-spec-00\">draft-ietf-http-v11-spec-00</a> was published in November 1995 and was formally published as <a href=\"https://tools.ietf.org/html/rfc2068\">RFC 2068</a> in 1997. The keen eyed will spot that the Secure Web Timeline doesn&#39;t quite capture that sequence of events, this is an unfortunate side effect of the tooling used to generate the visualisation. I tried to minimise such problems where possible.</p><p>An HTTP/1.1 revision exercise was started in mid-1997 in the form of <a href=\"https://tools.ietf.org/html/draft-ietf-http-v11-spec-rev-00\">draft-ietf-http-v11-spec-rev-00</a>. This completed in 1999 with the publication of <a href=\"https://tools.ietf.org/html/rfc2616\">RFC 2616</a>. Things went quiet in the IETF HTTP world until 2007. We&#39;ll come back to that shortly.</p>\n <div class=\"flex anchor relative\">\n <h2 id=\"a-history-of-ssl-and-tls\">A History of SSL and TLS</h2>\n <a href=\"#a-history-of-ssl-and-tls\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n \n <figure class=\"kg-card kg-image-card \">\n \n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/6pnAQiXiXCFpQpSkznYI1T/80a5516f4dafa64d1a5b60733b14c913/ssl-tls-standardisation.png\" alt=\"\" class=\"kg-image\" width=\"1215\" height=\"420\" loading=\"lazy\"/>\n \n </figure><p>Switching tracks to SSL. We see that the SSL 2.0 specification was released sometime around 1995, and that SSL 3.0 was released in November 1996. Interestingly, SSL 3.0 is described by <a href=\"https://tools.ietf.org/html/rfc6101\">RFC 6101</a>, which was released in August 2011. This sits in <b>Historic</b> category, which &quot;is usually done to document ideas that were considered and discarded, or protocols that were already historic when it was decided to document them.&quot; according to the <a href=\"https://www.ietf.org/blog/iesg-statement-designating-rfcs-historic/?primary_topic=7&\">IETF</a>. In this case it is advantageous to have an IETF-owned document that describes SSL 3.0 because it can be used as a canonical reference elsewhere.</p><p>Of more interest to us is how SSL inspired the development of TLS, which began life as <a href=\"https://tools.ietf.org/html/draft-ietf-tls-protocol-00\">draft-ietf-tls-protocol-00</a> in November 1996. This went through 6 draft versions and was published as <a href=\"https://tools.ietf.org/html/rfc2246\">RFC 2246</a> - TLS 1.0 at the start of 1999.</p><p>Between 1995 and 1999, the SSL and TLS protocols were used to secure HTTP communications on the Internet. This worked just fine as a de facto standard. It wasn&#39;t until January 1998 that the formal standardisation process for HTTPS was started with the publication of I-D <a href=\"https://tools.ietf.org/html/draft-ietf-tls-https-00\">draft-ietf-tls-https-00</a>. That work concluded in May 2000 with the publication of <a href=\"https://tools.ietf.org/html/rfc2616\">RFC 2616</a> - HTTP over TLS.</p><p>TLS continued to evolve between 2000 and 2007, with the standardisation of TLS 1.1 and 1.2. There was a gap of 7 years until work began on the next version of TLS, which was adopted as <a href=\"https://tools.ietf.org/html/draft-ietf-tls-tls13-00\">draft-ietf-tls-tls13-00</a> in April 2014 and, after 28 drafts, completed as <a href=\"https://tools.ietf.org/html/rfc8446\">RFC 8446</a> - TLS 1.3 in August 2018.</p>\n <div class=\"flex anchor relative\">\n <h2 id=\"internet-standardisation-process\">Internet standardisation process</h2>\n <a href=\"#internet-standardisation-process\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>After taking a small look at the timeline, I hope you can build a sense of how the IETF works. One generalisation for the way that Internet standards take shape is that researchers or engineers design experimental protocols that suit their specific use case. They experiment with protocols, in public or private, at various levels of scale. The data helps to identify improvements or issues. The work may be published to explain the experiment, to gather wider input or to help find other implementers. Take up of this early work by others may make it a de facto standard; eventually there may be sufficient momentum that formal standardisation becomes an option.</p><p>The status of a protocol can be an important consideration for organisations that may be thinking about implementing, deploying or in some way using it. A formal standardisation process can make a de facto standard more attractive because it tends to provide stability. The stewardship and guidance is provided by an organisation, such as the IETF, that reflects a wider range of experiences. However, it is worth highlighting that not all all formal standards succeed.</p><p>The process of creating a final standard is almost as important as the standard itself. Taking an initial idea and inviting contribution from people with wider knowledge, experience and use cases can to help produce something that will be of more use to a wider population. However, the standardisation process is not always easy. There are pitfalls and hurdles. Sometimes the process takes so long that the output is no longer relevant.</p><p>Each Standards Defining Organisation tends to have its own process that is geared around its field and participants. Explaining all of the details about how the IETF works is well beyond the scope of this blog. The IETF&#39;s &quot;<a href=\"https://www.ietf.org/how/\">How we work</a>&quot; page is an excellent starting point that covers many aspects. The best method to forming understanding, as usual, is to get involved yourself. This can be as easy as joining an email list or adding to discussion on a relevant GitHub repository.</p>\n <div class=\"flex anchor relative\">\n <h2 id=\"cloudflares-running-code\">Cloudflare's running code</h2>\n <a href=\"#cloudflares-running-code\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>Cloudflare is proud to be early an adopter of new and evolving protocols. We have a long record of adopting new standards early, such as <a href=\"/introducing-http2/\">HTTP/2</a>. We also test features that are experimental or yet to be final, like <a href=\"/introducing-tls-1-3/\">TLS 1.3</a> and <a href=\"/introducing-spdy/\">SPDY</a>.</p><p>In relation to the IETF standardisation process, deploying this running code on real networks across a diverse body of websites helps us understand how well the protocol will work in practice. We combine our existing expertise with experimental information to help improve the running code and, where it makes sense, feedback issues or improvements to the WG that is standardising a protocol.</p><p>Testing new things is not the only priority. Part of being an innovator is knowing when it is time to move forward and put older innovations in the rear view mirror. Sometimes this relates to security-oriented protocols, for example, Cloudflare <a href=\"/sslv3-support-disabled-by-default-due-to-vulnerability/\">disabled SSLv3 by default</a> due of the POODLE vulnerability. In other cases, protocols become superseded by a more technologically advanced one; Cloudflare <a href=\"/deprecating-spdy/\">deprecated SPDY</a> support in favour of HTTP/2.</p><p>The introduction and deprecation of relevant protocols are represented on the Secure Web Timeline as <b>orange lines</b>. Dotted vertical lines help correlate Cloudflare events to relevant IETF documents. For example, Cloudflare introduced TLS 1.3 support in September 2016, with the final document, <a href=\"https://tools.ietf.org/html/rfc8446\">RFC 8446</a>, being published almost two years later in August 2018.</p>\n <figure class=\"kg-card kg-image-card \">\n \n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/ptcxVRf8P4wmKMz6uSzAk/4d37f0581a865bc4f120282e7d9d5ebf/cf-events.png\" alt=\"\" class=\"kg-image\" width=\"623\" height=\"463\" loading=\"lazy\"/>\n \n </figure>\n <div class=\"flex anchor relative\">\n <h2 id=\"refactoring-in-httpbis\">Refactoring in HTTPbis</h2>\n <a href=\"#refactoring-in-httpbis\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>HTTP/1.1 is a very successful protocol and the timeline shows that there wasn&#39;t much activity in the IETF after 1999. However, the true reflection is that years of active use gave implementation experience that unearthed latent issues with <a href=\"https://tools.ietf.org/html/rfc2616\">RFC 2616</a>, which caused some interoperability issues. Furthermore, the protocol was extended by other RFCs like 2817 and 2818. It was decided in 2007 to kickstart a new activity to improve the HTTP protocol specification. This was called HTTPbis (where &quot;bis&quot; stems from Latin meaning &quot;two&quot;, &quot;twice&quot; or &quot;repeat&quot;) and it took the form of a new Working Group. The original <a href=\"https://tools.ietf.org/wg/httpbis/charters?item=charter-httpbis-2007-10-23.txt\">charter</a> does a good job of describing the problems that were trying to be solved.</p><p>In short, HTTPbis decided to refactor <a href=\"https://tools.ietf.org/html/rfc2616\">RFC 2616</a>. It would incorporate errata fixes and buy in some aspects of other specifications that had been published in the meantime. It was decided to split the document up into parts. This resulted in 6 I-Ds published in December 2007:</p><ul><li><p>draft-ietf-httpbis-p1-messaging</p></li><li><p>draft-ietf-httpbis-p2-semantics</p></li><li><p>draft-ietf-httpbis-p4-conditional</p></li><li><p>draft-ietf-httpbis-p5-range</p></li><li><p>draft-ietf-httpbis-p6-cache</p></li><li><p>draft-ietf-httpbis-p7-auth</p></li></ul>\n <figure class=\"kg-card kg-image-card \">\n \n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/5cCDzKbc2DBLJgD1cdLCor/c928470939df5acd6112503c41c78db3/http11-refactor.png\" alt=\"\" class=\"kg-image\" width=\"730\" height=\"531\" loading=\"lazy\"/>\n \n </figure><p>The diagram shows how this work progressed through a lengthy drafting process of 7 years, with 27 draft versions being released, before final standardisation. In June 2014, the so-called RFC 723x series was released (where x ranges from 0 to 5). The Chair of the HTTPbis WG celebrated this achievement with the acclimation &quot;<a href=\"https://www.mnot.net/blog/2014/06/07/rfc2616_is_dead\">RFC2616 is Dead</a>&quot;. If it wasn&#39;t clear, these new documents obsoleted the older <a href=\"https://tools.ietf.org/html/rfc2616\">RFC 2616</a>.</p>\n <div class=\"flex anchor relative\">\n <h2 id=\"what-does-any-of-this-have-to-do-with-http-3\">What does any of this have to do with HTTP/3?</h2>\n <a href=\"#what-does-any-of-this-have-to-do-with-http-3\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>While the IETF was busy working on the RFC 723x series the world didn&#39;t stop. People continued to enhance, extend and experiment with HTTP on the Internet. Among them were Google, who had started to experiment with something called SPDY (pronounced speedy). This protocol was touted as improving the performance of web browsing, a principle use case for HTTP. At the end of 2009 SPDY v1 was announced, and it was quickly followed by SPDY v2 in 2010.</p><p>I want to avoid going into the technical details of SPDY. That&#39;s a topic for another day. What is important, is to understand that SPDY took the core paradigms of HTTP and modified the interchange format slightly in order to gain improvements. With hindsight, we can see that HTTP has clearly delimited semantics and syntax. Semantics describe the concept of request and response exchanges including: methods, status codes, header fields (metadata) and bodies (payload). Syntax describe how to map semantics to bytes on the wire.</p><p>HTTP/0.9, 1.0 and 1.1 share many semantics. They also share syntax in the form of character strings that are sent over TCP connections. SPDY took HTTP/1.1 semantics and changed the syntax from strings to binary. This is a really interesting topic but we will go no further down that rabbit hole today.</p><p>Google&#39;s experiments with SPDY showed that there was promise in changing HTTP syntax, and value in keeping the existing HTTP semantics. For example, keeping the format of URLs to use https:// avoided many problems that could have affected adoption.</p><p>Having seen some of the positive outcomes, the IETF decided it was time to consider what HTTP/2.0 might look like. The <a href=\"https://github.com/httpwg/wg-materials/blob/gh-pages/ietf83/HTTP2.pdf\">slides</a> from the HTTPbis session held during IETF 83 in March 2012 show the requirements, goals and measures of success that were set out. It is also clearly states that &quot;HTTP/2.0 only signifies that the wire format isn&#39;t compatible with that of HTTP/1.x&quot;.</p>\n <figure class=\"kg-card kg-image-card \">\n \n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/3EQMui9QKRGR8Vzcu5wMZA/229e6a1cb1cc1fa78da96dc34f59c220/http2-standardisation.png\" alt=\"\" class=\"kg-image\" width=\"489\" height=\"382\" loading=\"lazy\"/>\n \n </figure><p>During that meeting the community was invited to share proposals. I-Ds that were submitted for consideration included <a href=\"https://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00\">draft-mbelshe-httpbis-spdy-00</a>, <a href=\"https://tools.ietf.org/html/draft-montenegro-httpbis-speed-mobility-00\">draft-montenegro-httpbis-speed-mobility-00</a> and <a href=\"https://tools.ietf.org/html/draft-tarreau-httpbis-network-friendly-00\">draft-tarreau-httpbis-network-friendly-00</a>. Ultimately, the SPDY draft was adopted and in November 2012 work began on <a href=\"https://tools.ietf.org/html/draft-ietf-httpbis-http2-00\">draft-ietf-httpbis-http2-00</a>. After 18 drafts across a period of just over 2 years, <a href=\"https://tools.ietf.org/html/rfc7540\">RFC 7540</a> - HTTP/2 was published in 2015. During this specification period, the precise syntax of HTTP/2 diverged just enough to make HTTP/2 and SPDY incompatible.</p><p>These years were a very busy period for the HTTP-related work at the IETF, with the HTTP/1.1 refactor and HTTP/2 standardisation taking place in parallel. This is in stark contrast to the many years of quiet in the early 2000s. Be sure to check out the full timeline to really appreciate the amount of work that took place.</p><p>Although HTTP/2 was in the process of being standardised, there was still benefit to be had from using and experimenting with SPDY. Cloudflare <a href=\"/spdy-now-one-click-simple-for-any-website/\">introduced support for SPDY</a> in August 2012 and only deprecated it in February 2018 when our statistics showed that less than 4% of Web clients continued to want SPDY. Meanwhile, we <a href=\"/introducing-http2/\">introduced HTTP/2</a> support in December 2015, not long after the RFC was published, when our analysis indicated that a meaningful proportion of Web clients could take advantage of it.</p><p>Web client support of the SPDY and HTTP/2 protocols preferred the secure option of using TLS. The introduction of <a href=\"/introducing-universal-ssl/\">Universal SSL</a> in September 2014 helped ensure that all websites signed up to Cloudflare were able to take advantage of these new protocols as we introduced them.</p>\n <div class=\"flex anchor relative\">\n <h3 id=\"gquic\">gQUIC</h3>\n <a href=\"#gquic\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>Google continued to experiment between 2012 and 2015 they released SPDY v3 and v3.1. They also started working on gQUIC (pronounced, at the time, as quick) and the initial public specification was made available in early 2012.</p><p>The early versions of gQUIC made use of the SPDY v3 form of HTTP syntax. This choice made sense because HTTP/2 was not yet finished. The SPDY binary syntax was packaged into QUIC packets that could sent in UDP datagrams. This was a departure from the TCP transport that HTTP traditionally relied on. When stacked up all together this looked like:</p>\n <figure class=\"kg-card kg-image-card \">\n \n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/40oAdMSmePG37lMEb8Odfi/b5cf02bbe9256889bd0cc103a34484a9/gquic-stack.png\" alt=\"\" class=\"kg-image\" width=\"1028\" height=\"753\" loading=\"lazy\"/>\n \n </figure><p>SPDY over gQUIC layer cake</p><p>gQUIC used clever tricks to achieve performance. One of these was to break the clear layering between application and transport. What this meant in practice was that gQUIC only ever supported HTTP. So much so that gQUIC, termed &quot;QUIC&quot; at the time, was synonymous with being the next candidate version of HTTP. Despite the continued changes to QUIC over the last few years, which we&#39;ll touch on momentarily, to this day, the term QUIC is understood by people to mean that initial HTTP-only variant. Unfortunately this is a regular source of confusion when discussing the protocol.</p><p>gQUIC continued to experiment and eventually switched over to a syntax much closer to HTTP/2. So close in fact that most people simply called it &quot;HTTP/2 over QUIC&quot;. However, because of technical constraints there were some very subtle differences. One example relates to how the HTTP headers were serialized and exchanged. It is a minor difference but in effect means that HTTP/2 over gQUIC was incompatible with the IETF&#39;s HTTP/2.</p><p>Last but not least, we always need to consider the security aspects of Internet protocols. gQUIC opted not to use TLS to provide security. Instead Google developed a different approach called QUIC Crypto. One of the interesting aspects of this was a new method for speeding up security handshakes. A client that had previously established a secure session with a server could reuse information to do a &quot;zero <a href=\"https://www.cloudflare.com/learning/cdn/glossary/round-trip-time-rtt/\">round-trip time</a>&quot;, or 0-RTT, handshake. 0-RTT was later incorporated into TLS 1.3.</p>\n <div class=\"flex anchor relative\">\n <h2 id=\"are-we-at-the-point-where-you-can-tell-me-what-http-3-is-yet\">Are we at the point where you can tell me what HTTP/3 is yet?</h2>\n <a href=\"#are-we-at-the-point-where-you-can-tell-me-what-http-3-is-yet\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>Almost.</p><p>By now you should be familiar with how standardisation works and gQUIC is not much different. There was sufficient interest that the Google specifications were written up in I-D format. In June 2015 <a href=\"https://tools.ietf.org/html/draft-tsvwg-quic-protocol-00\">draft-tsvwg-quic-protocol-00</a>, entitled &quot;QUIC: A UDP-based Secure and Reliable Transport for HTTP/2&quot; was submitted. Keep in mind my earlier statement that the syntax was almost-HTTP/2.</p><p>Google <a href=\"https://groups.google.com/a/chromium.org/forum/#!topic/proto-quic/otGKB4ytAyc\">announced</a> that a Bar BoF would be held at IETF 93 in Prague. For those curious about what a &quot;Bar BoF&quot; is, please consult <a href=\"https://tools.ietf.org/html/rfc6771\">RFC 6771</a>. Hint: BoF stands for Birds of a Feather.</p>\n <figure class=\"kg-card kg-image-card \">\n \n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/364tlrFLOtgAYBYxHrOXy8/18f5cebace8c29778e06109fe878c3b8/quic-standardisation.png\" alt=\"\" class=\"kg-image\" width=\"560\" height=\"515\" loading=\"lazy\"/>\n \n </figure><p>The outcome of this engagement with the IETF was, in a nutshell, that QUIC seemed to offer many advantages at the transport layer and that it should be decoupled from HTTP. The clear separation between layers should be re-introduced. Furthermore, there was a preference for returning back to a TLS-based handshake (which wasn&#39;t so bad since TLS 1.3 was underway at this stage, and it was incorporating 0-RTT handshakes).</p><p>About a year later, in 2016, a new set of I-Ds were submitted:</p><ul><li><p><a href=\"https://tools.ietf.org/html/draft-hamilton-quic-transport-protocol-00\">draft-hamilton-quic-transport-protocol-00</a></p></li><li><p><a href=\"https://tools.ietf.org/html/draft-thomson-quic-tls-00\">draft-thomson-quic-tls-00</a></p></li><li><p><a href=\"https://tools.ietf.org/html/draft-iyengar-quic-loss-recovery-00\">draft-iyengar-quic-loss-recovery-00</a></p></li><li><p><a href=\"https://tools.ietf.org/html/draft-shade-quic-http2-mapping-00\">draft-shade-quic-http2-mapping-00</a></p></li></ul><p>Here&#39;s where another source of confusion about HTTP and QUIC enters the fray. <a href=\"https://tools.ietf.org/html/draft-shade-quic-http2-mapping-00\">draft-shade-quic-http2-mapping-00</a> is entitled &quot;HTTP/2 Semantics Using The QUIC Transport Protocol&quot; and it describes itself as &quot;a mapping of HTTP/2 semantics over QUIC&quot;. However, this is a misnomer. HTTP/2 was about changing syntax while maintaining semantics. Furthermore, &quot;HTTP/2 over gQUIC&quot; was never an accurate description of the syntax either, for the reasons I outlined earlier. Hold that thought.</p><p>This IETF version of QUIC was to be an entirely new transport protocol. That&#39;s a large undertaking and before diving head-first into such commitments, the IETF likes to gauge actual interest from its members. To do this, a formal <a href=\"https://www.ietf.org/how/bofs/\">Birds of a Feather</a> meeting was held at the IETF 96 meeting in Berlin in 2016. I was lucky enough to attend the session in person and the <a href=\"https://datatracker.ietf.org/meeting/96/materials/slides-96-quic-0\">slides</a> don&#39;t give it justice. The meeting was attended by hundreds, as shown by Adam Roach&#39;s <a href=\"https://www.flickr.com/photos/adam-roach/28343796722/in/photostream/\">photograph</a>. At the end of the session consensus was reached; QUIC would be adopted and standardised at the IETF.</p><p>The first IETF QUIC I-D for mapping HTTP to QUIC, <a href=\"https://tools.ietf.org/html/draft-ietf-quic-http-00\">draft-ietf-quic-http-00</a>, took the Ronseal approach and simplified its name to &quot;HTTP over QUIC&quot;. Unfortunately, it didn&#39;t finish the job completely and there were many instances of the term HTTP/2 throughout the body. Mike Bishop, the I-Ds new editor, identified this and started to fix the HTTP/2 misnomer. In the 01 draft, the description changed to &quot;a mapping of HTTP semantics over QUIC&quot;.</p><p>Gradually, over time and versions, the use of the term &quot;HTTP/2&quot; decreased and the instances became mere references to parts of <a href=\"https://tools.ietf.org/html/rfc7540\">RFC 7540</a>. Roll forward two years to October 2018 and the I-D is now at version 16. While HTTP over QUIC bares similarity to HTTP/2 it ultimately is an independent, non-backwards compatible HTTP syntax. However, to those that don&#39;t track IETF development very closely (a very very large percentage of the Earth&#39;s population), the document name doesn&#39;t capture this difference. One of the main points of standardisation is to aid communication and interoperability. Yet a simple thing like naming is a major contributor to confusion in the community.</p><p>Recall what was said in 2012, &quot;HTTP/2.0 only signifies that the wire format isn&#39;t compatible with that of HTTP/1.x&quot;. The IETF followed that existing cue. After much deliberation in the lead up to, and during, IETF 103, consensus was reached to rename &quot;HTTP over QUIC&quot; to HTTP/3. The world is now in a better place and we can move on to more important debates.</p>\n <div class=\"flex anchor relative\">\n <h2 id=\"but-rfc-7230-and-7231-disagree-with-your-definition-of-semantics-and-syntax\">But RFC 7230 and 7231 disagree with your definition of semantics and syntax!</h2>\n <a href=\"#but-rfc-7230-and-7231-disagree-with-your-definition-of-semantics-and-syntax\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>Sometimes document titles can be confusing. The present HTTP documents that describe syntax and semantics are:</p><ul><li><p><a href=\"https://tools.ietf.org/html/rfc7230\">RFC 7230</a> - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</p></li><li><p><a href=\"https://tools.ietf.org/html/rfc7231\">RFC 7231</a> - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</p></li></ul><p>It is possible to read too much into these names and believe that fundamental HTTP semantics are specific for versions of HTTP i.e. HTTP/1.1. However, this is an unintended side effect of the HTTP family tree. The good news is that the HTTPbis Working Group are trying to address this. Some brave members are going through another round of document revision, as Roy Fielding put it, &quot;one more time!&quot;. This work is underway right now and is known as the HTTP Core activity (you may also have heard of this under the moniker HTTPtre or HTTPter; naming things is hard). This will condense the six drafts down to three:</p><ul><li><p>HTTP Semantics (draft-ietf-httpbis-semantics)</p></li><li><p>HTTP Caching (draft-ietf-httpbis-caching)</p></li><li><p>HTTP/1.1 Message Syntax and Routing (draft-ietf-httpbis-messaging)</p></li></ul><p>Under this new structure, it becomes more evident that HTTP/2 and HTTP/3 are syntax definitions for the common HTTP semantics. This doesn&#39;t mean they don&#39;t have their own features beyond syntax but it should help frame discussion going forward.</p>\n <div class=\"flex anchor relative\">\n <h2 id=\"pulling-it-all-together\">Pulling it all together</h2>\n <a href=\"#pulling-it-all-together\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>This blog post has taken a shallow look at the standardisation process for HTTP in the IETF across the last three decades. Without touching on many technical details, I&#39;ve tried to explain how we have ended up with HTTP/3 today. If you skipped the good bits in the middle and are looking for a one liner here it is: HTTP/3 is just a new HTTP syntax that works on IETF QUIC, a UDP-based multiplexed and secure transport. There are many interesting technical areas to explore further but that will have to wait for another day.</p><p>In the course of this post, we explored important chapters in the development of HTTP and TLS but did so in isolation. We close out the blog by pulling them all together into the complete Secure Web Timeline presented below. You can use this to investigate the detailed history at your own comfort. And for the super sleuths, be sure to check out the <a href=\"/content/images/2019/01/web_timeline_large1.svg\">full version including draft numbers</a>.</p>\n <figure class=\"kg-card kg-image-card \">\n \n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/3eL8vJkYylVmR4T5Aa1Zdf/2f2929308ee42e450917639874835c1d/cf-secure-web-timeline-1.png\" alt=\"\" class=\"kg-image\" width=\"1303\" height=\"2444\" loading=\"lazy\"/>\n \n </figure>"],"published_at":[0,"2019-01-24T17:57:09.000+00:00"],"updated_at":[0,"2024-10-09T23:09:40.277Z"],"feature_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/4sHg74EBOhB89AyctJUIOV/0147d90b72529c6e60c6b345dd194c83/http-3-from-root-to-tip.png"],"tags":[1,[[0,{"id":[0,"76HSdQ6sNz56VVQXRUhhSw"],"name":[0,"QUIC"],"slug":[0,"quic"]}],[0,{"id":[0,"56vA0Z6hqev6QaJBQmO2J8"],"name":[0,"TLS"],"slug":[0,"tls"]}],[0,{"id":[0,"6Mp7ouACN2rT3YjL1xaXJx"],"name":[0,"Security"],"slug":[0,"security"]}],[0,{"id":[0,"4mFivBDCciYNedwQVKLKAg"],"name":[0,"HTTP3"],"slug":[0,"http3"]}],[0,{"id":[0,"SSoBzzf0KiZJPco6VApIL"],"name":[0,"IETF"],"slug":[0,"ietf"]}]]],"relatedTags":[0],"authors":[1,[[0,{"name":[0,"Lucas Pardue"],"slug":[0,"lucas"],"bio":[0,"HTTP/2, HTTP/3 and QUIC @Cloudflare. IETF QUIC WG Co-Chair. I write some words, some code and occasionally speak."],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/1k0fbniT2p2wjRfMognV4V/dca8d2e3a3e7fa4e24d7ddd9832eff1d/lucas.jpg"],"location":[0,"London"],"website":[0,null],"twitter":[0,"@SimmerVigor"],"facebook":[0,null]}]]],"meta_description":[0,"Explore HTTP/3 from root to tip and discover the backstory of this new HTTP syntax that works on top of the IETF QUIC transport."],"primary_author":[0,{}],"localeList":[0,{"name":[0,"HTTP/3: From root to tip Config"],"enUS":[0,"English for Locale"],"zhCN":[0,"Translated for Locale"],"zhHansCN":[0,"No Page for Locale"],"zhTW":[0,"No Page for Locale"],"frFR":[0,"Translated for Locale"],"deDE":[0,"Translated for Locale"],"itIT":[0,"No Page for Locale"],"jaJP":[0,"No Page for Locale"],"koKR":[0,"No Page for Locale"],"ptBR":[0,"No Page for Locale"],"esLA":[0,"No Page for Locale"],"esES":[0,"Translated for Locale"],"enAU":[0,"No Page for Locale"],"enCA":[0,"No Page for Locale"],"enIN":[0,"No Page for Locale"],"enGB":[0,"No Page for Locale"],"idID":[0,"No Page for Locale"],"ruRU":[0,"No Page for Locale"],"svSE":[0,"No Page for Locale"],"viVN":[0,"No Page for Locale"],"plPL":[0,"No Page for Locale"],"arAR":[0,"No Page for Locale"],"nlNL":[0,"No Page for Locale"],"thTH":[0,"No Page for Locale"],"trTR":[0,"No Page for Locale"],"heIL":[0,"No Page for Locale"],"lvLV":[0,"No Page for Locale"],"etEE":[0,"No Page for Locale"],"ltLT":[0,"No Page for Locale"]}],"url":[0,"https://blog.cloudflare.com/http-3-from-root-to-tip"],"metadata":[0,{"title":[0],"description":[0],"imgPreview":[0,""]}]}],"initialReadingTime":[0,"18"],"relatedPosts":[1,[[0,{"id":[0,"5BHU4q5GpzBQ1OLQoUvkKN"],"title":[0,"What’s new in Cloudflare: Account Owned Tokens and Zaraz Automated Actions"],"slug":[0,"account-owned-tokens-automated-actions-zaraz"],"excerpt":[0,"Cloudflare customers can now create Account Owned Tokens , allowing more flexibility around access control for their Cloudflare services. Additionally, Zaraz Automation Actions streamlines event tracking and third-party tool integration. "],"featured":[0,false],"html":[0,"<p>In October 2024, we started publishing roundup blog posts to share the latest features and updates from our teams. Today, we are announcing general availability for Account Owned Tokens, which allow organizations to improve access control for their Cloudflare services. Additionally, we are launching Zaraz Automated Actions, which is a new feature designed to streamline event tracking and tool integration when setting up third-party tools. By automating common actions like pageviews, custom events, and e-commerce tracking, it removes the need for manual configurations.</p>\n <div class=\"flex anchor relative\">\n <h2 id=\"improving-access-control-for-cloudflare-services-with-account-owned-tokens\">Improving access control for Cloudflare services with Account Owned Tokens</h2>\n <a href=\"#improving-access-control-for-cloudflare-services-with-account-owned-tokens\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>Cloudflare is critical infrastructure for the Internet, and we understand that many of the organizations that build on Cloudflare rely on apps and integrations outside the platform to make their lives easier. In order to allow access to Cloudflare resources, these apps and integrations interact with Cloudflare via our API, enabled by access tokens and API keys. Today, the API Access Tokens and API keys on the Cloudflare platform are owned by individual users, which can lead to some difficulty representing services, and adds an additional dependency on managing users alongside token permissions.</p>\n <div class=\"flex anchor relative\">\n <h3 id=\"whats-new-about-account-owned-tokens\">What’s new about Account Owned Tokens</h3>\n <a href=\"#whats-new-about-account-owned-tokens\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>First, a little explanation because the terms can be a little confusing. On Cloudflare, we have both Users and Accounts, and they mean different things, but sometimes look similar. Users are people, and they sign in with an email address. Accounts are not people, they’re the top-level bucket we use to organize all the resources you use on Cloudflare. Accounts can have many users, and that’s how we enable collaboration. If you use Cloudflare for your personal projects, both your User and Account might have your email address as the name, but if you use Cloudflare as a company, the difference is more apparent because your user is “<a href=\"mailto:joe.smith@example.com\"><u>joe.smith@example.com</u></a>” and the account might be “Example Company”. </p>\n <figure class=\"kg-card kg-image-card\">\n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/5tcNkxDjYz9jAXnfV0bPON/920a9dade7145de2adee21afa43d786e/image13.jpg\" alt=\"\" class=\"kg-image\" width=\"1836\" height=\"1225\" loading=\"lazy\"/>\n </figure><p>Account Owned Tokens are not confined by the permissions of the creating user (e.g. a user can never make a token that can edit a field that they otherwise couldn’t edit themselves) and are scoped to the account they are owned by. This means that instead of creating a token belonging to the user “<a href=\"mailto:joe.smith@example.com\"><u>joe.smith@example.com</u></a>”, you can now create a token belonging to the account “Example Company”.</p>\n <figure class=\"kg-card kg-image-card\">\n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/ibh4sT2wgVLVTgqgv2rtO/eb972a5b1c5fa0f70471631430a8ff91/image8.jpg\" alt=\"\" class=\"kg-image\" width=\"1385\" height=\"1623\" loading=\"lazy\"/>\n </figure><p>The ability to make these tokens, owned by the account instead of the user, allows for more flexibility to represent what the access should be used for.</p><p>Prior to Account Owned Tokens, customers would have to have a user (<a href=\"mailto:joe.smith@example.com\"><u>joe.smith@example.com</u></a>) create a token to pull a list of Cloudflare zones for their account and ensure their security settings are set correctly as part of a compliance workflow, for example. All of the actions this compliance workflow does are now attributed to joe.smith, and if joe.smith leaves the company and his permissions are revoked, the compliance workflow fails.</p><p>With this new release, an Account Owned Token could be created, named “compliance workflow”, with permissions to do this operation independently of <a href=\"mailto:joe.smith@example.com\"><u>joe.smith@example.com</u></a>. All actions this token does are attributable to “compliance workflow”. This token is visible and manageable by all the superadmins on your Cloudflare account. If joe.smith leaves the company, the access remains independent of that user, and all super administrators on the account moving forward can still see, edit, roll, and delete the token as needed.</p><p>Any long-running services or programs can be represented by these types of tokens, be made visible (and manageable) by all super administrators in your Cloudflare account, and truly represent the service, instead of the users managing the service. Audit logs moving forward will log that a given token was used, and user access can be kept to a minimum.</p>\n <div class=\"flex anchor relative\">\n <h3 id=\"getting-started\">Getting started</h3>\n <a href=\"#getting-started\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>Account Owned Tokens can be found on the new “API Tokens” tab under the “Manage Account” section of your Cloudflare dashboard, and any Super Administrators on your account have the capability to create, edit, roll, and delete these tokens. The API is the same, but at a new <code>/account/&lt;accountId&gt;/tokens</code> endpoint.</p>\n <figure class=\"kg-card kg-image-card\">\n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/uZFVUp1RRP1NgZli9RAYN/5e2b90bea51b7b45bb25478120fd9024/Screenshot_2024-11-13_at_20.14.43.png\" alt=\"\" class=\"kg-image\" width=\"2024\" height=\"648\" loading=\"lazy\"/>\n </figure>\n <figure class=\"kg-card kg-image-card\">\n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/1kiUi4lsJESJqr9HhgCS92/b4b0a3e955742346a5c945601fff4885/image3.png\" alt=\"\" class=\"kg-image\" width=\"1394\" height=\"896\" loading=\"lazy\"/>\n </figure>\n <div class=\"flex anchor relative\">\n <h3 id=\"why-where-should-i-use-account-owned-tokens\">Why/where should I use Account Owned Tokens?</h3>\n <a href=\"#why-where-should-i-use-account-owned-tokens\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>There are a few places we would recommend replacing your User Owned Tokens with Account Owned Tokens:</p><p>1. <b>Long-running services that are managed by multiple people:</b> When multiple users all need to manage the same service, Account Owned Tokens can remove the bottleneck of requiring a single person to be responsible for all the edits, rotations, and deletions of the tokens. In addition, this guards against any user lifecycle events affecting the service. If the employee that owns the token for your service leaves the company, the service’s token will no longer be based on their permissions.</p><p>2.<b> Cloudflare accounts running any services that need attestable access records beyond user membership:</b> By restricting all of your users from being able to access the API, and consolidating all usable tokens to a single list at the account level, you can ensure that a complete list of all API access can be found in a single place on the dashboard, under “Account API Tokens”.</p>\n <figure class=\"kg-card kg-image-card\">\n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/2qtssh6bef5Ne6kugqUUnc/af11e3db733f4f38188988ac42034c26/image9.png\" alt=\"\" class=\"kg-image\" width=\"1379\" height=\"252\" loading=\"lazy\"/>\n </figure><p>3. <b>Anywhere you’ve created “Service Users”:</b> “Service Users”, or any identity that is meant to allow multiple people to access Cloudflare, are an active threat surface. They are generally highly privileged, and require additional controls (vaulting, password rotation, monitoring) to ensure non-repudiation and appropriate use. If these operations solely require API access, consolidating that access into an Account Owned Token is safe.</p>\n <div class=\"flex anchor relative\">\n <h3 id=\"why-where-should-i-use-user-owned-tokens\">Why/where should I use User Owned Tokens?</h3>\n <a href=\"#why-where-should-i-use-user-owned-tokens\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>There are a few scenarios/situations where you should continue to use User Owned Tokens:</p><ol><li><p><b>Where programmatic access is done by a single person at an external interface:</b> If a single user has an external interface using their own access privileges at Cloudflare, it still makes sense to use a personal token, so that information access can be traced back to them. (e.g. using a personal token in a data visualization tool that pulls logs from Cloudflare)</p></li><li><p><a href=\"https://developers.cloudflare.com/api/operations/user-user-details\"><b><u>User level operations</u></b></a><b>:</b> Any operations that operate on your own user (e.g. email changes, password changes, user preferences) still require a user level token.</p></li><li><p><b>Where you want to control resources over multiple accounts with the same credential:</b> As of November 2024, Account Owned Tokens are scoped to a single account. In 2025, we want to ensure that we can create cross-account credentials, anywhere that multiple accounts have to be called in the same set of operations should still rely on API Tokens owned by a user.</p></li><li><p><b>Where we currently do not support a given endpoint:</b> We are currently in the process of working through a <a href=\"https://developers.cloudflare.com/fundamentals/api/get-started/account-owned-tokens/\"><u>list of our services</u></a> to ensure that they all support Account Owned Tokens. When interacting with any of these services that are not supported programmatically, please continue to use User Owned Tokens.</p></li><li><p><b>Where you need to do token management programmatically:</b> If you are in an organization that needs to create and delete large numbers of tokens programmatically, please continue to use User Owned Tokens. In late 2024, watch for the “Create Additional Tokens” template on the Account Owned Tokens Page. This template and associated created token will allow for the management of additional tokens.</p></li></ol>\n <figure class=\"kg-card kg-image-card\">\n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/4BGL99WFnh4oOgTFhRY5N3/26bca9fa8851729d4128c2836db62c3c/image6.png\" alt=\"\" class=\"kg-image\" width=\"996\" height=\"66\" loading=\"lazy\"/>\n </figure>\n <div class=\"flex anchor relative\">\n <h3 id=\"what-does-this-mean-for-my-existing-tokens-and-programmatic-access-moving-forward\">What does this mean for my existing tokens and programmatic access moving forward?</h3>\n <a href=\"#what-does-this-mean-for-my-existing-tokens-and-programmatic-access-moving-forward\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>We do not plan to decommission User Owned Tokens, as they still have a place in our overall access model and are handy for ensuring user-centric workflows can be implemented.</p><p>As of November 2024, we’re still working to ensure that ALL of our endpoints work with Account Owned Tokens, and we expect to deliver additional token management improvements continuously, with an expected end date of Q3 2025 to cover all endpoints.</p><p>A list of services that support, and do not support, Account Owned Tokens can be found in our <a href=\"https://developers.cloudflare.com/fundamentals/api/get-started/account-owned-tokens/\"><u>documentation.</u></a></p>\n <div class=\"flex anchor relative\">\n <h3 id=\"whats-next\">What’s next?</h3>\n <a href=\"#whats-next\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>If Account Owned Tokens could provide value to your or your organization, documentation is available <a href=\"https://developers.cloudflare.com/fundamentals/api/get-started/account-owned-tokens/\"><u>here</u></a>, and you can give them a try today from the “API Tokens” menu in your dashboard.</p>\n <div class=\"flex anchor relative\">\n <h2 id=\"zaraz-automated-actions-makes-adding-tools-to-your-website-a-breeze\">Zaraz Automated Actions makes adding tools to your website a breeze</h2>\n <a href=\"#zaraz-automated-actions-makes-adding-tools-to-your-website-a-breeze\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n \n <figure class=\"kg-card kg-image-card\">\n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/5DkxlchIDUZbQ15x0H0usK/eb656617c1c83805bda98c7dfe896bda/image2.png\" alt=\"\" class=\"kg-image\" width=\"1999\" height=\"1125\" loading=\"lazy\"/>\n </figure><p><a href=\"https://www.cloudflare.com/en-gb/application-services/products/zaraz/\"><u>Cloudflare Zaraz</u></a> is a tool designed to manage and optimize third-party tools like analytics, marketing tags, or social media scripts on websites. By loading these third-party services through Cloudflare’s network, Zaraz improves website performance, security, and privacy. It ensures that these external scripts don&#39;t slow down page loading times or expose sensitive user data, as it handles them efficiently through Cloudflare&#39;s global network, reducing latency and improving the user experience.</p><p>Automated Actions are a new product feature that allow users to easily setup page views, custom events, and e-commerce tracking without going through the tedious process of manually setting up triggers and actions.</p>\n <div class=\"flex anchor relative\">\n <h3 id=\"why-we-built-automated-actions\">Why we built Automated Actions</h3>\n <a href=\"#why-we-built-automated-actions\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>An action in Zaraz is a way to tell a third party tool that a user interaction or event has occurred when certain conditions, defined by <a href=\"https://developers.cloudflare.com/zaraz/custom-actions/create-trigger/\"><u>triggers</u></a>, are met. You create actions from within the tools page, associating them with specific tools and triggers.</p>\n <figure class=\"kg-card kg-image-card\">\n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/6a0xBA0uG55z4mhVkN0aYl/10101523491c68e4f2eec022737d15d4/image12.png\" alt=\"\" class=\"kg-image\" width=\"1124\" height=\"1366\" loading=\"lazy\"/>\n </figure><p>Setting up a tool in Zaraz has always involved a few steps: <a href=\"https://developers.cloudflare.com/zaraz/custom-actions/create-trigger/\"><u>configuring a trigger</u></a>, <a href=\"https://developers.cloudflare.com/zaraz/custom-actions/create-action/\"><u>linking it to a tool action</u></a> and finally calling <a href=\"https://developers.cloudflare.com/zaraz/web-api/track/\"><code><u>zaraz.track()</u></code></a>. This process allowed advanced configurations with complex rules, and while it was powerful, it occasionally left users confused — why isn’t calling <code>zaraz.track()</code> enough? We heard your feedback, and we’re excited to introduce <b>Zaraz Automated Actions</b>, a feature designed to make Zaraz easier to use by reducing the amount of work needed to configure a tool.</p><p>With Zaraz Automated Actions, you can now automate sending data to your third-party tools without the need to create a manual configuration. Inspired by the simplicity of <a href=\"https://developers.cloudflare.com/zaraz/web-api/ecommerce/\"><code><u>zaraz.ecommerce()</u></code></a>, we’ve extended this ease to all Zaraz events, removing the need for manual trigger and action setup. For example, calling <code>zaraz.track(‘myEvent’)</code> will send your event to the tool without the need to configure any triggers or actions.</p>\n <div class=\"flex anchor relative\">\n <h3 id=\"getting-started-with-automated-actions\">Getting started with Automated Actions</h3>\n <a href=\"#getting-started-with-automated-actions\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>When adding a new tool in Zaraz, you’ll now see an additional step where you can choose one of three Automated Actions: <b>pageviews</b>, <b>all other events</b>, or <b>ecommerce</b>. These options allow you to specify what kind of events you want to automate for that tool.</p>\n <figure class=\"kg-card kg-image-card\">\n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/1LRtb8XpSukCAgmK7uIA5Y/ab11ae9b58f474d08893b496a0eea764/image7.png\" alt=\"\" class=\"kg-image\" width=\"1536\" height=\"876\" loading=\"lazy\"/>\n </figure><ul><li><p><b>Pageviews</b>: Automatically sends data to the tool whenever someone visits a page on your site, without any manual configuration.</p></li><li><p><b>All other events</b>: Sends all custom events triggered using zaraz.track() to the selected tool, making it easy to automate tracking of user interactions.</p></li><li><p><b>Ecommerce</b>: Automatically sends all e-commerce events triggered via zaraz.ecommerce() to the tool, streamlining your sales and transaction tracking.</p></li></ul><p>These Automated Actions are also available for all your existing tools, which can be toggled on or off from the tool detail page in your Zaraz dashboard. This flexibility allows you to fine-tune which actions are automated based on your needs.</p>\n <figure class=\"kg-card kg-image-card\">\n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/xy1tIfYTfOo7p2IUeCS5d/42b26d6cfc4c05d8adc67edfc38ac34c/image10.png\" alt=\"\" class=\"kg-image\" width=\"1364\" height=\"1184\" loading=\"lazy\"/>\n </figure>\n <div class=\"flex anchor relative\">\n <h3 id=\"custom-actions-for-tools-without-automated-action-support\">Custom actions for tools without Automated Action support</h3>\n <a href=\"#custom-actions-for-tools-without-automated-action-support\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>Some tools do not support automated actions because the tool itself does not support page view, custom, or e-commerce events. For such tools you can still create your own custom actions, just like before. Custom actions allow you to configure specific events to send data to your tools based on unique triggers. The process remains the same, and you can follow the detailed steps outlined in our<a href=\"https://developers.cloudflare.com/zaraz/get-started/create-actions/\"> <u>Create Actions guide</u></a>. Remember to set up your trigger first, or choose an existing one, before configuring the action.</p><h4>Automatically enrich your payload</h4><p>When creating a custom action, it is now easier to send Event Properties using the <b>Include Event Properties field.</b> When this is toggled on, you can automatically send client-specific data with each action, such as user behavior or interaction details. For example, to send an <code>userID</code> property when sending a <code>click</code> event you can do something like this: <code>zaraz.track(‘click’, { userID: “foo” })</code>.</p><p>Additionally, you can enable the <b>Include System Properties</b> option to send system-level information, such as browser, operating system, and more. In your action settings click on “Add Field”, pick the “Include System Properties”, click on confirm and then toggle the field on. </p><p>For a full list of system properties, visit our<a href=\"https://developers.cloudflare.com/zaraz/reference/context/\"> <u>System Properties reference guide</u></a>. These options give you greater flexibility and control over the data you send with custom actions.</p><p>These two fields replace the now deprecated “Enrich Payload” dropdown field.</p>\n <figure class=\"kg-card kg-image-card\">\n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/73nCsNmeG58p6n0ylxMV8E/5cb87b516aaceb38319f9175dc7ccbf3/image5.png\" alt=\"\" class=\"kg-image\" width=\"1646\" height=\"1222\" loading=\"lazy\"/>\n </figure><p>Zaraz Automated Actions marks a significant step forward in simplifying how you manage events across your tools. By automating common actions like page views, e-commerce events, and custom tracking, you can save time and reduce the complexity of manual configurations. Whether you’re leveraging Automated Actions for speed or creating custom actions for more tailored use cases, Zaraz offers the flexibility to fit your workflow. </p><p>We’re excited to see how you use this feature. Please don’t hesitate to reach out to us on Cloudflare <a href=\"https://discord.gg/2TRr6nSxdd\"><u>Zaraz’s Discord Channel</u></a> — we’re always there fixing issues, listening to feedback, and announcing exciting product updates.</p>\n <div class=\"flex anchor relative\">\n <h2 id=\"never-miss-an-update\">Never miss an update</h2>\n <a href=\"#never-miss-an-update\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>We’ll continue to share roundup blog posts as we continue to build and innovate. Be sure to follow along on the <a href=\"https://blog.cloudflare.com/\"><u>Cloudflare Blog</u></a> for the latest news and updates.</p>"],"published_at":[0,"2024-11-14T14:00+00:00"],"updated_at":[0,"2024-11-14T14:00:02.977Z"],"feature_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/3VWKTtUa2kR7bRA7qdWQco/ff616f7de68e09dc971d463e2de47a1e/image11.png"],"tags":[1,[[0,{"id":[0,"4pES8Ke33O2ROIX5tVMqyc"],"name":[0,"Identity"],"slug":[0,"identity"]}],[0,{"id":[0,"6Mp7ouACN2rT3YjL1xaXJx"],"name":[0,"Security"],"slug":[0,"security"]}],[0,{"id":[0,"4HIPcb68qM0e26fIxyfzwQ"],"name":[0,"Developers"],"slug":[0,"developers"]}],[0,{"id":[0,"6QktrXeEFcl4e2dZUTZVGl"],"name":[0,"Product News"],"slug":[0,"product-news"]}],[0,{"id":[0,"5KsuE8WNLu5C4uyvr4XWCV"],"name":[0,"Zaraz"],"slug":[0,"zaraz"]}],[0,{"id":[0,"2OotqBxtRdi5MuC90AlyxE"],"name":[0,"Analytics"],"slug":[0,"analytics"]}],[0,{"id":[0,"49e0LtPKRtCoIvqkN8MIde"],"name":[0,"Managed Components"],"slug":[0,"managed-components"]}]]],"relatedTags":[0],"authors":[1,[[0,{"name":[0,"Joseph So"],"slug":[0,"joseph"],"bio":[0,null],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/3F1bSGwaBGKWlM5Q31Xw6t/9363eb1f1d344fa5de3c18a95cc70ce6/joseph.jpg"],"location":[0,null],"website":[0,null],"twitter":[0,null],"facebook":[0,null]}],[0,{"name":[0,"Omar Mohammad"],"slug":[0,"omar-mohammad"],"bio":[0],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/2u1Z353anm1tZlXvVFgHLf/42420bda338fb6cfcd73a70491de8fa4/omar_hydw.jpg"],"location":[0],"website":[0],"twitter":[0],"facebook":[0]}],[0,{"name":[0,"Yo'av Moshe"],"slug":[0,"yoav"],"bio":[0,null],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/26RcxowCLD305zrVRKtZES/91114909ce83a7d11280b2394a5f63b2/yoav.jpeg"],"location":[0,null],"website":[0,null],"twitter":[0,"@yoavmoshe"],"facebook":[0,null]}]]],"meta_description":[0,"Cloudflare customers can now create Account Owned Tokens, allowing more flexibility around access control for their Cloudflare services. Additionally, Zaraz Automation Actions streamlines event tracking and third-party tool integration. "],"primary_author":[0,{}],"localeList":[0,{"name":[0,"blog-english-only"],"enUS":[0,"English for Locale"],"zhCN":[0,"No Page for Locale"],"zhHansCN":[0,"No Page for Locale"],"zhTW":[0,"No Page for Locale"],"frFR":[0,"No Page for Locale"],"deDE":[0,"No Page for Locale"],"itIT":[0,"No Page for Locale"],"jaJP":[0,"No Page for Locale"],"koKR":[0,"No Page for Locale"],"ptBR":[0,"No Page for Locale"],"esLA":[0,"No Page for Locale"],"esES":[0,"No Page for Locale"],"enAU":[0,"No Page for Locale"],"enCA":[0,"No Page for Locale"],"enIN":[0,"No Page for Locale"],"enGB":[0,"No Page for Locale"],"idID":[0,"No Page for Locale"],"ruRU":[0,"No Page for Locale"],"svSE":[0,"No Page for Locale"],"viVN":[0,"No Page for Locale"],"plPL":[0,"No Page for Locale"],"arAR":[0,"No Page for Locale"],"nlNL":[0,"No Page for Locale"],"thTH":[0,"No Page for Locale"],"trTR":[0,"No Page for Locale"],"heIL":[0,"No Page for Locale"],"lvLV":[0,"No Page for Locale"],"etEE":[0,"No Page for Locale"],"ltLT":[0,"No Page for Locale"]}],"url":[0,"https://blog.cloudflare.com/account-owned-tokens-automated-actions-zaraz"],"metadata":[0,{"title":[0,"What’s new in Cloudflare: Account Owned Tokens and Zaraz Automated Actions"],"description":[0,"Cloudflare customers can now create Account Owned Tokens, allowing more flexibility around access control for their Cloudflare services. Additionally, Zaraz Automation Actions streamlines event tracking and third-party tool integration."],"imgPreview":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/1twrUnGJjrT3iDakOgSc4T/ed981a6ce2dfe1295a289bdda1307a15/What_s_new_in_Cloudflare-_Account_Owned_Tokens_and_Zaraz_Automated_Actions-OG.png"]}]}],[0,{"id":[0,"3mOPXbiTgeQHBChx4vUuMs"],"title":[0,"A look at the latest post-quantum signature standardization candidates"],"slug":[0,"another-look-at-pq-signatures"],"excerpt":[0,"NIST has standardized four post-quantum signature schemes so far, and they’re not done yet: there are fourteen new candidates in the running for standardization. In this blog post we take measure of them and discover why we ended up with so many PQ signatures."],"featured":[0,false],"html":[0,"<p>On October 24, 2024, the National Institute of Standards and Technology (NIST) <a href=\"https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/khAfIZPktRE/m/bBZWmET-AAAJ\"><u>announced</u></a> that they’re advancing fourteen post-quantum signature schemes to the second round of the “<a href=\"https://csrc.nist.gov/projects/pqc-dig-sig\"><u>signatures on ramp</u></a>” competition. “Post-quantum” means that these algorithms are designed to resist <a href=\"https://blog.cloudflare.com/the-quantum-menace/\"><u>the attack of quantum computers</u></a>. NIST already standardized four post-quantum signature schemes (<a href=\"https://blog.cloudflare.com/nists-first-post-quantum-standards/\"><u>ML-DSA, SLH-DSA</u></a>, <a href=\"https://csrc.nist.gov/News/2020/stateful-hash-based-signature-schemes-sp-800-208\"><u>XMSS, and LHS</u></a>) and they are drafting a standard for a fifth (<a href=\"https://falcon-sign.info/\"><u>Falcon</u></a>). Why do we need even more, you might ask? We’ll get to that.</p><p>A regular reader of the blog will know that this is not the first time we’ve taken measure of post-quantum signatures. In <a href=\"https://blog.cloudflare.com/sizing-up-post-quantum-signatures/\"><u>2021</u></a> we took a first hard look, and reported on the performance impact we expect from large-scale measurements. Since then, dozens of new post-quantum algorithms have been proposed. Many of them have been submitted to this new NIST competition. We discussed some of the more promising ones in our <a href=\"https://blog.cloudflare.com/pq-2024/\"><u>early 2024 blog post</u></a>.</p><p>In this blog post, we will go over the fourteen schemes advanced to the second round of the on ramp and discuss their feasibility for use in TLS — the protocol that secures browsing the Internet. The defining feature of practically all of them, is that they require much more bytes on the wire. Back in 2021 we shared <a href=\"https://blog.cloudflare.com/sizing-up-post-quantum-signatures/\"><u>experimental results</u></a> on the impact of these extra bytes. Today, we will share some surprising statistics on how TLS is used in practice. One is that today already almost half the data sent over more than half the QUIC connections are just for the certificates.</p><p>For a broader context and introduction to the post-quantum migration, check out our <a href=\"https://blog.cloudflare.com/pq-2024\"><u>early 2024 blog post</u></a>. One take-away to mention here: there will be two migrations for TLS. First, we urgently need to migrate key agreement to post-quantum cryptography to protect against <a href=\"https://en.wikipedia.org/wiki/Harvest_now,_decrypt_later\"><u>attackers that store encrypted communication today</u></a> in order to decrypt it in the future when a quantum computer is available. The industry is making good progress here: <a href=\"https://radar.cloudflare.com/adoption-and-usage#post-quantum-encryption-adoption\"><u>18% of human requests</u></a> to websites using Cloudflare are <a href=\"https://blog.cloudflare.com/post-quantum-for-all/\"><u>secured</u></a> using post-quantum key agreement. The second migration, to post-quantum signatures (certificates), is not as urgent: we will need to have this sorted by the time the quantum computer arrives. However, it will be a bigger challenge.</p>\n <div class=\"flex anchor relative\">\n <h2 id=\"the-signatures-in-tls\">The signatures in TLS</h2>\n <a href=\"#the-signatures-in-tls\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>Before we have a look at the long list of post-quantum signature algorithms and their performance characteristics, let’s go through the signatures involved when browsing the Internet and their particular constraints.</p>\n <figure class=\"kg-card kg-image-card\">\n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/415VcZzABkhZjT60GRkQZM/f30ae24bd14e86534efd3e74d15eb5b5/image3.png\" alt=\"\" class=\"kg-image\" width=\"1164\" height=\"1268\" loading=\"lazy\"/>\n </figure><p>When you visit a website, the browser establishes a TLS connection with the server for that website. The connection starts with a cryptographic handshake. During this handshake, to authenticate the connection, the server signs the transcript so far, and presents the browser with a TLS <i>leaf</i> certificate to prove that it’s allowed to serve the website. This <i>leaf </i>certificate is signed by a certification authority (CA). Typically, it’s not signed by the CA’s <i>root</i> certificate, but by an <i>intermediate</i> CA certificate, which in turn is signed by the root CA, or another intermediate. That’s not all: a leaf certificate has to include at least two <i>signed certificate timestamps</i> (SCTs). These SCTs are signatures created by <a href=\"https://blog.cloudflare.com/introducing-certificate-transparency-and-nimbus/\"><u>certificate transparency (CT) logs</u></a> to attest they’ve been publicly logged. <a href=\"https://certificate.transparency.dev/howctworks/\"><u>Certificate Transparency</u></a> is what enables you to look up a certificate on websites such <a href=\"http://crt.sh\"><u>crt.sh</u></a> and <a href=\"https://www.merklemap.com/\"><u>merklemap</u></a>. In the future three or more SCTs might be required. Finally, servers may also send an <a href=\"https://blog.cloudflare.com/high-reliability-ocsp-stapling/\"><u>OCSP staple</u></a> to demonstrate a certificate hasn’t been revoked.</p><p>Thus, we’re looking at a minimum of five signatures (not counting the OCSP staple) and two public keys transmitted across the network to establish a new TLS connection.</p>\n <div class=\"flex anchor relative\">\n <h3 id=\"tailoring\">Tailoring</h3>\n <a href=\"#tailoring\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>Only the handshake transcript signature is created <i>online</i>; the other signatures are “offline”. That is, they are created ahead of time. For these offline signatures, fast verification is much more important than fast signing. On the other hand, for the handshake signature, we want to minimize the sum of signing and verification time.</p><p>Only the public keys of the leaf and intermediate certificates are transmitted on the wire during the handshake, and for those we want to minimize the combined size of the signature and the public key. For the other signatures, the public key is not transmitted during the handshake, and thus a scheme with larger public keys would be tolerable, and preferable if it trades larger public keys for smaller signatures.</p>\n <div class=\"flex anchor relative\">\n <h2 id=\"the-algorithms\">The algorithms</h2>\n <a href=\"#the-algorithms\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>Now that we’re up to speed, let’s have a look at the candidates that progressed (marked by 🤔 below), compared to the classical algorithms vulnerable to quantum attack (marked by ❌), and the post-quantum algorithms that are already standardized (✅) or soon will be (📝). Each submission proposes several variants. We list the most relevant variants to TLS from each submission. To explore all variants, check out <a href=\"https://research.cloudflare.com/outreach/academic-programs/interns/thom-wiggers/\"><u>Thom Wigger</u></a>’s <a href=\"https://pqshield.github.io/nist-sigs-zoo/\"><u>signatures zoo</u></a>.</p><style type=\"text/css\">\n.tg {border-collapse:collapse;border-spacing:0;margin:0px auto;}\n.tg td{border-color:black;border-style:solid;border-width:1px;font-family:Arial, sans-serif;font-size:14px;\n overflow:hidden;padding:10px 5px;word-break:normal;}\n.tg th{border-color:black;border-style:solid;border-width:1px;font-family:Arial, sans-serif;font-size:14px;\n font-weight:normal;overflow:hidden;padding:10px 5px;word-break:normal;}\n.tg .tg-d0am{background-color:#C0FF00;border-color:inherit;text-align:left;vertical-align:top}\n.tg .tg-mrls{background-color:#FFE400;border-color:inherit;text-align:left;vertical-align:top}\n.tg .tg-jxgv{background-color:#FFF;border-color:inherit;text-align:left;vertical-align:top}\n.tg .tg-0pky{border-color:inherit;text-align:left;vertical-align:top}\n.tg .tg-ezr1{background-color:#0F0;border-color:inherit;text-align:left;vertical-align:top}\n.tg .tg-5ece{border-color:inherit;font-size:small;text-align:left;vertical-align:top}\n.tg .tg-hqhz{background-color:#FF0;border-color:inherit;text-align:left;vertical-align:top}\n.tg .tg-boa2{background-color:#F90;border-color:inherit;color:#FFF;text-align:left;vertical-align:top}\n.tg .tg-4zxv{background-color:#F00;border-color:inherit;color:#FFF;text-align:left;vertical-align:top}\n@media screen and (max-width: 767px) {.tg {width: auto !important;}.tg col {width: auto !important;}.tg-wrap {overflow-x: auto;-webkit-overflow-scrolling: touch;margin: auto 0px;}}</style>\n<div class=\"tg-wrap\"><table class=\"tg\"><thead>\n <tr>\n <th class=\"tg-0pky\"></th>\n <th class=\"tg-0pky\"></th>\n <th class=\"tg-0pky\"></th>\n <th class=\"tg-0pky\" colspan=\"2\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">Sizes (bytes)</span></th>\n <th class=\"tg-0pky\" colspan=\"2\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">CPU time (lower is better)</span></th>\n </tr></thead>\n<tbody>\n <tr>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">Family</span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">Name variant</span></td>\n <td class=\"tg-0pky\"></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">Public key</span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">Signature</span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">Signing</span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">Verification</span></td>\n </tr>\n <tr>\n <td class=\"tg-jxgv\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">Elliptic curves</span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">Ed25519</span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">❌</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">32</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">64</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">0.15</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">1.3</span></td>\n </tr>\n <tr>\n <td class=\"tg-jxgv\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">Factoring</span></td>\n <td class=\"tg-5ece\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">RSA<small> 2048</small></span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">❌</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">272</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">256</span></td>\n <td class=\"tg-hqhz\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">80</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">0.4</span></td>\n </tr>\n <tr>\n <td class=\"tg-jxgv\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">Lattices</span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">ML-DSA <small>44</small></span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">✅</span></td>\n <td class=\"tg-mrls\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">1,312</span></td>\n <td class=\"tg-boa2\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#FFF;background-color:transparent\">2,420</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">1 (baseline)</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">1 (baseline)</span></td>\n </tr>\n <tr>\n <td class=\"tg-jxgv\" rowspan=\"3\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">Symmetric</span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">SLH-DSA <small>128s</small></span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">✅</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">32</span></td>\n <td class=\"tg-4zxv\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#FFF;background-color:transparent\">7,856</span></td>\n <td class=\"tg-4zxv\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#FFF;background-color:transparent\">14,000</span></td>\n <td class=\"tg-hqhz\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">40</span></td>\n </tr>\n <tr>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">SLH-DSA <small>128f</small></span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">✅</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">32</span></td>\n <td class=\"tg-4zxv\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#FFF;background-color:transparent\">17,088</span></td>\n <td class=\"tg-boa2\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#FFF;background-color:transparent\">720</span></td>\n <td class=\"tg-boa2\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#FFF;background-color:transparent\">110</span></td>\n </tr>\n <tr>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">LMS <small>M4_H20_W8</small></span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">✅</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">48</span></td>\n <td class=\"tg-mrls\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">1,112</span></td>\n <td class=\"tg-d0am\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">2.9</span> ⚠️</td>\n <td class=\"tg-d0am\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">8.4</span></td>\n </tr>\n <tr>\n <td class=\"tg-jxgv\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">Lattices</span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">Falcon <small>512</small></span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">📝</span></td>\n <td class=\"tg-hqhz\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">897</span></td>\n <td class=\"tg-hqhz\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">666</span></td>\n <td class=\"tg-d0am\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">3 ⚠️</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">0.7</span></td>\n </tr>\n <tr>\n <td class=\"tg-jxgv\" rowspan=\"2\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">Codebased</span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">CROSS <small>R-SDP(G)1 small</small></span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">🤔</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">38</span></td>\n <td class=\"tg-4zxv\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#FFF;background-color:transparent\">7,956</span></td>\n <td class=\"tg-hqhz\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">20</span></td>\n <td class=\"tg-hqhz\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">35</span></td>\n </tr>\n <tr>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">LESS <small>1s</small></span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">🤔</span></td>\n <td class=\"tg-4zxv\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#FFF;background-color:transparent\">97,484</span></td>\n <td class=\"tg-4zxv\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#FFF;background-color:transparent\">5,120</span></td>\n <td class=\"tg-boa2\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#FFF;background-color:transparent\">620</span></td>\n <td class=\"tg-4zxv\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#FFF;background-color:transparent\">1800</span></td>\n </tr>\n <tr>\n <td class=\"tg-jxgv\" rowspan=\"5\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">MPC in the head</span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">Mirath <small>Mirith Ia fast</small></span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">🤔</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">129</span></td>\n <td class=\"tg-4zxv\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#FFF;background-color:transparent\">7,877</span></td>\n <td class=\"tg-hqhz\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">25</span></td>\n <td class=\"tg-hqhz\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">60</span></td>\n </tr>\n <tr>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">MQOM <small>L1-gf251-fast</small></span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">🤔</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">59</span></td>\n <td class=\"tg-4zxv\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#FFF;background-color:transparent\">7,850</span></td>\n <td class=\"tg-hqhz\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">35</span></td>\n <td class=\"tg-boa2\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#FFF;background-color:transparent\">85</span></td>\n </tr>\n <tr>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">PERK <small>I-fast5</small></span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">🤔</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">240</span></td>\n <td class=\"tg-4zxv\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#FFF;background-color:transparent\">8,030</span></td>\n <td class=\"tg-hqhz\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">20</span></td>\n <td class=\"tg-hqhz\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">40</span></td>\n </tr>\n <tr>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">RYDE <small>128F</small></span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">🤔</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">86</span></td>\n <td class=\"tg-4zxv\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#FFF;background-color:transparent\">7,446</span></td>\n <td class=\"tg-hqhz\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">15</span></td>\n <td class=\"tg-hqhz\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">40</span></td>\n </tr>\n <tr>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">SDitH <small>gf251-L1-hyp</small></span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">🤔</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">132</span></td>\n <td class=\"tg-4zxv\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#FFF;background-color:transparent\">8,496</span></td>\n <td class=\"tg-hqhz\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">30</span></td>\n <td class=\"tg-boa2\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#FFF;background-color:transparent\">80</span></td>\n </tr>\n <tr>\n <td class=\"tg-jxgv\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">VOLE in the head</span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">FAEST <small>EM-128f</small></span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">🤔</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">32</span></td>\n <td class=\"tg-4zxv\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#FFF;background-color:transparent\">5,696</span></td>\n <td class=\"tg-d0am\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">6</span></td>\n <td class=\"tg-d0am\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">18</span></td>\n </tr>\n <tr>\n <td class=\"tg-jxgv\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">Lattices</span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">HAWK <small>512</small></span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">🤔</span></td>\n <td class=\"tg-hqhz\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">1,024</span></td>\n <td class=\"tg-hqhz\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">555</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">0.25</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">1.2</span></td>\n </tr>\n <tr>\n <td class=\"tg-jxgv\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">Isogeny</span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">SQISign <small>I</small></span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">🤔</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">64</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">177</span></td>\n <td class=\"tg-4zxv\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#FFF;background-color:transparent\">17,000</span></td>\n <td class=\"tg-4zxv\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#FFF;background-color:transparent\">900</span></td>\n </tr>\n <tr>\n <td class=\"tg-jxgv\" rowspan=\"8\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">Multivariate</span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">MAYO <small>one</small></span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">🤔</span></td>\n <td class=\"tg-hqhz\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">1,168</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">321</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">1.4</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">1.4</span></td>\n </tr>\n <tr>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">MAYO <small>two</small></span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">🤔</span></td>\n <td class=\"tg-4zxv\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#FFF;background-color:transparent\">5,488</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">180</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">1.7</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">0.8</span></td>\n </tr>\n <tr>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">QR-UOV <small>I-(31,165,60,3)</small></span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">🤔</span></td>\n <td class=\"tg-4zxv\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#FFF;background-color:transparent\">23,657</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">157</span></td>\n <td class=\"tg-hqhz\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">75</span></td>\n <td class=\"tg-boa2\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#FFF;background-color:transparent\">125</span></td>\n </tr>\n <tr>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">SNOVA <small>(24,5,4)</small></span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">🤔</span></td>\n <td class=\"tg-hqhz\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">1,016</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">248</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">0.9</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">1.4</span></td>\n </tr>\n <tr>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">SNOVA <small>(25,8,3)</small></span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">🤔</span></td>\n <td class=\"tg-boa2\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#FFF;background-color:transparent\">2,320</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">165</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">0.9</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">1.8</span></td>\n </tr>\n <tr>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">SNOVA <small>(37,17,2)</small></span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">🤔</span></td>\n <td class=\"tg-4zxv\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#FFF;background-color:transparent\">9,842</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">106</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">1</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">1.2</span></td>\n </tr>\n <tr>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">UOV <small>Is-pkc</small></span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">🤔</span></td>\n <td class=\"tg-4zxv\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#FFF;background-color:transparent\">66,576</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">96</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">0.3</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">2.3</span></td>\n </tr>\n <tr>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">UOV <small>Ip-pkc</small></span></td>\n <td class=\"tg-0pky\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">🤔</span></td>\n <td class=\"tg-4zxv\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#FFF;background-color:transparent\">43,576</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">128</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">0.3</span></td>\n <td class=\"tg-ezr1\"><span style=\"font-weight:400;font-style:normal;text-decoration:none;color:#000;background-color:transparent\">0.8</span></td>\n </tr>\n</tbody></table></div><p>Some notes about the table. It compares selected variants of the submissions progressed to the second round of the NIST PQC signature on ramp with earlier existing traditional and post-quantum schemes at the security level of AES-128. CPU times are taken from the <a href=\"https://pqshield.github.io/nist-sigs-zoo/\"><u>signatures zoo</u></a>, which collected them from the submission documents and some later advances. CPU performance varies significantly by platform and implementation, and should only be taken as a rough indication. We are early in the competition, and the on-ramp schemes will evolve: some will improve drastically (both in compute and size), whereas others will regress to counter new attacks. Check out <a href=\"https://pqshield.github.io/nist-sigs-zoo/\"><u>the zoo</u></a> for the latest numbers. We marked Falcon signing with a <i>⚠️</i>, as Falcon signing is hard to implement in a fast and timing side-channel secure manner. LMS signing has a ⚠️, as secure LMS signing requires keeping a state and the listed signing time assumes a 32MB cache. This will be discussed later on.</p><p>These are a lot of algorithms, and we didn’t even list all variants. One thing is clear: none of them perform as well as classical elliptic curve signatures across the board. Let’s start with NIST’s 2022 picks.</p>\n <div class=\"flex anchor relative\">\n <h3 id=\"ml-dsa-slh-dsa-and-falcon\">ML-DSA, SLH-DSA, and Falcon</h3>\n <a href=\"#ml-dsa-slh-dsa-and-falcon\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>The most viable general purpose post-quantum signature scheme standardized today is the lattice-based <b>ML-DSA</b> (<a href=\"https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.204.pdf\"><u>FIPS 204</u></a>), which started its life as <a href=\"https://pq-crystals.org/dilithium/index.shtml\"><u>Dilithium</u></a>. It’s light on the CPU and reasonably straightforward to implement. The big downside is that its signatures and public keys are large: 2.4kB and 1.3kB respectively. Here and for the balance of the blog post, we will only consider the variants at the AES-128 security level unless stated otherwise. Adding ML-DSA, adds 14.7kB to the TLS handshake (two 1312-byte public keys plus five 2420-byte signatures).</p><p><b>SLH-DSA</b> (<a href=\"https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.205.pdf\"><u>FIPS 205</u></a>, née <a href=\"https://sphincs.org/\"><u>SPHINCS</u><u><sup>+</sup></u></a>) looks strictly worse, adding 39kB and significant computational overhead for both signing and verification. The advantage of SLH-DSA, being solely based on hashes, is that its security is much better understood than ML-DSA. The lowest security level of SLH-DSA is generally more trusted than the highest security levels of many other schemes.</p><p><a href=\"https://falcon-sign.info/\"><b><u>Falcon</u></b></a> (to be renamed <a href=\"https://www.nist.gov/news-events/news/2024/08/nist-releases-first-3-finalized-post-quantum-encryption-standards\"><u>FN-DSA</u></a>) seems much better than SLH-DSA and ML-DSA if you look only at the numbers in the table. There is a catch though. For fast signing, Falcon requires fast floating-point arithmetic, which turns out to be <a href=\"https://blog.cloudflare.com/nist-post-quantum-surprise/#digital-signatures\"><u>difficult to implement securely</u></a>. Signing can be performed securely with emulated floating-point arithmetic, but that makes it roughly twenty times slower. This makes Falcon ill-suited for online signatures. Furthermore, the signing procedure of Falcon is complicated to implement. On the other hand, Falcon verification is simple and doesn’t require floating-point arithmetic.</p><p>Leaning into Falcon’s strength, by using ML-DSA for the handshake signature, and Falcon for the rest, we’re only adding 7.3kB (at security level of AES-128).</p><p>There is one more difficulty with Falcon worth mentioning: it’s missing a middle security level. That means that if Falcon-512 (which we considered so far) turns out to be weaker than expected, then the next one up is Falcon-1024, which has double signature and public key size. That amounts to adding about 11kB.</p>\n <div class=\"flex anchor relative\">\n <h3 id=\"stateful-hash-based-signatures\">Stateful hash-based signatures</h3>\n <a href=\"#stateful-hash-based-signatures\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>The very first post-quantum signature algorithms standardized are the stateful hash-based <a href=\"https://datatracker.ietf.org/doc/html/rfc8391\"><u>XMSS</u><u><sup>(MT)</sup></u></a> and <a href=\"https://datatracker.ietf.org/doc/html/rfc8554#page-45\"><u>LMS/HSS</u></a>. These are hash-based signatures, similar to SLH-DSA, and so we have a lot of trust in their security. They come with a big drawback: when creating a keypair you prepare a finite number of <i>signature slots</i>. For the variant listed in the table, there are about one million slots. Each slot can only be used once. If by accident a slot is used twice, then anyone can (<a href=\"https://eprint.iacr.org/2016/1042\"><u>probably</u></a>) use those two signatures to forge any new signature from that slot and break into the connection the certificate is supposed to protect. Remembering which slots have been used, is the <i>state</i> in <i>stateful</i> hash-based signature. Certificate authorities might be able to keep the state, but for general use, Adam Langley calls keeping the state a <a href=\"https://www.imperialviolet.org/2013/07/18/hashsig.html\"><u>huge foot-cannon</u></a>.</p><p>There are more quirks to keep in mind for stateful hash-based signatures. To start, during key generation, each slot needs to be prepared. Preparing each slot takes approximately the same amount of time as verifying a signature. Preparing all million takes a couple of hours on a single core. For intermediate certificates of a popular certificate authority, a million slots are not enough. Indeed, Let’s Encrypt issues more than <a href=\"https://letsencrypt.org/stats/\"><u>four million certificates per day</u></a>. Instead of increasing the number of slots directly, we can use an extra intermediate. This is what XMSS<sup>MT</sup> and HSS do internally. A final quirk of stateful hash-based signatures is that their security is bottlenecked on non-repudiation: the listed LMS instance has 192 bits of security against forgery, but only 96 bits against the signer themselves creating a single signature that verifies two different messages.</p><p>Even when stateful hash-based signatures or Falcon can be used, we are still adding a lot of bytes on the wire. From <a href=\"https://blog.cloudflare.com/sizing-up-post-quantum-signatures/\"><u>earlier experiments</u></a> we know that that will impact performance significantly. We summarize those findings later in this blog post, and share some new data. The short of it: it would be nice to have a post-quantum signature scheme that outperforms Falcon, or at least outperforms ML-DSA and is easier to deploy. This is one of the reasons NIST is running the second competition.</p><p>With that in mind, let’s have a look at the candidates.</p>\n <div class=\"flex anchor relative\">\n <h3 id=\"structured-lattice-alternatives\">Structured lattice alternatives</h3>\n <a href=\"#structured-lattice-alternatives\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>With only performance in mind, it is surprising that half of the candidates do worse than ML-DSA. There is a good reason for it: NIST is worried that we’re putting all our eggs in the structured lattices basket. SLH-DSA is an alternative to lattices today, but it doesn’t perform well enough for many applications. As such, NIST <a href=\"https://csrc.nist.gov/csrc/media/Projects/pqc-dig-sig/documents/call-for-proposals-dig-sig-sept-2022.pdf\"><u>would primarily like to standardize</u></a> another general purpose signature algorithm that is not based on structured lattices, and that outperforms SLH-DSA. We will briefly touch upon these schemes here.</p><h4>Code-based</h4><p><a href=\"https://www.cross-crypto.com/\"><u>CROSS</u></a> and <a href=\"https://www.less-project.com/#:~:text=LESS%20(Linear%20Equivalence%20Signature%20Scheme,the%20Linear%20Code%20Equivalence%20problem.\"><u>LESS</u></a> are two<b> code-based signature</b> schemes. <b>CROSS</b> is based on a variant of the traditional syndrome decoding problem. Its signatures are about as large as SLH-DSA, but its edge over SLH-DSA is the much better signing times. <b>LESS</b> is based on the novel <a href=\"https://eprint.iacr.org/2023/847\"><u>linear equivalence problem</u></a>. It only outperforms SLH-DSA on signature size, requiring larger public keys in return. For use in TLS, the high verification times of LESS are especially problematic. Given that LESS is based on a new approach, it will be interesting to see how much it can improve going forward.</p><h4>Multi-party computation in the head</h4><p>Five of the submissions (<a href=\"https://pqc-mira.org/\"><u>Mira</u></a><a href=\"https://pqc-mirith.org/\"><u>th</u></a>, <a href=\"https://mqom.org/\"><u>MQOM</u></a>, <a href=\"https://pqc-perk.org/\"><u>PERK</u></a>, <a href=\"https://pqc-ryde.org/\"><u>RYDE</u></a>, <a href=\"https://sdith.org/\"><u>SDitH</u></a>) use the <b>Multi-Party Computation in the Head</b> (MPCitH) paradigm.</p><p>It has been exciting to see the developments in this field. To explain a bit about it, let’s go back to <a href=\"https://microsoft.github.io/Picnic/\"><u>Picnic</u></a>. Picnic was an MPCitH submission to the previous NIST PQC competition. In essence, its private key is a random key <i>x</i>, and its public key is the hash <i>H(x)</i>. A signature is a zero-knowledge proof demonstrating that the signer knows <i>x</i>. So far, it’s pretty similar in shape to other signature schemes that use zero knowledge proofs. The difference is in how that proof is created. We have to talk about multi-party computation (MPC) first. MPC starts with splitting the key <i>x</i> into shares, using <a href=\"https://en.wikipedia.org/wiki/Shamir%27s_secret_sharing\"><u>Shamir secret sharing</u></a> for instance, and giving each party one share. No single party knows the value of <i>x</i> itself, but they can recover it by recombining. The insight of MPC is that these parties (with some communication) can perform arbitrary computation on the data they shared. In particular, they can compute a secret share of <i>H(x)</i>. Now, we can use that to make a zero-knowledge proof as follows. The signer simulates all parties in the multi-party protocol to compute and recombine <i>H(x)</i>. The signer then reveals part of the intermediate values of the computation using <a href=\"https://en.wikipedia.org/wiki/Fiat%E2%80%93Shamir_heuristic\"><u>Fiat–Shamir</u></a>: enough so that none of the parties could have cheated on any of the steps, but not enough that it allows the verifier to figure out <i>x</i> themselves.</p><p>For <i>H</i>, Picnic uses <a href=\"https://lowmc.github.io/\"><u>LowMC</u></a>, a block cipher for which it’s easy to do the multi-party computation. The initial submission of Picnic performed poorly compared to SLH-DSA with 32kB signatures. For the second round, Picnic was improved considerably, boasting 12kB signatures. SLH-DSA won out with smaller signatures, and more conservative security assumptions: Picnic relies on LowMC which didn’t receive as much study as the hashes on which SLH-DSA is based.</p><p>Back to the MPCitH candidates that progressed. All of them have variants (listed in the table) with similar or better signature sizes as SLH-DSA, while outperforming SLH-DSA considerably in signing time. There are variants with even smaller signatures, but their verification performance is significantly higher. The difference between the MPCitH candidates is the underlying <a href=\"https://en.wikipedia.org/wiki/Trapdoor_function\"><u>trapdoor</u></a> they use. In Picnic the trapdoor was LowMC. For both RYDE and SDiTH, the trapdoors used are based on variants of <a href=\"https://en.wikipedia.org/wiki/Decoding_methods#Syndrome_decoding\"><u>syndrome decoding</u></a>, and could be classified as code-based cryptography.</p><p>Over the years, MPCitH schemes have seen remarkable improvements in performance, and we don’t seem to have reached the end of it yet. There is still some way to go before these schemes would be competitive in TLS: signature size needs to be reduced without sacrificing the currently borderline acceptable verification performance. On top of that, not all underlying trapdoors of the various schemes have seen enough scrutiny.</p><h4>FAEST</h4><p><a href=\"https://faest.info/\"><u>FAEST</u></a> is a peek into the future. It’s similar to the MPCitH candidates in that its security reduces to an underlying trapdoor. It is quite different from those in that FAEST’s underlying trapdoor is AES. That means that, given the security analysis of FAEST is correct, it’s on the same footing as SLH-DSA. Despite the conservative trapdoor, FAEST beats the MPCitH candidates in performance. It also beats SLH-DSA on all metrics.</p><p>At the AES-128 security level, FAEST’s signatures are larger than ML-DSA. For those that want to hedge against improvements in lattice attacks, and would only consider higher security levels of ML-DSA, FAEST becomes an attractive alternative. ML-DSA-65 has a combined public key and signature size of 5.2kB, which is similar to FAEST EM-128f. ML-DSA-65 still has a slight edge in performance.</p><p>FAEST is based on the 2023 <a href=\"https://eprint.iacr.org/2023/996.pdf\"><u>VOLE in the Head</u></a> paradigm. These are new ideas, and it seems likely their full potential has not been realized yet. It is likely that FAEST will see improvements.</p><p>The VOLE in the Head techniques can and probably will be adopted by some of the MPCitH submissions. It will be interesting to see how far VOLEitH can be pushed when applied to less conservative trapdoors. Surpassing ML-DSA seems in reach, but Falcon? We will see.</p><p>Now, let’s move on to the submissions that surpass ML-DSA today.</p>\n <div class=\"flex anchor relative\">\n <h3 id=\"hawk\">HAWK</h3>\n <a href=\"#hawk\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p><a href=\"https://hawk-sign.info/\"><u>HAWK</u></a> is similar to Falcon, but improves upon it in a few key ways. Most importantly, it doesn’t rely on floating point arithmetic. Furthermore, its signing procedure is simpler and much faster. This makes HAWK suitable for online signatures. Using HAWK adds 4.8kB. Apart from size and speed, it’s beneficial to rely on only a single scheme: using multiple schemes increases the attack surface for algorithmic weaknesses and implementation mistakes.</p><p>Similar to Falcon, HAWK is missing a middle security level. Using HAWK-1024 doubles sizes (9.6kB).</p><p>There is one downside to HAWK over Falcon: HAWK relies on a new security assumption, the <a href=\"https://eprint.iacr.org/2021/1332.pdf\"><u>lattice isomorphism problem</u></a>.</p>\n <div class=\"flex anchor relative\">\n <h3 id=\"sqisign\">SQISign</h3>\n <a href=\"#sqisign\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p><a href=\"https://sqisign.org/\"><u>SQISign</u></a> is based on <a href=\"https://blog.cloudflare.com/sidh-go/\"><u>isogenies</u></a>. Famously, SIKE, another isogeny-based scheme in the previous competition, got <a href=\"https://eprint.iacr.org/2022/975.pdf\"><u>broken badly</u></a> late into the competition. SQISign is based on a different problem, though. SQISign is remarkable for having very small signatures and public keys: it even beats RSA-2048. The glaring downside is that it is computationally very expensive to compute and verify a signature. Isogeny-based signature schemes is a very active area of research with many advances over the years.</p><p>It seems unlikely that any future SQISign variant will sign fast enough for the TLS handshake signature. Furthermore, SQISign signing seems to be hard to implement in a timing side-channel secure manner. What about the other signatures of TLS? The bottleneck is verification time. It would be acceptable for SQISign to have larger signatures, if that allows it to have faster verification time.</p>\n <div class=\"flex anchor relative\">\n <h3 id=\"uov\">UOV</h3>\n <a href=\"#uov\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p><a href=\"https://www.uovsig.org/\"><u>UOV</u></a> (unbalanced oil and vinegar) is an old multivariate scheme with large public keys (67kB), but small signatures (96 bytes). Furthermore, it has excellent signing and verification performance. These interesting size tradeoffs make it quite suited for use cases where the public key is known in advance.</p><p>If we use UOV in TLS for the SCTs and root CA, whose public keys are not transmitted when setting up the connection, together with ML-DSA for the others, we’re looking at 7.2kB. That’s a clear improvement over using ML-DSA everywhere, and a tad better than combining ML-DSA with Falcon.</p><p>When combining UOV with HAWK instead of ML-DSA, we’re looking at adding only 3.4kB. That’s better again, but only a marginal improvement over using HAWK everywhere (4.8kB). The relative advantage of UOV improves if the certificate transparency ecosystem moves towards requiring more SCTs.</p><p>For SCTs, the size of UOV public keys seems acceptable, as there are not that many certificate transparency logs at the moment. Shipping a UOV public key for hundreds of root CAs is more painful, but within reason. Even with <a href=\"https://blog.cloudflare.com/pq-2024/#leaving-out-intermediate-certificates\"><u>intermediate suppression</u></a>, using UOV in each of the thousands of intermediate certificates does not make sense.</p>\n <div class=\"flex anchor relative\">\n <h3 id=\"structured-multivariate\">Structured multivariate</h3>\n <a href=\"#structured-multivariate\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>Since the original UOV, over the decades, many attempts have been made to add additional structure UOV, to get a better balance between the size of the signature and public key. Unfortunately many of these <i>structured multivariate</i> schemes, which include GeMMS and Rainbow, have been broken.</p><p>Let’s have a look at the multivariate candidates. The most interesting variant of <b>QR-UOV</b> for TLS has 24kB public keys and 157 byte signatures. The current verification times are unacceptably high, but there seems to be plenty of room for an improved implementation. There is also a variant with a 12kB public key, but its verification time needs to come down even further. In any case, the combined size QR-UOV’s public key and signatures remain large enough that it’s not a competitor of ML-DSA or Falcon. Instead, QR-UOV competes with UOV, where UOV’s public keys are unwieldy. Although QR-UOV hasn’t seen a direct attack yet, a similar scheme has recently been <a href=\"https://link.springer.com/chapter/10.1007/978-3-031-62746-0_9\"><u>weakened</u></a> and another <a href=\"https://link.springer.com/chapter/10.1007/978-3-030-44223-1_18\"><u>broken</u></a>.</p><p>Finally, we get to<b> </b><a href=\"https://snova.pqclab.org/\"><b><u>SNOVA</u></b></a> and <a href=\"https://pqmayo.org/\"><b><u>MAYO</u></b></a>. Although they’re based on a different technique, they have a lot of properties in common. To start, they have the useful property that they allow for a granular tradeoff between public key and signature size. This allows us to use a different variant optimized for whether we’re transmitting the public in the connection or not. Using MAYO<sub>one</sub> for the leaf and intermediate, and MAYO<sub>two</sub> for the others, adds 3.5kB. Similarly with SNOVA, we add 2.8kB. On top of that, both schemes have excellent signing and verification performance.</p><p>The elephant in the room is the security. During the end of the first round, a new <a href=\"https://www.jstage.jst.go.jp/article/jsiaml/15/0/15_53/_article\"><u>generic attack</u></a> on underdefined multivariate systems prompted the MAYO team to <a href=\"https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/jEKfDYUgdec/m/0UP_GNKSAwAJ\"><u>tweak their parameters</u></a> slightly. SNOVA has been hit a bit harder by three attacks (<a href=\"https://dl.acm.org/doi/10.1145/3659467.3659900\"><u>1</u></a>, <a href=\"https://eprint.iacr.org/2024/1297\"><u>2</u></a>, <a href=\"https://eprint.iacr.org/2024/1770.pdf\"><u>3</u></a>), but so far it seems that SNOVA’s parameters can be adjusted to compensate.</p><p>Ok, we had a look at all the candidates. What did we learn? There are some very promising algorithms that will reduce the number of bytes required on the wire compared to ML-DSA and Falcon. None of the practical ones will prevent us from adding any extra bytes to TLS. So, given that we must add some bytes: how many extra bytes are too many?</p>\n <div class=\"flex anchor relative\">\n <h2 id=\"how-many-added-bytes-are-too-many-for-tls\">How many added bytes are too many for TLS?</h2>\n <a href=\"#how-many-added-bytes-are-too-many-for-tls\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>On average, around 15 million TLS connections are established with Cloudflare per second. Upgrading each to ML-DSA, would take 1.8Tbps, which is 0.6% of our current total network capacity. No problem so far. The question is how these extra bytes affect performance.</p><p>Back in 2021, we <a href=\"https://blog.cloudflare.com/sizing-up-post-quantum-signatures/\"><u>ran a large-scale experiment</u></a> to measure the impact of big post-quantum certificate chains on connections to Cloudflare’s network over the open Internet. There were two important results. First, we saw a steep increase in the rate of client and middlebox failures when we added more than 10kB to existing certificate chains. Secondly, when adding less than 9kB, the slowdown in TLS handshake time would be approximately 15%. We felt the latter is workable, but far from ideal: such a slowdown is noticeable and people might hold off deploying post-quantum certificates before it’s too late.</p><p>Chrome is more cautious and set 10% as their target for maximum TLS handshake time regression. They <a href=\"https://dadrian.io/blog/posts/pqc-signatures-2024/#fnref:3\"><u>report</u></a> that deploying post-quantum key agreement has already incurred a 4% slowdown in TLS handshake time, for the extra 1.1kB from server-to-client and 1.2kB from client-to-server. That slowdown is proportionally larger than the 15% we found for 9kB, but that could be explained by slower upload speeds than download speeds.</p><p>There has been pushback against the focus on TLS handshake times. One argument is that session resumption alleviates the need for sending the certificates again. A second argument is that the data required to visit a typical website dwarfs the additional bytes for post-quantum certificates. One example is this <a href=\"https://www.amazon.science/publications/the-impact-of-data-heavy-post-quantum-tls-1-3-on-the-time-to-last-byte-of-real-world-connections\"><u>2024 publication</u></a>, where Amazon researchers have simulated the impact of large post-quantum certificates on data-heavy TLS connections. They argue that typical connections transfer multiple requests and hundreds of kilobytes, and for those the TLS handshake slowdown disappears in the margin.</p><p>Are session resumption and hundreds of kilobytes over a connection typical though? We’d like to share what we see. We focus on QUIC connections, which are likely initiated by browsers or browser-like clients. Of all QUIC connections with Cloudflare that carry at least one HTTP request, 37% are <a href=\"https://blog.cloudflare.com/even-faster-connection-establishment-with-quic-0-rtt-resumption/\"><u>resumptions</u></a>, meaning that key material from a previous TLS connection is reused, avoiding the need to transmit certificates. The median number of bytes transferred from server-to-client over a resumed QUIC connection is 4.4kB, while the average is 395kB. For non-resumptions the median is 7.8kB and average is 551kB. This vast difference between median and average indicates that a small fraction of data-heavy connections skew the average. In fact, only 15.8% of all QUIC connections transfer more than 100kB.</p><p>The median certificate chain today (with compression) is <a href=\"https://datatracker.ietf.org/doc/html/draft-ietf-tls-cert-abridge-02#section-4\"><u>3.2kB</u></a>. That means that almost 40% of all data transferred from server to client on more than half of the non-resumed QUIC connections are just for the certificates, and this only gets worse with post-quantum algorithms. For the majority of QUIC connections, using ML-DSA as a drop-in replacement for classical signatures would more than double the number of transmitted bytes over the lifetime of the connection.</p><p>It sounds quite bad if the vast majority of data transferred for a typical connection is just for the post-quantum certificates. It’s still only a proxy for what is actually important: the effect on metrics relevant to the end-user, such as the browsing experience (e.g. <a href=\"https://web.dev/articles/optimize-lcp\"><u>largest contentful paint</u></a>) and the amount of data those certificates take from a user’s monthly data cap. We will continue to investigate and get a better understanding of the impact.</p>\n <div class=\"flex anchor relative\">\n <h2 id=\"zooming-out\">Zooming out</h2>\n <a href=\"#zooming-out\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>That was a lot — let’s step back.</p><p>It’s great to see how much better the post-quantum signature algorithms are today in almost every family than they were in <a href=\"https://blog.cloudflare.com/sizing-up-post-quantum-signatures/\"><u>2021</u></a>. The improvements haven’t slowed down either. Many of the algorithms that do not improve over ML-DSA for TLS today could still do so in the third round. Looking back, we are also cautioned: several algorithms considered in 2021 have since been broken.</p><p>From an implementation and performance perspective for TLS today, HAWK, SNOVA, and MAYO are all clear improvements over ML-DSA and Falcon. They are also very new, and presently we cannot depend on them without a <a href=\"https://blog.cloudflare.com/pq-2024/#way-forward\"><u>plan B</u></a>. UOV has been around a lot longer. Due to its large public key, it will not work on its own, but be a very useful complement to another general purpose signature scheme.</p><p>Even with the best performers out of the competition, the way we see TLS connections used today, suggest that drop-in post-quantum certificates will have a big impact on at least half of them.</p><p>In the meantime, we can also make plan B our plan A: there are several ways in which we can reduce the number of signatures used in TLS. We can leave out intermediate certificates (<a href=\"https://datatracker.ietf.org/doc/html/draft-kampanakis-tls-scas-latest\"><u>1</u></a>, <a href=\"https://datatracker.ietf.org/doc/draft-ietf-tls-cert-abridge/\"><u>2</u></a>, <a href=\"https://datatracker.ietf.org/doc/html/draft-davidben-tls-trust-expr-04#name-intermediate-elision\"><u>3</u></a>). Another is to use a KEM <a href=\"https://kemtls.org/\"><u>instead of a signature</u></a> for handshake authentication. We can even get rid of all the offline signatures with a more <a href=\"https://datatracker.ietf.org/doc/html/draft-davidben-tls-merkle-tree-certs-03\"><u>ambitious redesign</u></a> for the <a href=\"https://www.youtube.com/watch?v=f8unMB2Qjho\"><u>vast majority</u></a> of visits: a post-quantum Internet with fewer bytes on the wire! We’ve discussed these ideas at more length in a <a href=\"https://blog.cloudflare.com/pq-2024/#way-forward\"><u>previous blog post</u></a>.</p><p>So what does this mean for the coming years? We will continue to work with browsers to understand the end user impact of large drop-in post-quantum certificates. When certificate authorities support them (our guess: 2026), we will add support for ML-DSA certificates <a href=\"https://blog.cloudflare.com/post-quantum-crypto-should-be-free/\"><u>for free</u></a>. This will be opt-in until cryptographically relevant quantum computers are imminent, to prevent undue performance regression. In the meantime, we will continue to pursue larger changes to the WebPKI, so that we can bring full post-quantum security to the Internet without performance compromise.</p><p>We’ve talked a lot about certificates, but what we need to care about today is encryption. Along with many across industry, including the major browsers, we have deployed the post-quantum key agreement X25519MLKEM768 across the board, and you can make sure your connections with Cloudflare are already secured against harvest-now/decrypt-later. Visit <a href=\"http://pq.cloudflareresearch.com\"><u>pq.cloudflareresearch.com</u></a> to learn how.</p>"],"published_at":[0,"2024-11-07T14:00+00:00"],"updated_at":[0,"2024-11-07T14:00:02.722Z"],"feature_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/14aKzVYYFvVhoxquNWWg1I/5da91d29f43ab0f6b5e08cf812c55aae/unnamed.png"],"tags":[1,[[0,{"id":[0,"6bIo7ayy56Fzdrtf9z2EWy"],"name":[0,"Post-Quantum"],"slug":[0,"post-quantum"]}],[0,{"id":[0,"1x7tpPmKIUCt19EDgM1Tsl"],"name":[0,"Research"],"slug":[0,"research"]}],[0,{"id":[0,"1QsJUMpv0QBSLiVZLLQJ3V"],"name":[0,"Cryptography"],"slug":[0,"cryptography"]}],[0,{"id":[0,"56vA0Z6hqev6QaJBQmO2J8"],"name":[0,"TLS"],"slug":[0,"tls"]}]]],"relatedTags":[0],"authors":[1,[[0,{"name":[0,"Bas Westerbaan"],"slug":[0,"bas"],"bio":[0,null],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/4KeBG8XO1ADZHuEV9v5Hwz/6c90a96cfb1373b208bffc35f3fd71f4/bas.png"],"location":[0,"The Netherlands"],"website":[0,"https://bas.westerbaan.name"],"twitter":[0,"@bwesterb"],"facebook":[0,null]}],[0,{"name":[0,"Luke Valenta"],"slug":[0,"luke"],"bio":[0,null],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/2FfvsynZPyK2w2lJSIXdqr/f8758aa6638121491d233932a076770e/luke.jpg"],"location":[0,"Austin, TX"],"website":[0,"https://lukevalenta.com/"],"twitter":[0,"@lukevalenta"],"facebook":[0,null]}]]],"meta_description":[0,"NIST has standardized four post-quantum signature schemes so far, and they’re not done yet: there are fourteen new candidates in the running for standardization. In this blog post we take measure of them and discover why we ended up with so many PQ signatures."],"primary_author":[0,{}],"localeList":[0,{"name":[0,"blog-english-only"],"enUS":[0,"English for Locale"],"zhCN":[0,"No Page for Locale"],"zhHansCN":[0,"No Page for Locale"],"zhTW":[0,"No Page for Locale"],"frFR":[0,"No Page for Locale"],"deDE":[0,"No Page for Locale"],"itIT":[0,"No Page for Locale"],"jaJP":[0,"No Page for Locale"],"koKR":[0,"No Page for Locale"],"ptBR":[0,"No Page for Locale"],"esLA":[0,"No Page for Locale"],"esES":[0,"No Page for Locale"],"enAU":[0,"No Page for Locale"],"enCA":[0,"No Page for Locale"],"enIN":[0,"No Page for Locale"],"enGB":[0,"No Page for Locale"],"idID":[0,"No Page for Locale"],"ruRU":[0,"No Page for Locale"],"svSE":[0,"No Page for Locale"],"viVN":[0,"No Page for Locale"],"plPL":[0,"No Page for Locale"],"arAR":[0,"No Page for Locale"],"nlNL":[0,"No Page for Locale"],"thTH":[0,"No Page for Locale"],"trTR":[0,"No Page for Locale"],"heIL":[0,"No Page for Locale"],"lvLV":[0,"No Page for Locale"],"etEE":[0,"No Page for Locale"],"ltLT":[0,"No Page for Locale"]}],"url":[0,"https://blog.cloudflare.com/another-look-at-pq-signatures"],"metadata":[0,{"title":[0,"A look at the latest post-quantum signature standardization candidates"],"description":[0,"NIST has standardized four post-quantum signature schemes so far, and they’re not done yet: there are fourteen new candidates in the running for standardization. In this blog post we take measure of them and discover why we ended up with so many PQ signatures."],"imgPreview":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/GJ6NG49gvA8D9v05bCZIC/79a0d682bf29db033ca86c4d7bfc5485/A_look_at_the_latest_post-quantum_signature_standardization_candidates_-OG.png"]}]}],[0,{"id":[0,"6e7vmGCa8tZRTNJWqYs1di"],"title":[0,"Cloudflare acquires Kivera to add simple, preventive cloud security to Cloudflare One "],"slug":[0,"cloudflare-acquires-kivera"],"excerpt":[0,"The acquisition and integration of Kivera broadens the scope of Cloudflare’s SASE platform beyond just apps, incorporating increased cloud security through proactive configuration management of cloud services. "],"featured":[0,false],"html":[0,"<p>We’re excited to announce that <a href=\"https://www.kivera.io/\"><u>Kivera</u></a>, a cloud security, data protection, and compliance company, has joined Cloudflare. This acquisition extends our SASE portfolio to incorporate inline cloud app controls, empowering <a href=\"https://www.cloudflare.com/zero-trust/\"><u>Cloudflare One</u></a> customers with preventative security controls for all their cloud services.</p><p>In today’s digital landscape, cloud services and SaaS (software as a service) apps have become indispensable for the daily operation of organizations. At the same time, the amount of data flowing between organizations and their cloud providers has ballooned, increasing the chances of data leakage, compliance issues, and worse, opportunities for attackers. Additionally, many companies — especially at enterprise scale — are working directly with multiple cloud providers for flexibility based on the strengths, resiliency against outages or errors, and cost efficiencies of different clouds. </p><p>Security teams that rely on <a href=\"https://www.cloudflare.com/learning/cloud/what-is-cspm/\"><u>Cloud Security Posture Management (CSPM)</u></a> or similar tools for monitoring cloud configurations and permissions and Infrastructure as code (IaC) scanning are falling short due to detecting issues only after misconfigurations occur with an overwhelming volume of alerts. The combination of Kivera and Cloudflare One puts preventive controls directly into the deployment process, or ‘inline’, blocking errors before they happen. This offers a proactive approach essential to protecting cloud infrastructure from evolving cyber threats, maintaining data security, and accelerating compliance. </p>\n <div class=\"flex anchor relative\">\n <h2 id=\"an-early-warning-system-for-cloud-security-risks\">An early warning system for cloud security risks </h2>\n <a href=\"#an-early-warning-system-for-cloud-security-risks\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>In a significant leap forward in cloud security, the combination of Kivera’s technology and Cloudflare One adds preventive, inline controls to enforce secure configurations for cloud resources. By inspecting cloud API traffic, these new capabilities equip organizations with enhanced visibility and granular controls, allowing for a proactive approach in mitigating risks, managing cloud security posture, and embracing a streamlined DevOps process when deploying cloud infrastructure.</p><p>Kivera will add the following capabilities to Cloudflare’s <a href=\"https://www.cloudflare.com/learning/access-management/what-is-sase/\"><u>SASE</u></a> platform:</p><ul><li><p><b>One-click security:</b> Customers benefit from immediate prevention of the most common cloud breaches caused by misconfigurations, such as accidentally allowing public access or policy inconsistencies.</p></li><li><p><b>Enforced cloud tenant control:</b> Companies can easily draw boundaries around their cloud resources and tenants to ensure that sensitive data stays within their organization. </p></li><li><p><b>Prevent data exfiltration:</b> Easily set rules to prevent data being sent to unauthorized locations.</p></li><li><p><b>Reduce ‘shadow’ cloud infrastructure:</b> Ensure that every interaction between a customer and their cloud provider is in line with preset standards. </p></li><li><p><b>Streamline cloud security compliance:</b> Customers can automatically assess and enforce compliance against the most common regulatory frameworks.</p></li><li><p><b>Flexible DevOps model:</b> Enforce bespoke controls independent of public cloud setup and deployment tools, minimizing the layers of lock-in between an organization and a cloud provider.</p></li><li><p><b>Complementing other cloud security tools:</b> Create a first line of defense for cloud deployment errors, reducing the volume of alerts for customers also using CSPM tools or Cloud Native Application Protection Platforms (CNAPPs). </p></li></ul>\n <figure class=\"kg-card kg-image-card\">\n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/7nALx5Qv8FBYxn1R6RkUvX/1b3dddb60d9d85142a9fda82d2eee381/BLOG-2592_2.png\" alt=\"BLOG-2592 2\" class=\"kg-image\" width=\"1999\" height=\"1155\" loading=\"lazy\"/>\n </figure><p><sub><i>An intelligent proxy that uses a policy-based approach to \nenforce secure configuration of cloud resources.</i></sub></p>\n <div class=\"flex anchor relative\">\n <h2 id=\"better-together-with-cloudflare-one\">Better together with Cloudflare One</h2>\n <a href=\"#better-together-with-cloudflare-one\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>As a SASE platform, Cloudflare One ensures safe access and provides data controls for cloud and SaaS apps. This integration broadens the scope of Cloudflare’s SASE platform beyond user-facing applications to incorporate increased cloud security through proactive configuration management of infrastructure services, beyond what CSPM and <a href=\"https://www.cloudflare.com/learning/access-management/what-is-a-casb/\"><u>CASB</u></a> solutions provide. With the addition of Kivera to Cloudflare One, customers now have a unified platform for all their inline protections, including cloud control, access management, and threat and data protection. All of these features are available with single-pass inspection, which is <a href=\"https://blog.cloudflare.com/network-performance-update-cio-edition/?_ga=2.241337794.1947644748.1710771073-1224524116.1709647459\"><u>50% faster</u></a> than <a href=\"https://www.cloudflare.com/learning/access-management/what-is-a-secure-web-gateway/\"><u>Secure Web Gateway (SWG)</u></a> alternatives. </p><p>With the earlier <a href=\"https://blog.cloudflare.com/cloudflare-acquires-bastionzero/\"><u>acquisition of BastionZero</u></a>, a Zero Trust infrastructure access company, Cloudflare One expanded the scope of its VPN replacement solution to cover infrastructure resources as easily as it does apps and networks. Together Kivera and BastionZero enable centralized security management across hybrid IT environments, and provide a modern DevOps-friendly way to help enterprises connect and protect their hybrid infrastructure with Zero Trust best practices.</p><p>Beyond its SASE capabilities, Cloudflare One is integral to <a href=\"https://www.cloudflare.com/connectivity-cloud/\"><u>Cloudflare’s connectivity cloud</u></a>, enabling organizations to consolidate IT security tools on a single platform. This simplifies secure access to resources, from developer privileged access to technical infrastructure and expanding cloud services. As <a href=\"https://www.cloudflare.com/lp/forrester-wave-sse-2024/\"><u>Forrester echoes</u></a>, “Cloudflare is a good choice for enterprise prospects seeking a high-performance, low-maintenance, DevOps-oriented solution.”</p>\n <div class=\"flex anchor relative\">\n <h2 id=\"the-growing-threat-of-cloud-misconfigurations\">The growing threat of cloud misconfigurations</h2>\n <a href=\"#the-growing-threat-of-cloud-misconfigurations\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>The cloud has become a prime target for cyberattacks. According to the <a href=\"https://www.crowdstrike.com/resources/reports/crowdstrike-2023-cloud-risk-report-executive-summary/\"><u>2023 Cloud Risk Report</u></a>, CrowdStrike observed a 95% increase in cloud exploitation from 2021 to 2022, with a staggering 288% jump in cases involving threat actors directly targeting the cloud.</p><p>Misconfigurations in cloud infrastructure settings, such as improperly set security parameters and default access controls, provide adversaries with an easy path to infiltrate the cloud. According to the <a href=\"https://cpl.thalesgroup.com/sites/default/files/content/cloud-security/2024/2024-thales-cloud-security-study-global-edition.pdf\"><u>2023 Thales Global Cloud Security Study</u></a>, which surveyed nearly 3,000 IT and security professionals from 18 countries, 44% of respondents reported experiencing a data breach, with misconfigurations and human error identified as the leading cause, accounting for 31% of the incidents.</p><p>Further, according to Gartner<sup>Ⓡ</sup>, “Through 2027, 99% of records compromised in cloud environments will be the result of user misconfigurations and account compromise, not the result of an issue with the cloud provider.”<sup>1</sup></p><p>Several factors contribute to the rise of cloud misconfigurations:</p><ul><li><p><b>Rapid adoption of cloud services:</b> Leaders are often driven by the scalability, cost-efficiency, and ability to support remote work and real-time collaboration that cloud services offer. These factors enable rapid adoption of cloud services which can lead to unintentional misconfigurations as IT teams struggle to keep up with the pace and complexity of these services. </p></li><li><p><b>Complexity of cloud environments:</b> Cloud infrastructure can be highly complex with multiple services and configurations to manage. For example, <a href=\"https://public.docs.kivera.io/docs/access-analyzer\"><u>AWS alone offers</u></a> 373 services with 15,617 actions and 140,000+ parameters, making it challenging for IT teams to manage settings accurately. </p></li><li><p><b>Decentralized management:</b> In large organizations, cloud infrastructure resources are often managed by multiple teams or departments. Without centralized oversight, inconsistent security policies and configurations can arise, increasing the risk of misconfigurations.</p></li><li><p><b>Continuous Integration and Continuous Deployment (CI/CD):</b> CI/CD pipelines promote the ability to rapidly deploy, change and frequently update infrastructure. With this velocity comes the increased risk of misconfigurations when changes are not properly managed and reviewed.</p></li><li><p><b>Insufficient training and awareness:</b> Employees may lack the cross-functional skills needed for cloud security, such as understanding networks, identity, and service configurations. This knowledge gap can lead to mistakes and increases the risk of misconfigurations that compromise security.</p></li></ul>\n <div class=\"flex anchor relative\">\n <h3 id=\"common-exploitation-methods\">Common exploitation methods </h3>\n <a href=\"#common-exploitation-methods\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>Threat actors exploit cloud services through various means, including targeting misconfigurations, abusing privileges, and bypassing encryption. Misconfigurations such as exposed storage buckets or improperly secured APIs offer attackers easy access to sensitive data and resources. Privilege abuse occurs when attackers gain unauthorized access through compromised credentials or poorly managed identity and access management (IAM) policies, allowing them to escalate their access and move laterally within the cloud environment. Additionally, unencrypted data enables attackers to intercept and decrypt data in transit or at rest, further compromising the integrity and confidentiality of sensitive information.</p><p>Here are some other vulnerabilities that organizations should address: </p><ul><li><p><b>Unrestricted access to cloud tenants:</b> Allowing unrestricted access exposes cloud platforms to <a href=\"https://www.cloudflare.com/learning/security/what-is-data-exfiltration/\">data exfiltration</a> by malicious actors. Limiting access to approved tenants with specific IP addresses and service destinations helps prevent unauthorized access.</p></li><li><p><b>Exposed access keys:</b> Exposed access keys can be exploited by unauthorized parties to steal or delete data. Requiring encryption for the access keys and restricting their usage can mitigate this risk.</p></li><li><p><b>Excessive account permissions:</b> Granting excessive privileges to cloud accounts increases the potential impact of security breaches. Limiting permissions to necessary operations helps prevent lateral movement and privilege escalation by threat actors.</p></li><li><p><b>Inadequate network segmentation:</b> Poorly managed network security groups and insufficient segmentation practices can allow attackers to move freely within cloud environments. Drawing boundaries around your cloud resources and tenants ensures that data stays within your organization.</p></li><li><p><b>Improper public access configuration:</b> Incorrectly exposing critical services or storage resources to the internet increases the likelihood of unauthorized access and data compromise. Preventing public access drastically reduces risk.</p></li><li><p><b>Shadow cloud infrastructure:</b> Abandoned or neglected cloud instances are often left vulnerable to exploitation, providing attackers with opportunities to access sensitive data left behind. Preventing untagged or unapproved cloud resources to be created can reduce the risk of exposure.</p></li></ul>\n <div class=\"flex anchor relative\">\n <h2 id=\"limitations-of-existing-tools\">Limitations of existing tools </h2>\n <a href=\"#limitations-of-existing-tools\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>Many organizations turn to CSPM tools to give them more visibility into cloud misconfigurations. These tools often alert teams after an issue occurs, putting security teams in a reactive mode. Remediation efforts require collaboration between security teams and developers to implement changes, which can be time-consuming and resource-intensive. This approach not only delays issue resolution but also exposes companies to compliance and legal risks, while failing to train employees on secure cloud practices. <a href=\"https://www.ibm.com/reports/data-breach-action-guide\"><u>On average</u></a>, it takes 207 days to identify these breaches and an additional 70 days to contain them. </p><p>Addressing the growing threat of cloud misconfigurations requires proactive security measures and continuous monitoring. Organizations must adopt proactive security solutions that not only detect and alert but also prevent misconfigurations from occuring in the first place and enforce best practices. Creating a first line of defense for cloud deployment errors reduces the volume of alerts for customers, especially those also using CSPM tools or CNAPPs. </p><p>By implementing these proactive strategies, organizations can safeguard their cloud environments against the evolving landscape of cyber threats, ensuring robust security and compliance while minimizing risks and operational disruptions.</p>\n <div class=\"flex anchor relative\">\n <h2 id=\"whats-next-for-kivera\">What’s next for Kivera</h2>\n <a href=\"#whats-next-for-kivera\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>The Kivera product will not be a point solution add-on. We’re making it a core part of our Cloudflare One offering because integrating features from products like our Secure Web Gateway give customers a comprehensive solution that works better together.</p><p>We’re excited to welcome Kivera to the Cloudflare team. Through the end of 2024 and into early 2025, Kivera’s team will focus on integrating their preventive inline cloud app controls directly into Cloudflare One. We are looking for early access testers and teams to provide feedback about what they would like to see. If you’d like early access, please <a href=\"https://www.cloudflare.com/lp/cloud-app-controls\"><u>join the waitlist</u></a>.</p><p><sub>[1] Source: Outcome-Driven Metrics You Can Use to Evaluate Cloud Security Controls, Gartner, Charlie Winckless, Paul Proctor, Manuel Acosta, 09/28/2023 </sub></p><p><sub>GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All rights reserved.</sub></p><p>\n</p>"],"published_at":[0,"2024-10-08T06:00-07:00"],"updated_at":[0,"2024-11-22T18:43:45.968Z"],"feature_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/30RE4iMKhbDhGGXskFMplQ/d014591604196342f215cb093d7100b4/BLOG-2592_1.png"],"tags":[1,[[0,{"id":[0,"6l7hyMgGAf9GhOz3E7MNxh"],"name":[0,"Data Protection"],"slug":[0,"data-protection"]}],[0,{"id":[0,"013htAspXBEMdE76Afcyq2"],"name":[0,"Acquisitions"],"slug":[0,"acquisitions"]}],[0,{"id":[0,"2Kxh34kIQRA3gyymmhJpsR"],"name":[0,"Email Security"],"slug":[0,"email-security"]}],[0,{"id":[0,"73lXar1fZP6qrIIcgBA5Te"],"name":[0,"Cloud Email Security"],"slug":[0,"cloud-email-security"]}],[0,{"id":[0,"2UI24t7uddD0CIIUJCu1f4"],"name":[0,"SASE"],"slug":[0,"sase"]}],[0,{"id":[0,"J61Eszqn98amrYHq4IhTx"],"name":[0,"Zero Trust"],"slug":[0,"zero-trust"]}],[0,{"id":[0,"6Mp7ouACN2rT3YjL1xaXJx"],"name":[0,"Security"],"slug":[0,"security"]}],[0,{"id":[0,"6QktrXeEFcl4e2dZUTZVGl"],"name":[0,"Product News"],"slug":[0,"product-news"]}],[0,{"id":[0,"4Z2oveL0P0AeqGa5lL4Vo1"],"name":[0,"Cloudflare One"],"slug":[0,"cloudflare-one"]}]]],"relatedTags":[0],"authors":[1,[[0,{"name":[0,"Noelle Kagan"],"slug":[0,"noelle"],"bio":[0,null],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/4mJ1POhjqxk4ugsdEWIzZ3/19785afce2122fdd522375f73ae77bfb/noelle.png"],"location":[0,null],"website":[0,null],"twitter":[0,null],"facebook":[0,null]}],[0,{"name":[0,"Neil Brown"],"slug":[0,"neil-brown"],"bio":[0],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/15RcwB6GdLCUih1FFhwmLD/505ee5bf2c94069e8d7c364474f5d42f/Screenshot_2024-10-07_at_3.02.06_PM.png"],"location":[0],"website":[0],"twitter":[0],"facebook":[0]}],[0,{"name":[0,"Yumna Moazzam"],"slug":[0,"yumna"],"bio":[0],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/r0Nl4nvnTaWMbkYq6OaqB/23d73ea7949bace057cef7e67808f1ac/Outlook-n0p4yq3n.png"],"location":[0],"website":[0],"twitter":[0],"facebook":[0]}]]],"meta_description":[0,"The acquisition and integration of Kivera broadens the scope of Cloudflare’s SASE platform beyond just apps, incorporating increased cloud security through proactive configuration management of cloud services. "],"primary_author":[0,{}],"localeList":[0,{"name":[0,"blog-english-only"],"enUS":[0,"English for Locale"],"zhCN":[0,"No Page for Locale"],"zhHansCN":[0,"No Page for Locale"],"zhTW":[0,"No Page for Locale"],"frFR":[0,"No Page for Locale"],"deDE":[0,"No Page for Locale"],"itIT":[0,"No Page for Locale"],"jaJP":[0,"No Page for Locale"],"koKR":[0,"No Page for Locale"],"ptBR":[0,"No Page for Locale"],"esLA":[0,"No Page for Locale"],"esES":[0,"No Page for Locale"],"enAU":[0,"No Page for Locale"],"enCA":[0,"No Page for Locale"],"enIN":[0,"No Page for Locale"],"enGB":[0,"No Page for Locale"],"idID":[0,"No Page for Locale"],"ruRU":[0,"No Page for Locale"],"svSE":[0,"No Page for Locale"],"viVN":[0,"No Page for Locale"],"plPL":[0,"No Page for Locale"],"arAR":[0,"No Page for Locale"],"nlNL":[0,"No Page for Locale"],"thTH":[0,"No Page for Locale"],"trTR":[0,"No Page for Locale"],"heIL":[0,"No Page for Locale"],"lvLV":[0,"No Page for Locale"],"etEE":[0,"No Page for Locale"],"ltLT":[0,"No Page for Locale"]}],"url":[0,"https://blog.cloudflare.com/cloudflare-acquires-kivera"],"metadata":[0,{"title":[0,"Cloudflare acquires Kivera to add simple, preventive cloud security to Cloudflare One"],"description":[0,"The acquisition and integration of Kivera broadens the scope of Cloudflare’s SASE platform beyond just apps, incorporating increased cloud security through proactive configuration management of cloud services. "],"imgPreview":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/2hr2uadS2ijoa710twE0e4/cecd5e9c68247511afa1bbf15e653962/BLOG-2592_OG.png"]}]}],[0,{"id":[0,"1uvkAn3IB6vSEO91XsPyAO"],"title":[0,"Enhance your website's security with Cloudflare’s free security.txt generator"],"slug":[0,"security-txt"],"excerpt":[0,"Introducing Cloudflare’s free security.txt generator, empowering all users to easily create and manage their security.txt files. This feature enhances vulnerability disclosure processes, aligns with industry standards, and is integrated into the dashboard for seamless access. Strengthen your website's security today!"],"featured":[0,false],"html":[0,"\n <div class=\"flex anchor relative\">\n <h2 id=\"a-story-of-security-and-simplicity\">A story of security and simplicity</h2>\n <a href=\"#a-story-of-security-and-simplicity\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>Meet Georgia, a diligent website administrator at a growing e-commerce company. Every day, Georgia juggles multiple tasks, from managing server uptime to ensuring customer data security. One morning, Georgia receives an email from a security researcher who discovered a potential vulnerability on the website. The researcher struggled to find the right contact information, leading to delays in reporting the issue. Georgia realizes the need for a standardized way to communicate with security researchers, ensuring that vulnerabilities are reported swiftly and efficiently. This is where security.txt comes in.</p>\n <div class=\"flex anchor relative\">\n <h2 id=\"why-security-txt-matters\">Why security.txt matters</h2>\n <a href=\"#why-security-txt-matters\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p><a href=\"https://securitytxt.org/\"><u>Security.txt</u></a> is becoming a widely adopted standard among security-conscious organizations. By providing a common location and format for vulnerability disclosure information, it helps bridge the gap between security researchers and organizations. This initiative is supported by major companies and aligns with global security best practices. By offering an automated security.txt generator for free, we aim to empower all of our users to enhance their security measures without additional costs.</p><p>In 2020, Cloudflare published the Cloudflare Worker for the security.txt generator as an <a href=\"https://github.com/cloudflare/securitytxt-worker?cf_history_state=%7B%22guid%22%3A%22C255D9FF78CD46CDA4F76812EA68C350%22%2C%22historyId%22%3A8%2C%22targetId%22%3A%22532D731DBD87B52B996FF5AD5ADDA824%22%7D\"><u>open-source project on GitHub</u></a>, demonstrating our commitment to enhancing web security. This tool is actively used by Cloudflare to streamline vulnerability disclosure processes. However, over the past few years, we&#39;ve observed a growing demand from our customers for an easier way to implement this standard. In response to this demand and to further support the adoption of security.txt across the Internet, we integrated it directly into our dashboard, making it simple for all our users to enhance their security practices. You can learn more about the initial release and its impact in our previous blog post <a href=\"https://blog.cloudflare.com/security-dot-txt/\"><u>here</u></a>. </p>\n <div class=\"flex anchor relative\">\n <h3 id=\"who-can-use-the-free-cloudflare-security-txt-generator\">Who can use the free Cloudflare security.txt generator</h3>\n <a href=\"#who-can-use-the-free-cloudflare-security-txt-generator\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>This feature is designed for any Cloudflare user who manages a website, from small business owners to large enterprises, from developers to security professionals. Whether you&#39;re a seasoned security expert or new to website management, this tool provides an easy way to create and manage your security.txt file in your Cloudflare account, ensuring that you&#39;re prepared to handle vulnerability reports effectively.</p>\n <div class=\"flex anchor relative\">\n <h3 id=\"technical-insights-leveraging-cloudflares-tools\">Technical insights: leveraging Cloudflare’s tools</h3>\n <a href=\"#technical-insights-leveraging-cloudflares-tools\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>Our security.txt generator is seamlessly integrated into our dashboard. Here&#39;s how it works:</p>\n <figure class=\"kg-card kg-image-card\">\n <Image src=\"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/2z7tEph5hu4T7LCkZU5KFQ/8bc9c8efe332cda618c5dd8bb51e38da/image1.png\" alt=\"\" class=\"kg-image\" width=\"1490\" height=\"1233\" loading=\"lazy\"/>\n </figure><p>When the user enters their data in the Cloudflare Dashboard, the information is immediately stored in a highly available and geo-redundant <a href=\"https://blog.cloudflare.com/performance-isolation-in-a-multi-tenant-database-environment/\"><u>PostgreSQL database</u></a>. This ensures that all user data is securely kept and can be accessed quickly from any location within our global network.</p><p>Instead of creating a static file at the point of data entry, we use a dynamic approach. When a request for the security.txt file is made via the standard .well-known path specified by <a href=\"https://www.rfc-editor.org/rfc/rfc9116\"><u>RFC 9116</u></a>, our system dynamically constructs the file using the latest data from our database. This method ensures that any updates made by users are reflected in real-time without requiring manual intervention or file regeneration. The data entered by users is synchronized across Cloudflare’s global network using our <a href=\"https://blog.cloudflare.com/introducing-quicksilver-configuration-distribution-at-internet-scale/\"><u>Quicksilver</u></a> technology. This allows for rapid propagation of changes, ensuring that any updates to the security.txt file are available almost instantaneously across all servers.</p><p>Each security.txt file includes an expiration timestamp, which is set during the initial configuration. This timestamp helps alert users when their information may be outdated, encouraging them to review and update their details regularly. For example, if a user sets an expiration date 365 days into the future, they will receive notifications as this date approaches, prompting them to refresh their information.</p><p>To ensure compliance with best practices, we also support optional fields such as encryption keys and signatures within the security.txt file. Users can link to their PGP keys for secure communications or include signatures to verify authenticity, enhancing trust with security researchers.</p><p>Users who prefer automation can manage their security.txt files through our <a href=\"https://developers.cloudflare.com/api/operations/update-security-txt\"><u>API</u></a>, allowing seamless integration with existing workflows and tools. This feature enables developers to programmatically update their security.txt configurations without manual dashboard interactions.</p><p>Users can also find a view of any missing security.txt files via <a href=\"https://developers.cloudflare.com/security-center/security-insights/\"><u>Security Insights</u></a> under Security Center.</p>\n <div class=\"flex anchor relative\">\n <h3 id=\"available-now-and-free-for-all-cloudflare-users\">Available now, and free for all Cloudflare users</h3>\n <a href=\"#available-now-and-free-for-all-cloudflare-users\" aria-hidden=\"true\" class=\"relative sm:absolute sm:-left-5\">\n <svg width=\"16\" height=\"16\" viewBox=\"0 0 24 24\"><path fill=\"currentcolor\" d=\"m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z\"></path></svg>\n </a>\n </div>\n <p>By making this feature available to all our users at no cost, we aim to support the security efforts of our entire community, helping you protect your digital assets and foster trust with your audience.</p><p>With the introduction of our free security.txt generator, we&#39;re taking a significant step towards simplifying security management for everyone. Whether you&#39;re a small business owner or a large enterprise, this tool empowers you to adopt industry best practices and ensure that you&#39;re ready to handle vulnerability reports effectively. <a href=\"https://developers.cloudflare.com/security-center/infrastructure/security-file/\"><u>Set up security.txt</u></a> on your websites today!</p>"],"published_at":[0,"2024-10-07T00:00+01:00"],"updated_at":[0,"2024-10-09T23:04:49.414Z"],"feature_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/5ZSJkAGSk5ed5rCURksXWu/cb4be89efbfdc63241530a2c166c06bc/image2.png"],"tags":[1,[[0,{"id":[0,"3Fo5JgRZ6Fh2HHzhEr7AKn"],"name":[0,"Better Internet"],"slug":[0,"better-internet"]}],[0,{"id":[0,"19xj8iWb9c1gd1fBmI1qB7"],"name":[0,"Security Posture"],"slug":[0,"security-posture"]}],[0,{"id":[0,"6Mp7ouACN2rT3YjL1xaXJx"],"name":[0,"Security"],"slug":[0,"security"]}],[0,{"id":[0,"iiynSxxhE6dlxRhbsXqc4"],"name":[0,"Standards"],"slug":[0,"standards"]}],[0,{"id":[0,"6o7rikedmBXTwqPLscJAuD"],"name":[0,"security.txt"],"slug":[0,"security-txt"]}]]],"relatedTags":[0],"authors":[1,[[0,{"name":[0,"Alexandra Moraru"],"slug":[0,"alexandra"],"bio":[0,null],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/URwbDrA0k9GNtNsCsAC7N/930223a35d0c7a39cb843e44f530ccba/alexandra.png"],"location":[0,"London"],"website":[0,null],"twitter":[0,"@alexandramoraru"],"facebook":[0,null]}],[0,{"name":[0,"Sam Khawasé"],"slug":[0,"sam-khawase"],"bio":[0],"profile_image":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/141PdciA0tD5Bh4g2n3vCH/4934115ae0bd6324003dc4c1054ef7a9/Profile_Aihole.jpg"],"location":[0],"website":[0],"twitter":[0],"facebook":[0]}]]],"meta_description":[0,"Introducing Cloudflare’s free security.txt generator, empowering all users to easily create and manage their security.txt files. This feature enhances vulnerability disclosure processes, aligns with industry standards, and is integrated into the dashboard for seamless access. Strengthen your website's security today!"],"primary_author":[0,{}],"localeList":[0,{"name":[0,"blog-english-only"],"enUS":[0,"English for Locale"],"zhCN":[0,"No Page for Locale"],"zhHansCN":[0,"No Page for Locale"],"zhTW":[0,"No Page for Locale"],"frFR":[0,"No Page for Locale"],"deDE":[0,"No Page for Locale"],"itIT":[0,"No Page for Locale"],"jaJP":[0,"No Page for Locale"],"koKR":[0,"No Page for Locale"],"ptBR":[0,"No Page for Locale"],"esLA":[0,"No Page for Locale"],"esES":[0,"No Page for Locale"],"enAU":[0,"No Page for Locale"],"enCA":[0,"No Page for Locale"],"enIN":[0,"No Page for Locale"],"enGB":[0,"No Page for Locale"],"idID":[0,"No Page for Locale"],"ruRU":[0,"No Page for Locale"],"svSE":[0,"No Page for Locale"],"viVN":[0,"No Page for Locale"],"plPL":[0,"No Page for Locale"],"arAR":[0,"No Page for Locale"],"nlNL":[0,"No Page for Locale"],"thTH":[0,"No Page for Locale"],"trTR":[0,"No Page for Locale"],"heIL":[0,"No Page for Locale"],"lvLV":[0,"No Page for Locale"],"etEE":[0,"No Page for Locale"],"ltLT":[0,"No Page for Locale"]}],"url":[0,"https://blog.cloudflare.com/security-txt"],"metadata":[0,{"title":[0,"Enhance your website's security with Cloudflare’s free security.txt generator"],"description":[0,"Introducing Cloudflare’s free security.txt generator, empowering all users to easily create and manage their security.txt files. This feature enhances vulnerability disclosure processes, aligns with industry standards, and is integrated into the dashboard for seamless access."],"imgPreview":[0,"https://cf-assets.www.cloudflare.com/zkvhlag99gkb/64dem9vOGrCmDEJHQoRgfe/b0a984c422f55a43c127c29205120d5b/Enhance_your_website-s_security_with_Cloudflare_s_free_security.txt_generator-OG.png"]}]}]]],"locale":[0,"en-us"],"translations":[0,{"posts.by":[0,"By"],"footer.gdpr":[0,"GDPR"],"lang_blurb1":[0,"This post is also available in {lang1}."],"lang_blurb2":[0,"This post is also available in {lang1} and {lang2}."],"lang_blurb3":[0,"This post is also available in {lang1}, {lang2} and {lang3}."],"footer.press":[0,"Press"],"header.title":[0,"The Cloudflare Blog"],"search.clear":[0,"Clear"],"search.filter":[0,"Filter"],"search.source":[0,"Source"],"footer.careers":[0,"Careers"],"footer.company":[0,"Company"],"footer.support":[0,"Support"],"footer.the_net":[0,"theNet"],"search.filters":[0,"Filters"],"footer.our_team":[0,"Our team"],"footer.webinars":[0,"Webinars"],"page.more_posts":[0,"More posts"],"posts.time_read":[0,"{time} min read"],"search.language":[0,"Language"],"footer.community":[0,"Community"],"footer.resources":[0,"Resources"],"footer.solutions":[0,"Solutions"],"footer.trademark":[0,"Trademark"],"header.subscribe":[0,"Subscribe"],"footer.compliance":[0,"Compliance"],"footer.free_plans":[0,"Free plans"],"footer.impact_ESG":[0,"Impact/ESG"],"posts.follow_on_X":[0,"Follow on X"],"footer.help_center":[0,"Help center"],"footer.network_map":[0,"Network Map"],"header.please_wait":[0,"Please Wait"],"page.related_posts":[0,"Related posts"],"search.result_stat":[0,"Results <strong>{search_range}</strong> of <strong>{search_total}</strong> for <strong>{search_keyword}</strong>"],"footer.case_studies":[0,"Case Studies"],"footer.connect_2024":[0,"Connect 2024"],"footer.terms_of_use":[0,"Terms of Use"],"footer.white_papers":[0,"White Papers"],"footer.cloudflare_tv":[0,"Cloudflare TV"],"footer.community_hub":[0,"Community Hub"],"footer.compare_plans":[0,"Compare plans"],"footer.contact_sales":[0,"Contact Sales"],"header.contact_sales":[0,"Contact Sales"],"header.email_address":[0,"Email Address"],"page.error.not_found":[0,"Page not found"],"footer.developer_docs":[0,"Developer docs"],"footer.privacy_policy":[0,"Privacy Policy"],"footer.request_a_demo":[0,"Request a demo"],"page.continue_reading":[0,"Continue reading"],"footer.analysts_report":[0,"Analyst reports"],"footer.for_enterprises":[0,"For enterprises"],"footer.getting_started":[0,"Getting Started"],"footer.learning_center":[0,"Learning Center"],"footer.project_galileo":[0,"Project Galileo"],"pagination.newer_posts":[0,"Newer Posts"],"pagination.older_posts":[0,"Older Posts"],"posts.social_buttons.x":[0,"Discuss on X"],"search.source_location":[0,"Source/Location"],"footer.about_cloudflare":[0,"About Cloudflare"],"footer.athenian_project":[0,"Athenian Project"],"footer.become_a_partner":[0,"Become a partner"],"footer.cloudflare_radar":[0,"Cloudflare Radar"],"footer.network_services":[0,"Network services"],"footer.trust_and_safety":[0,"Trust & Safety"],"header.get_started_free":[0,"Get Started Free"],"page.search.placeholder":[0,"Search Cloudflare"],"footer.cloudflare_status":[0,"Cloudflare Status"],"footer.cookie_preference":[0,"Cookie Preferences"],"header.valid_email_error":[0,"Must be valid email."],"footer.connectivity_cloud":[0,"Connectivity cloud"],"footer.developer_services":[0,"Developer services"],"footer.investor_relations":[0,"Investor relations"],"page.not_found.error_code":[0,"Error Code: 404"],"footer.logos_and_press_kit":[0,"Logos & press kit"],"footer.application_services":[0,"Application services"],"footer.get_a_recommendation":[0,"Get a recommendation"],"posts.social_buttons.reddit":[0,"Discuss on Reddit"],"footer.sse_and_sase_services":[0,"SSE and SASE services"],"page.not_found.outdated_link":[0,"You may have used an outdated link, or you may have typed the address incorrectly."],"footer.report_security_issues":[0,"Report Security Issues"],"page.error.error_message_page":[0,"Sorry, we can't find the page you are looking for."],"header.subscribe_notifications":[0,"Subscribe to receive notifications of new posts:"],"footer.cloudflare_for_campaigns":[0,"Cloudflare for Campaigns"],"header.subscription_confimation":[0,"Subscription confirmed. Thank you for subscribing!"],"posts.social_buttons.hackernews":[0,"Discuss on Hacker News"],"footer.diversity_equity_inclusion":[0,"Diversity, equity & inclusion"],"footer.critical_infrastructure_defense_project":[0,"Critical Infrastructure Defense Project"]}],"localesAvailable":[1,[[0,"zh-cn"],[0,"fr-fr"],[0,"de-de"],[0,"es-es"]]],"footerBlurb":[0,"Cloudflare's connectivity cloud protects <a target='_blank' href='https://www.cloudflare.com/network-services/' rel='noreferrer'>entire corporate networks</a>, helps customers build <a target='_blank' href='https://workers.cloudflare.com/' rel='noreferrer'>Internet-scale applications efficiently</a>, accelerates any <a target='_blank' href='https://www.cloudflare.com/performance/accelerate-internet-applications/' rel='noreferrer'>website or Internet application</a>, <a target='_blank' href='https://www.cloudflare.com/ddos/' rel='noreferrer'>wards off DDoS attacks</a>, keeps <a target='_blank' href='https://www.cloudflare.com/application-security/' rel='noreferrer'>hackers at bay</a>, and can help you on <a target='_blank' href='https://www.cloudflare.com/products/zero-trust/' rel='noreferrer'>your journey to Zero Trust</a>.<br/><br/>Visit <a target='_blank' href='https://one.one.one.one/' rel='noreferrer'>1.1.1.1</a> from any device to get started with our free app that makes your Internet faster and safer.<br/><br/>To learn more about our mission to help build a better Internet, <a target='_blank' href='https://www.cloudflare.com/learning/what-is-cloudflare/' rel='noreferrer'>start here</a>. If you&apos;re looking for a new career direction, check out <a target='_blank' href='http://www.cloudflare.com/careers' rel='noreferrer'>our open positions</a>."]}" ssr="" client="load" opts="{"name":"Post","value":true}" await-children=""><main id="post" class="flex flex-row flex-wrap items-center justify-center pt2 pt4-l"><article class="post-full mw-100 ph3 ph0-l fs-20px"><h1 class="f6 f7-l fw4 gray1 pt1 pt3-l mb1">HTTP/3: From root to tip</h1><p class="f3 fw5 gray5 db di-l mt2">2019-01-24</p><ul class="author-lists flex pl0 mt4"><li class="list flex items-center pr2 mb1-ns"><a href="/author/lucas" class="static-avatar pr1"><img class="author-profile-image br-100 mr2" src="https://blog.cloudflare.com/cdn-cgi/image/format=auto,dpr=3,width=64,height=64,gravity=face,fit=crop,zoom=0.5/https://cf-assets.www.cloudflare.com/zkvhlag99gkb/1k0fbniT2p2wjRfMognV4V/dca8d2e3a3e7fa4e24d7ddd9832eff1d/lucas.jpg" alt="Lucas Pardue" width="62" height="62"/></a><div class="author-name-tooltip"><a href="/author/lucas" class="fw4 f3 no-underline black mr3">Lucas Pardue</a></div></li></ul><section class="post-full-content"><div class="mb2 gray5">18 min read</div><div class="mt4">This post is also available in <a href="/zh-cn/http-3-from-root-to-tip">简体中文</a>, <a href="/de-de/http-3-from-root-to-tip">Deutsch</a>, <a href="/es-es/http-3-from-root-to-tip">Español</a> and <a href="/fr-fr/http-3-from-root-to-tip">Français</a>.</div><img class="mr2" src="https://cf-assets.www.cloudflare.com/zkvhlag99gkb/4sHg74EBOhB89AyctJUIOV/0147d90b72529c6e60c6b345dd194c83/http-3-from-root-to-tip.png" alt=""/><div class="post-content lh-copy gray1"><p>HTTP is the application protocol that powers the Web. It began life as the so-called HTTP/0.9 protocol in 1991, and by 1999 had evolved to HTTP/1.1, which was standardised within the IETF (Internet Engineering Task Force). HTTP/1.1 was good enough for a long time but the ever changing needs of the Web called for a better suited protocol, and HTTP/2 emerged in 2015. More recently it was announced that the IETF is intending to deliver a new version - <a href="https://www.cloudflare.com/learning/performance/what-is-http3/">HTTP/3</a>. To some people this is a surprise and has caused a bit of confusion. If you don't track IETF work closely it might seem that HTTP/3 has come out of the blue. However, we can trace its origins through a lineage of experiments and evolution of Web protocols; specifically the QUIC transport protocol.</p><p>If you're not familiar with QUIC, my colleagues have done a great job of tackling different angles. John's <a href="/the-quicening/">blog</a> describes some of the real-world annoyances of today's HTTP, Alessandro's <a href="/the-road-to-quic/">blog</a> tackles the nitty-gritty transport layer details, and Nick's blog covers <a href="/head-start-with-quic/">how to get hands on</a> with some testing. We've collected these and more at <a href="https://cloudflare-quic.com">https://cloudflare-quic.com</a>. And if that tickles your fancy, be sure to check out <a href="/enjoy-a-slice-of-quic-and-rust/">quiche</a>, our own open-source implementation of the QUIC protocol written in Rust.</p><p>HTTP/3 is the HTTP application mapping to the QUIC transport layer. This name was made official in the recent draft version 17 (<a href="https://tools.ietf.org/html/draft-ietf-quic-http-17">draft-ietf-quic-http-17</a>), which was proposed in late October 2018, with discussion and rough consensus being formed during the IETF 103 meeting in Bangkok in November. HTTP/3 was previously known as HTTP over QUIC, which itself was previously known as HTTP/2 over QUIC. Before that we had HTTP/2 over gQUIC, and way back we had SPDY over gQUIC. The fact of the matter, however, is that HTTP/3 is just a new HTTP syntax that works on IETF QUIC, a UDP-based multiplexed and secure transport.</p><p>In this blog post we'll explore the history behind some of HTTP/3's previous names and present the motivation behind the most recent name change. We'll go back to the early days of HTTP and touch on all the good work that has happened along the way. If you're keen to get the full picture you can jump to the end of the article or open this <a href="/content/images/2019/01/web_timeline_large1.svg">highly detailed SVG version</a>.</p> <figure class="kg-card kg-image-card "> <Image src="https://cf-assets.www.cloudflare.com/zkvhlag99gkb/1rKByCE0o19Q1zSD9Huliu/7f3540be1ff8f02da311c4df909def42/http3-stack.png" alt="" class="kg-image" width="1028" height="787" loading="lazy"/> </figure><p>An HTTP/3 layer cake</p> <div class="flex anchor relative"> <h2 id="setting-the-scene">Setting the scene</h2> <a href="#setting-the-scene" aria-hidden="true" class="relative sm:absolute sm:-left-5"> <svg width="16" height="16" viewBox="0 0 24 24"><path fill="currentcolor" d="m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z"></path></svg> </a> </div> <p>Just before we focus on HTTP, it is worth reminding ourselves that there are two protocols that share the name QUIC. As we explained <a href="/the-road-to-quic/">previously</a>, gQUIC is commonly used to identify Google QUIC (the original protocol), and QUIC is commonly used to represent the IETF standard-in-progress version that diverges from gQUIC.</p><p>Since its early days in the 90s, the web’s needs have changed. We've had new versions of HTTP and added user security in the shape of Transport Layer Security (TLS). We'll only touch on TLS in this post, our other <a href="/tag/tls/">blog posts</a> are a great resource if you want to explore that area in more detail.</p><p>To help me explain the history of HTTP and TLS, I started to collate details of protocol specifications and dates. This information is usually presented in a textual form such as a list of bullets points stating document titles, ordered by date. However, there are branching standards, each overlapping in time and a simple list cannot express the real complexity of relationships. In HTTP, there has been parallel work that refactors core protocol definitions for easier consumption, extends the protocol for new uses, and redefines how the protocol exchanges data over the Internet for performance. When you're trying to join the dots over nearly 30 years of Internet history across different branching work streams you need a visualisation. So I made one - the Cloudflare Secure Web Timeline. (NB: Technically it is a <a href="https://en.wikipedia.org/wiki/Cladogram">Cladogram</a>, but the term timeline is more widely known).</p><p>I have applied some artistic license when creating this, choosing to focus on the successful branches in the IETF space. Some of the things not shown include efforts in the W3 Consortium <a href="https://www.w3.org/Protocols/HTTP-NG/">HTTP-NG</a> working group, along with some exotic ideas that their authors are keen on explaining how to pronounce: <a href="https://blog.jgc.org/2012/12/speeding-up-http-with-minimal-protocol.html">HMURR (pronounced 'hammer')</a> and <a href="https://github.com/HTTPWorkshop/workshop2017/blob/master/talks/waka.pdf">WAKA (pronounced “wah-kah”)</a>.</p><p>In the next few sections I'll walk this timeline to explain critical chapters in the history of HTTP. To enjoy the takeaways from this post, it helps to have an appreciation of why standardisation is beneficial, and how the IETF approaches it. Therefore we'll start with a very brief overview of that topic before returning to the timeline itself. Feel free to skip the next section if you are already familiar with the IETF.</p> <div class="flex anchor relative"> <h2 id="types-of-internet-standard">Types of Internet standard</h2> <a href="#types-of-internet-standard" aria-hidden="true" class="relative sm:absolute sm:-left-5"> <svg width="16" height="16" viewBox="0 0 24 24"><path fill="currentcolor" d="m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z"></path></svg> </a> </div> <p>Generally, standards define common terms of reference, scope, constraint, applicability, and other considerations. Standards exist in many shapes and sizes, and can be informal (aka de facto) or formal (agreed/published by a Standards Defining Organisation such as IETF, ISO or MPEG). Standards are used in many fields, there is even a formal British Standard for making tea - BS 6008.</p><p>The early Web used HTTP and SSL protocol definitions that were published outside the IETF, these are marked as <b>red lines</b> on the Secure Web Timeline. The uptake of these protocols by clients and servers made them de facto standards.</p><p>At some point, it was decided to formalise these protocols (some motivating reasons are described in a later section). Internet standards are commonly defined in the IETF, which is guided by the informal principle of "rough consensus and running code". This is grounded in experience of developing and deploying things on the Internet. This is in contrast to a "clean room" approach of trying to develop perfect protocols in a vacuum.</p><p>IETF Internet standards are commonly known as RFCs. This is a complex area to explain so I recommend reading the blog post "<a href="https://www.ietf.org/blog/how-read-rfc/">How to Read an RFC</a>" by the QUIC Working Group Co-chair Mark Nottingham. A Working Group, or WG, is more or less just a mailing list.</p><p>Each year the IETF hold three meetings that provide the time and facilities for all WGs to meet in person if they wish. The agenda for these weeks can become very congested, with limited time available to discuss highly technical areas in depth. To overcome this, some WGs choose to also hold interim meetings in the months between the the general IETF meetings. This can help to maintain momentum on specification development. The QUIC WG has held several interim meetings since 2017, a full list is available on their <a href="https://datatracker.ietf.org/wg/quic/meetings/">meeting page</a>.</p><p>These IETF meetings also provide the opportunity for other IETF-related collections of people to meet, such as the <a href="https://www.iab.org/">Internet Architecture Board</a> or <a href="https://irtf.org/">Internet Research Task Force</a>. In recent years, an <a href="https://www.ietf.org/how/runningcode/hackathons/">IETF Hackathon</a> has been held during the weekend preceding the IETF meeting. This provides an opportunity for the community to develop running code and, importantly, to carry out interoperability testing in the same room with others. This helps to find issues in specifications that can be discussed in the following days.</p><p>For the purposes of this blog, the important thing to understand is that RFCs don't just spring into existence. Instead, they go through a process that usually starts with an IETF Internet Draft (I-D) format that is submitted for consideration of adoption. In the case where there is already a published specification, preparation of an I-D might just be a simple reformatting exercise. I-Ds have a 6 month active lifetime from the date of publish. To keep them active, new versions need to be published. In practice, there is not much consequence to letting an I-D elapse and it happens quite often. The documents continue to be hosted on the <a href="https://datatracker.ietf.org/doc/recent">IETF document’s website</a> for anyone that wants to read them.</p><p>I-Ds are represented on the Secure Web Timeline as <b>purple lines</b>. Each one has a unique name that takes the form of <i>draft-{author name}-{working group}-{topic}-{version}</i>. The working group field is optional, it might predict IETF WG that will work on the piece and sometimes this changes. If an I-D is adopted by the IETF, or if the I-D was initiated directly within the IETF, the name is <i>draft-ietf-{working group}-{topic}-{version}</i>. I-Ds may branch, merge or die on the vine. The version starts at 00 and increases by 1 each time a new draft is released. For example, the 4th draft of an I-D will have the version 03. Any time that an I-D changes name, its version resets back to 00.</p><p>It is important to note that anyone can submit an I-D to the IETF; you should not consider these as standards. But, if the IETF standardisation process of an I-D does reach consensus, and the final document passes review, we finally get an RFC. The name changes again at this stage. Each RFC gets a unique number e.g. <a href="https://tools.ietf.org/html/rfc7230">RFC 7230</a>. These are represented as <b>blue lines</b> on the Secure Web Timeline.</p><p>RFCs are immutable documents. This means that changes to the RFC require a completely new number. Changes might be done in order to incorporate fixes for errata (editorial or technical errors that were found and reported) or simply to refactor the specification to improve layout. RFCs may <b>obsolete</b> older versions (complete replacement), or just <b>update</b> them (substantively change).</p><p>All IETF documents are openly available on <a href="http://tools.ietf.org">http://tools.ietf.org</a>. Personally I find the <a href="https://datatracker.ietf.org">IETF Datatracker</a> a little more user friendly because it provides a visualisation of a documents progress from I-D to RFC.</p><p>Below is an example that shows the development of <a href="https://tools.ietf.org/html/rfc1945">RFC 1945</a> - HTTP/1.0 and it is a clear source of inspiration for the Secure Web Timeline.</p> <figure class="kg-card kg-image-card "> <Image src="https://cf-assets.www.cloudflare.com/zkvhlag99gkb/5SlEeIaoaU7r9PkklUSIOj/c24f0ba70885244920a29bea1daffd68/RFC-1945-datatracker.png" alt="" class="kg-image" width="522" height="197" loading="lazy"/> </figure><p>IETF Datatracker view of RFC 1945</p><p>Interestingly, in the course of my work I found that the above visualisation is incorrect. It is missing <a href="https://tools.ietf.org/html/draft-ietf-http-v10-spec-05">draft-ietf-http-v10-spec-05</a> for some reason. Since the I-D lifetime is 6 months, there appears to be a gap before it became an RFC, whereas in reality draft 05 was still active through until August 1996.</p> <div class="flex anchor relative"> <h2 id="exploring-the-secure-web-timeline">Exploring the Secure Web Timeline</h2> <a href="#exploring-the-secure-web-timeline" aria-hidden="true" class="relative sm:absolute sm:-left-5"> <svg width="16" height="16" viewBox="0 0 24 24"><path fill="currentcolor" d="m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z"></path></svg> </a> </div> <p>With a small appreciation of how Internet standards documents come to fruition, we can start to walk the the Secure Web Timeline. In this section are a number of excerpt diagrams that show an important part of the timeline. Each dot represents the date that a document or capability was made available. For IETF documents, draft numbers are omitted for clarity. However, if you want to see all that detail please check out the <a href="/content/images/2019/01/web_timeline_large1.svg">complete timeline</a>.</p><p>HTTP began life as the so-called HTTP/0.9 protocol in 1991, and in 1994 the I-D <a href="https://tools.ietf.org/html/draft-fielding-http-spec-00">draft-fielding-http-spec-00</a> was published. This was adopted by the IETF soon after, causing the name change to <a href="https://tools.ietf.org/html/draft-ietf-http-v10-spec-00">draft-ietf-http-v10-spec-00</a>. The I-D went through 6 draft versions before being published as <a href="https://tools.ietf.org/html/rfc1945">RFC 1945</a> - HTTP/1.0 in 1996.</p> <figure class="kg-card kg-image-card "> <Image src="https://cf-assets.www.cloudflare.com/zkvhlag99gkb/6fSsHSEtXc1HA38jJorxhO/d1a86966735f27d3b2ccfbcc1c8ec38d/http11-standardisation.png" alt="" class="kg-image" width="504" height="317" loading="lazy"/> </figure><p>However, even before the HTTP/1.0 work completed, a separate activity started on HTTP/1.1. The I-D <a href="https://tools.ietf.org/html/draft-ietf-http-v11-spec-00">draft-ietf-http-v11-spec-00</a> was published in November 1995 and was formally published as <a href="https://tools.ietf.org/html/rfc2068">RFC 2068</a> in 1997. The keen eyed will spot that the Secure Web Timeline doesn't quite capture that sequence of events, this is an unfortunate side effect of the tooling used to generate the visualisation. I tried to minimise such problems where possible.</p><p>An HTTP/1.1 revision exercise was started in mid-1997 in the form of <a href="https://tools.ietf.org/html/draft-ietf-http-v11-spec-rev-00">draft-ietf-http-v11-spec-rev-00</a>. This completed in 1999 with the publication of <a href="https://tools.ietf.org/html/rfc2616">RFC 2616</a>. Things went quiet in the IETF HTTP world until 2007. We'll come back to that shortly.</p> <div class="flex anchor relative"> <h2 id="a-history-of-ssl-and-tls">A History of SSL and TLS</h2> <a href="#a-history-of-ssl-and-tls" aria-hidden="true" class="relative sm:absolute sm:-left-5"> <svg width="16" height="16" viewBox="0 0 24 24"><path fill="currentcolor" d="m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z"></path></svg> </a> </div> <figure class="kg-card kg-image-card "> <Image src="https://cf-assets.www.cloudflare.com/zkvhlag99gkb/6pnAQiXiXCFpQpSkznYI1T/80a5516f4dafa64d1a5b60733b14c913/ssl-tls-standardisation.png" alt="" class="kg-image" width="1215" height="420" loading="lazy"/> </figure><p>Switching tracks to SSL. We see that the SSL 2.0 specification was released sometime around 1995, and that SSL 3.0 was released in November 1996. Interestingly, SSL 3.0 is described by <a href="https://tools.ietf.org/html/rfc6101">RFC 6101</a>, which was released in August 2011. This sits in <b>Historic</b> category, which "is usually done to document ideas that were considered and discarded, or protocols that were already historic when it was decided to document them." according to the <a href="https://www.ietf.org/blog/iesg-statement-designating-rfcs-historic/?primary_topic=7&">IETF</a>. In this case it is advantageous to have an IETF-owned document that describes SSL 3.0 because it can be used as a canonical reference elsewhere.</p><p>Of more interest to us is how SSL inspired the development of TLS, which began life as <a href="https://tools.ietf.org/html/draft-ietf-tls-protocol-00">draft-ietf-tls-protocol-00</a> in November 1996. This went through 6 draft versions and was published as <a href="https://tools.ietf.org/html/rfc2246">RFC 2246</a> - TLS 1.0 at the start of 1999.</p><p>Between 1995 and 1999, the SSL and TLS protocols were used to secure HTTP communications on the Internet. This worked just fine as a de facto standard. It wasn't until January 1998 that the formal standardisation process for HTTPS was started with the publication of I-D <a href="https://tools.ietf.org/html/draft-ietf-tls-https-00">draft-ietf-tls-https-00</a>. That work concluded in May 2000 with the publication of <a href="https://tools.ietf.org/html/rfc2616">RFC 2616</a> - HTTP over TLS.</p><p>TLS continued to evolve between 2000 and 2007, with the standardisation of TLS 1.1 and 1.2. There was a gap of 7 years until work began on the next version of TLS, which was adopted as <a href="https://tools.ietf.org/html/draft-ietf-tls-tls13-00">draft-ietf-tls-tls13-00</a> in April 2014 and, after 28 drafts, completed as <a href="https://tools.ietf.org/html/rfc8446">RFC 8446</a> - TLS 1.3 in August 2018.</p> <div class="flex anchor relative"> <h2 id="internet-standardisation-process">Internet standardisation process</h2> <a href="#internet-standardisation-process" aria-hidden="true" class="relative sm:absolute sm:-left-5"> <svg width="16" height="16" viewBox="0 0 24 24"><path fill="currentcolor" d="m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z"></path></svg> </a> </div> <p>After taking a small look at the timeline, I hope you can build a sense of how the IETF works. One generalisation for the way that Internet standards take shape is that researchers or engineers design experimental protocols that suit their specific use case. They experiment with protocols, in public or private, at various levels of scale. The data helps to identify improvements or issues. The work may be published to explain the experiment, to gather wider input or to help find other implementers. Take up of this early work by others may make it a de facto standard; eventually there may be sufficient momentum that formal standardisation becomes an option.</p><p>The status of a protocol can be an important consideration for organisations that may be thinking about implementing, deploying or in some way using it. A formal standardisation process can make a de facto standard more attractive because it tends to provide stability. The stewardship and guidance is provided by an organisation, such as the IETF, that reflects a wider range of experiences. However, it is worth highlighting that not all all formal standards succeed.</p><p>The process of creating a final standard is almost as important as the standard itself. Taking an initial idea and inviting contribution from people with wider knowledge, experience and use cases can to help produce something that will be of more use to a wider population. However, the standardisation process is not always easy. There are pitfalls and hurdles. Sometimes the process takes so long that the output is no longer relevant.</p><p>Each Standards Defining Organisation tends to have its own process that is geared around its field and participants. Explaining all of the details about how the IETF works is well beyond the scope of this blog. The IETF's "<a href="https://www.ietf.org/how/">How we work</a>" page is an excellent starting point that covers many aspects. The best method to forming understanding, as usual, is to get involved yourself. This can be as easy as joining an email list or adding to discussion on a relevant GitHub repository.</p> <div class="flex anchor relative"> <h2 id="cloudflares-running-code">Cloudflare's running code</h2> <a href="#cloudflares-running-code" aria-hidden="true" class="relative sm:absolute sm:-left-5"> <svg width="16" height="16" viewBox="0 0 24 24"><path fill="currentcolor" d="m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z"></path></svg> </a> </div> <p>Cloudflare is proud to be early an adopter of new and evolving protocols. We have a long record of adopting new standards early, such as <a href="/introducing-http2/">HTTP/2</a>. We also test features that are experimental or yet to be final, like <a href="/introducing-tls-1-3/">TLS 1.3</a> and <a href="/introducing-spdy/">SPDY</a>.</p><p>In relation to the IETF standardisation process, deploying this running code on real networks across a diverse body of websites helps us understand how well the protocol will work in practice. We combine our existing expertise with experimental information to help improve the running code and, where it makes sense, feedback issues or improvements to the WG that is standardising a protocol.</p><p>Testing new things is not the only priority. Part of being an innovator is knowing when it is time to move forward and put older innovations in the rear view mirror. Sometimes this relates to security-oriented protocols, for example, Cloudflare <a href="/sslv3-support-disabled-by-default-due-to-vulnerability/">disabled SSLv3 by default</a> due of the POODLE vulnerability. In other cases, protocols become superseded by a more technologically advanced one; Cloudflare <a href="/deprecating-spdy/">deprecated SPDY</a> support in favour of HTTP/2.</p><p>The introduction and deprecation of relevant protocols are represented on the Secure Web Timeline as <b>orange lines</b>. Dotted vertical lines help correlate Cloudflare events to relevant IETF documents. For example, Cloudflare introduced TLS 1.3 support in September 2016, with the final document, <a href="https://tools.ietf.org/html/rfc8446">RFC 8446</a>, being published almost two years later in August 2018.</p> <figure class="kg-card kg-image-card "> <Image src="https://cf-assets.www.cloudflare.com/zkvhlag99gkb/ptcxVRf8P4wmKMz6uSzAk/4d37f0581a865bc4f120282e7d9d5ebf/cf-events.png" alt="" class="kg-image" width="623" height="463" loading="lazy"/> </figure> <div class="flex anchor relative"> <h2 id="refactoring-in-httpbis">Refactoring in HTTPbis</h2> <a href="#refactoring-in-httpbis" aria-hidden="true" class="relative sm:absolute sm:-left-5"> <svg width="16" height="16" viewBox="0 0 24 24"><path fill="currentcolor" d="m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z"></path></svg> </a> </div> <p>HTTP/1.1 is a very successful protocol and the timeline shows that there wasn't much activity in the IETF after 1999. However, the true reflection is that years of active use gave implementation experience that unearthed latent issues with <a href="https://tools.ietf.org/html/rfc2616">RFC 2616</a>, which caused some interoperability issues. Furthermore, the protocol was extended by other RFCs like 2817 and 2818. It was decided in 2007 to kickstart a new activity to improve the HTTP protocol specification. This was called HTTPbis (where "bis" stems from Latin meaning "two", "twice" or "repeat") and it took the form of a new Working Group. The original <a href="https://tools.ietf.org/wg/httpbis/charters?item=charter-httpbis-2007-10-23.txt">charter</a> does a good job of describing the problems that were trying to be solved.</p><p>In short, HTTPbis decided to refactor <a href="https://tools.ietf.org/html/rfc2616">RFC 2616</a>. It would incorporate errata fixes and buy in some aspects of other specifications that had been published in the meantime. It was decided to split the document up into parts. This resulted in 6 I-Ds published in December 2007:</p><ul><li><p>draft-ietf-httpbis-p1-messaging</p></li><li><p>draft-ietf-httpbis-p2-semantics</p></li><li><p>draft-ietf-httpbis-p4-conditional</p></li><li><p>draft-ietf-httpbis-p5-range</p></li><li><p>draft-ietf-httpbis-p6-cache</p></li><li><p>draft-ietf-httpbis-p7-auth</p></li></ul> <figure class="kg-card kg-image-card "> <Image src="https://cf-assets.www.cloudflare.com/zkvhlag99gkb/5cCDzKbc2DBLJgD1cdLCor/c928470939df5acd6112503c41c78db3/http11-refactor.png" alt="" class="kg-image" width="730" height="531" loading="lazy"/> </figure><p>The diagram shows how this work progressed through a lengthy drafting process of 7 years, with 27 draft versions being released, before final standardisation. In June 2014, the so-called RFC 723x series was released (where x ranges from 0 to 5). The Chair of the HTTPbis WG celebrated this achievement with the acclimation "<a href="https://www.mnot.net/blog/2014/06/07/rfc2616_is_dead">RFC2616 is Dead</a>". If it wasn't clear, these new documents obsoleted the older <a href="https://tools.ietf.org/html/rfc2616">RFC 2616</a>.</p> <div class="flex anchor relative"> <h2 id="what-does-any-of-this-have-to-do-with-http-3">What does any of this have to do with HTTP/3?</h2> <a href="#what-does-any-of-this-have-to-do-with-http-3" aria-hidden="true" class="relative sm:absolute sm:-left-5"> <svg width="16" height="16" viewBox="0 0 24 24"><path fill="currentcolor" d="m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z"></path></svg> </a> </div> <p>While the IETF was busy working on the RFC 723x series the world didn't stop. People continued to enhance, extend and experiment with HTTP on the Internet. Among them were Google, who had started to experiment with something called SPDY (pronounced speedy). This protocol was touted as improving the performance of web browsing, a principle use case for HTTP. At the end of 2009 SPDY v1 was announced, and it was quickly followed by SPDY v2 in 2010.</p><p>I want to avoid going into the technical details of SPDY. That's a topic for another day. What is important, is to understand that SPDY took the core paradigms of HTTP and modified the interchange format slightly in order to gain improvements. With hindsight, we can see that HTTP has clearly delimited semantics and syntax. Semantics describe the concept of request and response exchanges including: methods, status codes, header fields (metadata) and bodies (payload). Syntax describe how to map semantics to bytes on the wire.</p><p>HTTP/0.9, 1.0 and 1.1 share many semantics. They also share syntax in the form of character strings that are sent over TCP connections. SPDY took HTTP/1.1 semantics and changed the syntax from strings to binary. This is a really interesting topic but we will go no further down that rabbit hole today.</p><p>Google's experiments with SPDY showed that there was promise in changing HTTP syntax, and value in keeping the existing HTTP semantics. For example, keeping the format of URLs to use https:// avoided many problems that could have affected adoption.</p><p>Having seen some of the positive outcomes, the IETF decided it was time to consider what HTTP/2.0 might look like. The <a href="https://github.com/httpwg/wg-materials/blob/gh-pages/ietf83/HTTP2.pdf">slides</a> from the HTTPbis session held during IETF 83 in March 2012 show the requirements, goals and measures of success that were set out. It is also clearly states that "HTTP/2.0 only signifies that the wire format isn't compatible with that of HTTP/1.x".</p> <figure class="kg-card kg-image-card "> <Image src="https://cf-assets.www.cloudflare.com/zkvhlag99gkb/3EQMui9QKRGR8Vzcu5wMZA/229e6a1cb1cc1fa78da96dc34f59c220/http2-standardisation.png" alt="" class="kg-image" width="489" height="382" loading="lazy"/> </figure><p>During that meeting the community was invited to share proposals. I-Ds that were submitted for consideration included <a href="https://tools.ietf.org/html/draft-mbelshe-httpbis-spdy-00">draft-mbelshe-httpbis-spdy-00</a>, <a href="https://tools.ietf.org/html/draft-montenegro-httpbis-speed-mobility-00">draft-montenegro-httpbis-speed-mobility-00</a> and <a href="https://tools.ietf.org/html/draft-tarreau-httpbis-network-friendly-00">draft-tarreau-httpbis-network-friendly-00</a>. Ultimately, the SPDY draft was adopted and in November 2012 work began on <a href="https://tools.ietf.org/html/draft-ietf-httpbis-http2-00">draft-ietf-httpbis-http2-00</a>. After 18 drafts across a period of just over 2 years, <a href="https://tools.ietf.org/html/rfc7540">RFC 7540</a> - HTTP/2 was published in 2015. During this specification period, the precise syntax of HTTP/2 diverged just enough to make HTTP/2 and SPDY incompatible.</p><p>These years were a very busy period for the HTTP-related work at the IETF, with the HTTP/1.1 refactor and HTTP/2 standardisation taking place in parallel. This is in stark contrast to the many years of quiet in the early 2000s. Be sure to check out the full timeline to really appreciate the amount of work that took place.</p><p>Although HTTP/2 was in the process of being standardised, there was still benefit to be had from using and experimenting with SPDY. Cloudflare <a href="/spdy-now-one-click-simple-for-any-website/">introduced support for SPDY</a> in August 2012 and only deprecated it in February 2018 when our statistics showed that less than 4% of Web clients continued to want SPDY. Meanwhile, we <a href="/introducing-http2/">introduced HTTP/2</a> support in December 2015, not long after the RFC was published, when our analysis indicated that a meaningful proportion of Web clients could take advantage of it.</p><p>Web client support of the SPDY and HTTP/2 protocols preferred the secure option of using TLS. The introduction of <a href="/introducing-universal-ssl/">Universal SSL</a> in September 2014 helped ensure that all websites signed up to Cloudflare were able to take advantage of these new protocols as we introduced them.</p> <div class="flex anchor relative"> <h3 id="gquic">gQUIC</h3> <a href="#gquic" aria-hidden="true" class="relative sm:absolute sm:-left-5"> <svg width="16" height="16" viewBox="0 0 24 24"><path fill="currentcolor" d="m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z"></path></svg> </a> </div> <p>Google continued to experiment between 2012 and 2015 they released SPDY v3 and v3.1. They also started working on gQUIC (pronounced, at the time, as quick) and the initial public specification was made available in early 2012.</p><p>The early versions of gQUIC made use of the SPDY v3 form of HTTP syntax. This choice made sense because HTTP/2 was not yet finished. The SPDY binary syntax was packaged into QUIC packets that could sent in UDP datagrams. This was a departure from the TCP transport that HTTP traditionally relied on. When stacked up all together this looked like:</p> <figure class="kg-card kg-image-card "> <Image src="https://cf-assets.www.cloudflare.com/zkvhlag99gkb/40oAdMSmePG37lMEb8Odfi/b5cf02bbe9256889bd0cc103a34484a9/gquic-stack.png" alt="" class="kg-image" width="1028" height="753" loading="lazy"/> </figure><p>SPDY over gQUIC layer cake</p><p>gQUIC used clever tricks to achieve performance. One of these was to break the clear layering between application and transport. What this meant in practice was that gQUIC only ever supported HTTP. So much so that gQUIC, termed "QUIC" at the time, was synonymous with being the next candidate version of HTTP. Despite the continued changes to QUIC over the last few years, which we'll touch on momentarily, to this day, the term QUIC is understood by people to mean that initial HTTP-only variant. Unfortunately this is a regular source of confusion when discussing the protocol.</p><p>gQUIC continued to experiment and eventually switched over to a syntax much closer to HTTP/2. So close in fact that most people simply called it "HTTP/2 over QUIC". However, because of technical constraints there were some very subtle differences. One example relates to how the HTTP headers were serialized and exchanged. It is a minor difference but in effect means that HTTP/2 over gQUIC was incompatible with the IETF's HTTP/2.</p><p>Last but not least, we always need to consider the security aspects of Internet protocols. gQUIC opted not to use TLS to provide security. Instead Google developed a different approach called QUIC Crypto. One of the interesting aspects of this was a new method for speeding up security handshakes. A client that had previously established a secure session with a server could reuse information to do a "zero <a href="https://www.cloudflare.com/learning/cdn/glossary/round-trip-time-rtt/">round-trip time</a>", or 0-RTT, handshake. 0-RTT was later incorporated into TLS 1.3.</p> <div class="flex anchor relative"> <h2 id="are-we-at-the-point-where-you-can-tell-me-what-http-3-is-yet">Are we at the point where you can tell me what HTTP/3 is yet?</h2> <a href="#are-we-at-the-point-where-you-can-tell-me-what-http-3-is-yet" aria-hidden="true" class="relative sm:absolute sm:-left-5"> <svg width="16" height="16" viewBox="0 0 24 24"><path fill="currentcolor" d="m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z"></path></svg> </a> </div> <p>Almost.</p><p>By now you should be familiar with how standardisation works and gQUIC is not much different. There was sufficient interest that the Google specifications were written up in I-D format. In June 2015 <a href="https://tools.ietf.org/html/draft-tsvwg-quic-protocol-00">draft-tsvwg-quic-protocol-00</a>, entitled "QUIC: A UDP-based Secure and Reliable Transport for HTTP/2" was submitted. Keep in mind my earlier statement that the syntax was almost-HTTP/2.</p><p>Google <a href="https://groups.google.com/a/chromium.org/forum/#!topic/proto-quic/otGKB4ytAyc">announced</a> that a Bar BoF would be held at IETF 93 in Prague. For those curious about what a "Bar BoF" is, please consult <a href="https://tools.ietf.org/html/rfc6771">RFC 6771</a>. Hint: BoF stands for Birds of a Feather.</p> <figure class="kg-card kg-image-card "> <Image src="https://cf-assets.www.cloudflare.com/zkvhlag99gkb/364tlrFLOtgAYBYxHrOXy8/18f5cebace8c29778e06109fe878c3b8/quic-standardisation.png" alt="" class="kg-image" width="560" height="515" loading="lazy"/> </figure><p>The outcome of this engagement with the IETF was, in a nutshell, that QUIC seemed to offer many advantages at the transport layer and that it should be decoupled from HTTP. The clear separation between layers should be re-introduced. Furthermore, there was a preference for returning back to a TLS-based handshake (which wasn't so bad since TLS 1.3 was underway at this stage, and it was incorporating 0-RTT handshakes).</p><p>About a year later, in 2016, a new set of I-Ds were submitted:</p><ul><li><p><a href="https://tools.ietf.org/html/draft-hamilton-quic-transport-protocol-00">draft-hamilton-quic-transport-protocol-00</a></p></li><li><p><a href="https://tools.ietf.org/html/draft-thomson-quic-tls-00">draft-thomson-quic-tls-00</a></p></li><li><p><a href="https://tools.ietf.org/html/draft-iyengar-quic-loss-recovery-00">draft-iyengar-quic-loss-recovery-00</a></p></li><li><p><a href="https://tools.ietf.org/html/draft-shade-quic-http2-mapping-00">draft-shade-quic-http2-mapping-00</a></p></li></ul><p>Here's where another source of confusion about HTTP and QUIC enters the fray. <a href="https://tools.ietf.org/html/draft-shade-quic-http2-mapping-00">draft-shade-quic-http2-mapping-00</a> is entitled "HTTP/2 Semantics Using The QUIC Transport Protocol" and it describes itself as "a mapping of HTTP/2 semantics over QUIC". However, this is a misnomer. HTTP/2 was about changing syntax while maintaining semantics. Furthermore, "HTTP/2 over gQUIC" was never an accurate description of the syntax either, for the reasons I outlined earlier. Hold that thought.</p><p>This IETF version of QUIC was to be an entirely new transport protocol. That's a large undertaking and before diving head-first into such commitments, the IETF likes to gauge actual interest from its members. To do this, a formal <a href="https://www.ietf.org/how/bofs/">Birds of a Feather</a> meeting was held at the IETF 96 meeting in Berlin in 2016. I was lucky enough to attend the session in person and the <a href="https://datatracker.ietf.org/meeting/96/materials/slides-96-quic-0">slides</a> don't give it justice. The meeting was attended by hundreds, as shown by Adam Roach's <a href="https://www.flickr.com/photos/adam-roach/28343796722/in/photostream/">photograph</a>. At the end of the session consensus was reached; QUIC would be adopted and standardised at the IETF.</p><p>The first IETF QUIC I-D for mapping HTTP to QUIC, <a href="https://tools.ietf.org/html/draft-ietf-quic-http-00">draft-ietf-quic-http-00</a>, took the Ronseal approach and simplified its name to "HTTP over QUIC". Unfortunately, it didn't finish the job completely and there were many instances of the term HTTP/2 throughout the body. Mike Bishop, the I-Ds new editor, identified this and started to fix the HTTP/2 misnomer. In the 01 draft, the description changed to "a mapping of HTTP semantics over QUIC".</p><p>Gradually, over time and versions, the use of the term "HTTP/2" decreased and the instances became mere references to parts of <a href="https://tools.ietf.org/html/rfc7540">RFC 7540</a>. Roll forward two years to October 2018 and the I-D is now at version 16. While HTTP over QUIC bares similarity to HTTP/2 it ultimately is an independent, non-backwards compatible HTTP syntax. However, to those that don't track IETF development very closely (a very very large percentage of the Earth's population), the document name doesn't capture this difference. One of the main points of standardisation is to aid communication and interoperability. Yet a simple thing like naming is a major contributor to confusion in the community.</p><p>Recall what was said in 2012, "HTTP/2.0 only signifies that the wire format isn't compatible with that of HTTP/1.x". The IETF followed that existing cue. After much deliberation in the lead up to, and during, IETF 103, consensus was reached to rename "HTTP over QUIC" to HTTP/3. The world is now in a better place and we can move on to more important debates.</p> <div class="flex anchor relative"> <h2 id="but-rfc-7230-and-7231-disagree-with-your-definition-of-semantics-and-syntax">But RFC 7230 and 7231 disagree with your definition of semantics and syntax!</h2> <a href="#but-rfc-7230-and-7231-disagree-with-your-definition-of-semantics-and-syntax" aria-hidden="true" class="relative sm:absolute sm:-left-5"> <svg width="16" height="16" viewBox="0 0 24 24"><path fill="currentcolor" d="m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z"></path></svg> </a> </div> <p>Sometimes document titles can be confusing. The present HTTP documents that describe syntax and semantics are:</p><ul><li><p><a href="https://tools.ietf.org/html/rfc7230">RFC 7230</a> - Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</p></li><li><p><a href="https://tools.ietf.org/html/rfc7231">RFC 7231</a> - Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</p></li></ul><p>It is possible to read too much into these names and believe that fundamental HTTP semantics are specific for versions of HTTP i.e. HTTP/1.1. However, this is an unintended side effect of the HTTP family tree. The good news is that the HTTPbis Working Group are trying to address this. Some brave members are going through another round of document revision, as Roy Fielding put it, "one more time!". This work is underway right now and is known as the HTTP Core activity (you may also have heard of this under the moniker HTTPtre or HTTPter; naming things is hard). This will condense the six drafts down to three:</p><ul><li><p>HTTP Semantics (draft-ietf-httpbis-semantics)</p></li><li><p>HTTP Caching (draft-ietf-httpbis-caching)</p></li><li><p>HTTP/1.1 Message Syntax and Routing (draft-ietf-httpbis-messaging)</p></li></ul><p>Under this new structure, it becomes more evident that HTTP/2 and HTTP/3 are syntax definitions for the common HTTP semantics. This doesn't mean they don't have their own features beyond syntax but it should help frame discussion going forward.</p> <div class="flex anchor relative"> <h2 id="pulling-it-all-together">Pulling it all together</h2> <a href="#pulling-it-all-together" aria-hidden="true" class="relative sm:absolute sm:-left-5"> <svg width="16" height="16" viewBox="0 0 24 24"><path fill="currentcolor" d="m12.11 15.39-3.88 3.88a2.52 2.52 0 0 1-3.5 0 2.47 2.47 0 0 1 0-3.5l3.88-3.88a1 1 0 0 0-1.42-1.42l-3.88 3.89a4.48 4.48 0 0 0 6.33 6.33l3.89-3.88a1 1 0 1 0-1.42-1.42Zm8.58-12.08a4.49 4.49 0 0 0-6.33 0l-3.89 3.88a1 1 0 0 0 1.42 1.42l3.88-3.88a2.52 2.52 0 0 1 3.5 0 2.47 2.47 0 0 1 0 3.5l-3.88 3.88a1 1 0 1 0 1.42 1.42l3.88-3.89a4.49 4.49 0 0 0 0-6.33ZM8.83 15.17a1 1 0 0 0 1.1.22 1 1 0 0 0 .32-.22l4.92-4.92a1 1 0 0 0-1.42-1.42l-4.92 4.92a1 1 0 0 0 0 1.42Z"></path></svg> </a> </div> <p>This blog post has taken a shallow look at the standardisation process for HTTP in the IETF across the last three decades. Without touching on many technical details, I've tried to explain how we have ended up with HTTP/3 today. If you skipped the good bits in the middle and are looking for a one liner here it is: HTTP/3 is just a new HTTP syntax that works on IETF QUIC, a UDP-based multiplexed and secure transport. There are many interesting technical areas to explore further but that will have to wait for another day.</p><p>In the course of this post, we explored important chapters in the development of HTTP and TLS but did so in isolation. We close out the blog by pulling them all together into the complete Secure Web Timeline presented below. You can use this to investigate the detailed history at your own comfort. And for the super sleuths, be sure to check out the <a href="/content/images/2019/01/web_timeline_large1.svg">full version including draft numbers</a>.</p> <figure class="kg-card kg-image-card "> <Image src="https://cf-assets.www.cloudflare.com/zkvhlag99gkb/3eL8vJkYylVmR4T5Aa1Zdf/2f2929308ee42e450917639874835c1d/cf-secure-web-timeline-1.png" alt="" class="kg-image" width="1303" height="2444" loading="lazy"/> </figure></div></section><section class="post-full-content flex flex-row flex-wrap mw7 center mb4"><div class="post-content lh-copy w-100 gray1 bt b--gray8 pt4">Cloudflare's connectivity cloud protects <a target='_blank' href='https://www.cloudflare.com/network-services/' rel='noreferrer'>entire corporate networks</a>, helps customers build <a target='_blank' href='https://workers.cloudflare.com/' rel='noreferrer'>Internet-scale applications efficiently</a>, accelerates any <a target='_blank' href='https://www.cloudflare.com/performance/accelerate-internet-applications/' rel='noreferrer'>website or Internet application</a>, <a target='_blank' href='https://www.cloudflare.com/ddos/' rel='noreferrer'>wards off DDoS attacks</a>, keeps <a target='_blank' href='https://www.cloudflare.com/application-security/' rel='noreferrer'>hackers at bay</a>, and can help you on <a target='_blank' href='https://www.cloudflare.com/products/zero-trust/' rel='noreferrer'>your journey to Zero Trust</a>.<br/><br/>Visit <a target='_blank' href='https://one.one.one.one/' rel='noreferrer'>1.1.1.1</a> from any device to get started with our free app that makes your Internet faster and safer.<br/><br/>To learn more about our mission to help build a better Internet, <a target='_blank' href='https://www.cloudflare.com/learning/what-is-cloudflare/' rel='noreferrer'>start here</a>. If you're looking for a new career direction, check out <a target='_blank' href="https://www.cloudflare.com/careers" rel='noreferrer'>our open positions</a>.</div></section><div class="pv2 ph0-l mw7 center" id="social-buttons"><div class="mt5-l mt2 mb4 f2 flex flex-row-ns flex-column flex-wrap"><a id="social-button-hn" title="Discuss on Hacker News" href="https://news.ycombinator.com/submitlink?u=https://blog.cloudflare.com/http-3-from-root-to-tip" target="_blank" rel="noreferrer" class="mr2-ns mb0-l white link b pv3 ph3 mb3 " style="background-color:#0055DC"><svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" x="0px" y="0px" viewBox="0 0 512 512" class="mr2"><g><path d="M31,31v450h450V31H31z M270.1,287.6v94.9h-28.1v-94.9L165,143.5h31.9L256,254.3l59.1-110.8H347 C347,143.5,270.1,287.6,270.1,287.6z"></path></g></svg><span class="v-mid">Discuss on Hacker News</span></a></div></div><iframe sandbox="allow-scripts allow-popups" title="cloudflare-tv-live-link" id="cloudflare-tv-embed" src="https://cloudflare.tv/embed/live.html" loading="lazy"></iframe><a href="/tag/quic" class="dib pl2 pr2 pt1 pb1 mb2 bg-gray8 no-underline blue3 f2 mr1">QUIC</a><a href="/tag/tls" class="dib pl2 pr2 pt1 pb1 mb2 bg-gray8 no-underline blue3 f2 mr1">TLS</a><a href="/tag/security" class="dib pl2 pr2 pt1 pb1 mb2 bg-gray8 no-underline blue3 f2 mr1">Security</a><a href="/tag/http3" class="dib pl2 pr2 pt1 pb1 mb2 bg-gray8 no-underline blue3 f2 mr1">HTTP3</a><a href="/tag/ietf" class="dib pl2 pr2 pt1 pb1 mb2 bg-gray8 no-underline blue3 f2 mr1">IETF</a></article></main><div class="ph3 pv3"><div class=" flex flex-row flex-wrap mw7 center"><div class="w-100 bt b--gray8"><p class="black fw5 f4 mt4">Follow on X</p></div><div class="w-100 pb2"><span>Lucas Pardue</span><span class="ph1">|</span><a href="https://x.com/@SimmerVigor" class="no-underline">@SimmerVigor</a></div><div class="w-100 pb2"><span>Cloudflare</span><span class="ph2">|</span><a href="https://x.com/@cloudflare" class="no-underline">@cloudflare</a></div></div></div><div data-testid="related-posts-section" class="pv4 ph3 ph0-l flex flex-row flex-wrap mw7 center"><div class="w-100 bt b--gray8"><p class="orange fw5 f4 mt4 ttu">Related posts</p></div><article data-testid="related-posts-article" class="w-100 w-100-m w-50-l ph3 mb4"><p data-testid="related-posts-article-date" class="f3 fw5 gray5" data-iso-date="2024-11-14T14:00+00:00">November 14, 2024 2:00 PM</p><a data-testid="related-posts-article-title" href="/account-owned-tokens-automated-actions-zaraz" class="no-underline gray1 f4 fw5"><h2 class="gray1 f4 fw5 mt2">What’s new in Cloudflare: Account Owned Tokens and Zaraz Automated Actions</h2></a><p data-testid="related-posts-article-excerpt" class="gray1 lh-copy">Cloudflare customers can now create Account Owned Tokens , allowing more flexibility around access control for their Cloudflare services. Additionally, Zaraz Automation Actions streamlines event tracking and third-party tool integration. ...</p><ul class="flex pl0 fw6 f2 mb3 flex flex-wrap"><span>By </span><li class="list flex items-center" style="white-space:nowrap"><div class="author-name-tooltip"><a href="/author/joseph" class="fw5 f2 black no-underline">Joseph So</a><span class="fw5 f2 black no-underline">, </span></div></li><li class="list flex items-center" style="white-space:nowrap"><div class="author-name-tooltip"><a href="/author/omar-mohammad" class="fw5 f2 black no-underline">Omar Mohammad</a><span class="fw5 f2 black no-underline">, </span></div></li><li class="list flex items-center" style="white-space:nowrap"><div class="author-name-tooltip"><a href="/author/yoav" class="fw5 f2 black no-underline">Yo'av Moshe</a></div></li></ul><div data-testid="related-posts-article-tags" class="flex flex-row flex-wrap"><span><a href="/tag/identity" class="no-underline f1 fw2 blue3 underline-hover">Identity,</a> </span><span><a href="/tag/security" class="no-underline f1 fw2 blue3 underline-hover">Security,</a> </span><span><a href="/tag/developers" class="no-underline f1 fw2 blue3 underline-hover">Developers,</a> </span><span><a href="/tag/product-news" class="no-underline f1 fw2 blue3 underline-hover">Product News,</a> </span><span><a href="/tag/zaraz" class="no-underline f1 fw2 blue3 underline-hover">Zaraz,</a> </span><span><a href="/tag/analytics" class="no-underline f1 fw2 blue3 underline-hover">Analytics,</a> </span><span><a href="/tag/managed-components" class="no-underline f1 fw2 blue3 underline-hover">Managed Components</a> </span></div></article><article data-testid="related-posts-article" class="w-100 w-100-m w-50-l ph3 mb4"><p data-testid="related-posts-article-date" class="f3 fw5 gray5" data-iso-date="2024-11-07T14:00+00:00">November 07, 2024 2:00 PM</p><a data-testid="related-posts-article-title" href="/another-look-at-pq-signatures" class="no-underline gray1 f4 fw5"><h2 class="gray1 f4 fw5 mt2">A look at the latest post-quantum signature standardization candidates</h2></a><p data-testid="related-posts-article-excerpt" class="gray1 lh-copy">NIST has standardized four post-quantum signature schemes so far, and they’re not done yet: there are fourteen new candidates in the running for standardization. In this blog post we take measure of them and discover why we ended up with so many PQ signatures....</p><ul class="flex pl0 fw6 f2 mb3 flex flex-wrap"><span>By </span><li class="list flex items-center" style="white-space:nowrap"><div class="author-name-tooltip"><a href="/author/bas" class="fw5 f2 black no-underline">Bas Westerbaan</a><span class="fw5 f2 black no-underline">, </span></div></li><li class="list flex items-center" style="white-space:nowrap"><div class="author-name-tooltip"><a href="/author/luke" class="fw5 f2 black no-underline">Luke Valenta</a></div></li></ul><div data-testid="related-posts-article-tags" class="flex flex-row flex-wrap"><span><a href="/tag/post-quantum" class="no-underline f1 fw2 blue3 underline-hover">Post-Quantum,</a> </span><span><a href="/tag/research" class="no-underline f1 fw2 blue3 underline-hover">Research,</a> </span><span><a href="/tag/cryptography" class="no-underline f1 fw2 blue3 underline-hover">Cryptography,</a> </span><span><a href="/tag/tls" class="no-underline f1 fw2 blue3 underline-hover">TLS</a> </span></div></article><article data-testid="related-posts-article" class="w-100 w-100-m w-50-l ph3 mb4"><p data-testid="related-posts-article-date" class="f3 fw5 gray5" data-iso-date="2024-10-08T06:00-07:00">October 08, 2024 1:00 PM</p><a data-testid="related-posts-article-title" href="/cloudflare-acquires-kivera" class="no-underline gray1 f4 fw5"><h2 class="gray1 f4 fw5 mt2">Cloudflare acquires Kivera to add simple, preventive cloud security to Cloudflare One </h2></a><p data-testid="related-posts-article-excerpt" class="gray1 lh-copy">The acquisition and integration of Kivera broadens the scope of Cloudflare’s SASE platform beyond just apps, incorporating increased cloud security through proactive configuration management of cloud services. ...</p><ul class="flex pl0 fw6 f2 mb3 flex flex-wrap"><span>By </span><li class="list flex items-center" style="white-space:nowrap"><div class="author-name-tooltip"><a href="/author/noelle" class="fw5 f2 black no-underline">Noelle Kagan</a><span class="fw5 f2 black no-underline">, </span></div></li><li class="list flex items-center" style="white-space:nowrap"><div class="author-name-tooltip"><a href="/author/neil-brown" class="fw5 f2 black no-underline">Neil Brown</a><span class="fw5 f2 black no-underline">, </span></div></li><li class="list flex items-center" style="white-space:nowrap"><div class="author-name-tooltip"><a href="/author/yumna" class="fw5 f2 black no-underline">Yumna Moazzam</a></div></li></ul><div data-testid="related-posts-article-tags" class="flex flex-row flex-wrap"><span><a href="/tag/data-protection" class="no-underline f1 fw2 blue3 underline-hover">Data Protection,</a> </span><span><a href="/tag/acquisitions" class="no-underline f1 fw2 blue3 underline-hover">Acquisitions,</a> </span><span><a href="/tag/email-security" class="no-underline f1 fw2 blue3 underline-hover">Email Security,</a> </span><span><a href="/tag/cloud-email-security" class="no-underline f1 fw2 blue3 underline-hover">Cloud Email Security,</a> </span><span><a href="/tag/sase" class="no-underline f1 fw2 blue3 underline-hover">SASE,</a> </span><span><a href="/tag/zero-trust" class="no-underline f1 fw2 blue3 underline-hover">Zero Trust,</a> </span><span><a href="/tag/security" class="no-underline f1 fw2 blue3 underline-hover">Security,</a> </span><span><a href="/tag/product-news" class="no-underline f1 fw2 blue3 underline-hover">Product News,</a> </span><span><a href="/tag/cloudflare-one" class="no-underline f1 fw2 blue3 underline-hover">Cloudflare One</a> </span></div></article><article data-testid="related-posts-article" class="w-100 w-100-m w-50-l ph3 mb4"><p data-testid="related-posts-article-date" class="f3 fw5 gray5" data-iso-date="2024-10-07T00:00+01:00">October 06, 2024 11:00 PM</p><a data-testid="related-posts-article-title" href="/security-txt" class="no-underline gray1 f4 fw5"><h2 class="gray1 f4 fw5 mt2">Enhance your website's security with Cloudflare’s free security.txt generator</h2></a><p data-testid="related-posts-article-excerpt" class="gray1 lh-copy">Introducing Cloudflare’s free security.txt generator, empowering all users to easily create and manage their security.txt files. This feature enhances vulnerability disclosure processes, aligns with industry standards, and is integrated into the dashboard for seamless access. Strengthen your website's security today!...</p><ul class="flex pl0 fw6 f2 mb3 flex flex-wrap"><span>By </span><li class="list flex items-center" style="white-space:nowrap"><div class="author-name-tooltip"><a href="/author/alexandra" class="fw5 f2 black no-underline">Alexandra Moraru</a><span class="fw5 f2 black no-underline">, </span></div></li><li class="list flex items-center" style="white-space:nowrap"><div class="author-name-tooltip"><a href="/author/sam-khawase" class="fw5 f2 black no-underline">Sam Khawasé</a></div></li></ul><div data-testid="related-posts-article-tags" class="flex flex-row flex-wrap"><span><a href="/tag/better-internet" class="no-underline f1 fw2 blue3 underline-hover">Better Internet,</a> </span><span><a href="/tag/security-posture" class="no-underline f1 fw2 blue3 underline-hover">Security Posture,</a> </span><span><a href="/tag/security" class="no-underline f1 fw2 blue3 underline-hover">Security,</a> </span><span><a href="/tag/standards" class="no-underline f1 fw2 blue3 underline-hover">Standards,</a> </span><span><a href="/tag/security-txt" class="no-underline f1 fw2 blue3 underline-hover">security.txt</a> </span></div></article></div></astro-island><footer class="pt4 pb4 pl1 pr1 main-footer"><div class="mw8 center dn db-l ph3"><div class="flex flex-row justify-between"><div class="main-footer__menu-group"><ul id="getting-started-menu" class="list pl0"><li class="pt1 pb1 f1 main-footer__menu-group__header js-toggle-footer-group" data-submenu="getting-started-menu">Getting Started<i class="icon-caret-down"></i></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/plans/free/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="free-plans" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Free plans</a></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/enterprise/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="enterprise" class="f1 blue3 no-underline underline-hover" rel="noreferrer">For enterprises</a></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/plans/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="compare-plans" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Compare plans</a></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/about-your-website/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="get-a-recommendation" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Get a recommendation</a></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/plans/enterprise/demo/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="request-a-demo" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Request a demo</a></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/plans/enterprise/contact/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="contact-sales" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Contact Sales</a></li></ul></div><div class="main-footer__menu-group"><ul id="company-menu" class="list pl0"><li class="pt1 pb1 f1" data-submenu="company-menu">Resources<i class="icon-caret-down"></i></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/learning/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="learning-center" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Learning Center</a></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/analysts/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="analysts-report" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Analyst reports</a></li><li class="pt1 pb1"><a href="https://radar.cloudflare.com/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="overview" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Cloudflare Radar</a></li><li class="pt1 pb1"><a href="https://cloudflare.tv/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="tv" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Cloudflare TV</a></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/case-studies/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="case-studies" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Case Studies</a></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/resource-hub/?resourcetype=Webinar" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="webinars" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Webinars</a></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/resource-hub/?resourcetype=Whitepaper" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="white-papers" class="f1 blue3 no-underline underline-hover" rel="noreferrer">White Papers</a></li><li class="pt1 pb1"><a href="https://developers.cloudflare.com" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="developer-docs" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Developer docs</a></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/the-net/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="theNet" class="f1 blue3 no-underline underline-hover" rel="noreferrer">theNet</a></li></ul></div><div class="main-footer__menu-group"><ul id="sales-menu" class="list pl0"><li class="pt1 pb1 f1 main-footer__menu-group__header js-toggle-footer-group" data-submenu="sales-menu">Solutions<i class="icon-caret-down"></i></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/connectivity-cloud/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="connectivity-cloud" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Connectivity cloud</a></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/zero-trust/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="zero-trust" class="f1 blue3 no-underline underline-hover" rel="noreferrer">SSE and SASE services</a></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/application-services/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="application-services" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Application services</a></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/network-services/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="network-services" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Network services</a></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/developer-platform/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="developer-services" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Developer services</a></li></ul></div><div class="main-footer__menu-group"><ul id="community-menu" class="list pl0"><li class="pt1 pb1 f1 main-footer__menu-group__header js-toggle-footer-group" data-submenu="community-menu">Community<i class="icon-caret-down"></i></li><li class="pt1 pb1"><a href="https://community.cloudflare.com" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="community_hub" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Community Hub</a></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/galileo/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="galileo" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Project Galileo</a></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/athenian/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="athenian" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Athenian Project</a></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/campaigns/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="cloudflare-for-campaigns" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Cloudflare for Campaigns</a></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/partners/technology-partners/cidp/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="critical-infrastructure-defense-project" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Critical Infrastructure Defense Project</a></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/connect2024/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="connect-2024" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Connect 2024</a></li></ul></div><div class="main-footer__menu-group"><ul id="support-menu" class="list pl0"><li class="pt1 pb1 f1 main-footer__menu-group__header js-toggle-footer-group" data-submenu="support-menu">Support<i class="icon-caret-down"></i></li><li class="pt1 pb1"><a href="https://support.cloudflare.com" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="help-center" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Help center</a></li><li class="pt1 pb1"><a href="https://www.cloudflarestatus.com" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="status" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Cloudflare Status</a></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/compliance/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="compliance" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Compliance</a></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/gdpr/introduction/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="gdpr" class="f1 blue3 no-underline underline-hover" rel="noreferrer">GDPR</a></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/trust-hub/abuse-approach/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="trust-and-safety" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Trust & Safety</a></li></ul></div><div class="main-footer__menu-group"><ul id="company-menu" class="list pl0"><li class="pt1 pb1 f1 main-footer__menu-group__header js-toggle-footer-group" data-submenu="company-menu">Company<i class="icon-caret-down"></i></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/about-overview/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="overview" class="f1 blue3 no-underline underline-hover" rel="noreferrer">About Cloudflare</a></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/people/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="our_team" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Our team</a></li><li class="pt1 pb1"><a href="https://cloudflare.net/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="investor-relations" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Investor relations</a></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/press/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="press" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Press</a></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/careers/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="careers" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Careers</a></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/diversity-equity-and-inclusion/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="diversity-equity-inclusion" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Diversity, equity & inclusion</a></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/impact/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="impact-ESG" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Impact/ESG</a></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/network/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="network_map" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Network Map</a></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/press-kit/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="press-kit" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Logos & press kit</a></li><li class="pt1 pb1"><a href="https://www.cloudflare.com/partners/" target="_blank" data-tracking-category="footer" data-tracking-action="click" data-tracking-label="partners" class="f1 blue3 no-underline underline-hover" rel="noreferrer">Become a partner</a></li></ul></div></div></div><div class="mw8 center ph3"><div class="flex flex-row flex-wrap justify-center md:justify-between items-center pt4"><div class="flex flex-row space-x-4 items-start w-25-l pb4 pb0-l"><a target="_blank" rel="noreferrer" href="https://www.facebook.com/Cloudflare/" class="w-8"><img class="w-8" src="https://www.cloudflare.com/img/footer/facebook.svg" alt="facebook"/></a><a target=" _blank" rel="noreferrer" href="https://x.com/Cloudflare" class="w-8"><img class="w-8" src="https://www.cloudflare.com/img/footer/twitter.svg" alt="X"/></a><a target="_blank" rel="noreferrer" href="https://www.linkedin.com/company/cloudflare" class="w-8"><img class="w-8" src="https://www.cloudflare.com/img/footer/linkedin.svg" alt="linkedin"/></a><a target="_blank" rel="noreferrer" href="https://www.youtube.com/cloudflare" class="w-8"><img class="w-8" src="https://www.cloudflare.com/img/footer/youtube.svg" alt="youtube"/></a><a target="_blank" rel="noreferrer" href="https://www.instagram.com/cloudflare" class="w-8"><img class="w-8" src="https://www.cloudflare.com/img/footer/instagram.svg" alt="instagram"/></a></div><div class="w-70-l tr-l tl-ns"><div><span class="main-footer__copyright f1">© 2024 Cloudflare, Inc. </span><span class="main-footer__copyright f1">|</span><a href="https://www.cloudflare.com/privacypolicy/" target="_blank" class="main-footer__copyright f1 no-underline underline-hover" rel="noreferrer"> Privacy Policy </a><span class="main-footer__copyright f1">|</span><a href="https://www.cloudflare.com/website-terms/" target="_blank" class="main-footer__copyright f1 no-underline underline-hover" rel="noreferrer"> Terms of Use </a><span class="main-footer__copyright f1">|</span><a href="https://www.cloudflare.com/disclosure/" target="_blank" class="main-footer__copyright f1 no-underline underline-hover" rel="noreferrer"> Report Security Issues </a><span class="main-footer__copyright f1">|</span><img class="mw2 ph1" src="/images/privacy-options.svg" alt="Privacy Options"/><a href="#cookie-settings" id="ot-sdk-btn" class="ot-sdk-show-settings main-footer__copyright f1 no-underline underline-hover"><span class="brandGray5">Cookie Preferences</span> </a><span class="main-footer__copyright f1">|</span><a href="https://www.cloudflare.com/trademark/" target="_blank" class="main-footer__copyright f1 no-underline underline-hover" rel="noreferrer"> Trademark </a></div></div></div></div></footer></html>

CINXE.COM

HTTP/3: From root to tip