Re: IESG Statement On Oppressive or Exclusionary Language

Dan Harkins <dharkins@lounge.org> Sun, 09 August 2020 20:30 UTC

Return-Path: <dharkins@lounge.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 777983A0DE6 for <ietf@ietfa.amsl.com>; Sun, 9 Aug 2020 13:30:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.849
X-Spam-Level:
X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.949, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 NvgwpBG9Gzbv for <ietf@ietfa.amsl.com>; Sun, 9 Aug 2020 13:30:25 -0700 (PDT)
Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 3C9DA3A0D55 for <ietf@ietf.org>; Sun, 9 Aug 2020 13:30:25 -0700 (PDT)
Received: from trixy.bergandi.net (cpe-76-176-14-122.san.res.rr.com [76.176.14.122]) by wwwlocal.goatley.com (PMDF V6.8 #2433) with ESMTP id <0QET1TDMOCYPZ7@wwwlocal.goatley.com> for ietf@ietf.org; Sun, 09 Aug 2020 15:30:25 -0500 (CDT)
Received: from Dans-MacBook-Pro.local ([69.12.173.8]) by trixy.bergandi.net (PMDF V6.7-x01 #2433) with ESMTPSA id <0QET00FF8DBCZH@trixy.bergandi.net> for ietf@ietf.org; Sun, 09 Aug 2020 13:38:01 -0700 (PDT)
Received: from 69-12-173-8.static.dsltransport.net ([69.12.173.8] EXTERNAL) (EHLO Dans-MacBook-Pro.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Sun, 09 Aug 2020 13:38:00 -0700
Date: Sun, 09 Aug 2020 13:30:23 -0700
From: Dan Harkins <dharkins@lounge.org>
Subject: Re: IESG Statement On Oppressive or Exclusionary Language
In-reply-to: <1C71E46D-E3D8-441D-8131-83128FDEDD94@strayalpha.com>
To: Joe Touch <touch@strayalpha.com>
Cc: ietf@ietf.org
Message-id: <0b4e9337-6d7e-bb5b-5028-9702920c9e79@lounge.org>
MIME-version: 1.0
Content-type: text/plain; charset="utf-8"; format="flowed"
Content-language: en-US
Content-transfer-encoding: 8bit
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=69.12.173.8)
X-PMAS-External-Auth: 69-12-173-8.static.dsltransport.net [69.12.173.8] (EHLO Dans-MacBook-Pro.local)
References: <45d477cb-7cca-55c7-c4f1-d12cab784997@lounge.org> <1C71E46D-E3D8-441D-8131-83128FDEDD94@strayalpha.com>
X-PMAS-Software: PreciseMail V3.3 [200808b] (trixy.bergandi.net)
X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/IX87LnBvGrTKUyKlMbuxoujO1bY>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 09 Aug 2020 20:30:37 -0000

On 8/9/20 12:58 PM, Joe Touch wrote:
> In physical locks, the master is the common key. It doesn’t control the other keys.
>
> In crypto, the master is the root or primary; others are child or derivatives. It doesn’t ‘control’ them either.
>
> Most crypto texts and docs need to explain that because it’s not understood from the terms alone.

   Who said anything about control? As has been pointed out to you already
on the list, there are different meanings to the word "master" and those
other meanings do not necessarily reflect a controlling relationship.

   I haven't seen any crypto texts spend any time explaining how the "master
key" doesn't really control the other keys. Seriously, zero out of hundreds
that I've read. It's a term of art.

   But then so is "master bathroom" and we have already seen the woke virus
infect the realty business.

   Dan.

> Joe
>
>> On Aug 9, 2020, at 12:50 PM, Dan Harkins <dharkins@lounge.org> wrote:
>>
>> 
>> On 8/9/20 12:23 PM, Joe Touch wrote:
>>>>> On Aug 9, 2020, at 10:54 AM, Nico Williams <nico@cryptonector.com> wrote:
>>>>   Really, asserting that "master secret"
>>>> is problematic is simply credibility-destroying.
>>> Besides your concern, how does one secret actively control another?
>>>
>>> Or is it just that there is one root key from which others are derived?
>>>
>>> Ie why even bother defending a term that’s inaccurate to start?
>>    It's not inaccurate.
>>
>>    In locksmithing a "master key" is one that opens all the doors while a
>> non-master key (which is not called a "slave key" by the way) only opens
>> the door it is milled for.
>>
>>    Analogously, in cryptology a key can be a "master key" if possession of
>> it can be used to decrypt all the different traffic flows and a non-master
>> key (which is also not called a "slave key") only decrypts the flow it
>> was generated for. It's a great term.
>>
>>    You can even get key hierarchies and the analogy holds. There could be
>> one key for all doors in the building and separate keys for all doors on
>> particular floors and then keys that are specific for particular doors.
>> Similarly you could have a key that could be used to decrypt all flows on
>> all cluster members, a separate key that could be used to decrypt all
>> flows on one cluster, and flow-specific keys that just decrypt one
>> individual flow on one cluster. It's a great term.
>>
>>    Asserting that use of "master key" or "master secret" is a problem or
>> that it somehow "discourages participation in the IETF" (which is what has
>> been asserted for this new category of Problematic Words) is absurd!
>>
>>    Dan.
>>
>>