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

ekr <notifications@github.com> Sun, 10 November 2019 22:41 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 []) by ietfa.amsl.com (Postfix) with ESMTP id A438D120115 for <quic-issues@ietfa.amsl.com>; Sun, 10 Nov 2019 14:41:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.596
X-Spam-Status: No, score=-6.596 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_28=1.404, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 6fZmtHobV7H2 for <quic-issues@ietfa.amsl.com>; Sun, 10 Nov 2019 14:41:06 -0800 (PST)
Received: from out-6.smtp.github.com (out-6.smtp.github.com []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCD4B120044 for <quic-issues@ietf.org>; Sun, 10 Nov 2019 14:41:06 -0800 (PST)
Received: from github-lowworker-d31a065.va3-iad.github.net (github-lowworker-d31a065.va3-iad.github.net []) by smtp.github.com (Postfix) with ESMTP id E928C1C0507 for <quic-issues@ietf.org>; Sun, 10 Nov 2019 14:41:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1573425665; bh=L4R/2fRYeI5GyZdwmSs9wnwZ2I9iMW/7uQsP+TdapPc=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=ooRX2zclkjibH56avsAVc6giim3dW5Pp5jlx2/Hhtd7csAcYI5uduEwRmNFVWbZ0q 6n3br1G8hhKoNS34FF8zjL7zZpMNvfuMPLnO+SgOrbPkkT2YHalO2enywSV5JNnicJ hqTYAdPnDE7yagPqJJ51YBNwGNOrcEsVESsLW844=
Date: Sun, 10 Nov 2019 14:41:05 -0800
From: ekr <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2Y6YJZJG3467CB2CN32XCIDEVBNHHB6CGIZA@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@github.com>
Subject: [quicwg/base-drafts] Remove handshake confirmed test for KeyUpdte (#3212)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dc89201dace2_36aa3fbe58ecd96013530c4"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ekr
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/FBD0gNlXB-yv-E_CwBJlLt8weeo>
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: Sun, 10 Nov 2019 22:41:09 -0000

S 6.1 Says

   An endpoint MUST NOT initiate a key update prior to having confirmed
   the handshake (Section 4.1.2).  An endpoint MUST NOT initiate a
   subsequent key update prior unless it has received an acknowledgment
   for a packet that was sent protected with keys from the current key

However, I believe that the requirement to have confirmed the
handshake is redundant. As a reminder, the conditions under which the
handshake is confirmed are:

   (1) the handshake is complete, and
   (2) the endpoint has received an acknowledgment for a
       packet sent with 1-RTT keys

1. On the client side, the 1-RTT keys aren't available until the handshake
   is complete, so it's not possible to send 1-RTT packet and therefore
   not possible to have them ACKed.

2. On the server side, the 1-RTT keys are available before the handshake
   is complete, but because the server is forbidden from reading any
   1-RTT data before processing CFIN (S 5.6), it *also* cannot have
   received an acknowledgement for a packet sent with 1-RTT keys.

In other words, condition (2) implies condition (1), no?

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