Re: [kitten] AD review of draft-ietf-kitten-krb-spake-preauth-06
Benjamin Kaduk <kaduk@mit.edu> Wed, 29 April 2020 01:23 UTC
Return-Path: <kaduk@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 BCCC43A099F; Tue, 28 Apr 2020 18:23:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, 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 tRIDe2jICJ3f; Tue, 28 Apr 2020 18:23:38 -0700 (PDT)
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 88FA13A0998; Tue, 28 Apr 2020 18:23:38 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 03T1NXfl018654 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Apr 2020 21:23:36 -0400
Date: Tue, 28 Apr 2020 18:23:33 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Robbie Harwood <rharwood@redhat.com>
Cc: Greg Hudson <ghudson@mit.edu>, draft-ietf-kitten-krb-spake-preauth.all@ietf.org, Nathaniel McCallum <npmccallum@redhat.com>, kitten@ietf.org
Message-ID: <20200429012333.GD27494@kduck.mit.edu>
References: <20190404235859.GM54777@kduck.mit.edu> <5ee8aeab-30c9-f963-3391-3a860e20c426@mit.edu> <jlg8sifqi9w.fsf@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <jlg8sifqi9w.fsf@redhat.com>
User-Agent: Mutt/1.12.1 (2019-06-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/QNkXT77QH1JHuuWRAUyvDazTBHw>
Subject: Re: [kitten] AD review of draft-ietf-kitten-krb-spake-preauth-06
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 29 Apr 2020 01:23:41 -0000
On Tue, Apr 28, 2020 at 07:53:31PM -0400, Robbie Harwood wrote: > Greg Hudson <ghudson@mit.edu> writes: > > > Ben sent feedback on the SPAKE preauth draft a little over a year ago. > > I deferred acting on the smaller feedback items at the time, while > > observing the CFRG's progress on PAKE algorithms. > > > > The CFRG has selected CPace over SPAKE2 for a balanced PAKE. As such > > I doubt there will be a need for a CFRG SPAKE2 document. At this time > > I don't think there would be sufficient interest in retooling the > > Kerberos preauth mechanism for CPace, or making breaking changes. I > > have prepared changes to draft-ietf-kitten-krb-spake-preauth to drop > > its dependency on draft-irtf-cfrg-spake2, instead referring > > informatively to the Abdalla/Pointcheval paper and describing the > > group operations explicitly. > > > > These changes, as well as updates addressing the smaller feedback > > items, are at > > https://github.com/greghudson/ietf/commit/6ecf1b9dfacc804692d858c726888855a512b8b7 > > . I will update the draft unless it seems like there isn't WG > > consensus on this direction. > > Appreciate you being proactive about picking up work on SPAKE again. > > > Some responses to a few of the smaller feedback items: > > > > On 4/4/19 7:58 PM, Benjamin Kaduk wrote: > >> > >> In addition to potentially allocating a new value for the RFC version > >> of this spec, we probably also want to say a bit more about the > >> registration procedures. Should requestors send the request directly > >> to the list, or to IANA first and IANA sends to the list? Is the > >> list publicly archived (and can anyone sign up as a member)? > > > > I'm a little lost here. The mailing list was Nathaniel's idea and I am > > not attached to it. There are hundreds of IANA registries; it seems > > like we should be picking from a few best practices for update > > procedures rather than breaking ground. > > CCing Nathaniel - anything to add? > > I accept some of the blame for this - I think I wrote the language - but > the mailing list was Nathaniel's request. I believe I modeled what it > specifies after RFC 7517 (there's no particular reason for that one, > just what we happened to be working on at the time). > > Is it normal for requests to be sent to IANA at all when Designated > Experts are used? Is the mailing list registration normally specified > in this fashion? I can't find anything in RFC 8126 about it, but I'm > happy to make changes / accept changes to this document regardless. I think that the mailing list thing gained traction with a group of folks in the OAuth community and expanded through to JOSE+JWT and then the IoT analogues (COSE+CWT), at which point it was large enough that other unrelated groups started picking up on it (including TLS). There's nothing that requires having a mailing list, though it does give the community some visibility into the workings of the DE review process (as well as, depending on list permissions, a way to get notified about pending allocations). That said, the default behavior you get for a registry if you don't say otherwise, is that IANA is the first point of contact. That is, you ask IANA to allocate a value (usually via a webform), and behind the scenes IANA goes off and talks to the Experts, before acting on the decision of the Experts. Sometimes IANA has to relay questions and answers back and forth and it feels a bit silly, but that's the way it's historically been done. As a couple examples, RFC 7519 (JWT) creates jwt-reg-review@ietf.org, and https://datatracker.ietf.org/list/nonwg lists a few more. I don't think there is a perfect example yet of what text to use in the RFC when using this sort of review process, though -- the examples that come to mind still leave some ambiguity about what requestors and IANA are supposed to do. -Ben
- [kitten] AD review of draft-ietf-kitten-krb-spake… Benjamin Kaduk
- Re: [kitten] AD review of draft-ietf-kitten-krb-s… Greg Hudson
- Re: [kitten] AD review of draft-ietf-kitten-krb-s… Benjamin Kaduk
- Re: [kitten] AD review of draft-ietf-kitten-krb-s… Greg Hudson
- Re: [kitten] AD review of draft-ietf-kitten-krb-s… Greg Hudson
- Re: [kitten] AD review of draft-ietf-kitten-krb-s… Benjamin Kaduk
- Re: [kitten] AD review of draft-ietf-kitten-krb-s… Robbie Harwood
- Re: [kitten] AD review of draft-ietf-kitten-krb-s… Benjamin Kaduk
- Re: [kitten] AD review of draft-ietf-kitten-krb-s… Nathaniel McCallum
- Re: [kitten] AD review of draft-ietf-kitten-krb-s… Robbie Harwood
- Re: [kitten] AD review of draft-ietf-kitten-krb-s… Benjamin Kaduk
- Re: [kitten] AD review of draft-ietf-kitten-krb-s… Benjamin Kaduk