[quicwg/base-drafts] secdir review of -qpack; issue 11 (#4399)

Lars Eggert <notifications@github.com> Fri, 20 November 2020 09:21 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 749763A1A37 for <quic-issues@ietfa.amsl.com>; Fri, 20 Nov 2020 01:21:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.554
X-Spam-Level:
X-Spam-Status: No, score=-1.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 s7phUUaI3Uht for <quic-issues@ietfa.amsl.com>; Fri, 20 Nov 2020 01:21:41 -0800 (PST)
Received: from smtp.github.com (out-22.smtp.github.com [192.30.252.205]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 213743A16C4 for <quic-issues@ietf.org>; Fri, 20 Nov 2020 01:21:41 -0800 (PST)
Received: from github.com (hubbernetes-node-e9cd32e.ac4-iad.github.net [10.52.118.44]) by smtp.github.com (Postfix) with ESMTPA id 59F075606B6 for <quic-issues@ietf.org>; Fri, 20 Nov 2020 01:21:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1605864100; bh=NPImBaurldgmPD5mzCM0eZcg3IM5WXPfv23rtqu4wXE=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=R80NchFzmu6CphXkhmlQ3EwAu20H/QTCBGGUl/1y2lHmMd4bWPi1yEYYjO0h3mxiD uEJvfXAG3KLOuAtTs1XVwSK5vipYsw8RLFXslv99RlAArQF1Iu87bfADn5FrXfH6id uqO3QpxCHzJq3qtVpiMYd4RDRW78yjjiZ2onT8pg=
Date: Fri, 20 Nov 2020 01:21:40 -0800
From: Lars Eggert <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZBJDS7EJVYPQAXHXV5YNV2JEVBNHHCZC2GOY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/4399@github.com>
Subject: [quicwg/base-drafts] secdir review of -qpack; issue 11 (#4399)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5fb78aa4496fd_3e19b4129728"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: larseggert
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/eXat0Ek7pRoJR5f45LsHBrXBYcE>
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, 20 Nov 2020 09:21:42 -0000

Magnus Nystrom [wrote](https://datatracker.ietf.org/doc/review-ietf-quic-qpack-19-secdir-lc-nystrom-2020-11-19/):
>  - The security considerations section is well written, but the attack
   scenario of "mutual distrustful parties" is unclear to me. One stated
   scenario is where multiple client connections aggregate at an intermediary
   that then maintains a single connection to an origin server. Another stated
   scenario is where multiple origin servers connect to an intermediary which
   then serves a client. In these scenarios, is the concern that the
   intermediary may control either a client or an origin server and thus would
   be able to leverage the compression context at, say, a second client and
   then observe (as the intermediary) the result of a guess for a field tuple?
   It may be helpful to explain this in a little more detail.


-- 
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/4399