Re: [quicwg/base-drafts] Describe a new version negotiation mechanism which allows for (#1755)

Kazuho Oku <> Thu, 27 September 2018 04:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7979A130DED for <>; Wed, 26 Sep 2018 21:37:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MUGvIIp28ILk for <>; Wed, 26 Sep 2018 21:37:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BB5DF130DEC for <>; Wed, 26 Sep 2018 21:37:54 -0700 (PDT)
Date: Wed, 26 Sep 2018 21:37:53 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1538023073; bh=Lyt8cMosTRDZ4wQhTVwuzMSv6A4qfj9OuhrNvIR6skI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=oVe8U/ohQrkeqePsC5BeCVBHCKS8onDS7PpUOjed4yoA+Rf5NT4ixmfvGPSNd3PXk d7bUcqjQVXVPiHhHtqJfiTpNEbpzn04cH1KKwiJcwmOm7PguOC/K2nAQ1gqEwLhkzW 05FlhWIppgqONbUuOJZ2kontwiQX7A8vsusgYPBs=
From: Kazuho Oku <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/1755/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Describe a new version negotiation mechanism which allows for (#1755)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bac5ea1bb366_3d063f8255ad45b410933d"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 27 Sep 2018 04:37:57 -0000

> The big loser here is the validation of version negotiation. I think that most of that is stuff we want to lose. By having all the client's supported versions available to the server we lose a lot of the complication that the text was addressing.

IIUC, the risk here is that if we have a client and server that support both QUIC v1 and vX (a future version of QUIC that does not use TLS), we cannot detect downgrade attack that forces the peers to use v1 instead of vX.

Are we fine with that?

If not, I might prefer retaining the current approach in v1 _and_ consider introducing the proposed approach in v2 (my understanding is that this type of version negotiation can be introduced afterwards, like we introduced supported_versions in TLS 1.3).

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: