[secdir] Secdir review of draft-ietf-quic-qpack

Magnus Nyström <magnusn@gmail.com> Thu, 19 November 2020 06:00 UTC

Return-Path: <magnusn@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62D3E3A0E29 for <secdir@ietfa.amsl.com>; Wed, 18 Nov 2020 22:00:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 8ckqPO8ErNpM for <secdir@ietfa.amsl.com>; Wed, 18 Nov 2020 22:00:02 -0800 (PST)
Received: from mail-il1-x12d.google.com (mail-il1-x12d.google.com [IPv6:2607:f8b0:4864:20::12d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B91C13A0E28 for <secdir@ietf.org>; Wed, 18 Nov 2020 22:00:02 -0800 (PST)
Received: by mail-il1-x12d.google.com with SMTP id w8so4224712ilg.12; Wed, 18 Nov 2020 22:00:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=rhru7VH0ahCYqg2KFM+k25YtGx85LRxu6apxl8gdhnY=; b=jrF71OS5LP02pHKiRzzYD+7DzZ5EkEm1bj954UoIC3uv1IyoT4IG4k75iUgxdXhh3v JtcO03suW2Ufo9vZi8oiMk+4+5IODg+3rKMxBZuCqhiOqlqN6MCyaZK2vCnUXh5SyhOk el3Dp3xHxIIlYvEboH2tS/pPvilBDgvex08hfoKXyRgllQXmsr+w2msaQj2NV1wbmtUf OyeocKiCyNl7gj8vsFnOuweqerbHAX62WkKSem8iN8oRuqOOReHwhfnze0n8y60AVodn WMj3oB+4nlBSQL3mpEDaL0I64z4YdwF2O6a9zRInu0JQ2NtwCKTc7vRn3XLyGDQPd3SQ T7Ig==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=rhru7VH0ahCYqg2KFM+k25YtGx85LRxu6apxl8gdhnY=; b=Iif9Y0FI8q9KjbaQKLsskyKZN3DcmicYQ9KGW2RPtSBforomAgbNDgSmdccLHIHlYj Z0jYuKJfHB2YNNo/yaaxPBYXPOt5sS31vXrjoACjhIvOoBZYGuM9lBf8f24sj6WIvvjN Tvr4t96faRg5WW41qbIlqRener7s0evd/k6lEDXoJv2Of4e7z6xBRhpICEQsw8gIzPES xPr5TrjO511nGafYhCb+MI30E5mmzHELVPo5w6Ry04H2V24k/3A+pmLN5UtjeKXuMH29 Kdkb4DGzQXgjVW16MJHHxJsg5y2M6JC9kjMKygiHtaIH7Q7oWW3YUUWrrV+D9pUT/5EP 0ZFA==
X-Gm-Message-State: AOAM533YmA7omq4o9T7n30iSp6fwai9KCdoxVExMTSEGTI8lmpOqteSH r745aeifTA8qOO+uSUFhzMmnRiUpFwBJW3dh3Q4/ZdNr
X-Google-Smtp-Source: ABdhPJyzu6FAG4jTzPM65VJbWdNeF0ZhFqbtN+OvUPwp1yC6qxuhriN0jLK8SkgQLmxBHw3+cTb2dDtbdv62vhq2Vu4=
X-Received: by 2002:a92:a1c8:: with SMTP id b69mr4242666ill.186.1605765601865; Wed, 18 Nov 2020 22:00:01 -0800 (PST)
MIME-Version: 1.0
References: <CADajj4ZQnWkjKdWpBgsB0oyX8_Kzj6HOL-Vkm=TrByBQMEJfPw@mail.gmail.com> <CADajj4bCTF5EeF6DZkCHpP0_GTnUYQtqa0OE3qf3Z5_AmKWfyA@mail.gmail.com> <CADajj4YxgdNXkWX7dLP0nBDWXLSKFa8M_KWWCPCgfCibYtWkAw@mail.gmail.com> <CADajj4Yw13QWbSqF_hd+P_fcNA4_YvdwqF=OgJ4pdS_1vrWphA@mail.gmail.com> <CADajj4Zw+Js8neUujMbekReVdMMFcz46NDwdHsMdWXob6Upc_w@mail.gmail.com>
In-Reply-To: <CADajj4Zw+Js8neUujMbekReVdMMFcz46NDwdHsMdWXob6Upc_w@mail.gmail.com>
From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= <magnusn@gmail.com>
Date: Wed, 18 Nov 2020 21:59:50 -0800
Message-ID: <CADajj4aoBaSYTFFnvAjcL7mTnfoUJOWzvve=NRhgB3qe5X8uWQ@mail.gmail.com>
To: secdir@ietf.org, draft-ietf-quic-qpac@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004ab34f05b46f70c7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/rpZTQljN_jjI1nv2GP8vbPr8SUM>
Subject: [secdir] Secdir review of draft-ietf-quic-qpack
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Nov 2020 06:00:05 -0000

 I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

This document describes a mechanism for compressing HTTP fields in the
context of HTTP/3.

   - 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.

   While there are several options listed, there is also no recommendation
   as to what strategy (option) implementations should choose to protect
   against this attack. It seems like the Never-Indexed-Literal is a good
   candidate which should be easy to implement.
   - For Section 7.5, is it intended to communicate that an attacker will
   not be able (based on no current known attack against static Huffman
   encodings) to mount the previously described "probing" attack? If so,
   adding a sentence at the end of the section along the lines of "Thus, the
   previously mentioned probing attack is not known to be applicable for any
   fields where static Huffman encoding is used."

Thanks,
-- Magnus