IETF Logo Mail Archive

Re: [Ohttp] Request to Charter a New Working Group: Oblivious HTTP (OHTTP)

Eliot Lear <lear@lear.ch> Tue, 08 June 2021 10:10 UTC

Return-Path: <lear@lear.ch>
X-Original-To: ohttp@ietfa.amsl.com
Delivered-To: ohttp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB36C3A2B21; Tue, 8 Jun 2021 03:10:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.89
X-Spam-Level:
X-Spam-Status: No, score=-0.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=lear.ch
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 PfL5hWiujZTJ; Tue, 8 Jun 2021 03:10:25 -0700 (PDT)
Received: from upstairs.ofcourseimright.com (upstairs.ofcourseimright.com [185.32.222.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 972653A2B20; Tue, 8 Jun 2021 03:10:18 -0700 (PDT)
Received: from [IPv6:2001:420:c0c0:1011::6] ([IPv6:2001:420:c0c0:1011:0:0:0:6]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 158AADnt108337 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Tue, 8 Jun 2021 12:10:14 +0200
Authentication-Results: upstairs.ofcourseimright.com; dmarc=none (p=none dis=none) header.from=lear.ch
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=lear.ch; s=upstairs; t=1623147014; bh=+T9e1y9+/jQbEavOJKYgzhzqtbCL26AIfIq14eCvxa4=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=VerhtcTgbDbDIZvE4Ucqowfx4mr2v51YlHM6ZzJ2SQHMWRYInqk+Ve791qTpCNJ5c YDEv2nsUjtDm0WRJeQDtzgCqjTbIBURHaciY1Igxj6wFJGAc+EiDcqGisf+ofSUd3Q KIX4e/GeSBmXq+y3usEVFXf6oSC3jt/Zap1buq3c=
To: 'IESG' <iesg@ietf.org>
Cc: ohttp@ietf.org, ietf <IETF@ietf.org>
References: <162309061157.32548.930649503797136245@ietfa.amsl.com>
From: Eliot Lear <lear@lear.ch>
Message-ID: <d8932acb-397b-25b9-7bab-50c1a313d583@lear.ch>
Date: Tue, 08 Jun 2021 12:10:08 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: <162309061157.32548.930649503797136245@ietfa.amsl.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="ZsChkzgNVzkMm7nZXnO0vhVD8Ltdc6z1d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ohttp/bG5qUCPuGvRa3F2F7OkfUqEzA9o>
Subject: Re: [Ohttp] Request to Charter a New Working Group: Oblivious HTTP (OHTTP)
X-BeenThere: ohttp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Oblivious HTTP <ohttp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ohttp>, <mailto:ohttp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ohttp/>
List-Post: <mailto:ohttp@ietf.org>
List-Help: <mailto:ohttp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ohttp>, <mailto:ohttp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jun 2021 10:10:31 -0000

Hi IESG,

Martin's draft is interesting, but I have several questions:

 1. How is the key configuration authenticated and retrieved?  I *think*
    the intent is that a direct HTTPS request is made, but it's not
    clear.  Is it to a /.well-known something or other?  Is it a GET or
    a POST?
 2. Is the use of this work likely to help miscreants more than those in
    need of privacy?
 3. Should we expect session capabilities be built in at higher layers
    through identifiers passed in forms?

I want to spend just a little time on (2).  If what we are doing is 
standardizing tooling and providing libraries for BOTnets to operate 
against web sites, where the web site has no recourse when it is 
attacked, then why would anyone implement this?  It also seems that this 
tooling will hamper lawful intercept, *unless* session mechanisms are 
re-established in the content, in which case, aren't we going to bring 
on a rather large retooling?  And if so, will the ends of the draft 
actually be met?

Is this same service going to further harm clients by making it even 
more difficult to block known malicious web sites?  Not only would a 
local deployment not be able to do this, but proxies themselves wouldn't 
be able to spot malware.  Combine that with some rather impressive 
phishing capabilities of bad actors, and aren't we just hamstringing our 
ability to put down malware attacks?

I am *asking* these questions, but I would rather that they get properly 
discussed and answered before the WG is approved.  What I would hate to 
see is a lot of effort take place to land people right back to where 
they were.

Eliot

On 07.06.21 20:30, IESG Secretary wrote:
> The IESG has received a request to charter a new working group,
> Oblivious HTTP (OHTTP).  The proposed charter, which is a work in
> progress, can be found here:
>
> <https://datatracker.ietf.org/doc/charter-ietf-ohttp/>
>
> The charter will be discussed on the <ohttp@ietf.org> mailing list,
> which can be subscribed to here:
>
> <https://www.ietf.org/mailman/listinfo/ohttp>
>
> _______________________________________________
> IETF-Announce mailing list
> IETF-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

v2.23.0 | Report a Bug | By Email