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

Alissa Cooper <alissa@cooperw.in> Tue, 25 June 2019 14:53 UTC

Return-Path: <alissa@cooperw.in>
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 15962120183; Tue, 25 Jun 2019 07:53:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cooperw.in header.b=M5EOXj/O; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=D5zCpJ6C
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 FE2QC4KsuhE8; Tue, 25 Jun 2019 07:53:37 -0700 (PDT)
Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 028421205E1; Tue, 25 Jun 2019 07:53:28 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id ECF48220FF; Tue, 25 Jun 2019 10:53:26 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Tue, 25 Jun 2019 10:53:26 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm3; bh=v m8oq0eVdPoAT1I84LMjV7r2781Vsp1eicbzocjcjok=; b=M5EOXj/OmMApEwcVo pbD6X4CoMy/j70Bci0FUT4rA2Pr/Vpn0FK0m6fg7Yzi9rT/XNZc6/nYg9iFl37ED OeTxn+Un5N3zVcySn+N3oYVCgxb28rqWHg1eC6wxqe5ZwbjsLCjJ1dxCridzp2ga neulAW0ovC8PkqKur2+UChqFsDcc6RH+4SLtfvywdF3F5pINdtv6FcPCR8F5D5lU pXLTrUIcqnC0bC3CBqW169kCzoVn3uRiBeqo90vtEV8DCRFDQvzcliabytlvpnz9 qw5G3E4gMKqIWoIJJYx3fV1CJtz5xUMpj5gzjin8pPvQ2mROiqD30Jq+VRUHz1hK iKhBg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=vm8oq0eVdPoAT1I84LMjV7r2781Vsp1eicbzocjcj ok=; b=D5zCpJ6CsWLLqaLG4cCZRXSv1MFdt5QOeqwA4Ubw+Kjj7iIxwNVNdy66+ y65iWBdnUPjx1lifl23M5hkXscEjU+IfJnTBJJ/36ewa/An1VSAW/pqlas+gYe91 D5ssI9XCrc7IgV27XdzbvSKWxfBuPwGVeDiIIyDR8QmDNj+y2HYKoFxc4pSu0rdU Ulm6wpLq84OdtWJu7Lj2/krxGWGLO3GlAHImzjxq0PTqUG55Xw/OjiOhCT0UPc8I LluQNA5mBXxkyyn+V8yt8aKEE4I/3yGOEBS6184gcVou8r4uqhF0QdSy+6viEtlq z/Pjk9xIia6pfdX3Jat19rT89dXRA==
X-ME-Sender: <xms:ZjUSXbLyTRVhkcfkcN2MqDQVQRMD4xjAaza0PMTn96JNv06LAztxew>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrudeggdekudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtdejnecuhfhrohhmpeetlhhishhs rgcuvehoohhpvghruceorghlihhsshgrsegtohhophgvrhifrdhinheqnecuffhomhgrih hnpehivghtfhdrohhrghenucfkphepuddtkedrhedurddutddurdelkeenucfrrghrrghm pehmrghilhhfrhhomheprghlihhsshgrsegtohhophgvrhifrdhinhenucevlhhushhtvg hrufhiiigvpedt
X-ME-Proxy: <xmx:ZjUSXbFXgat2-hdLWTCHUSigTKP3WzlHrpl8ZL-I-A_WTV81d8-VQg> <xmx:ZjUSXWx5mC0_SuyzNidpLZM1rUfafFSUD3qwB7SB5zEpiBueNQbqdA> <xmx:ZjUSXfxqYi7WLGVd2k9jswyIREQCii9Y0QdR7xmUR7mYBDt16e6xOQ> <xmx:ZjUSXXcKmMF24ukzqD1m-7ujXYW5-EPWaXRPBFAknJXRkp4vmtTVgw>
Received: from alcoop-m-c46z.fios-router.home (pool-108-51-101-98.washdc.fios.verizon.net [108.51.101.98]) by mail.messagingengine.com (Postfix) with ESMTPA id 553D780061; Tue, 25 Jun 2019 10:53:26 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <4706ad44c52bf2a76c429fc40d8c3a64c59b2303.camel@redhat.com>
Date: Tue, 25 Jun 2019 10:53:25 -0400
Cc: Benjamin Kaduk <kaduk@mit.edu>, IESG <iesg@ietf.org>, draft-ietf-curdle-gss-keyex-sha2@ietf.org, daniel.migault@ericsson.com, curdle-chairs@ietf.org, curdle@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <D2EB3E35-9282-418B-9E89-1A539CCA4292@cooperw.in>
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> <4706ad44c52bf2a76c429fc40d8c3a64c59b2303.camel@redhat.com>
To: Simo Sorce <simo@redhat.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/curdle/hkTvQmMC8oBXvSvXjQlaoCic-Zs>
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: Tue, 25 Jun 2019 14:53:40 -0000


> On Jun 24, 2019, at 5:15 PM, Simo Sorce <simo@redhat.com> wrote:
> 
> 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.

Since this document updates RFC 4462, would it be possible to add a note (perhaps in Section 3) indicating that the term “owner” is synonymous with “change controller” in both documents?

Thanks,
Alissa

> 
> Simo.
> 
> -- 
> Simo Sorce
> RHEL Crypto Team
> Red Hat, Inc
> 
> 
> 
>