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

Magnus Nyström <> Thu, 19 November 2020 06:15 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D68843A0E67; Wed, 18 Nov 2020 22:15:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lkb0Nmx2jfRZ; Wed, 18 Nov 2020 22:15:06 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id ADA353A0E66; Wed, 18 Nov 2020 22:15:06 -0800 (PST)
Received: by with SMTP id l13so4297703ilg.3; Wed, 18 Nov 2020 22:15:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <> <> <> <> <>
In-Reply-To: <>
From: Magnus Nyström <>
Date: Wed, 18 Nov 2020 22:14:54 -0800
Message-ID: <>
Content-Type: multipart/alternative; boundary="0000000000002b1ad605b46fa611"
Archived-At: <>
Subject: Re: [secdir] Secdir review of draft-ietf-quic-qpack
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> 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