Re: Benjamin Kaduk's Discuss on draft-ietf-quic-transport-33: (with DISCUSS and COMMENT)

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Thu, 07 January 2021 14:35 UTC

Return-Path: <mikkelfj@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2BC3A119D; Thu, 7 Jan 2021 06:35:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 gt3FUzaLdofD; Thu, 7 Jan 2021 06:34:58 -0800 (PST)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9A653A1196; Thu, 7 Jan 2021 06:34:57 -0800 (PST)
Received: by mail-lf1-x131.google.com with SMTP id o19so15080127lfo.1; Thu, 07 Jan 2021 06:34:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=aZgvmLK513ZNQAnjWhkyBj+bDROfiE15LrwDnQmh8ug=; b=ltIFL983yrsEzxLo3LPlU94St/HRmo2eLKsm4PmF+TDm5lTAi3v5+SbdHDHXS22KEw OTfannmVXkSnhGbN30/moIyaCRq433bvc4xCPpEW22xUxDEjn/oVS3OgX+mUW2H+eIbr EWDjHXXwcYyYA47Q5CoPxELFe6HeU8BJNjokWj0AnEA91AGJ+OZZIjWQUsnfVhHgG7Fn RKyEIeT+qn15MeDoa15595Z6PHpD779wJRau/+5cnUmwBhpJjyERlm330ydySQA9Tm0O L8/o1PgtanSziwtNfAPmBfGsezFi63jD0vMs9ZE5I/+lQ0kevnX/+nAR73bB8iT23/tt xD2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=aZgvmLK513ZNQAnjWhkyBj+bDROfiE15LrwDnQmh8ug=; b=XMciwAry1SzrW4boaDUAU/qY7C5HZdwFVtvTBZOiLywWWxG53Q+UlXm/DJKQ9EudNL 7+kmyUATa3teurG5op8SZrcaC5P32OPAvOi1JTQIrSY26l3+pAkmD/n3oc3wPmSJQMdS xjewexp+PDNZci0mnBi4CyUk2qVY+eqfoH0zz4QqthRrSxb5ExmGAA9MIJHiwoBf0ZxI evtn5EF9AoyKXkI9Kzb/RuURlr9pacBYLxewTMTytMbRBdxddhwacSW5kgT5MPxbx8bb 65khbHfZpaFuzjLZq9KmtuxE+hDHnwUwh16ZZl5ci/mrSl2eCPkkH5GmZxH4O9V5KS49 Gm/A==
X-Gm-Message-State: AOAM531U9z8aDol3ej/kosTDGWp7NTVWMNUVSBqRVpV/sp7BZFELlIpK Dhn3MIggeIKEkAVAlQBtsKMpXG4gqNBymoZd
X-Google-Smtp-Source: ABdhPJzW8lmaC1/XZ2zMSHcJ4ZcKmg+RuA65BZwKEp54RttQ4pYsOQ1NbYP6eXqAAWLEHFQoMPmKVQ==
X-Received: by 2002:ac2:4c2f:: with SMTP id u15mr3800062lfq.163.1610030095690; Thu, 07 Jan 2021 06:34:55 -0800 (PST)
Received: from [192.168.8.100] (109.58.155.143.mobile.3.dk. [109.58.155.143]) by smtp.gmail.com with ESMTPSA id g190sm1177210lfd.72.2021.01.07.06.34.54 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Jan 2021 06:34:55 -0800 (PST)
From: Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com>
Message-Id: <293B4391-BB07-402F-B19D-6A93D0C78BA2@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_195099F6-D008-4FF9-8048-F768F4F67F99"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
Subject: Re: Benjamin Kaduk's Discuss on draft-ietf-quic-transport-33: (with DISCUSS and COMMENT)
Date: Thu, 07 Jan 2021 15:34:53 +0100
In-Reply-To: <20210107065404.GH93151@kduck.mit.edu>
Cc: Martin Thomson <mt@lowentropy.net>, Lars Eggert <lars@eggert.org>, WG Chairs <quic-chairs@ietf.org>, The IESG <iesg@ietf.org>, quic@ietf.org, draft-ietf-quic-transport@ietf.org
To: Benjamin Kaduk <kaduk@mit.edu>
References: <160996950953.25754.14270013028683006869@ietfa.amsl.com> <39c24306-42dc-454a-8a60-cfbd86ab6c64@www.fastmail.com> <20210107065404.GH93151@kduck.mit.edu>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/1W0D56x3qHOebdkDJ263F83BkGk>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jan 2021 14:35:01 -0000


> On 7 Jan 2021, at 07.54, Benjamin Kaduk <kaduk@mit.edu> wrote:
> 
>  Do we have any reason to believe that non-standards-track versions
> will or will not intend to coexist with v1?  I, at least, do not have any
> data on that question either way.  I think this relates to my (3) above --
> are we assuming that the problem of downgrade protection only becomes
> relevant when there is specifically an IETF v2?

There are probably no information available at this point, but given how easy it is to deploy a new QUIC version, it is likely that several non-standard versions will emerge. Some variability can happen within v1 using extension frames but for example crypto will require a new version.

TLS 1.3 is not suitable for very resource constrained devices so it is likely that optimized protocols will emerge either as a standard or out of necessity. Another example could be space communication with network characteristics beyond what is practical in v1, and this isn’t that far out given that a mobile network has already been contracted for a moon base.

Even so, the overreaching concern was that producing a broken version negotiation protocol would be far worse than not providing one as long as there is only one version. This would also allow for practical experiments - keeping in mind that at the time, various prototype implementations were rather rudimentary. There were other more pressing concerns such as connection migration that had to be done right in v1. Getting everything right would risk never getting anything done.

So ideally version negotiation should be ready for v1 but realistically, it is not critical facility as long as there is only one version. Thus, anyone releasing other versions while there is no standardized negotiation protocol would necessarily not be able to safely interoperate with other versions in general, but they would be able to detect multiple client versions and decide to accept or reject a connection.

We have also historically seen downgrade attacks in critical infrastructure such as TLS, so version negotiation should not be taken lightly. Again, no negotiation is better than bad negotiation.

Mikkel