Re: [quicwg/base-drafts] handling of coalesced packets with decryption errors creates DoS opportunity (#2308)

Kazuho Oku <notifications@github.com> Wed, 08 May 2019 23:52 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 996DA120240 for <quic-issues@ietfa.amsl.com>; Wed, 8 May 2019 16:52:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.606
X-Spam-Level:
X-Spam-Status: No, score=-6.606 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_IMAGE_ONLY_28=1.404, 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 6A1Xjli5tGzY for <quic-issues@ietfa.amsl.com>; Wed, 8 May 2019 16:52:04 -0700 (PDT)
Received: from out-3.smtp.github.com (out-3.smtp.github.com [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43F71120091 for <quic-issues@ietf.org>; Wed, 8 May 2019 16:52:04 -0700 (PDT)
Date: Wed, 08 May 2019 16:52:03 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1557359523; bh=JfAtpuDAk+XwQmcfxN0sL1j8y1qCXvVeMPDwbKl8fYQ=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ML2rNCveHCCPDieV6oRLtgJRfVYn9B1DXlE6JE/rjNRVcEBXUGS+IgPan501W+Duz Ps15k7e+5ya6AG3InhSlcNcvT+Km/x/w8qG3BQf++HvmJ4pq9CeYLiPwg4yIycUnKJ ENBEpWTFnCir7zJuwhwKjv/lyt8ZyQnweyailt3M=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK6KUFUKSVZKHPI47NN24CPCHEVBNHHBPH547M@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2308/490692288@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2308@github.com>
References: <quicwg/base-drafts/issues/2308@github.com>
Subject: Re: [quicwg/base-drafts] handling of coalesced packets with decryption errors creates DoS opportunity (#2308)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5cd36ba34cd82_5a8f3fcdf08cd96414457d"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/Pes7LhREv0OXwupOtaOkDyZPfFE>
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: Wed, 08 May 2019 23:52:20 -0000

@huitema 
> implementations are free to drop packets for whatever reason. In the rare cases of false positive, when the funny coalesced packet is not in fact an attack, the peer will just resend after at time out.

IIRC, one of the concerns regarding this approach was that we might see a deadlock if the peer has dropped the keys necessary for processing the the first packet within a datagram, and decides to drop the entire datagram due to not being able to process the first packet. Then, the endpoint might simply retransmit the coalesced datagram that starts from the same packet type as the previous datagram, and that datagram again gets dropped by the server, and ...

Therefore, it has been my view that it is beneficial to specify the minimum requirements that guarantees the connection to make progress. IIRC, my preference was to define a minimum number of packets within a single datagram that a receiver should process. But I am fine with what we have in the text right now, because it does not make the implementations complicated; a sensible sender would never send a datagram containing more than one packet at the same encryption level, detecting them on the receiver-side is an implementation choice.

-- 
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/2308#issuecomment-490692288