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

Robbie Harwood <rharwood@redhat.com> Tue, 28 April 2020 23:53 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 F31FE3A0AE4 for <kitten@ietfa.amsl.com>; Tue, 28 Apr 2020 16:53:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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, SPF_HELO_NONE=0.001, SPF_PASS=-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 yDIgRE-qyHPr for <kitten@ietfa.amsl.com>; Tue, 28 Apr 2020 16:53:44 -0700 (PDT)
Received: from us-smtp-delivery-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE7943A085A for <kitten@ietf.org>; Tue, 28 Apr 2020 16:53:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1588118022; 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=dZwgdwFqtJOPX164Fm8gycRf55mqp739IZLxerUkYm8=; b=cAX9rBswHqfeSwiXTxWdIamzPPdlbbppMsKbzMDWoFgghqeh2XYJi5I6s0VspsXk4gUIEe lEzdoukrtizZfiNkBt55T19/2Ufa2uvsN9g3A64baYxiNNotRmMOUU3m0qaGV/sNufbOEx QXtbYh2Yap9jIlvTfQD14afYjBQBs+4=
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-289-yqI8SQy-MVOIFt34lsVaig-1; Tue, 28 Apr 2020 19:53:38 -0400
X-MC-Unique: yqI8SQy-MVOIFt34lsVaig-1
Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A640D835B44; Tue, 28 Apr 2020 23:53:37 +0000 (UTC)
Received: from localhost (unknown [10.10.110.58]) by smtp.corp.redhat.com (Postfix) with ESMTP id B5A3519C4F; Tue, 28 Apr 2020 23:53:34 +0000 (UTC)
From: Robbie Harwood <rharwood@redhat.com>
To: Greg Hudson <ghudson@mit.edu>, Benjamin Kaduk <kaduk@mit.edu>, draft-ietf-kitten-krb-spake-preauth.all@ietf.org, Nathaniel McCallum <npmccallum@redhat.com>
Cc: kitten@ietf.org
In-Reply-To: <5ee8aeab-30c9-f963-3391-3a860e20c426@mit.edu>
References: <20190404235859.GM54777@kduck.mit.edu> <5ee8aeab-30c9-f963-3391-3a860e20c426@mit.edu>
Date: Tue, 28 Apr 2020 19:53:31 -0400
Message-ID: <jlg8sifqi9w.fsf@redhat.com>
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23
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/GaLC2_fAbWW-ab6PeIA3nOvwbAE>
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: Tue, 28 Apr 2020 23:53:46 -0000

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.

Thanks,
--Robbie