[quicwg/base-drafts] Is Retry a new connection or what? (#2180)

ekr <notifications@github.com> Fri, 14 December 2018 01:15 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 38E3C130F03 for <quic-issues@ietfa.amsl.com>; Thu, 13 Dec 2018 17:15:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.459
X-Spam-Level:
X-Spam-Status: No, score=-9.459 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, 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] 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 6hKBXzwmx0QY for <quic-issues@ietfa.amsl.com>; Thu, 13 Dec 2018 17:15:33 -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 CEFC6130EF7 for <quic-issues@ietf.org>; Thu, 13 Dec 2018 17:15:32 -0800 (PST)
Date: Thu, 13 Dec 2018 17:15:31 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1544750131; bh=rsxDGl2WbQipXIAbxhrepmZE57ET4/FONrTxfDBsjhU=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=VSCD3pKlPGYKgyL834/UCcujiysoDhDyaWGn5ro5dTH2rJNlCDwJuX7v1Cw/9DzCq Xj8s14egxn46LWUQztkqXQmEq6y/NVx0czEU0F1LfzL1egYTGn5HMasia9nSwJQl20 rdoMqTU3ANxxngVnXvMPaHg/MJrY47up/Rw2hAIo=
From: ekr <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab72da610b3d96fa91439301e910bb4409f3ec496192cf00000001182ac63392a169ce174d10b9@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2180@github.com>
Subject: [quicwg/base-drafts] Is Retry a new connection or what? (#2180)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c130433e6978_78943f8b918d45bc1782a2"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ekr
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/sggdm4sl3disQLn0vooq1-ww25w>
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, 14 Dec 2018 01:15:35 -0000

I've been trying to reason about Retry and in particular the following text:

```
   The next Initial packet from the client uses the connection ID and
   token values from the Retry packet (see Section 7.2).  Aside from
   this, the Initial packet sent by the client is subject to the same
   restrictions as the first Initial packet.  A client can either reuse
   the cryptographic handshake message or construct a new one at its
   discretion.
```

This seems like it really is saying that a Retry is a new connection, and in particular that the server cannot memorize the CRYPTO from the previous Initial (which it might otherwise choose to do). I'm still trying to figure out if this is the right answer, but it seems confusing to allow the client to have both behaviors, especially as we encourage the "construct a new one". Also, if you construct a new one, could you potentially reuse the KeyShare values (might be an issue with PQ). 

I'm not quite sure what I think about this, but I wanted to post an issue to see if other people think it's weird and if so, maybe we should take a more prescriptive stance.

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