Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-httpbis-bcp56bis-12

Mark Nottingham <mnot@mnot.net> Mon, 26 July 2021 02:43 UTC

Return-Path: <mnot@mnot.net>
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 B91FA3A15B1; Sun, 25 Jul 2021 19:43:55 -0700 (PDT)
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, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=ywSxhtIt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=maFmtYoU
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 hffE88kwHzbA; Sun, 25 Jul 2021 19:43:51 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA1163A15AA; Sun, 25 Jul 2021 19:43:50 -0700 (PDT)
Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id B3DDA5C00AD; Sun, 25 Jul 2021 22:43:49 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute6.internal (MEProxy); Sun, 25 Jul 2021 22:43:49 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=N bIBjqzrmaoFGt1svjWzkmjcYrchHEExp3VTBOUNUDg=; b=ywSxhtItSik1TpzPb pvGZXUoIvlFl02J+zqWn4ipsiULkbPHx0wn2lGCF4LTv6Qk07BVIIY2WqkqPo2vg uKgF3pzo8KZnKb6QBStBHDhMqoRJYu/HtBeftK94E/Y6lsN9fKUUsLWuR0tSYb72 4U6WjVYUEQR7Cj7CgAW8KFE++jDHbtYCM+dQmH20m3vwzb8+1KpDO0rjw/NwnT8k Ngfi4S5SBnASyH+PxDvyYdsAmnP1OnwlTQs7kDoDsYkoAV4ULzdRPis586Zw0X6g S+Gpg4v8YV5WPK1haBxbzUsLyHyHdXPYWoWi6vaK0q2+gAi3YAx54IgHIr3ucz6n xpZPg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=NbIBjqzrmaoFGt1svjWzkmjcYrchHEExp3VTBOUNU Dg=; b=maFmtYoUmdOWvW1u8Fw8U/UYXHqQpl7lVc5KNZHtKa22HAN+rQThckFko RghJXNQxNqMNuz5mNog9F3ln6N3oi1inC5n9g7FVYFivt6ecV6gePI1SUcoMHt/w ItzPdFMzx8eelCuSZZpSM07rIFiFSH35qF8CS3GJ6nR0VLbGOWwKteOHtzdnEjNv 4mPvXQjpdahQjXoS6lvSCadi5Udns9VyKkABud/9KppZOWp67CgPyrWW1PmeTXd7 E6PjziLki5AyuOGXnM4GtPmeeIJbRQGpBGqoGgKO1cmfblDaMqsknrWjjbrBlJVE HBFDNKoplzAtdLkGdxDuqvD5RhvLA==
X-ME-Sender: <xms:ZCH-YL4ELPuyZqs7g4_Ord9HKS5Gv7ybUTNqRBJfxlmfwUGLWgb6Lw> <xme:ZCH-YA7VHumf6Jl_o3gnO3u7QnWuanOT_erhSvsVbdEpAWYp5iEGO0y-yPyrZCmt- rbNJQ6sf8pnV3kTJw>
X-ME-Received: <xmr:ZCH-YCej03lWgsSDcY_bdl7Nkn-tQNCLIjOpTMOms8eaVvxDZmxLwGJh_DPXMrkLAqpjcVCiPCn1wxteG6z67UpMrFM-qDMNqG02Zi8i7r3-H9uopWGvUWcw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrgeeggdehkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurheptggguffhjgffgffkfhfvofesthhqmh dthhdtvdenucfhrhhomhepofgrrhhkucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhn ohhtrdhnvghtqeenucggtffrrghtthgvrhhnpeelffdvueevffffkeeggfffueegheelke ekteejlefhleekveekudeiieevvdetgfenucffohhmrghinhepghhithhhuhgsrdgtohhm pdhmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrih hlfhhrohhmpehmnhhothesmhhnohhtrdhnvght
X-ME-Proxy: <xmx:ZCH-YMLtiIJHyQZMkhegYYMZYUgLaubqk5GzP-a7vpgk3T5VslaIIw> <xmx:ZCH-YPJLBUE3KjHhCxA3Y_6xi_xLf_sspGOq-xBCgK-AkZ4fCNyidA> <xmx:ZCH-YFxee9EjadL1zDdj0TEBS3O4AbNDYPDMcTY1xnKXVM7pfMp5nA> <xmx:ZSH-YH8VvC9kFEUqCh3rgSphw_h6YGUpPZQHM712HyPgdQneRV0Ddw>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun, 25 Jul 2021 22:43:46 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <162723422613.4754.2816752947598222075@ietfa.amsl.com>
Date: Mon, 26 Jul 2021 12:43:44 +1000
Cc: secdir@ietf.org, draft-ietf-httpbis-bcp56bis.all@ietf.org, ietf-http-wg@w3.org, last-call@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <86B9EF7F-8AC1-49A5-B33D-F9A8D5A96A45@mnot.net>
References: <162723422613.4754.2816752947598222075@ietfa.amsl.com>
To: Joseph Salowey <joe@salowey.net>
X-Mailer: Apple Mail (2.3654.120.0.1.13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/Bdv27v30pJbTn1fDUGX-4f68uj8>
Subject: Re: [secdir] [Last-Call] Secdir last call review of draft-ietf-httpbis-bcp56bis-12
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: Mon, 26 Jul 2021 02:43:56 -0000

Thanks for the review. I've opened an issue to track it:
  https://github.com/httpwg/http-extensions/issues/1582

Responses below.


> On 26 Jul 2021, at 3:30 am, Joseph Salowey via Datatracker <noreply@ietf.org> wrote:

> Major Issues:
> 
> + I had trouble with section 4.12 Client Authentication which states:
> 
> "Applications can use HTTP authentication Section 11 of
> [I-D.ietf-httpbis-semantics] to identify clients. The Basic authentication
> scheme [RFC7617] MUST NOT be used unless the underlying transport is
> authenticated, integrity-protected and confidential (e.g., as provided the
> "HTTPS" URI scheme, or another using TLS). The Digest scheme [RFC7616] MUST NOT
> be used unless the underlying transport is similarly secure, or the chosen hash
> algorithm is not "MD5"."
> 
> I'm not sure what the "or chosen hash algorithm is not "MD5" is meant to say. 
> What I think the document should say is:
> 
> The Digest scheme [RFC7616] MUST NOT be used unless the underlying transport is
> similarly secure. The "MD5" digest algorithm MUST NOT be used.

Hmm. I forgot that RFC7616 has a pre-existing requirement in Section 5.1:

> If Digest Authentication is being used, it SHOULD be over a secure channel like HTTPS [RFC2818].

Are we saying that that SHOULD is really a MUST for all uses of HTTP, or just those in scope for this document? Likewise for the effective deprecation of md5.

If so, perhaps the easiest thing to do would be to state that clearly; e.g.,

"""
[RFC7616] Section 5.1 recommends that the Digest scheme be used over a secure channel like HTTPS. This document strengthens that recommendation to MUST, and deprecates the md5 hash algorithm in the Digest scheme.
"""

... and listing 7616 as being updated by this document.

Thoughts?

> + There is a security consideration that I think the document should cover. 
> Many HTTP based protocols make heavy use of bearer tokens, such as session
> cookies, for authentication and authorization purposes.  This means that an
> attacker that can eavesdrop on HTTP communications can often escalate their
> privilege to perform operations on resources.   I think you could add this to
> the security considerations:
> 
> " Section 4.4.2 requires support for 'https' URLs, and discourages the use of
> 'http' URLs, to provide authentication, integrity and confidentiality, as well
> as mitigate pervasive monitoring attacks.  Many HTTP based protocols make heavy
> use of bearer tokens, such as session cookies, for authentication and
> authorization purposes.  This means that an attacker that can eavesdrop on HTTP
> communications can often escalate their privilege to perform operations on
> resources. "

See https://github.com/httpwg/http-extensions/commit/fe3f298e4d60514306e391398cc870abaedd8bf9

> Minor Issues:
> 
> + Section 4.5.1 - This could be a good place to mention RFC-8470 on TLS 1.3
> early data which can also be a source of GET request replay

See https://github.com/httpwg/http-extensions/commit/b03c376179e278deb3d994eac152c6a131702840

Cheers,

--
Mark Nottingham   https://www.mnot.net/