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

MikkelFJ <> Wed, 19 June 2019 08:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A2B1D120073 for <>; Wed, 19 Jun 2019 01:22:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.02
X-Spam-Status: No, score=-7.02 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_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.415, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id l69iN74Gn69a for <>; Wed, 19 Jun 2019 01:22:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DA43312002F for <>; Wed, 19 Jun 2019 01:22:03 -0700 (PDT)
Date: Wed, 19 Jun 2019 01:22:02 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1560932522; bh=VHT5g5q2ta29R69b8eOGV9opviZF7xMaP3OGOcTAYmI=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=jnaMqo1BDKoxo1FjX/BhKT/xbiMp2dU2mEoSvIOu3T+VA4jl5JtzLPb6+k5lf4Suf AkkHtlrBrO10r/DYOwyKd/OJZ99FNYiPyDPh6s4cs8ND6G+OeiJKSh+RBStSXMgLeJ u/qm3cW6ZHvEjskPi4xD5GW1dQFmD0/h571GmDuk=
From: MikkelFJ <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/pull/2791/>
In-Reply-To: <quicwg/base-drafts/pull/>
References: <quicwg/base-drafts/pull/>
Subject: Re: [quicwg/base-drafts] Receiver's behavior on key update (#2791)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d09f0aa2fa19_18e3fecd50cd96820976"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 19 Jun 2019 08:22:06 -0000

> An endpoint should not call it a violation when it receives a packet carrying an awfully outdated key phase, because such behavior would allow an on-path attacker to disrupt a connection, by buffering a and injecting a very old packet. That also means that there's no reason to define when an old key is dropped.

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. We cannot say that a packet should always be dropped since it is valid to close in some cases, it is just hard to specify.

My mention of unprotect relates to my own text which uses your term "authenticate and decrypt" repetitively in order to be precise.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: