Re: [Ohttp] Discovery

Eliot Lear <lear@lear.ch> Fri, 25 June 2021 07:03 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 B0CCF3A3E12 for <ohttp@ietfa.amsl.com>; Fri, 25 Jun 2021 00:03:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.427
X-Spam-Level:
X-Spam-Status: No, score=-2.427 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, NICE_REPLY_A=-0.338, SPF_PASS=-0.001, T_SPF_HELO_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 gK7CwRn5jYdp for <ohttp@ietfa.amsl.com>; Fri, 25 Jun 2021 00:03:12 -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 84E843A3E11 for <ohttp@ietf.org>; Fri, 25 Jun 2021 00:03:11 -0700 (PDT)
Received: from Lear-Air.local ([IPv6:2a02:aa15:4101:2a80:c01e:e099:a667:10e9]) (authenticated bits=0) by upstairs.ofcourseimright.com (8.15.2/8.15.2/Debian-18) with ESMTPSA id 15P738UQ490432 (version=TLSv1.3 cipher=TLS_AES_128_GCM_SHA256 bits=128 verify=NO); Fri, 25 Jun 2021 09:03:09 +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=1624604589; bh=qEixZZfl1BCd8ALfE6X3jDcVYCrkOrRT5psQJNhNiZs=; h=To:References:From:Subject:Date:In-Reply-To:From; b=h8LwA1skEAM7sGJFeSyQLMHb62KJ9clkYqch4rZ6xwJIW6Wj8fY0wF0X9xAAV/GWT W/BKct7va/sGSqBxRKRxl6ip0dZii+WnOh90w5xEJVn85/BUAAU0DXCdae3KM6Z7P3 mszIdHxdKuLcJ1ogChH7Jk6Iir77pqlfJYqsz1NY=
To: Martin Thomson <mt@lowentropy.net>, ohttp@ietf.org
References: <D8268CF8-94DA-4E91-9286-4E45B8E26CB6@mnot.net> <c57ed5b0-c17a-0bca-f42a-dafaa1725792@lear.ch> <1F7246CE-589A-4B34-B514-AFA0F640A384@mnot.net> <238476f4-6bf9-4124-8146-e8c051b1b25f@www.fastmail.com> <f1308d19-085d-dadf-df69-da6f8b1b5171@lear.ch> <276764677.18198.1624458666099@appsuite-gw2.open-xchange.com> <CABcZeBOjF4sdk_zO5xaPjN3DxCpQcna4hVaUTXzVoJB5HsPUWQ@mail.gmail.com> <530ff450-6e8e-432f-8ba4-c8b2503d31a9@www.fastmail.com>
From: Eliot Lear <lear@lear.ch>
Message-ID: <63fb9389-21a9-cf31-d01f-86e5f7934b28@lear.ch>
Date: Fri, 25 Jun 2021 09:03:06 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <530ff450-6e8e-432f-8ba4-c8b2503d31a9@www.fastmail.com>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="gDm8z18pmA140oNmoHcLCG9hYX3n9uMFQ"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ohttp/pCvc5uxP1NRmnNm7ajG4UJlqXgI>
Subject: Re: [Ohttp] Discovery
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: Fri, 25 Jun 2021 07:03:18 -0000

Hi Martin,

On 25.06.21 02:29, Martin Thomson wrote
> I understand that there are important use cases that might be affected by the widespread deployment of new security protocols.  That's commonplace.  But we don't agree not to design a protocol solely on the basis that it affects practices.  We do things like consider whether there are alternative ways in which the same goals might be met, or whether the practices are worth protecting.  If a use case is important and there are no good alternatives as a result of the new design, that is grounds for rejecting a protocol.

While I do believe the IETF should have a broader discussion about 
rfc2804 and societal implications of our work, now that I understand the 
use case, we needn't have that conversation now. You're right: I am 
aiming for something more targeted in this case:

>> The working group will consider the operational impact as part of the protocol design and document operational considerations.

There are two issues that we should specifically address:

  * Enterprise controls should not be subverted, especially when it's
    unnecessary to do so in this particular case.  Mark accurately
    described what I was referring to.
  * The risks of use of the mechanism need to be understood as part of
    its applicability, particularly as relates to DNS and similar and
    the masking of C&C networks.  That harms the Internet, and so is in
    scope.

Let's all agree that these conversations will happen, relating to the 
protocol design, and I can live with the above words.

The broader conversation about the evolving Internet Threat Model needs 
to once again be rebooted, but that doesn't need to happen in this WG.  
It really does need to happen.

Eliot