IETF Logo Mail Archive

Re: [quicwg/base-drafts] Connection migration should be indistinguishable from a new connection (#203)

Kazuho Oku <notifications@github.com> Mon, 05 February 2018 08:56 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 8F70312946D for <quic-issues@ietfa.amsl.com>; Mon, 5 Feb 2018 00:56:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, 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 CCISrJzdHKIj for <quic-issues@ietfa.amsl.com>; Mon, 5 Feb 2018 00:56:37 -0800 (PST)
Received: from github-smtp2a-ext-cp1-prd.iad.github.net (github-smtp2-ext7.iad.github.net [192.30.252.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3F601241F5 for <quic-issues@ietf.org>; Mon, 5 Feb 2018 00:56:36 -0800 (PST)
Date: Mon, 05 Feb 2018 00:56:36 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1517820996; bh=rNzVK7KFGYZEnPtGFFT1rWMoPxlGagiBJjmQJVu7cVQ=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=aMuJT1wu42BEhGy1J4q8KYCpHvyPzcDjnNmUJVJJOWxxRvz3tC53jOq5YsvH5vBlH uWtv7zoWSC9k8rnAI8I0uqrFY9WmnSii/lvoBZOWjmr3F+7EqXOXiufbUo/X1kju6q Sypc2mVDq3vMRhWUSEgxi2CPAon7lU+zT6vzJz00=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab04c04ea47bde161841b823db285e198b7fefbe9192cf00000001168fde4492a169ce0c118d76@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/203/363019619@github.com>
In-Reply-To: <quicwg/base-drafts/issues/203@github.com>
References: <quicwg/base-drafts/issues/203@github.com>
Subject: Re: [quicwg/base-drafts] Connection migration should be indistinguishable from a new connection (#203)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5a781c444f03_689e3fc45447ef344144c5"; 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/MdmoJgVB1ocSpf_00e1WJxuaIt0>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.22
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, 05 Feb 2018 08:56:38 -0000

If ossification is the concern, I think we should eliminate the distinction between long and short packet headers.

There is no need for INITIAL and HANDSHAKE to have their packet type and version number sent in cleartext. The fields can be sent as part of the AEAD-encrypted payload. We can always use short header, and when seeing an unidentified CID, do a trial decryption to see if it is a pre-1-RTT packet that contains a type and version number.

If privacy is a concern, we need to generate and emit a new ECDH keyshare every time the connection migrates. I am not sure if we want to do that.

-- 
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/203#issuecomment-363019619

v2.37.1 | Report a Bug | By Email | System Status