Re: draft-tiesel-quic-unreliable-streams-01 - comments

"Philipp S. Tiesel" <phils@in-panik.de> Mon, 06 November 2017 09:16 UTC

Return-Path: <phils@in-panik.de>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA9013FB57 for <quic@ietfa.amsl.com>; Mon, 6 Nov 2017 01:16:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
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 Fqxxs68VvGBL for <quic@ietfa.amsl.com>; Mon, 6 Nov 2017 01:16:01 -0800 (PST)
Received: from einhorn-mail.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D8B313F963 for <quic@ietf.org>; Mon, 6 Nov 2017 01:15:59 -0800 (PST)
X-Envelope-From: phils@in-panik.de
Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id vA69EoLB021865 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 Nov 2017 10:14:50 +0100
Received: from [2001:638:809:ff1f::8295:dc66] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <phils@in-panik.de>) id 1eBdU6-0001i8-GO; Mon, 06 Nov 2017 10:14:22 +0100
From: "Philipp S. Tiesel" <phils@in-panik.de>
Message-Id: <B814D19D-2FD6-42B6-867E-8A26C7475E0F@in-panik.de>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D48B2C7E-C5D6-4E0C-AEC5-D2EA43096AF7"
Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\))
Subject: Re: draft-tiesel-quic-unreliable-streams-01 - comments
Date: Mon, 06 Nov 2017 10:14:49 +0100
In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD832288@DGGEMM506-MBX.china.huawei.com>
Cc: QUIC WG <quic@ietf.org>
To: Roni Even <roni.even@huawei.com>
References: <6E58094ECC8D8344914996DAD28F1CCD82A735@DGGEMM506-MBS.china.huawei.com> <FBF9665E-15CE-437B-A575-25AEA7C88073@in-panik.de> <6E58094ECC8D8344914996DAD28F1CCD832288@DGGEMM506-MBX.china.huawei.com>
X-Mailer: Apple Mail (2.3445.4.7)
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/BsxwifpQ2L_vsBgF5QyBltel9Wg>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2017 09:16:03 -0000


> On 5. Nov 2017, at 08:32, Roni Even <roni.even@huawei.com> wrote:
>> From: Philipp S. Tiesel [mailto:phils@in-panik.de]
>>> On 1. Nov 2017, at 14:03, Roni Even <roni.even@huawei.com> wrote:
>>> 
>>> In the security section “ An active, on path attacker can drop selected
>>> frames “ . What does it mean selected frames, the whole payload is
>>> encrypted.
>>> 
>> This is a little complicated:
>> - Assume having “stream-as-a-message” streams with two different kins of
>> messages sized A,B
>> - Assume each message fits into one packet, but two messages will not fit
>> - Assume one doesn't want to split packets to fill packets to MTU due to
>> latency constrains  => If an attacker know the inside protocol, the attacker
>> can distinguish from the packet length wether it is an A or B kind message
>> 
>> To avoid this, one has to pad all packets… I should clarify this.
> [Roni Even] I understand this case but what does selected frames mean, I assume that the attacker does not know what is in each stream in order to select a specific one, so why will he just drop one and not the other or why not both?


Assuming the attacker _knows the protocol_, the attacker would also know the sizes of all kinds of messages and may use this knowledge to recover protocol state or selectively drop messages.

For a protocol like HTTP, the attack vector is rather small.
If one uses this against video conferencing applications, an attacker could prevent rate adaption  by dropping reception reports (larger than a pure QUIC ACK, smaller than a video frame).
If one uses this on IoT control stuff, an attacker might be able to learn a lot about the system state by observing sizes and timings.

This is nothing we can fix within QUIC without massive scarifies, but application developers must keep in mind.


AVE!
  Philipp S. Tiesel / phils…
-- 
   {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----,
      wenn w eine   aube ist dn      man au dran dre en                   |
           o     Schr        an muss     hc         h   (Kurt Schwitters) |
:wq!  <----(phone: +49-179-6737439)---<---(jabber: phils@in-panik.de)----'