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

Kazuho Oku <notifications@github.com> Mon, 07 January 2019 06:08 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 7C735128CF3 for <quic-issues@ietfa.amsl.com>; Sun, 6 Jan 2019 22:08:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.065
X-Spam-Level:
X-Spam-Status: No, score=-8.065 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, 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 J1Su6BMX5i_I for <quic-issues@ietfa.amsl.com>; Sun, 6 Jan 2019 22:08:34 -0800 (PST)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F6A81274D0 for <quic-issues@ietf.org>; Sun, 6 Jan 2019 22:08:34 -0800 (PST)
Date: Sun, 06 Jan 2019 22:08:32 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1546841312; bh=J1/GMf1a1AnK1p5jnaQiSU9h/lFQ0vKz3d6ovMXYrJ4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=F7jSjptWcmKM8qUXEg7F6AK9hiyJS/sP2YnkS60aUjyb+63FxhXNOaT6Kq225Btcq KwY7lUedPyKZI9kyVkEPVQdCIEk+QufydW4XNoVE5K4NHGiHWGsvg6dCaFxI6tvib5 JADyRXkWLLbc72ad9yzC0za5r7ISgCEnsrZ83MsA=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab7dcdf549f113ef31177023c8f46625e8d521560e92cf00000001184aaee092a169ce179fbcfb@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/451831439@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_5c32ece0a5c87_13bd3f99300d45b8879022"; 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/JKy-G5iV78Asnr-_XPwI8o8ZifI>
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: Mon, 07 Jan 2019 06:08:36 -0000

>> For example, an attacker can also send a packet that successfully decrypts, that contains many tiny CRYPTO frames (4-bytes each). I'd assume that processing of that would be more costly than AEAD-decrypting every 35 bytes.
> 
> I don't understand this. Why is processing CRYPTO frames expensive? In my implementation, assembling stream (and crypto stream) data is not an expensive operation.

Because for every 4-byte CRYPTO frame (containing 1 octet of data), you need to decode 2 varints (length and offset fields), check if it's newly received data, and then write it to the buffer. If the data is new, there would be a call to TLS stack that causes the TLS stack to see if the entire handshake message is available, which would turn out not to be true. TLS stack will then buffer the data. After that, the transport layer will remove the newly received data from the transport-level buffer.

My assumption is that doing this amount of processing is more heavyweight than running two AES operations and one GCM operation per every 35 bytes.

Based on that, I do not think we need a statement that specifies how to handle these tiny CRYPTO frames, or similar types of attacks (e.g., a packet payload containing many ACK frames). The same goes for not specifying how to handle tiny QUIC 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/2308#issuecomment-451831439