Re: [Curdle] Alissa Cooper's Discuss on draft-ietf-curdle-gss-keyex-sha2-09: (with DISCUSS)

Benjamin Kaduk <kaduk@mit.edu> Mon, 24 June 2019 21:08 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: curdle@ietfa.amsl.com
Delivered-To: curdle@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60AAF120199; Mon, 24 Jun 2019 14:08:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 TFoNhaosZTJo; Mon, 24 Jun 2019 14:08:50 -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 4BD87120177; Mon, 24 Jun 2019 14:08:49 -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 x5OL8cAm024460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 24 Jun 2019 17:08:40 -0400
Date: Mon, 24 Jun 2019 16:08:37 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Alissa Cooper <alissa@cooperw.in>
Cc: IESG <iesg@ietf.org>, draft-ietf-curdle-gss-keyex-sha2@ietf.org, daniel.migault@ericsson.com, curdle-chairs@ietf.org, curdle@ietf.org
Message-ID: <20190624210837.GE48838@kduck.mit.edu>
References: <156140748841.17734.7894701055354347252.idtracker@ietfa.amsl.com> <20190624201955.GD48838@kduck.mit.edu> <2F78AD47-6C9C-457E-9AA1-031EEBC9082F@cooperw.in>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <2F78AD47-6C9C-457E-9AA1-031EEBC9082F@cooperw.in>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/SFikg-xhafXKHkMT6DdqymNVXzs>
Subject: Re: [Curdle] Alissa Cooper's Discuss on draft-ietf-curdle-gss-keyex-sha2-09: (with DISCUSS)
X-BeenThere: curdle@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "List for discussion of potential new security area wg." <curdle.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/curdle>, <mailto:curdle-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/curdle/>
List-Post: <mailto:curdle@ietf.org>
List-Help: <mailto:curdle-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/curdle>, <mailto:curdle-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Jun 2019 21:08:52 -0000

On Mon, Jun 24, 2019 at 05:01:28PM -0400, Alissa Cooper wrote:
> 
> 
> > On Jun 24, 2019, at 4:19 PM, Benjamin Kaduk <kaduk@mit.edu> wrote:
> > 
> > On Mon, Jun 24, 2019 at 01:18:08PM -0700, Alissa Cooper via Datatracker wrote:
> >> Alissa Cooper has entered the following ballot position for
> >> draft-ietf-curdle-gss-keyex-sha2-09: Discuss
> >> 
> >> When responding, please keep the subject line intact and reply to all
> >> email addresses included in the To and CC lines. (Feel free to cut this
> >> introductory paragraph, however.)
> >> 
> >> 
> >> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> >> for more information about IESG DISCUSS and COMMENT positions.
> >> 
> >> 
> >> The document, along with other ballot positions, can be found here:
> >> https://datatracker.ietf.org/doc/draft-ietf-curdle-gss-keyex-sha2/
> >> 
> >> 
> >> 
> >> ----------------------------------------------------------------------
> >> DISCUSS:
> >> ----------------------------------------------------------------------
> >> 
> >> "The IESG is considered to be the owner of all these key exchange
> >>   methods; this does NOT imply that the IESG is considered to be the
> >>   owner of the underlying GSS-API mechanism."
> >> 
> >> I don't understand this text. What does it mean for the IESG to be the owner of a method?
> > 
> > The IESG has change control for the SSH key exchange method; the IESG does
> > not necessarily have change control for the underlying GSS-API mechanism.
> 
> Thanks. I think it would be clearer to say that than to talk about ownership. But given that the registry policy is IETF Review, is it really appropriate to say that the IESG has change control? Would s/IESG has change control/IETF has change control/ be more accurate?

I'll wait to see what the authors think about the "ownership" vs. "change
control" pedagogy.  With respect to IESG vs. IETF, it seems that the IESG
is who is tasked with determining the consensus of the IETF, so in practice
it would be the IESG with control, even if in some formal sense the
authority is vested with the IETF.  (I thought it was near-universal to
list the IESG as the contact when the IETF is the nominal responsible
party; is this case different somehow?)

Thanks,

Ben