IETF Logo Mail Archive

Re: [quicwg/base-drafts] Simplify version negotiation (#2133)

ekr <notifications@github.com> Wed, 12 December 2018 22:39 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 5D45513130B for <quic-issues@ietfa.amsl.com>; Wed, 12 Dec 2018 14:39:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.46
X-Spam-Level:
X-Spam-Status: No, score=-9.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, 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 917xtmLuG8qC for <quic-issues@ietfa.amsl.com>; Wed, 12 Dec 2018 14:39:48 -0800 (PST)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 656A013130A for <quic-issues@ietf.org>; Wed, 12 Dec 2018 14:39:48 -0800 (PST)
Date: Wed, 12 Dec 2018 14:39:47 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1544654387; bh=PUQIPXw8gkoEI6WYwXvNhDKftiw2BbSHI4KVBpU02as=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=rLOGTP6RO8epKo8qp8c1HeHdTFPGDe81C+wYgZRYrS+qEP/mxjFKqJ9o87f66GDil h98gWLlUEVKSt9eXQTJLyCKMIoCos7THwr8E3QzsEuoC6mM180+4f351mRYRK3XRNq 9Uyfa4i7iounOmHTuZU2k/CNp/BGddM7bNPfjLMg=
From: ekr <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab53c2be6c1f003285726dec25d2d33460ccf1aee792cf000000011829503392a169ce17450cf5@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2133/c446771319@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2133@github.com>
References: <quicwg/base-drafts/pull/2133@github.com>
Subject: Re: [quicwg/base-drafts] Simplify version negotiation (#2133)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c118e3331419_44f43fb2366d45c04087c6"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ekr
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/c93XdKd8GdN372YqdaSYovpmQCg>
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: Wed, 12 Dec 2018 22:39:50 -0000

> The current VN mechanism has the property of being part of the protocol
> invariants, whereas the new one only works if the server can parse CRYPTO
> frames and a TLS 1.3 client hello. Requiring all future versions to be able
> to parse past versions' transport parameters does not sound simple to me.
>

As I said in my initial message, that's *not* the property that it
requires. Rather, it requires that all versions that can inter-negotiate be
able to parse each others parameters. It's quite possible with this design
to have two entirely different lines of QUIC versions, one of which has
CRYPTO frames and TLS 1.3, and one of has something entirely different. Can
you describe a practical situation in which this would not be sufficient?


-- 
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/2133#issuecomment-446771319

v2.23.0 | Report a Bug | By Email