[Ohai] The last few OHTTP issues

Martin Thomson <mt@lowentropy.net> Thu, 25 August 2022 04:46 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: ohai@ietfa.amsl.com
Delivered-To: ohai@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B51C1522B5 for <ohai@ietfa.amsl.com>; Wed, 24 Aug 2022 21:46:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.805
X-Spam-Level:
X-Spam-Status: No, score=-2.805 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_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=D2gTSA2+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=PfDri935
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjN_OOO1cTm9 for <ohai@ietfa.amsl.com>; Wed, 24 Aug 2022 21:46:07 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A2CFC14F740 for <ohai@ietf.org>; Wed, 24 Aug 2022 21:46:07 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id EA1055C0086 for <ohai@ietf.org>; Thu, 25 Aug 2022 00:46:05 -0400 (EDT)
Received: from imap41 ([10.202.2.91]) by compute3.internal (MEProxy); Thu, 25 Aug 2022 00:46:05 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=cc:content-type:date:date:from:from:in-reply-to:message-id :mime-version:reply-to:sender:subject:subject:to:to; s=fm2; t= 1661402765; x=1661489165; bh=JNhE5YTdlUbXeXIQ5fDE/3LGxH7YALMas1X 9d6yyr6M=; b=D2gTSA2+ONzPy/mmHHGj8elLWoGCRPfFq6OPUjJim8PG+DK1O2w WHy6WSP25zM/g1CuqrpBSWKJo8EJmLplpH/0wgPJ+9ubvTN6INetLNaEi+iqcfOJ FekHL2Tp7iHyFP1zysAEWXlhoh6xzSDyK17X7P+WzP5Hsf326OrvLESwVisSk2r/ OY83ir7ULUQxiewTJV5dJhY1q2FrWi6JBLioz5a7Z0M0JY44KVgwDd7c37HPkKWG cMhG4byCluwpofbnZ4s9IWPgfWUJpMQx/FcvmSkVgnndjgwf8MPzqIskZxTSADto 43a/NIVQ1Dsc46P6vH2SU4F0WDYPXRK5IAg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:message-id:mime-version :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1661402765; x= 1661489165; bh=JNhE5YTdlUbXeXIQ5fDE/3LGxH7YALMas1X9d6yyr6M=; b=P fDri935R+NtafFgUMEEVgXVRt+bZk73qPqA22KqCXaVlL+xzN92Hg1H8fqOB1HQv DN/13GgX7WKJbmfQ2fRkOLIlPcAQVdxXrkh7ik/OKjQN7TAJRSz4jJ1syUor9La/ C6jvspsXAI9d1esCcMcfouC0hcItNTdcaBWTQVGjeU8Vnc6Ed3CtlkcDZIEKoXO+ nCh6JIMRgX251GUV646alMCMm15UHa05zACV/O8ClAQzxuY35u4tt/EpxZlHS6XQ OUsX4VF62vOjejaHQsZk04izR8hb3pAJROtxVSnb3ySjI/RCwg6pQ4btbu4c36ny YkO2q4Srho1Sg1b/SY/Vw==
X-ME-Sender: <xms:jf4GY0qApf_6gTfjdd-_IR1eK-CebY6_Yxp1ynZn64J5aWFOSyorTA> <xme:jf4GY6o36EJw3bmGcAIUnKAsYAoqYj89YQtHMHUsNkAJ0DTZX-GlMQTzYW_HPra4A iHA0MLkt3LWfnvE6Ck>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrvdejvddgkeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfffhffvufgtsehttdertd erredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhhofigv nhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpeegueehueejvdeiveffhedvke egffekgffgtdetleefkeeffedtjefhtdduvddutdenucffohhmrghinhepghhithhhuhgs rdgtohhmnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:jf4GY5PH-tJDNocMdl4HaGXq9weajxb91wvlWdpATrNxmCNQMFi9kQ> <xmx:jf4GY753fN5FP70dwG6ozOnCoCA2ybNP1jeo0DY3Q_4pSoy0KMe5kQ> <xmx:jf4GYz50__FmXXCVpJTYZM8V7c2nJB9EoGbINqVgJUnmMdKQ3N4dfg> <xmx:jf4GY1HqBczYE4W6K4WBYBmAiiM1Uj9zeyZ4_Ppjpbclp8JZjfsImA>
Feedback-ID: ic129442d:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id A1F5D2340077; Thu, 25 Aug 2022 00:46:05 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-841-g7899e99a45-fm-20220811.002-g7899e99a
Mime-Version: 1.0
Message-Id: <c3a61d01-357c-451b-b747-48fa563755b0@betaapp.fastmail.com>
Date: Thu, 25 Aug 2022 14:45:47 +1000
From: Martin Thomson <mt@lowentropy.net>
To: ohai@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/ohai/-e8OiGHaw0raEInFQjLUV1u8yDo>
Subject: [Ohai] The last few OHTTP issues
X-BeenThere: ohai@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Oblivious HTTP Application Intermediation <ohai.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ohai>, <mailto:ohai-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ohai/>
List-Post: <mailto:ohai@ietf.org>
List-Help: <mailto:ohai-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ohai>, <mailto:ohai-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Aug 2022 04:46:11 -0000

As the chairs noted in the conclusion to WGLC a couple of non-trivial issues were raised during last call.

# Bad Key Configuration

https://github.com/ietf-wg-ohai/oblivious-http/issues/194 

In ODoH deployment experience thus far, this appears to be the most common problem as devices wake from a long sleep and the server has rotated keys.  So the idea is that it might be helpful for a gateway to indicate to a client that a key configuration was bad.

The proposed resolution is here: https://github.com/ietf-wg-ohai/oblivious-http/pull/196

The substance of that pull request is that we are defining a signal with RFC 7807 (specifically, the revision that the HTTPAPI WG are finishing up).  There's also some text on why any signal like this that isn't encrypted might be unreliable and how clients might want to use a heuristic for refreshing key configurations as a backstop.

# Asynchronous Submission

https://github.com/ietf-wg-ohai/oblivious-http/issues/179

The question is what you might do if the relay or gateway decide to store a request and deal with it later.  The use case for this is a submission service where the content of the response isn't interesting to the client.  In particular, this might allow a gateway to keep its key offline somewhere if it doesn't have to encapsulate a response.

The discussion there resolved on keeping this out of scope. It looks like this is entirely possible without new specification work, just with existing HTTP semantics (202, specifically).  There's a draft draft floating around somewhere that walks through some of the implications in more detail.

That outcome seemed uncontroversial, so we have already closed the issue, but it's worth raising here in case we overstepped.

# Action

I'd like to merge the remaining pull requests next week, on Thursday-ish.  Please review the issues and let the editors know before the end of the month if you disagree with the direction we've proposed.

Unless our esteemed chairs disagree, this will be the last change before we revise the draft in preparation for publication.