Re: [quicwg/base-drafts] Remove handshake confirmed test for KeyUpdte (#3212)

Kazuho Oku <notifications@github.com> Mon, 11 November 2019 04:22 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 B36FC1200FB for <quic-issues@ietfa.amsl.com>; Sun, 10 Nov 2019 20:22:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Level:
X-Spam-Status: No, score=-7.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 1mjXMemffEHN for <quic-issues@ietfa.amsl.com>; Sun, 10 Nov 2019 20:22:37 -0800 (PST)
Received: from out-21.smtp.github.com (out-21.smtp.github.com [192.30.252.204]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D408912001E for <quic-issues@ietf.org>; Sun, 10 Nov 2019 20:22:36 -0800 (PST)
Date: Sun, 10 Nov 2019 20:22:35 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1573446155; bh=yXuBVHKpTfkFXTN8jABmYa9pv4QRgROnTnNCI9TB3Ow=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=qqgMVyNsX23zpHmacvzcint6UiGwR+rqnJPOIroJNM5pkTxCy2mvYDLH0cqK3LsNH dq467vizIpTszehVYhLxraRh9qSShjE3P1fNeV1QVsAtBAWnoXhnvYwXQ6iGdXMpIA HxgW9CICydcBys5+6Qk1To6PwB3G9t1HsWwdilhI=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKY7ECHNUXFI2URNN2N32YKIXEVBNHHB6CGIZA@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3212/552287760@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3212@github.com>
References: <quicwg/base-drafts/issues/3212@github.com>
Subject: Re: [quicwg/base-drafts] Remove handshake confirmed test for KeyUpdte (#3212)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dc8e20be3bac_bde3fbd294cd9681653735"; 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/CXuUso0b0I9xN9SxR8e6OECWV8k>
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, 11 Nov 2019 04:22:39 -0000

@nibanks 
> We've done performance tests with msquic and changing the key after each key update is ACK'ed and it showed absolutely no impact on throughput. As far as extra complexity it's hard to say. We implemented key update as it was spec'ed now and didn't have to make any complicated extra logic to get to this state.

I'm not sure if what you describe is following the recommendation. Quoting from the spec:
* Endpoints SHOULD wait three times the PTO before initiating a key update after receiving an acknowledgment that confirms that the previous key update was received. ([section 6.5](https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#rfc.section.6.5))
* Endpoints SHOULD instead defer the creation of the next set of receive packet protection keys until some time after a key update completes, up to three times the PTO.  ([section 6.3](https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#rfc.section.6.3))

Depending on how the peer is implemented, updating the key as soon as receiving an ACK would cause packet drops.

-- 
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/3212#issuecomment-552287760