IETF Logo Mail Archive

Re: [quicwg/base-drafts] Conflicting error codes (#4087)

Christian Huitema <notifications@github.com> Mon, 14 September 2020 23:05 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 23F053A0BAB for <quic-issues@ietfa.amsl.com>; Mon, 14 Sep 2020 16:05:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.177
X-Spam-Level:
X-Spam-Status: No, score=-3.177 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.695, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-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 (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 ZafvIAyhTfsA for <quic-issues@ietfa.amsl.com>; Mon, 14 Sep 2020 16:05:23 -0700 (PDT)
Received: from out-23.smtp.github.com (out-23.smtp.github.com [192.30.252.206]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A49003A0BB0 for <quic-issues@ietf.org>; Mon, 14 Sep 2020 16:05:23 -0700 (PDT)
Received: from github-lowworker-0f78100.ash1-iad.github.net (github-lowworker-0f78100.ash1-iad.github.net [10.56.25.48]) by smtp.github.com (Postfix) with ESMTP id 8E92C600762 for <quic-issues@ietf.org>; Mon, 14 Sep 2020 16:05:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1600124722; bh=PrA54L8ytesSIWZkC069A4TpiUudeyWI6RvOd5OZ0J0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=bdqThqNjSJbghDdDRmxYV4qJOC8eorYTS11/y/RL1rzmmidak3/YSmkmnQuSbYuIi o16TnySyBNB0tzTGVVwYcCHDze7PFD+ptjUjTZskEFikbhd/jIVVZv7ktrceAzKM1V pKOrxZdpV6ko7l95TY/OUNsMtTjN8hfAbxtg8sJY=
Date: Mon, 14 Sep 2020 16:05:22 -0700
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZXGIOTZ63UMX3B5NF5NPMDFEVBNHHCTETOJE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/4087/692364214@github.com>
In-Reply-To: <quicwg/base-drafts/issues/4087@github.com>
References: <quicwg/base-drafts/issues/4087@github.com>
Subject: Re: [quicwg/base-drafts] Conflicting error codes (#4087)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5f5ff7327f0fc_67ec19f01494d"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
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/zGYTe_h17GCs8yX_tOBrbO_fGYU>
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: Mon, 14 Sep 2020 23:05:25 -0000

@janaiyengar the sender is **NOT** required to close the connection when it sends too many packets. That's not what the TLS limits say. The requirement is to use key rotation, move to the next epoch, and start using a new encryption key.

Reading the fine print, I believe the KEY_UPDATE_ERROR error will happen in one of two conditions:

1) The node starts a key rotation but the peer keeps using the old key for too long, for example if the peer continues using the old key but acknowledges packets sent with the new key.

2) The peer transmits too many packets for the epoch.

This is different from the integrity limit, which does require closing the connection if too many decryption failures are observed.


-- 
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/issues/4087#issuecomment-692364214

v2.31.3 | Report a Bug | By Email | System Status