Re: [Secdispatch] GNU Name System

Russ Housley <housley@vigilsec.com> Fri, 24 July 2020 13:34 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: secdispatch@ietfa.amsl.com
Delivered-To: secdispatch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE41F3A08A6 for <secdispatch@ietfa.amsl.com>; Fri, 24 Jul 2020 06:34:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=unavailable 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 minou8WlkTqN for <secdispatch@ietfa.amsl.com>; Fri, 24 Jul 2020 06:34:50 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 575F53A0AF5 for <secdispatch@ietf.org>; Fri, 24 Jul 2020 06:34:50 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C2C3E300B6A for <secdispatch@ietf.org>; Fri, 24 Jul 2020 09:34:47 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 5VRIgZnG-2XW for <secdispatch@ietf.org>; Fri, 24 Jul 2020 09:34:46 -0400 (EDT)
Received: from a860b60074bd.fios-router.home (pool-72-66-113-56.washdc.fios.verizon.net [72.66.113.56]) by mail.smeinc.net (Postfix) with ESMTPSA id 18933300A48; Fri, 24 Jul 2020 09:34:46 -0400 (EDT)
From: Russ Housley <housley@vigilsec.com>
Message-Id: <AAD94089-98A1-46D4-AAAC-3ED7B68CAC8C@vigilsec.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D813475A-AC73-4179-A2D8-25DDCB2C99B5"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.15\))
Date: Fri, 24 Jul 2020 09:34:47 -0400
In-Reply-To: <707BC467-05E0-43C9-AF86-AE741E4E26FD@callas.org>
Cc: IETF SecDispatch <secdispatch@ietf.org>, "draft-schanzen-gns@ietf.org" <draft-schanzen-gns@ietf.org>
To: Jon Callas <jon@callas.org>
References: <31625.1595368614@localhost> <707BC467-05E0-43C9-AF86-AE741E4E26FD@callas.org>
X-Mailer: Apple Mail (2.3445.104.15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/LLwCZc2MmMc0yQiCHo9cT_UUgdU>
Subject: Re: [Secdispatch] GNU Name System
X-BeenThere: secdispatch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Dispatch <secdispatch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdispatch/>
List-Post: <mailto:secdispatch@ietf.org>
List-Help: <mailto:secdispatch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdispatch>, <mailto:secdispatch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 24 Jul 2020 13:34:52 -0000

Jon:

> * There are a number of eccentric things in the protocol now. I don't mean that as a pejorative -- there are lots of eccentric things I like, SDSI, for example. I also like CFB mode as well as Twofish. Why, though, are they here? Are the design decisions leading to these? There's not a lot in the draft about these decisions. In general, it's better to stick to the well-trodden paths, to pick algorithms, modes, etc. that are in common use. In specific there are often reasons to do something on its own; I can see that a naming system might have reasons for going its own way. We just need a discussion of them. New code, new algorithms mean new bugs. If you can write about these decisions, "Most people do X, we are doing Y, because Z" that helps understand why the decisions are there. Some can be guessed -- CFB means no CBC padding, and no keying issues of a stream cipher like CTR mode. Tell us, though. I also really want to see what's going on and why with the record data encryption ini
>  4.3. 

These days, I ask why an AEAD is not being used.

Russ