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

Magnus Nyström <magnusn@gmail.com> Thu, 19 November 2020 06:15 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 D68843A0E67; Wed, 18 Nov 2020 22:15:07 -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 lkb0Nmx2jfRZ; Wed, 18 Nov 2020 22:15:06 -0800 (PST)
Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 ADA353A0E66; Wed, 18 Nov 2020 22:15:06 -0800 (PST)
Received: by mail-il1-x136.google.com with SMTP id l13so4297703ilg.3; Wed, 18 Nov 2020 22:15:06 -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=t/BK0Yi0OcZNMoh5Lhs2huZ5tvWnkl8zM4tpC08ANYM=; b=ZfHAeb9l0/W6nJXGoF0vc47NxH9cvMaUIU/P9ELBzqVswba76BnmbpeMpsfxk72XD8 KsBy9csm+YiHiCE6Tzlz6W9+bN1nj2zlK5cMSodFsPnJrpLcAZx5AIaJqKfWflJGQRci ziq3aR/HokJi6gA7m2Q9n3COP22vq5KrR5A+ukgOVTuCie3zMrHnfPPvzZPI73tfY3p7 IrLQHHplu6DDCDEgpL8riaNws7tSxkY+wEDrAZ5QtdMKX1qgwwmCBz80fxR69lkONUzH Qjcew++lvju/AucfMmM3Y8QpC5S2lBGp9GZeK0JAylCSO1CbdVHaFCfCnZOw4lSsFnQP d8zg==
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=t/BK0Yi0OcZNMoh5Lhs2huZ5tvWnkl8zM4tpC08ANYM=; b=LjoA12rdCIW2dvaCZgoZLFR/kxnPS7pjX9dOjVrlb7PkVShJ2RS+q7s6QJ3ckbizPM VDuJ/1Y+nL56BNl0eAe5i8HKMTlxTRDAA+9ZrlraoK7ve6PTBtv9IqA1bZxag45TqjA8 n6YrEQ6eGKWa95/aRdqFQFCLG2zH/nJaO1fFIM0P2+NKILUV+ZHBVaW+OGa7/5EOcZYv Mv3cF67e4ZeeAaZYucQDAtskRlhCH9yHm4vHTBw5tVwB/Bxwqxx/Zn+N+Q3hN+GRv3Z/ CY4JWRl5+8I5msKHETmWo8rwMPpOYsfJpBPavhPB3XLqyCOS6Lj0DvwliMAqGuYptpsJ gLHg==
X-Gm-Message-State: AOAM531aprcLHisoUsWvGcecCr362dwQ4Kii2ZNssUDpxwP6hvBskWkT FVzgQ2ewRdCCCDEkfYFjn/c/EBFGDPObl6/qbdE03n7Q
X-Google-Smtp-Source: ABdhPJxi9O71XrjMDjk9ZPNMBgLkj4Gd/IyYP0qb0tazE7gRVJ3ih1wZ9ADWno5e9XtJv42hyVpbxovkeJsQY3LoMeo=
X-Received: by 2002:a92:a1c8:: with SMTP id b69mr4310770ill.186.1605766505763; Wed, 18 Nov 2020 22:15:05 -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> <CADajj4aoBaSYTFFnvAjcL7mTnfoUJOWzvve=NRhgB3qe5X8uWQ@mail.gmail.com>
In-Reply-To: <CADajj4aoBaSYTFFnvAjcL7mTnfoUJOWzvve=NRhgB3qe5X8uWQ@mail.gmail.com>
From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= <magnusn@gmail.com>
Date: Wed, 18 Nov 2020 22:14:54 -0800
Message-ID: <CADajj4aRrhrJHH4sd4-Z6B95jRi_K+wyf2nYfrvyppVaPOr6og@mail.gmail.com>
To: secdir@ietf.org, draft-ietf-quic-qpack@ietf.org
Content-Type: multipart/alternative; boundary="0000000000002b1ad605b46fa611"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/UjA1L2peMvhVfkdzvF0PGsxZZyQ>
Subject: Re: [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:15:08 -0000

Correcting qpack ietf email address, sorry.

On Wed, Nov 18, 2020 at 9:59 PM Magnus Nyström <magnusn@gmail.com> wrote:

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