Re: [quicwg/base-drafts] Stronger migration handshake (#2370)

Christian Huitema <notifications@github.com> Mon, 28 January 2019 01:43 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 EE04F130F2C for <quic-issues@ietfa.amsl.com>; Sun, 27 Jan 2019 17:43:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -11.149
X-Spam-Level:
X-Spam-Status: No, score=-11.149 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_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-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 tmOdAR1kzsiA for <quic-issues@ietfa.amsl.com>; Sun, 27 Jan 2019 17:43:25 -0800 (PST)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BC00130EA4 for <quic-issues@ietf.org>; Sun, 27 Jan 2019 17:43:25 -0800 (PST)
Date: Sun, 27 Jan 2019 17:43:24 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1548639804; bh=ANWd5fjdXt6ImFa37cz1ZZB+O0E4qnOGe43hFwAxAm8=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=M8XNA1cE/p50JzAG5JYkxe4p4J0QEEc1wALZnPjVRDWDRBdsig+tRDJOmzUMAXBF8 nBWmjIhfIzFMbGus7PGhWMB42LdTSNdwIBwY9fQGqMIPCMvnZdnpx9jwyBXLE1ib0x QLh97bNqgh78n9V+UFnWwQq11shebsJy98YTF1yM=
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abe2f02bb6f38777be2ba87bd7aa72e95da0873ebd92cf000000011866203c92a169ce180d1061@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2370/review/196856940@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2370@github.com>
References: <quicwg/base-drafts/pull/2370@github.com>
Subject: Re: [quicwg/base-drafts] Stronger migration handshake (#2370)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c4e5e3c6702d_55453f86d40d45b89403ee"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
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/yBlJ6jgRV7zimZdYZKcPiR30dg0>
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 01:43:27 -0000

huitema commented on this pull request.



>  endpoints retaining a stable address for the duration of the handshake.
+An endpoint MUST NOT initiate connection migration before the handshake is
+finished for it and its peer and the endpoint has 1-RTT keys. This means
+that the server MUST NOT initiate connection migration before it has
+received at least one 1-RTT data from the client, and the client 
+MUST NOT initiate connection migration before receiving 
+acknowledgement by the server of at least one of its
+1-RTT messages.

I really don't like the CRYPTO frames reference. There is no FIN mark on the crypto stream, and the QUIC engine proper does not know when "all crypto frames" have been received. I was careful to use signals that the transport stack understand: obtaining keys, receiving packets, etc.

-- 
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/2370#discussion_r251266038