Re: [arch-d] Time to reboot RFC1984 and RFC2804?

"Joel M. Halpern" <jmh@joelhalpern.com> Tue, 13 October 2020 13:47 UTC

Return-Path: <jmh@joelhalpern.com>
X-Original-To: architecture-discuss@ietfa.amsl.com
Delivered-To: architecture-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1AE3A0FD2 for <architecture-discuss@ietfa.amsl.com>; Tue, 13 Oct 2020 06:47:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.311
X-Spam-Level:
X-Spam-Status: No, score=-2.311 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, NICE_REPLY_A=-0.213, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.com
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 Gbvm5UtHomls for <architecture-discuss@ietfa.amsl.com>; Tue, 13 Oct 2020 06:46:58 -0700 (PDT)
Received: from maila2.tigertech.net (maila2.tigertech.net [208.80.4.152]) (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 8C4723A0CDB for <architecture-discuss@ietf.org>; Tue, 13 Oct 2020 06:46:58 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by maila2.tigertech.net (Postfix) with ESMTP id 4C9cKZ3BZHz6G84t; Tue, 13 Oct 2020 06:46:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1602596818; bh=B6Ch73RV+5ja+2/e4T8G6xIrSHXvU7Tra1jARedrOv8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=EbjCKaF6Tu+pVWl/e19D9F9by2Uzy8uZ208hJkoosk4SarTdFq2pGYHlf2BLAjzPL GxG+pukKF+EHOBIaHvzEKTMU4FL7YhPalrZ3MdL4jjkkwqFUeG6YccWWhAv0EAj704 Pc2egBBLlpayfWc5B1zR2pAkeMg41MjZ0xM5M52s=
X-Quarantine-ID: <Q4T4fC0F4j4O>
X-Virus-Scanned: Debian amavisd-new at a2.tigertech.net
Received: from [192.168.128.43] (unknown [50.225.209.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by maila2.tigertech.net (Postfix) with ESMTPSA id 4C9cKY6Dg6z6G8pk; Tue, 13 Oct 2020 06:46:57 -0700 (PDT)
To: Stewart Bryant <stewart.bryant@gmail.com>
Cc: "architecture-discuss@ietf.org" <architecture-discuss@ietf.org>
References: <8fa06d77-e73b-aa15-683d-937e8841566f@gmail.com> <975E28FE326C22E8CD32DCC8@PSB> <5021a377-e9ca-1580-c2f0-3351b9f5fe04@huitema.net> <LO2P265MB05736C784B36942C7ECF71ECC2070@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM> <e80b6f1e-3949-b2ee-6e61-a2f3dfce9b0c@cs.tcd.ie> <586DC363-B5F8-4727-8734-815F3E17F345@gmail.com> <c5b37390-d463-fa35-215b-569698098d6a@cs.tcd.ie> <65CD5A4A-E7AD-4051-90A6-31AD536AB0AD@gmail.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <41765f57-b3b6-9eb4-1450-0776d02c1bab@joelhalpern.com>
Date: Tue, 13 Oct 2020 09:46:56 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <65CD5A4A-E7AD-4051-90A6-31AD536AB0AD@gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/architecture-discuss/a1GTTWXRuT6WBK8b1MUvf1xV8HQ>
Subject: Re: [arch-d] Time to reboot RFC1984 and RFC2804?
X-BeenThere: architecture-discuss@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: open discussion forum for long/wide-range architectural issues <architecture-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/architecture-discuss/>
List-Post: <mailto:architecture-discuss@ietf.org>
List-Help: <mailto:architecture-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/architecture-discuss>, <mailto:architecture-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Oct 2020 13:47:00 -0000

Stewart, please do not describe this as "allowing people to do bad 
things to innocent people".  We are not "allowing"anything.  We are 
trying to properly protect communication, without regard to the content.

Recasting it as the IETF allowing harm misrepresents almost all aspects 
of the problem.

As for squaring teh circle, I tend to trust the many crypto 
professionals who have repeatedly looked at this trying to find 
compromises, and the many reports they have produced about it.

Yours,
Joel

On 10/13/2020 9:34 AM, Stewart Bryant wrote:
> 
> 
>> On 13 Oct 2020, at 14:17, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
>>
>>
>> Hiya,
>>
>> On 13/10/2020 13:48, Stewart Bryant wrote:
>>>
>>> Stephen,
>>>
>>> Those governments are looking for ways to stop real harm to real
>>> people.
>>
>> Some are, yes. That is not all they are interested in doing
>> of course (they all do like a bit of spying here and there:-)
>> and all that varies enormously from one to another government.
>> Some governments want these changes in order to do what I would
>> call harm.
> 
> Engineering calls for a pragmatic balance of results and costs.
> 
>>From where I sit, I see a significant downside in allowing bad people to do bad things to innocent people.
> 
>>
>>>
>>> We have to accept that we have unintentionally played a part in
>>> causing some of that harm.
>>
>> And a lot of good. IMO, on balance, and after having done
>> this stuff for >3 decades, I'm happy that we've done overall
>> far more good (with crypto in protocols) than harm. (That
>> doesn't include surveillance capitalism, but that isn't the
>> same issue.)
>>
>>> So the problem that we have a moral responsibility to address is to
>>> find methods that stop or minimise those harms.
>>
>> I don't accept that. The "we" isn't clear, but what
>> does seem clear is that meeting the requirements posed
>> is (IMO anyway) likely to do more harm. I've never
>> seen any proponent of borked crypto do a proper analysis
>> of the damage that would be done - they almost always
>> seem to approach it as mostly a PR exercise and so go
>> straight to the "think of the children" and "what about
>> the terrorists" talking points.
> 
> Well I am certainly concerned about those two groups.
> 
> So the interesting question is whether there is any other way of addressing the requirement without borking the crypto, at least for the majority of applications used by those causing the harm.
> 
>>
>>> The problem may be hard but so were many other problems that we now
>>> take for granted as solved.
>>
>> I didn't say "hard." I said "squaring the circle." The
>> latter isn't possible and is much more like the "magic"
>> that is being asked for, and has been asked for since
>> the Clipper days, without any technical progress at all
>> in those 25 years.
> 
> Are, but that is my point. Maybe we cannot exactly square the circle, but perhaps, if we look at the problem in the right way we can create a sufficiently close approximation that it satisfies the requirement?
> 
> Stewart
> 
> 
> 
>>
>> S.
>>
>>>
>>> Stewart
>>>
>>>
>>>
>> <0x5AB2FAF17B172BEA.asc>
> 
> _______________________________________________
> Architecture-discuss mailing list
> Architecture-discuss@ietf.org
> https://www.ietf.org/mailman/listinfo/architecture-discuss
>