martinthomson

There are two forms of QUIC common header: long and short. Long form packets are used for the initial exchange - until both 1-RTT packet protection can be started AND version negotiation is complete. Short form packets carry the bulk of the data.

This removes a lot of the flexibility that was the source of most of the objections to the current format. Fields are aligned on four octet boundaries. All long-form header variations have the exact same form. The connection ID is in the same place in both short and long form. The long form clearly identifies the role of the sender in the first octet and it identifies the

martinthomson

Poking at the Topics Classifier

I just spent some time poking at the Topics classifier (available at chrome://topics-internals/; Model version: 2206021246).

With the complete list of 349 topics in topics.txt (source), I generated some names based on the topic strings. This just takes the last component of the topic, and hyphenates it, as follows:

sed -e 's/&/ and /g;s/  */-/g;s/[,()]//g;s/.*[ \/]-*\([-a-zA-Z]*\)$/\1.com/' topics.txt

martinthomson

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\.md]
"Content Type"="text/markdown"
@="md_auto_file"
"PerceivedType"="text"

martinthomson

martinthomson

Run this with an argument of the version number (in hex).

This is a copy of what I used for QUICv1.

martinthomson

The TLS key schedule looks like this:

QUIC effectively exports the various traffic secrets, so I had assumed that its use of the different base label in HKDF-Expand-Label() would be limited to those uses that were after that export. I forgot key update when writing this up, but that was fixed in #1899.

However, in looking at what people implemented, it appears that the base label they use was used for the entirety of the TLS key schedule.

martinthomson

Oblivious HTTP Working Group (OHTTP) Charter

In a number of different settings, interactions between clients and servers involve information that could be sensitive when associated with client identity.

Client-server protocols like HTTP reveal aspects of client identity to servers through these interactions, especially source addresses. Even without client identity, a server might be able to build a profile of client activity by correlating requests from the same client over time.

martinthomson

diff --git a/draft-ietf-quic-http.txt b/draft-ietf-quic-http.mnot.txt
index 922b3770..fdd6cf0e 100644
--- a/draft-ietf-quic-http.txt
+++ b/draft-ietf-quic-http.mnot.txt
@@ -1032,23 +1032,23 @@ Table of Contents
    response is important.  The server SHOULD send PUSH_PROMISE frames
    prior to sending HEADERS or DATA frames that reference the promised
    responses.  This reduces the chance that a client requests a resource
    that will be pushed by the server.
 

martinthomson

<dsig:Transform id="selective"
      Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"
      xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
     <dsig:XPath
      xmlns:pidf="urn:ietf:params:xml:ns:pidf"
      xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
      xmlns:dep="urn:ietf:params:xml:ns:pidf:geopriv10:dsig"
      xmlns:dm="urn:ietf:params:xml:ns:pidf:data-model">

   <!-- The 'presence' element -->

martinthomson

var buffer = require('buffer');
var crypto = require('crypto');
var assert = require('assert');

var INITIAL_SECRET = Buffer.from('ef4fb0abb47470c41befcf8031334fae485e09a0', 'hex');
var SHA256 = 'sha256';
var AES_GCM = 'aes-128-gcm';
var AES_ECB = 'aes-128-ecb';

function log(m, k) {