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

Simo Sorce <simo@redhat.com> Mon, 24 June 2019 21:15 UTC

Return-Path: <simo@redhat.com>
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 20293120199; Mon, 24 Jun 2019 14:15:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 IHoK-ad32YD2; Mon, 24 Jun 2019 14:15:35 -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 1817B12016B; Mon, 24 Jun 2019 14:15:35 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 189FFC0546D3; Mon, 24 Jun 2019 21:15:27 +0000 (UTC)
Received: from ovpn-117-91.phx2.redhat.com (ovpn-117-91.phx2.redhat.com [10.3.117.91]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 263F510013D9; Mon, 24 Jun 2019 21:15:23 +0000 (UTC)
Message-ID: <4706ad44c52bf2a76c429fc40d8c3a64c59b2303.camel@redhat.com>
From: Simo Sorce <simo@redhat.com>
To: Benjamin Kaduk <kaduk@mit.edu>, 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
Date: Mon, 24 Jun 2019 17:15:22 -0400
In-Reply-To: <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> <20190624210837.GE48838@kduck.mit.edu>
Organization: Red Hat, Inc.
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Mon, 24 Jun 2019 21:15:34 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/648I4xzBEjwXVJr1m54gwKjxB9o>
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:15:37 -0000

On Mon, 2019-06-24 at 16:08 -0500, Benjamin Kaduk wrote:
> 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?)

If I remember correctly this language has been inherited untouched from
the original RFC we are updating.

If at all possible we'd like to maintain consistency with the previous
language and not change it.

Simo.

-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc