Re: Alternate Version + Salt in Alt-Svc

"Martin Thomson" <> Mon, 04 November 2019 21:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 777A2120091 for <>; Mon, 4 Nov 2019 13:43:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=ePogQO26; dkim=pass (2048-bit key) header.b=nnHTtF7T
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dnW9ZnDLDqIQ for <>; Mon, 4 Nov 2019 13:43:05 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 139DE120121 for <>; Mon, 4 Nov 2019 13:43:05 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 79CB855C for <>; Mon, 4 Nov 2019 16:43:04 -0500 (EST)
Received: from imap2 ([]) by compute1.internal (MEProxy); Mon, 04 Nov 2019 16:43:04 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm3; bh=rUWCdvK9ZULzN7mgKt57aybfPBRwd3B NBbpDetF1ZYY=; b=ePogQO267/X8GVuNLmWnGkd8iNe+dRUXd/fnPybQbjmjApd 7mJmiyZyO3m3Q1HwlDNjbW7zn8hjWKeMb/oej4Nkvb4C6rDhe42X5Ihs37EeO4dQ NqR3tzMjZTy7viur3PXww2jQ7fAdnK6Rj6R81eY1/W9gTWfdH2W6u6APY5F6hYQs VNqCXDiFFkwHhCf2vhtQNyD5rhVYu6glBTodUrrlVtPhOhzG9lm4hXCXeod81uNL ehGPu6KmGF5t4ufJXMIso/XKoK34G72k0jfguBF51A7Nwl9Wtx8+adLbKwWTaiXK 0+TmS1K9rOGCrF5vMVltuEqOXS2hO/oa3AUZArw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=rUWCdv K9ZULzN7mgKt57aybfPBRwd3BNBbpDetF1ZYY=; b=nnHTtF7TK/KhCSf7+ebhCV HR1uk4CeXP2todirfJsywudXNLdPp4ErGNnrkFyFZnvLl7ftLjTpl7KfqGW74SjP F7NyfJgdg3QeeT0NJw1IsFo8+u6jDU8E2JYlWu0aJiED3/czriaXmNWPmVcM4My9 IB4U7sDMzyowSmF4NnMBH5DKqVR2P6GnyjgMbsPGFJsq+A6KHrAgfUTCmsVhzUc4 VZ4zyz+gGFPHMsDlqGoOaXrkKPPhKMmKUW9t75FToTtuQjn+SWmpd1S00p9NGdx1 ab39jJaA+C2EmDOb9rqbs+OnMii48LK28P0rGg0LPYVMvBZxV9Y9Y60EEjFUDRWQ ==
X-ME-Sender: <xms:Z5vAXevGnlsMkUSE5Ln-3f6m_20xwqcuB_OFl_TdQArM-CSmhL8pVg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedruddufedgudehfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesth dtredtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehl ohifvghnthhrohhphidrnhgvtheqnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslh hofigvnhhtrhhophihrdhnvghtnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:Z5vAXUCIpuYeUjzCNCegjE1a2BoMV-DwcjeZmVkGuYSAaD6JVTdvAg> <xmx:Z5vAXVKWY1kx-Sl5UTorQ4IMbzm5adBdEddgqC-CmVYwt02QAqh3SQ> <xmx:Z5vAXb25pngvnAkdfZU5YXygtVvxSWNv7HZR3EhrJr_JYw6-kM9JIQ> <xmx:aJvAXXOccMHmjpfUMq3TLjhr56BAzypsqcmi7qVte6283qO8o2A5mg>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id D0683E00A3; Mon, 4 Nov 2019 16:43:03 -0500 (EST)
X-Mailer: Webmail Interface
User-Agent: Cyrus-JMAP/3.1.7-509-ge3ec61c-fmstable-20191030v1
Mime-Version: 1.0
Message-Id: <>
In-Reply-To: <>
References: <>
Date: Tue, 05 Nov 2019 08:42:44 +1100
From: "Martin Thomson" <>
Subject: Re: Alternate Version + Salt in Alt-Svc
Content-Type: text/plain
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 21:43:08 -0000

On Tue, Nov 5, 2019, at 07:34, Ryan Hamilton wrote:
> 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.

Yes, this is an issue.  Thanks for identifying it.  We hadn't gotten to Alt-Svc for this yet, we're having enough trouble with NEW_TOKEN :)

The general rule we follow for these things is to require confidentiality for the initial signaling and to only use the value once.  That works for session tickets, it works for NEW_TOKEN, and I see no reason not to have it apply here also.  That means falling back to version==1 for connection attempts after the first.

That diminishes the value of the addition a little, but I don't think that it is enough to be concerned.  The alternative service still exists and can be used, and successful connection attempts should provision the client with more tokens for future connections.