Re: Alternate Version + Salt in Alt-Svc

Tommy Pauly <> Mon, 04 November 2019 20:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6AC8112002E for <>; Mon, 4 Nov 2019 12:41:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OmgKyRZ29_hz for <>; Mon, 4 Nov 2019 12:41:17 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D371A120018 for <>; Mon, 4 Nov 2019 12:41:16 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id xA4KajrN034533; Mon, 4 Nov 2019 12:41:14 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=Y4fJQlxfUM4+OYXqItA7RC1GN7GZynxV5QEiRMllQ08=; b=IyMygh5Ra99+0kB/j9EAQD9fqKe5/Za974EGU2C+D3CkkqR6YUfDCTq2e9n+Rrf+7Ky5 ouVRYTAS8BqssAoVbTWV2x6xdZu7ZgNYMwghFrNg+QRR02/Q5moibxeUMZsFh8VpeAw9 s1EduxFH6N+Vvx/bmYDn4UzpbhcJvqepBar0ufFWiJmsuu+QDTVL4oFGbhRqJUVyzDu0 8T+Q33gTQb+UQj4o2BEPg1NkSuc84DY0izmaG9gLicDuyT3r/kjSC95Zu/+7Xd7UgvU8 qHiz4YpnoHbPhi0cKW5RlbMAdlk2zZC1GXK1AtfODpo2dcRTtUWNZpk61qjZvgegbKNA tw==
Received: from ( []) by with ESMTP id 2w16ftptxb-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 04 Nov 2019 12:41:14 -0800
Received: from ( []) by (Oracle Communications Messaging Server 64bit (built May 7 2019)) with ESMTPS id <>; Mon, 04 Nov 2019 12:41:14 -0800 (PST)
Received: from by (Oracle Communications Messaging Server 64bit (built May 7 2019)) id <>; Mon, 04 Nov 2019 12:41:14 -0800 (PST)
X-Va-T-CD: fd7fa2cf43a24f878f649a9cdf606cb8
X-Va-E-CD: 66b6aa0fce50738e37fdc0243428133e
X-Va-R-CD: a9cadcb32177681a04248ce6c161c5f1
X-Va-CD: 0
X-Va-ID: 35403bd1-c961-4f7d-8f24-1a39ecfbbf2a
X-V-T-CD: fd7fa2cf43a24f878f649a9cdf606cb8
X-V-E-CD: 66b6aa0fce50738e37fdc0243428133e
X-V-R-CD: a9cadcb32177681a04248ce6c161c5f1
X-V-CD: 0
X-V-ID: 1344633f-fa0f-420b-a59a-384a7504ab2b
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-11-04_11:,, signatures=0
Received: from [] by (Oracle Communications Messaging Server 64bit (built May 7 2019)) with ESMTPSA id <>; Mon, 04 Nov 2019 12:41:14 -0800 (PST)
From: Tommy Pauly <>
Message-id: <>
Content-type: multipart/alternative; boundary="Apple-Mail=_42479E83-94F7-4916-B419-830321BEAD20"
MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\))
Subject: Re: Alternate Version + Salt in Alt-Svc
Date: Mon, 04 Nov 2019 12:41:12 -0800
In-reply-to: <>
To: Ryan Hamilton <>
References: <>
X-Mailer: Apple Mail (2.3594.4.17)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-04_11:, , signatures=0
Archived-At: <>
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Nov 2019 20:41:19 -0000

I do think that this privacy concern is a valid issue to think about and try to mitigate, or at least reduce in scope. Good to discuss!

Clients could of course choose to not use a version received via Alt-Svc when they don't want to be linked (in which case they would also not want to do 0-RTT, etc). So there could be guidance on when to use these versions. That may reduce the amount that the alternate version gets used, though; and even end up causing failures only of some categories of connections.

Another way out here is to use the Alt-Svc value that comes from another source, like the proposal in HTTPSSVC. That would be harder to target users with.


> On Nov 4, 2019, at 12:34 PM, Ryan Hamilton <> wrote:
> Howdy Folks,
> We've discussed the idea of attempting to reduce ossification by allowing the server to deliver an alternative version and initial salt to the client which can be used to speak "QUIC v1". One such mechanism for delivering this version to the client is Alt-Svc. In the context of HTTP/3 this has the wonderful property that even the first connection from a client to the server can use this alternative version.
> However, it seems that there might be a privacy/linkability issue with this approach that I'm curious to get the groups' take on. If this information were delivered via Alt-Svc, I would imagine that the naïve implementation would be to cache the Alt-Svc info as until it expires (via the ma= attribute) and use the alternative version/salt in each subsequent QUIC connection. Since the version field is 32 bits, that potentially allows each user to use a distinct version. This is great for anti-ossification, but seems problematic for linkability/privacy.
> I can think of solutions/mitigations for this issue (like restricting the number of bits which can be flipped by the server, or expiring the alternative version in the client on first use, etc) but I'd be curious if this seems like an issue to other folks first.
> Cheers,
> Ryan