Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ace-dtls-authorize-12

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 27 October 2020 15:31 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F48A3A0E91; Tue, 27 Oct 2020 08:31:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level:
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.247, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=alum.mit.edu
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 ybrqRGA-gbcB; Tue, 27 Oct 2020 08:31:47 -0700 (PDT)
Received: from NAM10-DM6-obe.outbound.protection.outlook.com (mail-dm6nam10on2075.outbound.protection.outlook.com [40.107.93.75]) (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 F055B3A0E8C; Tue, 27 Oct 2020 08:31:46 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ANkAcFHGvoh6r/nLOjM4iPrGM9pfH+RzoLHqwUrnOLRd3IS+HCfyB16zQH7znK+IK9JnW8S4XxIb8JX+ycbodvrB4iXswYDaEwXkFmxY188FMI6ds3Nmwy0/tNsp8BpcYtf8Ae2Os6C/zQ1ZUjp3HcB4MhtJJbO2KBM+i8uL1zqEh3u/WOqOB52N/+DHtRt+DCCPrD1CJDcctaU2BTRAEUZagmMq3CwbWCiTyjuUP3dXq6cAU5mAmP3AE6qIIv4fjlcITSf5nqrgi3tVSPqcF3lRzgq/S5Jf+4UdSHWg5+/sKAi36ju17cDivCHyP7Ldz4F42rFtkFzQog2NvEF4Mg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8ulyA5qxRZaL8AXJOsluJCX1U4yvzQG/4EI1aRasObc=; b=TOlBdQja/bahEtqcSn516SrMrKwWU5rOyI+TiKRzfUYhLIYlD0DiSg7dQQKLReV3N4P6LnU/rEtUXLx0p3ksxS3oJxuG0b0wOYln0pFrRl2TmdHhke562NkuN8e+HOZm8RFtpwT1u+vvktYKqk8UrwlEzffAgkN7MYkOuisYHpFeuTwfSWiqtqyNvbYIPCQiUNMKLRlaIUTl127LMIfxxuWaaxjUUDLqxJV/fHtJgP6sbUf0R7yQU/w5NeBMeEnWl7nDOb4UGJLT2J1NNy/0FTKbKyJNI1pUOlIf78MaBHI1AnaTdv0W0m7G4hRXY7fCBZ72sJ71fPmmIXKdh4gYPg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 18.7.68.33) smtp.rcpttodomain=mit.edu smtp.mailfrom=alum.mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu; dkim=none (message not signed); arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alum.mit.edu; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8ulyA5qxRZaL8AXJOsluJCX1U4yvzQG/4EI1aRasObc=; b=hvwpwCxgfGkOlcU/i1Fz6yrSF1tbalUeJV2bO6FA+fLXU9bkeAtLiM0EnmTHuMIV/1HACMscDn+xNdiRWh2Emvnp+n9RsPZLqJutD1oLK1BaqounHMsgXNlzq0hv2cE5gpWUpHChlOHMMlBvnImMpvZ+MpdDNyaN99iiflgNQp4=
Received: from MN2PR07CA0019.namprd07.prod.outlook.com (2603:10b6:208:1a0::29) by BN7PR12MB2802.namprd12.prod.outlook.com (2603:10b6:408:25::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.28; Tue, 27 Oct 2020 15:31:44 +0000
Received: from BL2NAM02FT042.eop-nam02.prod.protection.outlook.com (2603:10b6:208:1a0:cafe::4d) by MN2PR07CA0019.outlook.office365.com (2603:10b6:208:1a0::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18 via Frontend Transport; Tue, 27 Oct 2020 15:31:43 +0000
X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 18.7.68.33) smtp.mailfrom=alum.mit.edu; mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=bestguesspass action=none header.from=alum.mit.edu;
Received-SPF: Pass (protection.outlook.com: domain of alum.mit.edu designates 18.7.68.33 as permitted sender) receiver=protection.outlook.com; client-ip=18.7.68.33; helo=outgoing-alum.mit.edu;
Received: from outgoing-alum.mit.edu (18.7.68.33) by BL2NAM02FT042.mail.protection.outlook.com (10.152.76.193) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.20 via Frontend Transport; Tue, 27 Oct 2020 15:31:43 +0000
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id 09RFVfnQ031949 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Tue, 27 Oct 2020 11:31:41 -0400
To: Benjamin Kaduk <kaduk@mit.edu>, =?UTF-8?Q?G=c3=b6ran_Selander?= <goran.selander@ericsson.com>
Cc: Olaf Bergmann <bergmann@tzi.org>, "draft-ietf-ace-dtls-authorize.all@ietf.org" <draft-ietf-ace-dtls-authorize.all@ietf.org>, General Area Review Team <gen-art@ietf.org>
References: <8c2725a3-f89f-7ea1-dda9-681edd463a32@alum.mit.edu> <87y2muo6ix.fsf@wangari> <87v9gomsf4.fsf@wangari> <b0e2088b-ab24-3d35-c98a-161955d3fc7a@alum.mit.edu> <87v9gcg6za.fsf@wangari> <b8a6b44d-ff4d-448c-6ca0-779cb98187c5@alum.mit.edu> <BBE7312D-0581-47A6-BA0D-BC7E5093F67C@ericsson.com> <17035DB6-91C6-4934-9291-CD21EC0B33D4@ericsson.com> <20201026202158.GS39170@kduck.mit.edu>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <9b5d9366-fe35-b722-233d-c1c9f10f5c80@alum.mit.edu>
Date: Tue, 27 Oct 2020 11:31:40 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.4.0
MIME-Version: 1.0
In-Reply-To: <20201026202158.GS39170@kduck.mit.edu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-EOPAttributedMessage: 0
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 4ee743d6-542b-4c83-8868-08d87a8d6890
X-MS-TrafficTypeDiagnostic: BN7PR12MB2802:
X-Microsoft-Antispam-PRVS: <BN7PR12MB2802BDCF5F1F1869A3F24B8EF9160@BN7PR12MB2802.namprd12.prod.outlook.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:10000;
X-MS-Exchange-SenderADCheck: 1
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: KiMyixHm333ajqYqCnpRRND42diazAWEXIa0zAzghvIy/8j6CNq5RIE2dA/WhRIrOzJuoWzNgQXHI722HN5XCG82puCCHybHdeLu3ThVqequZtLzRT2zkjzfKC5iIAv+7rUTUEiksZGiv+/DWt60rM4Zep4vEI2wwFyLcQdR7a5HJuSdESHlvvWypxgyPZ7in3yT3CsuxDCKVMovpnf8n0NGb858xq3d07idSpNiBXPHuZtoyHTpqpq4VdUbbbAS9SpUP2rRSoJ+1zhP+tUb/RZZmsnNnoOu8zh335s89tVw57Uuorv3EFEcc3r7pA80dGzLJnQU2AehK+TlYKHyegHEL4CSdJ1eedBEIIMElwPWM/J5Ki5Xr5TPxOD7v21Ixv7xgl/69ReSIRrkr9HwJENcrPOmjtlqKGeFmZ6jo1KESlezYE8PBoTMLp3ZX+Sem+aET8KCpQgu+CVtNbXZ/9k2GUMlFtW6gFaQ1B6DjWF8CjA1cfYcCP7pTpoFvDXd
X-Forefront-Antispam-Report: CIP:18.7.68.33; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:outgoing-alum.mit.edu; PTR:outgoing-alum.mit.edu; CAT:NONE; SFS:(39860400002)(376002)(346002)(136003)(396003)(46966005)(83380400001)(75432002)(2616005)(478600001)(4326008)(336012)(966005)(186003)(956004)(356005)(26005)(31696002)(53546011)(70206006)(7596003)(5660300002)(82310400003)(86362001)(70586007)(82740400003)(66574015)(8936002)(786003)(31686004)(316002)(36906005)(110136005)(8676002)(54906003)(2906002)(47076004)(43740500002); DIR:OUT; SFP:1101;
X-OriginatorOrg: alum.mit.edu
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Oct 2020 15:31:43.5205 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4ee743d6-542b-4c83-8868-08d87a8d6890
X-MS-Exchange-CrossTenant-Id: 3326b102-c043-408b-a990-b89e477d582f
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3326b102-c043-408b-a990-b89e477d582f; Ip=[18.7.68.33]; Helo=[outgoing-alum.mit.edu]
X-MS-Exchange-CrossTenant-AuthSource: BL2NAM02FT042.eop-nam02.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR12MB2802
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/N1V6VAFmdBD1PQERKoEQuAg5pdM>
Subject: Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ace-dtls-authorize-12
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Oct 2020 15:31:50 -0000

On 10/26/20 4:21 PM, Benjamin Kaduk wrote:
> Hi Göran, Paul, Olaf,
> 
> Sorry for the slow reply.
> 
> I agree with Göran's original assessment that the language referring to
> 7049bis does provide enough information to have a deterministic encoding
> for the HKDF inputs.
> 
> As such, I don't think pull #28 is needed, and would prefer that it was
> reverted (the specific wording doesn't do a great job indicating that the
> whole list of requirements is "normative", to the extent that any example
> can be normative).

Ben, having raised the point, and knowing that you understood it, I am 
satisfied with whatever changes you do or don't decide to make to 
address it.

	Thanks,
	Paul

> Thanks,
> 
> Ben
> 
> On Thu, Oct 15, 2020 at 05:24:37PM +0000, Göran Selander wrote:
>> Hi Paul,
>>
>> Returning to the final remaining comment in your review. I made a pull request to clarify the change I proposed at the end of the mail below (to which I didn't find a response but I may have missed it):
>>
>> https://github.com/ace-wg/ace-dtls-profile/pull/28
>>
>> Does this address your concern?
>>
>> Thanks,
>> Göran
>>
>>
>> On 2020-09-25, 17:07, "Göran Selander" <goran.selander@ericsson.com> wrote:
>>
>>      Hi Paul,
>>
>>      On 2020-09-17, 17:26, "Paul Kyzivat" <pkyzivat@alum.mit.edu> wrote:
>>
>>          Hi Olaf,
>>
>>          On 9/17/20 4:09 AM, Olaf Bergmann wrote:
>>          > Hi Paul,
>>          >
>>          > Responding to you remaining comments please see inline.
>>          >
>>          > Paul Kyzivat <pkyzivat@alum.mit.edu> writes:
>>          >
>>          >>>>> * Also in section 3.3:
>>          >>>>>
>>          >>>>>      All CBOR data types are encoded in CBOR using preferred serialization
>>          >>>>>      and deterministic encoding as specified in Section 4 of
>>          >>>>>      [I-D.ietf-cbor-7049bis].  This implies in particular that the "type"
>>          >>>>>      and "L" components use the minimum length encoding.  The content of
>>          >>>>>      the "access_token" field is treated as opaque data for the purpose of
>>          >>>>>      key derivation.
>>          >>>>>
>>          >>>>> IIUC the type of serialization and encoding is a requirement. Will
>>          >>>>> need some rewording to make it so.
>>          >>>>
>>          >>>> I take it that you and Ben have agreed that the example description does
>>          >>>> not necessarily need normative language as the description of this key
>>          >>>> derivation procedure is meant as an example how the authorization server
>>          >>>> and the resource server can securely agree on a shared secret to be used
>>          >>>> between the client and the resource server.
>>          >>
>>          >> This still confuses me. IIUC preferred serialization and deterministic
>>          >> encoding are *optional* in CBOR. The text hear seems to require it,
>>          >> but doesn't use normative language to do so.
>>          >>
>>          >> If these are required for things to work then you make a normative
>>          >> statement about it. E.g., "The "type" and "L" components MUST use the
>>          >> minimum length encoding."
>>          >>
>>          >> Or do you intend that some other (non-minimum-length) MAY be used? (In
>>          >> which case both sides would need a side agreement on what encoding is
>>          >> used.)
>>          >
>>          > The text here just gives an example how key derivation may be used by
>>          > the authorization server and the resource server to agree on a shared
>>          > secret (that is used to encrypt the traffic between the resource server
>>          > and the to-be-authorized client).
>>          >
>>          > To that regard, the text is not really normative. The only normative
>>          > language we need here would be to avoid security issues. Commenting on
>>          > the data representation here is to be understood as a suggestion to use,
>>          > e.g., preferred CBOR serialization according to 7049bis.
>>          >
>>          > [...]
>>
>>          Sorry to be so dense, but I'm still not getting it.
>>
>>          I take your point that this is only an example of a way to agree on a
>>          shared secret. But at the end of the day they indeed must somehow agree
>>          on a shared secret. *If* they use this technique then it will only work
>>          if they also agree on a consistent way to do the serialization and
>>          encoding that is otherwise not standardized. So they need a side
>>          agreement, which is not a good situation for a standardized protocol.
>>
>>          At the very least it seems like you should highlight that some sort of
>>          out of band communication is required between the authorization and
>>          resource servers to establish the shared secret or the algorithm to be
>>          used for deriving the shared secret.
>>
>>      [GS]
>>      I'm not sure I understand the issue correctly.
>>
>>      Section 4.1 of ietf-cbor-7049bis states:
>>      'The preferred serialization always uses the shortest form of representing the argument'
>>
>>      This seems to me to be in coherence with:
>>      "All CBOR data types are encoded in CBOR using preferred serialization and deterministic encoding"
>>      and
>>      'This implies in particular that the "type" and "L" components use the minimum length encoding. '
>>
>>      If I understand right you would like to replace the latter sentence with:
>>      'The "type" and "L" components MUST use the minimum length encoding.'
>>
>>      But there are multiple statements in this example which could be replaced with normative language, e.g.,:
>>
>>      'In this example, HKDF consists of the composition of the HKDF-Extract and HKDF-Expand steps [RFC5869].'
>>
>>      'The symmetric key is derived from the key identifier, the key derivation key and other data:'
>>
>>      'type is set to the constant text string "ACE-CoAP-DTLS-key-derivation" '
>>
>>
>>      Would you be happy with only the specific normative statement you proposed (which BTW is fine to me) or would you like to see all statements like this to be replaced with normative text (or can we make a normative formulation at the beginning of the example indicating that "compliance to this example REQUIRES the following:")?
>>
>>      Thanks,
>>      Göran
>>
>>
>>
>>