Re: [quicwg/base-drafts] unrecoverable loss pattern leads to deadlock (#2863)

Kazuho Oku <notifications@github.com> Fri, 18 October 2019 07:04 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 610A71207FC for <quic-issues@ietfa.amsl.com>; Fri, 18 Oct 2019 00:04:07 -0700 (PDT)
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 WU3hkIGYP_nh for <quic-issues@ietfa.amsl.com>; Fri, 18 Oct 2019 00:04:05 -0700 (PDT)
Received: from out-18.smtp.github.com (out-18.smtp.github.com [192.30.252.201]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3ACD1202A0 for <quic-issues@ietf.org>; Fri, 18 Oct 2019 00:04:05 -0700 (PDT)
Received: from github-lowworker-fb56993.ac4-iad.github.net (github-lowworker-fb56993.ac4-iad.github.net [10.52.19.31]) by smtp.github.com (Postfix) with ESMTP id EDD666E1295 for <quic-issues@ietf.org>; Fri, 18 Oct 2019 00:04:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1571382244; bh=M5DnfrAqwxYs7uQHZ8VFvbMahEJ7Id8MasHSlRkbom8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=FK1laNMeCBwTt7z/63Ub3YHzpH6Or4COF4bU2fP1X60UI5731swKViA0TBTw96Mye O5awExyHHRU9dgScx6PkI9UrXXJNvYGE3v3B2zg570sXa0lLplCiC3TNsUSD/nzD+C Q4sTi7wKEhFhrwNjFJIrbzzPl9shNhOvoLUIuc/Q=
Date: Fri, 18 Oct 2019 00:04:04 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3XHFTZ5XZM33RUBJN3W2SHJEVBNHHBXDZPBM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2863/543555764@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2863@github.com>
References: <quicwg/base-drafts/issues/2863@github.com>
Subject: Re: [quicwg/base-drafts] unrecoverable loss pattern leads to deadlock (#2863)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5da963e4de285_5f643fa1d8acd9603192e5"; 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/VGF6XKjY2GdoMX1kkKPQxP8lo0s>
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: Fri, 18 Oct 2019 07:04:07 -0000

Regarding the way on discarding the Handshake keys, I think the failures the WG have made until now are that we have been looking for a clever method in trying to *infer* when a Handshake key can be dropped, and/or using 1-RTT packet to tell the peer that the peer can drop the handshake keys (the problem here is that the peer might continue retransmitting Handshake packets if the endpoint ceases to send 1-RTT packets). Based on the discussion in Cupertino, I think that if we are to drop the Handshake keys, we should adopt a safer approach.

I'd argue that there exists a class of approaches that can be considered safe. That is to require an endpoint to retain the Handshake keys until the peer sends an explicit signal instructing the endpoint to drop the Handshake keys. Assuming that my observation in [the comment right above](https://github.com/quicwg/base-drafts/issues/2863#issuecomment-543540677) is correct, we'd also need to adjust the transition to the handshake confirmed state to when an endpoint sends and receives that message.

That signal can be a new frame, a header bit, or a KeyUpdate.

-- 
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/2863#issuecomment-543555764