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

MikkelFJ <notifications@github.com> Thu, 21 June 2018 05:58 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 7323D13102A for <quic-issues@ietfa.amsl.com>; Wed, 20 Jun 2018 22:58:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.009
X-Spam-Level:
X-Spam-Status: No, score=-8.009 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, URIBL_BLOCKED=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 Ss7E_1i8-wT8 for <quic-issues@ietfa.amsl.com>; Wed, 20 Jun 2018 22:58:03 -0700 (PDT)
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 E3EFF130F20 for <quic-issues@ietf.org>; Wed, 20 Jun 2018 22:58:02 -0700 (PDT)
Date: Wed, 20 Jun 2018 22:58:02 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1529560682; bh=OzBFjxunudbRNTi6lYFzZiYAYJhFU0D2fKfeNXC1P6w=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=sPY1WFW0pzL4+i3TuZtVQ7jqDEfyM38K3MdCOLtWRXuzv+3K+75VQOzWvFMOxwYM7 ZRxHbTA4HeSlR4Mw8O+sEB6mukPkfw+xw5+M3isngVK0yFx5sBAUlvwiIAr8ncMwR6 G6E3/FoH+V2BiqTGkLAP1XQazWYGw22oeTKkoLNk=
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab5b2f74eaafa278545b52a401a00608dd3ac283eb92cf000000011743006a92a169ce13d69366@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/398985376@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_5b2b3e6a1ece0_1f7a3fc0b9696f7c23831"; 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/0kGlXupWrJeCBYHqu7eKbW_f2jg>
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: Thu, 21 Jun 2018 05:58:06 -0000

I believe the initial packet should always contain 1280 bytes, also after RETRY, otherwise an attacker might learn how to construct retry SCID's and use a second flight INITIAL as a DDoS vector.

The initial key should also be derived based on the NONCE in the current INITIAL packet. So, as I suggested before, it makes sense to carry the NONCE separately and make the initial DCID empty - at cannot be used for safe routing anyway and it simplifies routing logic because LB's don't have to know if the INITIAL DCID is random or not, they just have to take a decision based on emptiness.

The source SCID cannot be used as that NONCE without adding complexity to the clients LB infrastructure in a P2P server configuration. So I believe the NONCE should be a separate field. And it will not waste any space if the premise holds that all initial packets must be 1280 to prevent attacks.

-- 
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-398985376