Re: [quicwg/base-drafts] Client's initial destination CID is unauthenticated (#1486)

Martin Thomson <notifications@github.com> Wed, 27 June 2018 04:46 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 0D5AF130E7A for <quic-issues@ietfa.amsl.com>; Tue, 26 Jun 2018 21:46:57 -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 m_aTSaAhJpyX for <quic-issues@ietfa.amsl.com>; Tue, 26 Jun 2018 21:46:55 -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 DD19B126F72 for <quic-issues@ietf.org>; Tue, 26 Jun 2018 21:46:54 -0700 (PDT)
Date: Tue, 26 Jun 2018 21:46:54 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1530074814; bh=zsxvDf9q+sEe3ibbTxDebNYLkfjLBTnjXYJG6faDUDw=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Q0aMQgLGME3jD0WBnjIaYOKrH0BhwHy448rmhoOlm3nbLVJlpZCNFN159htIuOsbU D18gPgms0yFR1IPq+qYzXbwEDr9HyYCEWPor0FARQ+DEoRrHm8PeYANcACRYyINn/S WgvuwHYqHyhBqineNb2tshBvfE6/cLfiT/GjS4wM=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab093c8fe073be2513a55d27e69d48962e01254d3f92cf00000001174ad8be92a169ce140801b8@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1486/400541391@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1486@github.com>
References: <quicwg/base-drafts/issues/1486@github.com>
Subject: Re: [quicwg/base-drafts] Client's initial destination CID is unauthenticated (#1486)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b3316be3a548_548a3fa6377aef781880c1"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/93WV5k2I7lEoszpw55HdW59o6VI>
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, 27 Jun 2018 04:46:57 -0000

The current design allows for considerable flexibility in routing up until the point that the first Handshake packet commits to a set of connection IDs.  Part of that flexibility allows for changing the connection ID.

A server could decide to validate changes using the token it passes to clients in Retry packets, if it chose to do so.  This could validate the entire sequence of changes, at a modest cost in bytes.

The only protection a client has is that packets from Handshake on are authenticated with end-to-end keys.  An attacker can't modify these packets.  If the client doesn't change its opinion about its connection ID - and it has no reason to do so that I'm aware of - then an attacker can't change the client connection ID value without causing packets to be dropped eventually.

The server has the same protection available, though our design allows multiple options for a server to change connection IDs.  So the only value that is authenticated is the final value, which might not have been reached honestly if - for example - an attacker has used spoofed Retry packets to route the client to a sub-optimal server instance.

If the goal here is to authenticate the chain of connection IDs that are used, starting from the randomized value selected by the client, then it needs to cover more than a single value.

-- 
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/1486#issuecomment-400541391