Re: [kitten] AD review of draft-ietf-kitten-krb-spake-preauth-06

Robbie Harwood <rharwood@redhat.com> Wed, 29 April 2020 17:51 UTC

Return-Path: <rharwood@redhat.com>
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 4F39A3A14F0 for <kitten@ietfa.amsl.com>; Wed, 29 Apr 2020 10:51:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.92
X-Spam-Level:
X-Spam-Status: No, score=-2.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.82, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=redhat.com
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 PayB3fhA-Qpg for <kitten@ietfa.amsl.com>; Wed, 29 Apr 2020 10:51:10 -0700 (PDT)
Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF6D93A14F8 for <kitten@ietf.org>; Wed, 29 Apr 2020 10:51:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1588182669; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=B89TlvPuOhi37OqISBbnqf3B9+60Q+l0iuQdPNkUocg=; b=H37llvrgAKEqTXJnG/H6TESV5bCxRGO4olEfQJbxvSzxJXecOXt8y9kdAi4tD9SM4f628a RqzK3OyCMaET4rXshrSBXeqpkLBiXrM5G5oPU3znU7W4xGe/NyCaAnHE2Yj6GMzz4mgi62 teaionoQeD/yIRdYEaDsV3bvtbI6BXE=
Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-19-wFEgWHqjP1qsezbV23b2lA-1; Wed, 29 Apr 2020 13:50:55 -0400
X-MC-Unique: wFEgWHqjP1qsezbV23b2lA-1
Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 68A48462; Wed, 29 Apr 2020 17:50:54 +0000 (UTC)
Received: from localhost (unknown [10.10.110.74]) by smtp.corp.redhat.com (Postfix) with ESMTP id 53E805D9E5; Wed, 29 Apr 2020 17:50:51 +0000 (UTC)
From: Robbie Harwood <rharwood@redhat.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Greg Hudson <ghudson@mit.edu>, draft-ietf-kitten-krb-spake-preauth.all@ietf.org, Nathaniel McCallum <npmccallum@redhat.com>, kitten@ietf.org
In-Reply-To: <20200429012333.GD27494@kduck.mit.edu>
References: <20190404235859.GM54777@kduck.mit.edu> <5ee8aeab-30c9-f963-3391-3a860e20c426@mit.edu> <jlg8sifqi9w.fsf@redhat.com> <20200429012333.GD27494@kduck.mit.edu>
Date: Wed, 29 Apr 2020 13:50:47 -0400
Message-ID: <jlg1ro62nbc.fsf@redhat.com>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14
X-Mimecast-Spam-Score: 0
X-Mimecast-Originator: redhat.com
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha512"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/WH8T_9WtRAxJx8cAjYKddbC1Zuk>
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 17:51:13 -0000

Benjamin Kaduk <kaduk@mit.edu> writes:

> 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.

Thanks, that's helpful background.

Ben, how would you feel about changing the language to read something
like:

    Registry entries are to be evaluated using the Specification
    Required method.  All specifications must be be published prior to
    entry inclusion in the registry.  Once published, they can be
    submitted directly to the krb5-spake-review@ietf.org mailing list,
    where there will be a three-week long review period by Designated
    Experts.

    Prior to the end of the review period, the Designated Experts must
    approve or deny the request.  This decision is conveyed to both IANA
    and the submitter.  Since the mailing list archives are not public,
    it should include both a reasonably detailed explanation in the case
    of a denial as well as whether the request can be resubmitted.

(I'm not particularly attached to the mechanics of this.  My concerns
are first requiring that a specification exists, and second that it be
checked for reasonableness without being too arduous for submitters.)

Thanks,
--Robbie