Re: [quicwg/base-drafts] Improve KEY_PHASE description (#43)

Dragana Damjanovic <notifications@github.com> Thu, 08 December 2016 20:08 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 16C83129543 for <quic-issues@ietfa.amsl.com>; Thu, 8 Dec 2016 12:08:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.5
X-Spam-Level:
X-Spam-Status: No, score=-6.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_SORBS_SPAM=0.5, 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 k35zMcnNb1rK for <quic-issues@ietfa.amsl.com>; Thu, 8 Dec 2016 12:08:19 -0800 (PST)
Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext3.iad.github.net [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 D316F129574 for <quic-issues@ietf.org>; Thu, 8 Dec 2016 12:08:18 -0800 (PST)
Date: Thu, 08 Dec 2016 12:08:18 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1481227698; bh=yNeC+497J7e81hj6uk2eZqEDmgd9TePGDPfFQ1oMSdI=; h=From:Reply-To:To:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Za76/XqqnM9sW7YW5WkhTj4Oe93T1zwdFV2arEkBrOELarx9KzX1czQf1sdXvIan7 AtRJJojOTHWTaYQ7/0B2ee+WHRRCXi7MDu06FiaLn4bHcumXvNPmfpKEPTZQeSgAxM lZhkrzUM2W1kXQGjje49fsrTrMHfe+naL18Ejx3s=
From: Dragana Damjanovic <notifications@github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/43/review/12106709@github.com>
In-Reply-To: <quicwg/base-drafts/pull/43@github.com>
References: <quicwg/base-drafts/pull/43@github.com>
Subject: Re: [quicwg/base-drafts] Improve KEY_PHASE description (#43)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5849bdb23833_79083f8b317d313c1206f9"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ddragana
X-GitHub-Recipient: quic-issues
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/9NjcIatn13Q9XYuLc2NWqL2tYQE>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.17
Reply-To: quicwg/base-drafts <reply+0166e4abe275d456ae8dde71a598ec7c2a0ee02c1d98457392cf0000000114617fb292a169ce0b74c956@reply.github.com>
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, 08 Dec 2016 20:08:21 -0000

ddragana commented on this pull request.



> +decrypt these packets, which will be unsuccessful.  Though a server that has
+1-RTT keys can safely discard any unprotected handshake messages from the
+client, an unprotected ACK frame could indicate that the server needs to
+retransmit its own handshake messages.  ACK frames therefore cannot be
+discarded.
+
+Until the server has received a positive acknowledgment for all of its
+unprotected handshake messages, either in the form of an explicit acknowledgment
+or implicitly through the use of 1-RTT keys, it MUST NOT discard packets with a
+KEY_PHASE of 0 if they cannot be decrypted successfully.  If these packets are
+unprotected and contain ACK frames, those ACK frames MUST be recovered and used
+to determine whether to retransmit TLS handshake messages.
+
+TBD:
+
+: We could observe/require that all unprotected packets are marked with a

I would suggest to have VERSION bit set not only for unprotected packets but for 0RTT encrypted packets as well. For 2 reasons:
1)VERSION number tells the server how to interpreter packet, so if ClientHello packet gets lost and server receives 0RTT encrypted packet it will not know how to read it because it does not know which protocol version it is. (if we do not change the packet format for different version it might be ok, but we do not want to ossify on this). In that case it would need to wait for ClientHello and it will not be able to send acks to trigger retransmits, the version change request from server will be delayed,etc.
2) we can remove asymmetry: unprotected packet have KEY_PHASE=0 and VERSION=1, 0RTT packets have KEY_PHASE=1 and VERSION=1 and 1RTT packet have KEY_PHASE=1 and VERSION=0 (which will be the same on the server side and the same as the case when 0RTT is not used)

-- 
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/pull/43