martinthomson

absoluteURI = /[A-Za-z](?:[\+\-\.]|[A-Za-z]|\d)*:(?:\/\/(?:(?::|(?:[\-\._~]|[A-Za-z]|\d)|%(?:(?:[A-Fa-f]|\d)){2}|[!$&'\(\)\*\+,;=])*@)?(?:\[(?:(?:(?:(?:(?:[A-Fa-f]|\d)){1,4}:){6}(?:(?:(?:[A-Fa-f]|\d)){1,4}:(?:(?:[A-Fa-f]|\d)){1,4}|(?:\d|[1-9]\d|1(?:\d){2}|2[0-4]\d|25[0-5])\.(?:\d|[1-9]\d|1(?:\d){2}|2[0-4]\d|25[0-5])\.(?:\d|[1-9]\d|1(?:\d){2}|2[0-4]\d|25[0-5])\.(?:\d|[1-9]\d|1(?:\d){2}|2[0-4]\d|25[0-5]))|::(?:(?:(?:[A-Fa-f]|\d)){1,4}:){5}(?:(?:(?:[A-Fa-f]|\d)){1,4}:(?:(?:[A-Fa-f]|\d)){1,4}|(?:\d|[1-9]\d|1(?:\d){2}|2[0-4]\d|25[0-5])\.(?:\d|[1-9]\d|1(?:\d){2}|2[0-4]\d|25[0-5])\.(?:\d|[1-9]\d|1(?:\d){2}|2[0-4]\d|25[0-5])\.(?:\d|[1-9]\d|1(?:\d){2}|2[0-4]\d|25[0-5]))|(?:(?:(?:[A-Fa-f]|\d)){1,4})?::(?:(?:(?:[A-Fa-f]|\d)){1,4}:){4}(?:(?:(?:[A-Fa-f]|\d)){1,4}:(?:(?:[A-Fa-f]|\d)){1,4}|(?:\d|[1-9]\d|1(?:\d){2}|2[0-4]\d|25[0-5])\.(?:\d|[1-9]\d|1(?:\d){2}|2[0-4]\d|25[0-5])\.(?:\d|[1-9]\d|1(?:\d){2}|2[0-4]\d|25[0-5])\.(?:\d|[1-9]\d|1(?:\d){2}|2[0-4]\d|25[0-5]))|(?:(?:(?:(?:[A-Fa-f]|\d)){1,4}:)?(?:(?:[A-Fa-f]|\d)){1,4})?::(

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

package minhq_test

import (
	"io"
	"net"
	"testing"

	"github.com/ekr/minq"
	"github.com/stvp/assert"
)

martinthomson

Keybase proof

I hereby claim:

• I am martinthomson on github.
• I am martinthomson (https://keybase.io/martinthomson) on keybase.
• I have a public key ASDuem6wah9reI_8gyoUXVgD_mzE5F_JqofPsxvhEKvHFwo

To claim this, I am signing this object:

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) {

martinthomson

package minq_test

import "testing"

func recoverMinq(expected uint64, pn uint64, size int) uint64 {
	// Mask off the top of the expected sequence number
	mask := uint64(1)
	mask = (mask << (uint8(size) * 8)) - 1
	expectedLow := mask & expected
	high := ^mask & expected

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

<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

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

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.