IETF Logo Mail Archive

[quicwg/base-drafts] Discarding keys (#2378)

Tatsuhiro Tsujikawa <notifications@github.com> Mon, 28 January 2019 08:01 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 53723130FBA for <quic-issues@ietfa.amsl.com>; Mon, 28 Jan 2019 00:01:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.551
X-Spam-Level:
X-Spam-Status: No, score=-12.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, 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_PASS=-0.001, URIBL_BLOCKED=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 oF70tLqfG2vs for <quic-issues@ietfa.amsl.com>; Mon, 28 Jan 2019 00:01:04 -0800 (PST)
Received: from out-3.smtp.github.com (out-3.smtp.github.com [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0962E130FAF for <quic-issues@ietf.org>; Mon, 28 Jan 2019 00:01:04 -0800 (PST)
Date: Mon, 28 Jan 2019 00:01:03 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1548662463; bh=oUJxBy/gKf8ghyszF21DChSylwEqCf70sQoXnxxYrd0=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=L78UVXfpRnDHrXnEBzqGe6ZiSJAborCNdt+BbqgUOf7ibJSpmYK/L90I6vGWWZPsX meOF06SVKrdm1LSMAzznRMUALmiV00eNxlaIIKuMiZfnkIgirWEmK7vnW8MqmKQ/JZ hQJ3jrYFHzAObrg/M3c1AAInrR0LhNAF9+oL+pdU=
From: Tatsuhiro Tsujikawa <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab56c59be68ffc303dd9ccfe897077956f13bb0cc692cf00000001186678bf92a169ce180fd1de@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2378@github.com>
Subject: [quicwg/base-drafts] Discarding keys (#2378)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c4eb6bf29a3d_66823fa478ad45c42916189"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: tatsuhiro-t
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/l9oiiDNu-p8-0pXD_ZXoH_eCCOU>
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, 28 Jan 2019 08:01:06 -0000

https://tools.ietf.org/html/draft-ietf-quic-tls-17#section-4.9

>    After all CRYPTO frames for a given encryption level have been sent
   and all expected CRYPTO frames received, and all the corresponding
   acknowledgments have been received or sent, an endpoint starts a
   timer.

>    Once this timer expires, an endpoint MUST NOT either accept or
   generate new packets using those packet protection keys.  An endpoint
   can discard packet protection keys for that encryption level.

Suppose that client Handshake containing client Finished was received by server.  server sent its acknowledgement but it was lost.
In this situation, server starts timer (no?)
But client cannot start timer because it did not receive acknowledgement.  So client keeps resending Handshake packets. When timer expires on server, it discards key.  If client is unlucky, it still cannot get acknowledgement from server and keeps resending but server has already discarded key.
In this situation, when can client discard handshake key?
Should server start timer when it receives acknowledgement for the acknowledgement of client Handshake packet? 


-- 
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/2378

v2.23.0 | Report a Bug | By Email