Re: [quicwg/base-drafts] Let Endpoints Ignore invalid Initial Packets (#1819)

martinduke <notifications@github.com> Thu, 18 October 2018 23:43 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 B6D3E130E67 for <quic-issues@ietfa.amsl.com>; Thu, 18 Oct 2018 16:43:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.064
X-Spam-Level:
X-Spam-Status: No, score=-8.064 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.064, 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 R82k6Ww95Qug for <quic-issues@ietfa.amsl.com>; Thu, 18 Oct 2018 16:43:21 -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 74012130E64 for <quic-issues@ietf.org>; Thu, 18 Oct 2018 16:43:21 -0700 (PDT)
Date: Thu, 18 Oct 2018 16:43:20 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1539906200; bh=BuUV4eZbii6xQ1+rx2eCx/ruk1lwNt5Hwot4+si95wo=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=XwJoqQM+gYSFqhPsqTWmQoqE0XUFpMUkx9Gud+exFFf3epjhhp2pUOSXkOAbEWZQX OGHWjakjjZsNVSUdqxRjheF2RoEDjVdWhBsvfmCBgdlKnufcJ1g4uTsSHacA+41nnx TCY25Fr5dF2ELzTGZW//Au0q5lIAz5Pu8C2hpwes=
From: martinduke <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abbe969a7ab9446cdbcab565313eb7caecfd35c24992cf0000000117e0dc9892a169ce15cbb1a4@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/1819/review/166336515@github.com>
In-Reply-To: <quicwg/base-drafts/pull/1819@github.com>
References: <quicwg/base-drafts/pull/1819@github.com>
Subject: Re: [quicwg/base-drafts] Let Endpoints Ignore invalid Initial Packets (#1819)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bc91a98bafec_606e3f86eecd45c411744b"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinduke
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/LswMqi9llUCVSkIwfWTEoLgnoZQ>
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, 18 Oct 2018 23:43:24 -0000

martinduke commented on this pull request.



> @@ -736,6 +733,18 @@ and will contain a CRYPTO frame with an offset matching the size of the CRYPTO
 frame sent in the first Initial packet.  Cryptographic handshake messages
 subsequent to the first do not need to fit within a single UDP datagram.
 
+### Handling of Fatal Initial Packets
+
+The contents of some Initial packets may, according to this specification, force
+connection termination. For example, they might contain forbidden frame types
+or a CONNECTION_CLOSE frame. As Initial packets are not protected, these could
+indicate injection attacks to terminate the connection.
+
+Endpoints MAY treat the receipt of such packets as a connection error, drop them

There is nothing you can really do about injection attacks during the Initial phase of the handshake. This PR is more about the 3RTT (or, for lazy implementations, infinite) time that the initial keys remain lying around for use. This radically increases the time where a connection is vulnerable (especially if the server uses the client-generated CID, so that Initial keys are easy to generate).

In that context, I'm not sure how you would meaningfully process a late-arriving Initial Packet. Say the attacker sends the server Initial Packet #2 well after the handshake, with ACK, CRYPTO, and CONNECTION_CLOSE frames. Since Initial exchange is actually done, there are no outstanding packets to ACK. Since I've already started handshake CRYPTO exchange, it's too late to deliver any new CRYPTO data. So it is basically impossible to use frames to alter connection state except to bring down the connection by generating an error.

If your code sends off an ACK before processing the frames, that is a problem, but that seems like a bad thing to do for other reasons.

-- 
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/1819#discussion_r226498538