IETF Logo Mail Archive

Re: [quicwg/base-drafts] Disconnect with Initial Injection (#1951)

Marten Seemann <notifications@github.com> Fri, 30 November 2018 02:34 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 830AB12D4E7 for <quic-issues@ietfa.amsl.com>; Thu, 29 Nov 2018 18:34:22 -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 rsyvgxd6i4XI for <quic-issues@ietfa.amsl.com>; Thu, 29 Nov 2018 18:34:21 -0800 (PST)
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 CEF3712008A for <quic-issues@ietf.org>; Thu, 29 Nov 2018 18:34:20 -0800 (PST)
Date: Thu, 29 Nov 2018 18:34:19 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1543545259; bh=iZxkAVX9LNP911pQhG40zMRb7tcXX39S8gINTj1VBkk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=OVsIFgbGvIPMGwgFTJjya0oONpAaZ4fN4I4fzEY4AEOF/DLekiq+PlLQA51jWkNxD 3DSYtRh+8VqGSsH3V1L/Wb0pKNexJPpGPuw7Ktbsedd7Ee99FhXXBIHGtBYQ3/c4Kz KGF5SzKsFsvnmov68907I5vHP497bdkuL7qy0W4M=
From: Marten Seemann <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4aba2da10230b9faca9132c13249fa452a91142324992cf00000001181863ab92a169ce1678fc4e@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1951/443069551@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1951@github.com>
References: <quicwg/base-drafts/issues/1951@github.com>
Subject: Re: [quicwg/base-drafts] Disconnect with Initial Injection (#1951)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c00a1abbb7ff_55f33fa4bded45bc176911"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: marten-seemann
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/ZF3eil_smzXN5o4mdVq1W5l68Y8>
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 02:34:23 -0000

That seems like a very fragile solution to me. There are a lot more error conditions that than you describe (e.g. frames that are invalid in an Initial packet, incomplete frames, unknown frame types etc.).

It also feels wrong to me to act on some frames, and ignore other frames sent in the same packet. Either we have reason to believe that a packet was sent by an attacker, then we should drop it on the floor as a whole, or we believe it was sent by the peer, then we should process it entirely.

Dropping the keys as soon as possible has the beautiful property that we don’t have to worry about complex rules which packets are valid are which ones aren’t any more - since we know for sure that either way we don’t need to read these packets. 

-- 
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/1951#issuecomment-443069551

v2.23.0 | Report a Bug | By Email