Re: [quicwg/base-drafts] Authenticating connection IDs (#3439)

Christian Huitema <notifications@github.com> Thu, 05 March 2020 05:49 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 BF0933A0D87 for <quic-issues@ietfa.amsl.com>; Wed, 4 Mar 2020 21:49:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.099
X-Spam-Level:
X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_HELO_NONE=0.001, 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 6VA72iWdmM6c for <quic-issues@ietfa.amsl.com>; Wed, 4 Mar 2020 21:49:27 -0800 (PST)
Received: from out-16.smtp.github.com (out-16.smtp.github.com [192.30.254.199]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7810A3A0D42 for <quic-issues@ietf.org>; Wed, 4 Mar 2020 21:49:27 -0800 (PST)
Date: Wed, 04 Mar 2020 21:49:26 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1583387367; bh=Wbiv0BO4ykFG//VDCNtpOFtxC40X0vAlqIZh3E14zck=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=om/+tTTo0cKDVnfLnkWdsDbeRBWXTJEtwO8snmUIiKDqaDvpgXhsVab6q/cfB/mU1 9XXUxakx1uj8/MvLog+jU+WRAPDxX/6bwNsIwZozOIS+1cqTv2l26rcRrs4BsIAQuS 5NGxM2J3sCAfxQnUjsOFXUuDQ0EfwN9fgDPjZdjs=
From: Christian Huitema <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK2W7YYAA6NQNQL2X454NRZ6NEVBNHHCC4LIRI@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3439/595041061@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3439@github.com>
References: <quicwg/base-drafts/issues/3439@github.com>
Subject: Re: [quicwg/base-drafts] Authenticating connection IDs (#3439)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e6092e6a00bc_56713fd17b8cd96c371340"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: huitema
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/Donsxbn1sE0DB0cQcgABd_7_wOw>
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: Thu, 05 Mar 2020 05:49:30 -0000

What are the required attackers capabilities in order to mount this attack? Clearly, it can be mounted by a MITM, but MITM can do a lot of creative damage during the initial handshake. Can it be mounted by a Man-on-the-side?

In QUIC V1, we understand that authentication only starts when keys are exchanged. The connection-id attack appears to cause the connection to fail because connection IDs are authenticated in 1-RTT packets. That's bad, but there are many ways for MITM to interfere with the connection set up and cause the connection to fail at 1RTT. Do we really want to do something specific about the connection ID? Isn't that an example of piecemeal solutions that make the design complex without blocking all the holes?

We know the general outline of a stronger solution. It is presented in the authenticated handshake draft: derive a secret from the ESNI key of the server, use that secret to authenticate all initial packets. Doing that will suppress not just the connection ID attack, but also the whole class of "attacks by messing up with initial packets". I would much rather authenticate the handshake that pile up piecemeal solutions.

The working group has decided to push the authenticated handshake work to V2, and to accept that there may be DOS attacks during the initial handshake. Is the connection ID attack so special that we need to delay V1 for it?

-- 
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/3439#issuecomment-595041061