IETF Logo Mail Archive

Re: [quicwg/base-drafts] Compatible version upgrade (#1901)

Marten Seemann <notifications@github.com> Fri, 26 October 2018 00:30 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80F06130E19 for <quic-issues@ietfa.amsl.com>; Thu, 25 Oct 2018 17:30:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.47
X-Spam-Level:
X-Spam-Status: No, score=-8.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CkEUMUJeDCQ2 for <quic-issues@ietfa.amsl.com>; Thu, 25 Oct 2018 17:30:44 -0700 (PDT)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EAB7130E08 for <quic-issues@ietf.org>; Thu, 25 Oct 2018 17:30:44 -0700 (PDT)
Date: Thu, 25 Oct 2018 17:30:43 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1540513843; bh=UcprwdRDwRtSSiseHiEHZszqSlfTLYnFXVrBKBg4/E4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=D03P1oavLevWh91OoWfn8OKL/56lJq8hpei/9G0YSkZB3nQoDuGO2ruXOFeLh23a1 dJm5zXbQlZwbqiLrtq2YYPD2/37vOmk1xRNet8qYq4xdJK7S1R37MD38Y8+mXUTlnM SUQio5CeLntdsd9DgS78Sujz1WnhQxBd6WNj452w=
From: Marten Seemann <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abc03f191703af8fd75cc3b08b691f7d09e8e9096f92cf0000000117ea223392a169ce1640b1a8@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/1901/c433248615@github.com>
In-Reply-To: <quicwg/base-drafts/pull/1901@github.com>
References: <quicwg/base-drafts/pull/1901@github.com>
Subject: Re: [quicwg/base-drafts] Compatible version upgrade (#1901)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bd26033e2292_1afa3fdfc4cd45b81667378"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: marten-seemann
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/b-oBIuWyagd3oCSgobtbWW9Y3UU>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 26 Oct 2018 00:30:46 -0000

@kazuho How does this solve #1810?

> Consider the case where client supports five versions: v1, v1.1, v1.2, v2, v3. Compatible version upgrade is possible between different minor versions but not between major versions.
> The client, first attempts to connect using v3. The first packet will be a v3 packet. V1.x server responds with a VN that contains v1, v1.1, v1.2.
> Then, the client sends an Initial packet in v1, that contains a supported list of (v3, v2, v1, v1.1, v1.2). The server can determine which versions that the client assumed was impossible to use (i.e. v3, v2), because they are placed before v1 which is the packet version.

The equivalent to the case you describe in #1810 is the server being upgraded to support v2 just after sending the VNP. When receiving the v1 Initial packet from the client, containing v3 and v2 as impossible versions, it will conclude that an attacker injected the VNP, right?


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1901#issuecomment-433248615

v2.23.0 | Report a Bug | By Email