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

Robbie Harwood <rharwood@redhat.com> Tue, 29 August 2017 18:08 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 BEA7B132C37; Tue, 29 Aug 2017 11:08:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level:
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 D1NjR77kx2_Z; Tue, 29 Aug 2017 11:08:51 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 611801321AF; Tue, 29 Aug 2017 11:08:51 -0700 (PDT)
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 mx1.redhat.com (Postfix) with ESMTPS id 0353481236; Tue, 29 Aug 2017 18:08:51 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 0353481236
Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=rharwood@redhat.com
Received: from localhost (ovpn-66-67.rdu2.redhat.com [10.10.66.67]) by smtp.corp.redhat.com (Postfix) with ESMTP id B97595D98C; Tue, 29 Aug 2017 18:08:50 +0000 (UTC)
From: Robbie Harwood <rharwood@redhat.com>
To: Benjamin Kaduk <kaduk@mit.edu>, Greg Hudson <ghudson@mit.edu>
Cc: kitten@ietf.org, draft-ietf-kitten-krb-spake-preauth@ietf.org
In-Reply-To: <20170829012338.GM96685@kduck.kaduk.org>
References: <20170818181043.GC35188@kduck.kaduk.org> <59e6271c-5970-5cb7-209a-73a1e02cc5f8@mit.edu> <jlga82r2q1t.fsf@redhat.com> <c6d33fc1-13b6-03cf-0138-f3219cf7d7a1@mit.edu> <20170829012338.GM96685@kduck.kaduk.org>
Date: Tue, 29 Aug 2017 14:09:26 -0400
Message-ID: <jlg378a1c15.fsf@redhat.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Tue, 29 Aug 2017 18:08:51 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/8GPlHpAwcgFy_YGd2lSqB5VDEMY>
Subject: Re: [kitten] review of draft-ietf-kitten-krb-spake-preauth-00
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.22
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, 29 Aug 2017 18:08:53 -0000

Benjamin Kaduk <kaduk@mit.edu> writes:

> On Tue, Aug 22, 2017 at 06:49:58PM -0400, Greg Hudson wrote:
>> On 08/22/2017 06:30 PM, Robbie Harwood wrote:
>> >> I tend to agree that any mandatory-to-implement policy should be
>> >> written into this draft, and not be part of the registry.
>> > 
>> > The disadvantage of having mandatory-to-implement items defined but not
>> > in the registry is that it fragments the numbering.  For example, in our
>> > Kerberos SPAKE Groups registry, currently P-256 is required, and
>> > assigned ID Number: 1.  If we remove it from the registry, it won't have
>> > an ID Number.  (Unless we give it one a different way.)
>> 
>> I think I miscommunicated.  P-256 should be in the registry, but if we
>> want to specify that it is mandatory-to-implement, I believe we should
>> say that in the RFC outside of the IANA registry.
>
> That's my understanding as well -- the MTI items should still be in
> the registry, but the registry is not the best place to specify the
> MTI nature.  Making something MTI for a standards-track document
> "should" require standards-action, so there's not much value in having
> a field in the registry when there will have to be a new document
> for such things anyway.

Thanks for clarifying.  Language changes have been proposed.

--Robbie