[secdir] [new-work] WG Review: Oblivious Applications using Relayed HTTP (oarh)
The IESG <iesg@ietf.org> Tue, 07 September 2021 18:56 UTC
Return-Path: <new-work-bounces@ietf.org>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 874583A0C15; Tue, 7 Sep 2021 11:56:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1631040964; bh=p6XauYqcdXpmkWKMfSH7BrvnNYtT5BEAeApXnFFZ8B4=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=dB/MLWJZN4CbrB8+RDyfHvI/RmsleXFPJTckIV5oZA7NswDu1TBDJPZkoZ41B1Pi8 RoGZHvOivFNm8otk1/eKDwMhUUADLiQi1QHph0gzAnnOIxEnV8xlimpIykEJeeu/VT U/fORTU3+AGzrYGTiNzEnWVaQImWafpY7nxZxtKQ=
X-Mailbox-Line: From new-work-bounces@ietf.org Tue Sep 7 11:55:58 2021
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 089C83A0CBC; Tue, 7 Sep 2021 11:55:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1631040957; bh=p6XauYqcdXpmkWKMfSH7BrvnNYtT5BEAeApXnFFZ8B4=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Reply-To; b=LOCZg1xkYl3H6EKdwFaR9HdaPEtaVMitzAhK+xL1bE9Eu38+BxAbImyeWrcueEuh3 SRMCU8BGYDKElWht44ozeSe3vMA+4SXLRmEEFVfBcGKKKNHQDDuR0dja6o6BPObetW z+VwBwsSTrg4spV5oE2WkBaOpIY/N/RjA7LzhRkM=
X-Original-To: new-work@ietf.org
Delivered-To: new-work@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7ED3A0BC9 for <new-work@ietf.org>; Tue, 7 Sep 2021 11:55:36 -0700 (PDT)
MIME-Version: 1.0
From: The IESG <iesg@ietf.org>
To: new-work@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.37.0
Auto-Submitted: auto-generated
Precedence: bulk
MIME-Version: 1.0
Reply_to: <iesg@ietf.org>
Message-ID: <163104093641.14970.2832774121617725345@ietfa.amsl.com>
Date: Tue, 07 Sep 2021 11:55:36 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/new-work/YrJ5BkUBf0Mj6slRs2IgMC4m8KY>
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.29
Reply-To: iesg@ietf.org
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: new-work-bounces@ietf.org
Sender: new-work <new-work-bounces@ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/E6MB2123MgNZiyTuixfr5-aGBiA>
X-Mailman-Approved-At: Tue, 07 Sep 2021 12:26:57 -0700
Subject: [secdir] [new-work] WG Review: Oblivious Applications using Relayed HTTP (oarh)
X-BeenThere: secdir@ietf.org
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: Tue, 07 Sep 2021 18:56:11 -0000
A new IETF WG has been proposed in the Security Area. The initial chartering process was started under the name OHTTP, and subsequently the OHTTP BOF was held at IETF 111. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2021-09-17. Oblivious Applications using Relayed HTTP (oarh) ----------------------------------------------------------------------- Current status: Proposed WG Chairs: TBD Assigned Area Director: Francesca Palombini <francesca.palombini@ericsson.com> Security Area Directors: Benjamin Kaduk <kaduk@mit.edu> Roman Danyliw <rdd@cert.org> Mailing list: Address: oarh@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/oarh Archive: https://mailarchive.ietf.org/arch/browse/oarh/ Group page: https://datatracker.ietf.org/group/oarh/ Charter: https://datatracker.ietf.org/doc/charter-ietf-oarh/ In a number of different settings, interactions between clients and servers involve information that could be sensitive when associated with client identity. Client-server applications built on HTTP reveal aspects of client identity to servers through these interactions, especially source addresses. Even without client identity, a server might be able to build a profile of client activity by correlating requests from the same client over time. In HTTP-based applications where the information included in requests does not need to be correlated, the Oblivious HTTP protocol allows a supporting server to accept requests via a proxy. The proxy ensures that the server cannot see source addressing information for clients, which prevents servers linking requests to the same client using such information. Encryption ensures that the proxy is unable to read requests or responses. However, if the proxy and server collude, then neither of these privacy properties hold. Applications and use cases best suited for the Oblivious HTTP protocol are those that have discrete, transactional queries that might reveal small amounts of information over time. Examples include DNS queries, telemetry submission, and certificate revocation checking. In some of these application deployments, the relationship between client, server, and cooperating proxy might be configured out-of-band. General purpose HTTP applications such as web browsing are not in scope for the Oblivious HTTP protocol. Broad applicability is limited by multiple factors, including the need for explicit server support of the protocol. In contrast, transport-level proxies such as HTTP CONNECT or MASQUE are a more appropriate mechanism for those use cases, as they allow connecting to unmodified servers. The OARH working group will define the Oblivious HTTP protocol, a method of encapsulating HTTP requests and responses that provides protected, low-latency exchanges. This protocol will use existing cryptographic primitives to meet these goals. The working group will define any data formats necessary to carry encapsulated requests and responses, plus formats for supplementary material, such as server keying material, that might be needed to use the protocol. The OARH working group will include an applicability statement that documents the limitations of this design and any usage constraints that are necessary to ensure that the protocol is secure. The working group will consider the operational impact as part of the protocol design and document operational considerations. The working group will prioritize work on the core protocol elements as identified. In addition, the working group may work on other use cases and deployment models, including those that involve discovery of OHTTP proxies or servers and their key configurations. The OARH working group will work closely with other groups that develop the tools that Oblivious HTTP depends on (HTTPbis for HTTP, CFRG for HPKE) or that might use Oblivious HTTP (DPRIVE and ADD for DNS over HTTPS). The working group will use draft-thomson-http-oblivious as input. _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work