[quicwg/base-drafts] Set PTO Timer when discarding keys (#3613)

martinduke <notifications@github.com> Thu, 30 April 2020 01:20 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 248A03A0C3A for <quic-issues@ietfa.amsl.com>; Wed, 29 Apr 2020 18:20:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.302
X-Spam-Status: No, score=-2.302 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, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.82, 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 nt4GEZ7l33f6 for <quic-issues@ietfa.amsl.com>; Wed, 29 Apr 2020 18:20:28 -0700 (PDT)
Received: from out-25.smtp.github.com (out-25.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 44E0A3A0C39 for <quic-issues@ietf.org>; Wed, 29 Apr 2020 18:20:28 -0700 (PDT)
Received: from github-lowworker-f62aa54.va3-iad.github.net (github-lowworker-f62aa54.va3-iad.github.net []) by smtp.github.com (Postfix) with ESMTP id 2C2E6282B9D for <quic-issues@ietf.org>; Wed, 29 Apr 2020 18:20:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1588209627; bh=uPeptfXwNtt6t1ZNxuYvZpOwo8a0xuhnPgr95U4HG5Q=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=DI/E7aEE4P0/dI5+0bNhYzKNqO01O3d5VV8UskNyxhsX2Q1XxJ0b2u0LX4VhWCG6C KtytHsKDLgvKXnpA+69Jv9MpP7zo4YdL5qjCMlrJfNUEJ0xBnTXM9vWoF4uG39AWYI E1My//iVlS3xXskHZmAfi44bP1sJZZD209cbnr20=
Date: Wed, 29 Apr 2020 18:20:27 -0700
From: martinduke <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4CUZ3NJYLNEFT7OFF4WYENXEVBNHHCIVAFGY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3613@github.com>
Subject: [quicwg/base-drafts] Set PTO Timer when discarding keys (#3613)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5eaa27db1cf91_3fbe3fa61aacd960135487"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinduke
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/xdwMpZDQxRzefDUuqqoCDsnfNu0>
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: Thu, 30 Apr 2020 01:20:31 -0000

In the recovery draft, the pseudocode does something approximately right (appendix B.9, unfortunately buried in the congestion control example).

There is, however, no text in the spec that says you should set the PTO again when discarding keys if there is still outstanding data in the remaining contexts. This opens up some bizarre corner cases:

Server sends handshake flight + 1RTT
1RTT packets lost
Client acks the handshake flight -- all HS data is acked, and because the HS is not complete we do not set the PTO timer for the 1RTT data.
Client Finished arrives -- no action required by the spec.

It's true that HANDSHAKE_DONE will cover this in the server case, but in the client case where 0RTT is lost, the client might never send a 1RTT ack-eliciting packet. Better for us to tell the server to arm PTO when the handshake is confirmed. Better yet to do it when the handshake is complete, rather than when the keys are discarded (handshake confirmed).

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