Re: Key updates

Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> Fri, 10 August 2018 10:27 UTC

Return-Path: <mirja.kuehlewind@tik.ee.ethz.ch>
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 738FB130F0A for <quic@ietfa.amsl.com>; Fri, 10 Aug 2018 03:27:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=unavailable autolearn_force=no
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 Sps4AD5ag8hY for <quic@ietfa.amsl.com>; Fri, 10 Aug 2018 03:27:05 -0700 (PDT)
Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97C77130DE3 for <quic@ietf.org>; Fri, 10 Aug 2018 03:27:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 41n1Wr1q2pz15KJd; Fri, 10 Aug 2018 12:27:04 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch
Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ffpNUegxU4nl; Fri, 10 Aug 2018 12:27:02 +0200 (CEST)
X-MtScore: NO score=0
Received: from [82.130.103.20] (nb-10688.ethz.ch [82.130.103.20]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Fri, 10 Aug 2018 12:27:02 +0200 (CEST)
Subject: Re: Key updates
To: Martin Thomson <martin.thomson@gmail.com>
Cc: Ian Swett <ianswett=40google.com@dmarc.ietf.org>, QUIC WG <quic@ietf.org>
References: <CABkgnnW9-Jn1CH0rSwbtDmMrOZ+jstugVsOpWtShDJgT_KSyOw@mail.gmail.com> <CAKcm_gPXFXZc4ysm7ugG0T8GTWjgcO9hvO6ATj0MRiEufie=bQ@mail.gmail.com> <193166ED-C8C3-4A6B-9483-5546C34B5BDA@tik.ee.ethz.ch> <CABkgnnW1VhCKc+SDTGLJ0Q4BZZz9jJLmv3nOPrGTWWJe-dHTvg@mail.gmail.com>
From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= <mirja.kuehlewind@tik.ee.ethz.ch>
Message-ID: <8984a3c6-d506-54ec-6ce6-b5e95a18aee4@tik.ee.ethz.ch>
Date: Fri, 10 Aug 2018 12:27:02 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <CABkgnnW1VhCKc+SDTGLJ0Q4BZZz9jJLmv3nOPrGTWWJe-dHTvg@mail.gmail.com>
Content-Type: multipart/mixed; boundary="------------0AD8CA3712A08BE12929B923"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/9aa4l9NjGfmZ7sms1VKUOXaQqQQ>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.27
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: Fri, 10 Aug 2018 10:27:08 -0000

I was more thinking about things we know we want to do in future 
versions and where it would make implementation easier if we already 
design the current version with these changes in mind.

I think that something that is independent of the invariants.

On 07.08.2018 02:39, Martin Thomson wrote:
> On Mon, Aug 6, 2018 at 11:06 PM Mirja Kühlewind
> <mirja.kuehlewind@tik.ee.ethz.ch> wrote:
>> However, this brings us back to Martin’s other question: does it make sense to have a couple of reserved bits to make it easy to add a bit for the next version with minimal changes to the protocol machinery/wire image?
> 
> I think that was Dirkjan who asked that question.
> 
> The driving principle behind defining invariants was to avoid having
> to come back to this question repeatedly.  We have a version
> negotiation mechanism that allows us to change an awful lot between
> different protocol version.  We don't need to reserve a few bits
> because most of them are already reserved.
>