IETF Logo Mail Archive

Re: Key updates

Martin Thomson <martin.thomson@gmail.com> Tue, 07 August 2018 07:10 UTC

Return-Path: <martin.thomson@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 B9F8A130E5A for <quic@ietfa.amsl.com>; Tue, 7 Aug 2018 00:10:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 pYCnA13jZTUH for <quic@ietfa.amsl.com>; Tue, 7 Aug 2018 00:10:53 -0700 (PDT)
Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 7DFCC130D7A for <quic@ietf.org>; Tue, 7 Aug 2018 00:10:53 -0700 (PDT)
Received: by mail-oi0-x231.google.com with SMTP id q11-v6so26634269oic.12 for <quic@ietf.org>; Tue, 07 Aug 2018 00:10:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ghkIvtIUfOCDnXcWyAhxeq6FvEOg1H6ry4thMtksSz8=; b=Paa/7qH2sTdXqxVD4031tavt7oPFWQsuXeTcbR1dPIgMbkZYFy4+dRQCATm6+z3zuI ZTmLd7buS0ND4FvpDu2EvDWTh+GSnYfd4g4Re7R3Gb78xRfQtvHSc/AKJx+2/4SY9KN6 RlhIGQloOlrVz6arejsbB8Mx4hMkeHx5NTDgANJK3Ml+0iK/BYv8kFhFNBGO+/pdWNka cznw3Ztx0U4gPO36k4o+9jBaw/hVKHsbCT0swbUK6Xply3QS4nJdpPC1oCWG6XxE3ja/ TS/kKHSXayii0nxL6Gbj67/DjXydDejIDCbYxEt8TgiVsqCFtCGrHENNqpHSGvKffz3q r2hg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ghkIvtIUfOCDnXcWyAhxeq6FvEOg1H6ry4thMtksSz8=; b=Qts5E0PzKuF9WrowFyS0YGWehHwekc/3OqUp8PpItX06T+KjpADpfH0UxJ/gNn4Dzk fLJwFahdBZ7tk031z8mbau9kn6nu747POQi85HjV1auf7bZYlXc3NvvWLUPHJ0UeN1BL T+JJ3Uetan1GEnToKQLhb2ZGS1iQULAt9u1PG/3w91J/kksTbzWuOjBzbOm++YguVTjt a45jR8PDSEVuZ6TWvH0Fe9diKg/emV9ajpK40uy645zdiHknKws6U8Z4Q/GawT5oV6vn Z02l78mPtTDnd9fRwsSmW7Qzm2cyHqQbKHdO43rAHKFyubRSQ+OTrBAEiRxcCi5IfUKq qB8Q==
X-Gm-Message-State: AOUpUlEs4zk36FAKofyPTCuCR2syB8Tbxbi+xS2h8fXKgi4aWjFF5EfS rUUXnpCBmP4ZCvadLmMriAQO/sSnFFmbHNsPc38=
X-Google-Smtp-Source: AAOMgpeuwjkt3Ug7tNvCFdFpFdG1ZZWAditHWthf+dj18mQE+/qlZ5xxdPsBK4+XuHIgE2zLIStSKs6CMvP2K6chAWI=
X-Received: by 2002:aca:3d56:: with SMTP id k83-v6mr16990881oia.166.1533625852691; Tue, 07 Aug 2018 00:10:52 -0700 (PDT)
MIME-Version: 1.0
References: <CABkgnnW9-Jn1CH0rSwbtDmMrOZ+jstugVsOpWtShDJgT_KSyOw@mail.gmail.com> <CANatvzxJVMUrCW+28FAFC21-Yg_7g0ayaGMfpyaMyztosaAVjg@mail.gmail.com> <CABkgnnWFKLN7obL9H0+ayJDSAmR_Xzk2Yxaj6y92fEJEzD=URQ@mail.gmail.com> <CANatvzz4rC2BUK7xKeUQrHVJzXxzCnp4uXNFEargmkNcz82dLg@mail.gmail.com> <CABkgnnUiikrpqNZA8oKjAHe1aBjBSSV0gFzMwAXDr8HW4Wiufg@mail.gmail.com> <CANatvzx2z15uE=Be6WCuTs1AiwjuoNbqx3_fUYOozt70JyhdRw@mail.gmail.com>
In-Reply-To: <CANatvzx2z15uE=Be6WCuTs1AiwjuoNbqx3_fUYOozt70JyhdRw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Tue, 07 Aug 2018 17:10:41 +1000
Message-ID: <CABkgnnUNJ0+TbC6QxjppD8MrBPJGYDpKbqtRGgiwweWWu7m5XQ@mail.gmail.com>
Subject: Re: Key updates
To: Kazuho Oku <kazuhooku@gmail.com>
Cc: QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/7lmgMVglBdfethiouZS2BPbfWAE>
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: Tue, 07 Aug 2018 07:10:56 -0000

On Tue, Aug 7, 2018 at 5:01 PM Kazuho Oku <kazuhooku@gmail.com> wrote:
> My point is that the issue within the current design is that we
> require the endpoint to update if the peer initiates an update.
>
> I am suggesting to change that to "an endpoint updates its epoch if
> the peer starts using an epoch that is higher than it uses."
>
> Taking the example,
>
> A sends N+1
> B sends N followed by N+1 around the same time
> 0.5 RTT later both receive a packet at N+1, and they will stay using
> N+1, because each of them initiated an update and because the epoch
> that one uses is not smaller than the value used by the peer

I see, thanks for clarifying.  I don't think that this is a great idea
because it means that reordered packets will be dropped.  Reordering
is common enough for at least some implementations to want to retain N
for some time after this changeover.

v2.23.0 | Report a Bug | By Email