Re: [Secdispatch] GNU Name System

Jon Callas <jon@callas.org> Fri, 24 July 2020 20:02 UTC

Return-Path: <jon@callas.org>
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 9D9F73A0B01 for <secdispatch@ietfa.amsl.com>; Fri, 24 Jul 2020 13:02:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=callas.org
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 hMKoBs6Ca_rT for <secdispatch@ietfa.amsl.com>; Fri, 24 Jul 2020 13:02:42 -0700 (PDT)
Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D35A3A0B00 for <secdispatch@ietf.org>; Fri, 24 Jul 2020 13:02:42 -0700 (PDT)
Received: by mail-pl1-x630.google.com with SMTP id f7so239665pln.13 for <secdispatch@ietf.org>; Fri, 24 Jul 2020 13:02:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=callas.org; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0HAwko5GFx0iHW2MKeftIya3bQYZ5BarzyyKppVxtAI=; b=IN//Sn2v4SHo8Q9GCBv3mxj/ZvDibLKNsSFy6yuM8GVC/Zu5hp2lYTjw0qUd77KCXz EIGbAbL5B7gRAqMPYuOCMeRNBWqiQ7fS+SNFXqwjAclWENPbC5D7zXGDL+gdCAHHsGJR MoVe1YLQ2BTTqbd+PcyqNzEog9KVldzmd3VJhCIc6pFr2yVHvjpPRIt/dcoSj9NtI+nl 1Zr3Q/mJQpLGgOPJYX8Gm2GIGHBL59HqsFoiFjMWlHa1GN5GLq/M26EVijgMpGGqnFzF eGQ5ytwqdkL8I9uiq43GzWVEpOClw4WkFa6Y1nO0gsA6hnC+TgtxUZSp+7KWPkfO7DeY 1ZnQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=0HAwko5GFx0iHW2MKeftIya3bQYZ5BarzyyKppVxtAI=; b=ROU03ugXnt9kphyeMqqAAxwR9XJ2UfxdBuCzr7WANxdQhlsMJfoGQ3DtJAXvNfr1vv tVVOKixkLwDuUw5ywyL526GH3FTFgjCw5BRnHwg74dospBG49+6KcL3oCrAPbaMOAa6p 7PpuHKD/SKOQailcAJrXQOP9HcmF5G62fLvnF34iZNLQPazlCpFkfjWkEqKjTordvJqe hMRf36DAF6eMZF2uNkD49QjrnYqh3oGAPj7Jia82pSA9WT0otedCdfVYt20aEywpQKcL OY/IfqLUS270VZCjNwLTSnmUfi1VGVWHkUdFv4vZJlujPGTWatblmP1UEymbmekfXbLf /O4g==
X-Gm-Message-State: AOAM531NcMdJeou/q/2xGiiDh7+U2fC7o6uiR6narK0A8iF+2NpfAaYD EWrWMUjUbItcDw0+k8N4xiQV5A==
X-Google-Smtp-Source: ABdhPJyXJ6pBSe9es1IpldP74SR+5PYAaA+ROO7qL8WIdAgQR97ybtEbx6tH0tsnNvRPCgnXvA1fIg==
X-Received: by 2002:a17:90b:3750:: with SMTP id ne16mr6932218pjb.6.1595620961674; Fri, 24 Jul 2020 13:02:41 -0700 (PDT)
Received: from ?IPv6:2600:1700:38c4:12bf:9d37:7e34:323c:582b? ([2600:1700:38c4:12bf:9d37:7e34:323c:582b]) by smtp.gmail.com with ESMTPSA id 2sm7289026pfa.110.2020.07.24.13.02.40 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Jul 2020 13:02:41 -0700 (PDT)
From: Jon Callas <jon@callas.org>
Message-Id: <49DED701-CB78-4228-AFED-1E4421CE5EA7@callas.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_17E40F7C-9C17-41AC-9E02-E95C56622DDD"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Date: Fri, 24 Jul 2020 13:02:40 -0700
In-Reply-To: <AAD94089-98A1-46D4-AAAC-3ED7B68CAC8C@vigilsec.com>
Cc: Jon Callas <jon@callas.org>, IETF SecDispatch <secdispatch@ietf.org>, "draft-schanzen-gns@ietf.org" <draft-schanzen-gns@ietf.org>
To: Russ Housley <housley@vigilsec.com>
References: <31625.1595368614@localhost> <707BC467-05E0-43C9-AF86-AE741E4E26FD@callas.org> <AAD94089-98A1-46D4-AAAC-3ED7B68CAC8C@vigilsec.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdispatch/VAl-ZAGd-KFXucowJZKC-F6MZGQ>
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 20:02:44 -0000


> On Jul 24, 2020, at 6:34 AM, Russ Housley <housley@vigilsec.com> wrote:
> 
> 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.


That's why I framed it in terms of CBC or CTR. 

	Jon