IETF Logo Mail Archive

Re: [quicwg/base-drafts] Receiver's behavior on key update (#2791)

Kazuho Oku <notifications@github.com> Wed, 19 June 2019 08:32 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 BC254120391 for <quic-issues@ietfa.amsl.com>; Wed, 19 Jun 2019 01:32:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.391
X-Spam-Level:
X-Spam-Status: No, score=-6.391 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 nQKSbScYH0qO for <quic-issues@ietfa.amsl.com>; Wed, 19 Jun 2019 01:32:12 -0700 (PDT)
Received: from out-19.smtp.github.com (out-19.smtp.github.com [192.30.252.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0396E12002F for <quic-issues@ietf.org>; Wed, 19 Jun 2019 01:32:11 -0700 (PDT)
Date: Wed, 19 Jun 2019 01:32:10 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1560933130; bh=0Uwr96FLASxzWfUABUnk1LkRo8YbHjkO+ik6oUysmx8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Fb/JeKuR4WpqSgvHh2or4TjAhWc6qrVpFbbQu0L+OvXjPudIq1V+hpKAxlgxJ36DQ RFgToJ4BYGYlUTg21MtIfIu/DeWB4QKQzY1Pkqvv8AZdg4MWlXyxLTrsTZWcgQn8p5 XEffLa90L3vZFsk0WOjMLKb65gvGioh8dALLjtnw=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2ISMT4CCTAHPXINMV3C4SYVEVBNHHBWLWXFE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2791/c503462939@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2791@github.com>
References: <quicwg/base-drafts/pull/2791@github.com>
Subject: Re: [quicwg/base-drafts] Receiver's behavior on key update (#2791)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d09f30a8dd61_4d553fdfb42cd96c194835"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/NW-c4axHDDWh7mZFEnMFQQYI2Yc>
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, 19 Jun 2019 08:32:15 -0000

> My point is the arrival of a packet encrypted with a very new key in a very old packet number. Exactly when that packet number is too old is the question. It relates to the sender MUST not send with an older key. Ultimately it comes down to not observing keys with overlapping ranges.

Thank you for the clarification. It is my understanding that a "sender MUST NOT" implies "receiver MAY close when it detects violation," and IIRC we have agreed that such behavior is either desirable or permissible in this specific case.

I think we can clarify that and the mechanism could be simple, because we already suggest that an endpoint might track the lowest, successfully unprotected packet number of the current key phase.

-- 
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/2791#issuecomment-503462939

v2.23.0 | Report a Bug | By Email