Re: [quicwg/base-drafts] Looping with multiple Retry packets (#1451)

Kazuho Oku <notifications@github.com> Wed, 20 June 2018 22:24 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 B3E29130F36 for <quic-issues@ietfa.amsl.com>; Wed, 20 Jun 2018 15:24:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.01
X-Spam-Level:
X-Spam-Status: No, score=-8.01 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, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 4VxEteANgAqs for <quic-issues@ietfa.amsl.com>; Wed, 20 Jun 2018 15:24:46 -0700 (PDT)
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 CF3E3130F18 for <quic-issues@ietf.org>; Wed, 20 Jun 2018 15:24:45 -0700 (PDT)
Date: Wed, 20 Jun 2018 15:24:45 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1529533485; bh=shrVjdZtUmYISXdsjgDW7XoqVlRR7amxtgSneSBKklo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ldFKbNgoXbPaGedi34FKf8W65HovgrmIRHIkHV9qlHAtgelGr9otnEN1Ig75o0Zls 4LWiqBbE1E9oKltC3geLqnTODmY8G3HAhp+tnI4YUWlG/SrD6f/yAZ8r6e0x09qFpj Z+j6jRnld9NxOA3nTOQqdTszfIdzBkoAgbdi178Y=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab76d9741a79752a58775584f151d5943d3015d03492cf000000011742962c92a169ce13d69366@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1451/398917049@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1451@github.com>
References: <quicwg/base-drafts/issues/1451@github.com>
Subject: Re: [quicwg/base-drafts] Looping with multiple Retry packets (#1451)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b2ad42d1e81_40d83fb1c35f8f8415011b"; 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/zsGXcPKqNOh-cLElGBXH6gwHIU0>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.26
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: Wed, 20 Jun 2018 22:24:50 -0000

@ianswett:
> @kazuho why longer than 8 octets and not >=8 octets?
> 
> I would like the simple RETRY case to work as well, which is the server doesn't want to change the CID at all, and it is the terminal node, so I don't want to require senders of RETRY to be required to change CID.

I agree. My intent was to say `>= 8`. Sorry for the confusion.

> Related question: What CID is the client deriving the key for INITIAL packets from? I was thinking all INITIAL packets used the same key, but if the terminal server may not have seen the client's first DCID, that doesn't work unless the original DCID is put somewhere the final server can read in the token.

I agree with your observation, and think it would make sense to state that the DCID field of the Initial packet that carries the first Client Hello (i.e. the one that also gets padded up to 1280 octets) will be used as the key material.

-- 
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/1451#issuecomment-398917049