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