Re: [quicwg/base-drafts] Initials carrying different first ClientHello are considered as belonging to different connections (#2076)

MikkelFJ <notifications@github.com> Fri, 30 November 2018 19:23 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 67993130E73 for <quic-issues@ietfa.amsl.com>; Fri, 30 Nov 2018 11:23:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.46
X-Spam-Level:
X-Spam-Status: No, score=-9.46 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_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 OYTqttET2JsM for <quic-issues@ietfa.amsl.com>; Fri, 30 Nov 2018 11:23:22 -0800 (PST)
Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82592130E5E for <quic-issues@ietf.org>; Fri, 30 Nov 2018 11:23:22 -0800 (PST)
Date: Fri, 30 Nov 2018 11:23:21 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1543605801; bh=HK4wg4JkJsJ45YbGPtFPpciNw2LO7U1ofvNXko1Tc+k=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=UGSidQaikLnQh2r5WVRh1Z7FWIDXj/Z7RsxGPLIKJPREHhaAPWlE+I4ug3DjJ960T 1vCbW9WGp+POgILxl53uHt/nZkoaw+zptg+xGRFmkXoNDNFVxLO8gS96IjFFPZAUWX ZdOcohFoRVMpWXAhrRl9k4mWljJYr7EAhRPknmPo=
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abd08e8a6af9bf1baed6955f95dfc666b01d0ba40c92cf000000011819502992a169ce1701edfc@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2076/c443311377@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2076@github.com>
References: <quicwg/base-drafts/pull/2076@github.com>
Subject: Re: [quicwg/base-drafts] Initials carrying different first ClientHello are considered as belonging to different connections (#2076)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c018e298ce86_178c3fca94ed45c45037e3"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
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/Kec87Rsn-qTtOjtELefta1JD9gc>
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, 30 Nov 2018 19:23:24 -0000

Maybe this is a good approach but I'm not sure the exact approach is ideal.

If possible we should aim for a design that is not tightly coupled to TLS crypto content. We could for example add a nonce to the Hello and define that initial destination ID to be a specific well-defined hash of the Hello. The server then only needs to track the initial DCID but can verify incoming packets based on the hash. It is almost the same, but it gives the initial DCID more meaning.

If QUIC v.x does not use TLS, that version needs to make sure the initial DCID matches the critical signature of the first packet, which is then defined differently, but the mechanism remains the same. It might also be helpful to middleboxes?

-- 
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/2076#issuecomment-443311377