Re: [kitten] Murray Kucherawy's No Objection on draft-ietf-kitten-krb-spake-preauth-11: (with COMMENT)

Greg Hudson <ghudson@mit.edu> Mon, 22 January 2024 13:51 UTC

Return-Path: <ghudson@mit.edu>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED100C14CF0C for <kitten@ietfa.amsl.com>; Mon, 22 Jan 2024 05:51:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mit.edu
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eE77SgOcEnid for <kitten@ietfa.amsl.com>; Mon, 22 Jan 2024 05:51:38 -0800 (PST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 2B4D1C14CEFD for <kitten@ietf.org>; Mon, 22 Jan 2024 05:51:38 -0800 (PST)
Received: from [192.168.1.15] (pool-173-76-238-212.bstnma.fios.verizon.net [173.76.238.212]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 40MDpTOs026656 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 22 Jan 2024 08:51:30 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1705931492; bh=B2FSEd2HIL2WkqO0VwCuwUZ3Ibv13KsOTl706ge0ZLc=; h=Message-ID:Date:MIME-Version:Subject:From:Content-Type; b=VEI9oCo4HVbqODboqmGxIJoMCzuIzh1OUgnd95gKQRpPulCeipqwFskkdJN22T9Hc ltGn4olam4FrluXuCXcZJgZLEY2H0HHHja08pU7cOeNazjWKVj+BROCaSG+8YU7i/C Jn4uz57gm/2ovLAUKDr4zn/FhbTjfmqGuD/WvHlV6iCXbypNrYxq9Y7D1mghrwqH+a Dxo7WsRfb76qWgqEDSRwMRIBcaIt7nXnoI3S38f40yCnVH1t+C50ges9C27bx07AQ/ lt22d+70fbR7BgR6gjPugv1hOYr1EJ+iC9+6kWM9ciZ7rZBkqtZD/rcWU8n3vEpU8s DN1KuzsLl33gA==
Message-ID: <00445cfa-b492-4179-8835-20f0339a41cd@mit.edu>
Date: Mon, 22 Jan 2024 08:51:29 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-kitten-krb-spake-preauth@ietf.org, kitten-chairs@ietf.org, kitten@ietf.org, Nicolas Williams <nico@cryptonector.com>
References: <170559100930.21281.8142882686300667918@ietfa.amsl.com> <d5d9e798-c6c1-4f15-a1f2-4e08580a70c4@mit.edu> <CAL0qLwZUOepsqoGY+kb5tB8CBc=EOYAtoSXk35XAMD4LF5Hw8w@mail.gmail.com>
From: Greg Hudson <ghudson@mit.edu>
In-Reply-To: <CAL0qLwZUOepsqoGY+kb5tB8CBc=EOYAtoSXk35XAMD4LF5Hw8w@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/4zwa1qRJQDq_SzRYL9rle__n1SI>
Subject: Re: [kitten] Murray Kucherawy's No Objection on draft-ietf-kitten-krb-spake-preauth-11: (with COMMENT)
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 Jan 2024 13:51:39 -0000

On 1/18/24 23:17, Murray S. Kucherawy wrote:
>>> In Section 12, we're telling the Designated Experts that an I-D
>>> counts as a specification, even if it is never published as an RFC.

I misunderstood this comment as referring to the PA-SPAKE (151) 
registration in the existing IANA Kerberos preauthentication type 
registry.  Because of this misunderstanding, I initially replied that I 
assumed the comment wasn't actionable.

The comment was actually about the sentence "It is sufficient to have an 
Internet-Draft (that is posted and never published as an RFC)..." in the 
text establishing two new registries.  As Amanda Baber pointed out, this 
text also appears in RFC 8447.

Speaking as an implementer: we have seen numerous expensive mishaps 
related to number spaces in the Kerberos ecosystem over the decades, but 
to my knowledge none of them have involved implementers being warned 
away by references to expired I-Ds in registries.  I believe that the 
advantages of allowing I-Ds as specification references (they are 
in-house, long-lasting, and have a low barrier to entry) outweigh the 
disadvantages (they contain the word "draft" and may say that they are 
expired when you look them up).  This is a fairly weak preference.

Speaking as a document editor: based on the positions of Nico Williams 
and Simo Sorce, I think changing this sentence would not reflect WG 
consensus.  I hear and understand Eliot Lear's argument that this 
document should not endeavor to change global IANA policy regarding 
specification-required registries, but given the precedent in RFC 8447, 
I agree with Stephen Farrell that it would actually be a policy change 
to prevent new registries from explicitly allowing I-D specification 
references.

So for the next draft revision, I do not plan to change this sentence. 
If the IETF chooses to change it before publication, I do not object.