[Ohai] Re: Chunked OHTTP with zero-length chunks
Lucas Pardue <lucas@lucaspardue.com> Tue, 25 November 2025 14:53 UTC
Return-Path: <lucas@lucaspardue.com>
X-Original-To: ohai@mail2.ietf.org
Delivered-To: ohai@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 397CF90465FF for <ohai@mail2.ietf.org>; Tue, 25 Nov 2025 06:53:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.798
X-Spam-Level:
X-Spam-Status: No, score=-2.798 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=lucaspardue.com header.b="BNJNIXQp"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="gSvlOJbf"
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMOgnGfVnpJ4 for <ohai@mail2.ietf.org>; Tue, 25 Nov 2025 06:53:32 -0800 (PST)
Received: from fhigh-b1-smtp.messagingengine.com (fhigh-b1-smtp.messagingengine.com [202.12.124.152]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 41BB3904653D for <ohai@ietf.org>; Tue, 25 Nov 2025 06:53:25 -0800 (PST)
Received: from phl-compute-02.internal (phl-compute-02.internal [10.202.2.42]) by mailfhigh.stl.internal (Postfix) with ESMTP id C25EC7A01B5; Tue, 25 Nov 2025 09:53:19 -0500 (EST)
Received: from phl-imap-09 ([10.202.2.99]) by phl-compute-02.internal (MEProxy); Tue, 25 Nov 2025 09:53:19 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lucaspardue.com; h=cc:cc:content-type:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:subject:subject:to:to; s=fm2; t=1764082399; x= 1764168799; bh=JzfvI5Z4Sw5NQ+wdnlnnxm4d3YhFyiHXS32ybB8Qih0=; b=B NJNIXQpUehCrMAAwiB9TMKhZoUiYwyxPJV8UdgqY5fjSEgdaQxXDPkM5j9gztBjs ZxZWpNIEvT9g76CQpb/8Du0GbEjbhjMzt5i20shbc6Na6aqdMuEgL43/wfCnplqx Sp3ULoQAlMaGVvB0YPzLEmQuoPs0UXFYK27mwPxAoz0cSRKPluXirQzLZuuok6RE 5F2ZSUb7uiV0onFhHllMMANxisxT7yuEJZNgDAT9PPL4M8ceA87TJizOHPNm0H5r TzLJwMc0ycR9ff1+xNR4uowR7WfPL+140+1ShMwy+Q+7T6TK1z4dx9VmmZXRflrO iE1EYY1DNR3148dujDnYw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1764082399; x=1764168799; bh=JzfvI5Z4Sw5NQ+wdnlnnxm4d3YhFyiHXS32 ybB8Qih0=; b=gSvlOJbfjKzfQyDZpVRWApjnQXJmDGaSq20hO32RiZLiRK2H0ZY 7S2ywkYxQwB/EHWRfwzx0ieGp8grtA5qJI+fR/S7fizWU8xuWAYLITtSlsdndaY4 WICrlP9jz/p7wpCfxt1WCf3W2UuEMalugCbovgzBnry0lLuuG6IkYcqb/gFBbLGJ 7O3imPhwRre5RQNsL33R1IkSkk8SaR08U9UwXPKanqcb1+bMgCEAZV7LvW3NCdP2 BLMMQt2zqRSmZnANdqhxXu2wfdzKOMA1dUd82anoNEzeIf9WLw3c9zg4O3yi3XZY jk/HDD+zXHXaQYajXZMg1Xudc1Z0SeqaT/A==
X-ME-Sender: <xms:38IlaQH8lTg5geU27DD14VTQvarpA7hZgswHKe4ZB6nL1NPriYQWiQ> <xme:38IlaUIGwOKDgqECRBKyYj-xGM1z7xddNl6XsRdD_pKIf7IHjncrmrIcBa6WKNZ1d FUxJfKMXmV9Pjt2At2mhV_pldrkzQpci7ef0GbAvgqu1STE5LIZ390>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeeffedrtdeggddvgedujeeiucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepofggfffhvfevkfgjfhfutgesrgdtreerredtjeenucfhrhhomhepfdfnuhgtrghs ucfrrghrughuvgdfuceolhhutggrsheslhhutggrshhprghrughuvgdrtghomheqnecugg ftrfgrthhtvghrnhepgeefleeukedvudekhedtffettdefjeejfeehveelhfeukeduueff ffeffeeukedtnecuffhomhgrihhnpehgihhthhhusgdrtghomhenucevlhhushhtvghruf hiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehluhgtrghssehluhgtrghsphgr rhguuhgvrdgtohhmpdhnsggprhgtphhtthhopeegpdhmohguvgepshhmthhpohhuthdprh gtphhtthhopegushgthhhinhgriihirdhivghtfhesghhmrghilhdrtghomhdprhgtphht thhopehohhgrihesihgvthhfrdhorhhgpdhrtghpthhtoheprhhlsgesihhpvhdrshigpd hrtghpthhtohepmhhtsehlohifvghnthhrohhphidrnhgvth
X-ME-Proxy: <xmx:38IlacKegnbegDQzBhC5JZi3J4SVlSPNXCPMqLSXCMfIl5Ox2bE9Dg> <xmx:38IlaTKlRspOIpHojpVxDVP14kMykzODMwa6k3ujSwpnhNsivG_vyw> <xmx:38IlaRtQgaycTKkCNL5q2oUyEVY7HN5CbXFIGVWziqw04QX4GmRhbA> <xmx:38IlaYRrC7381TfWZqiwz8MyDYUbdyeb027xSzpbr_G-JDIjSOjZYw> <xmx:38IlaXjPcp1esw2KjZSOauPwaO-CtfNI-B_39O_Lx-PSaKu1BBRr0XUt>
Feedback-ID: i23b94938:Fastmail
Received: by mailuser.phl.internal (Postfix, from userid 501) id 3E7973020086; Tue, 25 Nov 2025 09:53:19 -0500 (EST)
X-Mailer: MessagingEngine.com Webmail Interface
MIME-Version: 1.0
X-ThreadId: Ax-qEBUIyGgR
Date: Tue, 25 Nov 2025 14:52:54 +0000
From: Lucas Pardue <lucas@lucaspardue.com>
To: Richard Barnes <rlb@ipv.sx>, David Schinazi <dschinazi.ietf@gmail.com>
Message-Id: <e8ae0236-97c1-4166-b7f0-f5577cb1dfeb@app.fastmail.com>
In-Reply-To: <CAL02cgS6gPMqiBfG9H-e3TNoyx9kNfqt+ArUmekSHMrND2YWqA@mail.gmail.com>
References: <4f08a9a4-126d-4ac1-99e3-ee81630ae76a@betaapp.fastmail.com> <CAPDSy+5fcZcigqW11jUQUv_WWG=ncn0V3h4k4Ejs4fFi17D9WQ@mail.gmail.com> <CAL02cgS6gPMqiBfG9H-e3TNoyx9kNfqt+ArUmekSHMrND2YWqA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="6961e66c20174788bccff45cd57f84da"
Message-ID-Hash: YYJEDW2A5L5MXIBSG2I6QUIGBV6OWJUF
X-Message-ID-Hash: YYJEDW2A5L5MXIBSG2I6QUIGBV6OWJUF
X-MailFrom: lucas@lucaspardue.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: Martin Thomson <mt@lowentropy.net>, ohai@ietf.org
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [Ohai] Re: Chunked OHTTP with zero-length chunks
List-Id: Oblivious HTTP Application Intermediation <ohai.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ohai/1R0VGT9YcSEkPIe2ZCqys_vNy-8>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ohai>
List-Help: <mailto:ohai-request@ietf.org?subject=help>
List-Owner: <mailto:ohai-owner@ietf.org>
List-Post: <mailto:ohai@ietf.org>
List-Subscribe: <mailto:ohai-join@ietf.org>
List-Unsubscribe: <mailto:ohai-leave@ietf.org>
I don't have an ohttp implementation but agree on the security issues of redundant or confusing encoding and message framing. +1 be strict. FWIW some of the code I'm responsible for has APIs to prevent sending non-final 0-length DATA frames etc. So this is some familiar territory. Cheers Lucas On Tue, Nov 25, 2025, at 13:52, Richard Barnes wrote: > It is late, but this seems like an important interoperability concern. So let's give this a week or two to confirm there's consensus (say around the strict approach) and then implement. > > If the authors wanted to draft a PR, that would probably help clarify the discussion. > > --Richard > > On Mon, Nov 24, 2025 at 9:07 PM David Schinazi <dschinazi.ietf@gmail.com> wrote: >> I would suggest taking the strict approach if the authors of the deployed implementations know they're not sending empty chunks. >> >> Google's in-progress implementation hasn't shipped yet, and we'll make sure to not send any empty chunks. >> >> David >> >> On Mon, Nov 24, 2025 at 5:14 PM Martin Thomson <mt@lowentropy.net> wrote: >>> One of the less-nice things about this format is that it is possible to encode a zero-length chunk. That is, a chunk that contains only the AEAD tag, no data. >>> >>> Discussion on https://github.com/ietf-wg-ohai/draft-ohai-chunked-ohttp/pull/50 indicates that at least two implementations had bugs in this area. Note that typical streaming APIs treat a zero-length return from a read as a stream termination, so this could even be exploited to abuse stacks. >>> >>> Two choices: >>> >>> 1. Advise against accepting zero-length chunks, as the above PR does. >>> 2. Ban them entirely. Aside from the final chunk, which might need to be empty as stream termination is a separate event from data delivery in many implementations. >>> >>> I can't think of a reason not to take the stricter approach. But it's very late. >>> >>> -- >>> Ohai mailing list -- ohai@ietf.org >>> To unsubscribe send an email to ohai-leave@ietf.org >> -- >> Ohai mailing list -- ohai@ietf.org >> To unsubscribe send an email to ohai-leave@ietf.org > -- > Ohai mailing list -- ohai@ietf.org > To unsubscribe send an email to ohai-leave@ietf.org >
- [Ohai] Chunked OHTTP with zero-length chunks Martin Thomson
- [Ohai] Re: Chunked OHTTP with zero-length chunks David Schinazi
- [Ohai] Re: Chunked OHTTP with zero-length chunks Richard Barnes
- [Ohai] Re: Chunked OHTTP with zero-length chunks Lucas Pardue
- [Ohai] Re: Chunked OHTTP with zero-length chunks Tommy Pauly
- [Ohai] Re: Chunked OHTTP with zero-length chunks Martin Thomson
- [Ohai] Re: Chunked OHTTP with zero-length chunks Tommy Pauly