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

Göran Selander <goran.selander@ericsson.com> Thu, 15 October 2020 17:24 UTC

Return-Path: <goran.selander@ericsson.com>
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 CB2053A07F0; Thu, 15 Oct 2020 10:24:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.3
X-Spam-Level:
X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, 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=ericsson.com
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 PTx-m5X7Sx2s; Thu, 15 Oct 2020 10:24:43 -0700 (PDT)
Received: from EUR05-VI1-obe.outbound.protection.outlook.com (mail-vi1eur05on2068.outbound.protection.outlook.com [40.107.21.68]) (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 BBBE33A0AE0; Thu, 15 Oct 2020 10:24:42 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h40lfwARp0+vzamEZsbrS+3x/rk+WlmEE/1vQOAN8GaQsDJrzDRtoG6JqsjU1j3vOlQ8D7+VNT/UucfAlcNoTnAmO2gi732jjqrhO2MPAIWXzLbO4zIRXA8ELrgsStV/S3wvVptc92ad+r14XChZE23/959BScEBSTpmO5dkSFKwDzkpYxzNXT12odM3IlHSE3JdHVNN7ngSlKypSKHdrsZppGgJ5Tzt4VXBg7IFH6gw3SdM9AANZnfkmwEAjBZrIDy1CLnoUK+cRL+DgpMSHW+3a4YpZWMOP4N3d2IYjv7XjoHKzrMwlNCcc3TZ396Aci0LOzpwmJJ9qU8T3Grewg==
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=tZJY+SDRdrH13Lez7SbS/XcCHPwsKlVux4c+woCYpp0=; b=aMd7nTF96Le8cOQB3uOL+kAlRZWyHMX0pT8I/vTcBGHe/jymo+8pgXQwY6iPIaxFAb68T3RsyW2LppLzzoCKSuBdlyL560kVBAc1H1GGpOP6eba99L4/MlrGhwf6cnzmXDFdZ8+EkdsnO3D3LpCTMrX8hZjuK5n2ACm1pEdnVF/xxaDs5zfEToWocmTCsKV8IRwoyDvBvXf1lY85W2a3yJoQhMmgGzOmfav7gsV2HuddcGMDwpUE8M1yuGtYKLJXzURh/3AE4+lqIaPcIxRdDrO8x+q3XdMss2t1uToGA99jO2VUn1XkoNaOR6L1t9tumencyW1yvZ3AmorjtLzoMg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tZJY+SDRdrH13Lez7SbS/XcCHPwsKlVux4c+woCYpp0=; b=GeelDlkNi8+jUlRrecTBqtP5VD3tzLHfzalBcmwpO37QrnYlc5NG6RbRA4rDeNb6eDYJMISJkH6syLnIAApXGIpqatPQuXfY/L4kmSFvNzd/ivMLQOF0FRBf1Y/iIOVj7z2RmIzD0wTLzlGfVNY+jJjCdROcEE4/y1vOwSzC1Ok=
Received: from HE1PR0702MB3674.eurprd07.prod.outlook.com (2603:10a6:7:82::14) by HE1PR0701MB2633.eurprd07.prod.outlook.com (2603:10a6:3:93::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.9; Thu, 15 Oct 2020 17:24:37 +0000
Received: from HE1PR0702MB3674.eurprd07.prod.outlook.com ([fe80::f5ce:b24:f47e:799c]) by HE1PR0702MB3674.eurprd07.prod.outlook.com ([fe80::f5ce:b24:f47e:799c%4]) with mapi id 15.20.3477.020; Thu, 15 Oct 2020 17:24:37 +0000
From: =?utf-8?B?R8O2cmFuIFNlbGFuZGVy?= <goran.selander@ericsson.com>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>, Olaf Bergmann <bergmann@tzi.org>
CC: "draft-ietf-ace-dtls-authorize.all@ietf.org" <draft-ietf-ace-dtls-authorize.all@ietf.org>, General Area Review Team <gen-art@ietf.org>
Thread-Topic: Gen-ART Last Call review of draft-ietf-ace-dtls-authorize-12
Thread-Index: AQHWXgqKUNF5KYj7Y0KijsQy9TxCz6koEzbrgDbTRl2ABVdjgIAImc7MgAB56YCADK8bAIAflN2A
Date: Thu, 15 Oct 2020 17:24:37 +0000
Message-ID: <17035DB6-91C6-4934-9291-CD21EC0B33D4@ericsson.com>
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>
In-Reply-To: <BBE7312D-0581-47A6-BA0D-BC7E5093F67C@ericsson.com>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.42.20101102
authentication-results: alum.mit.edu; dkim=none (message not signed) header.d=none;alum.mit.edu; dmarc=none action=none header.from=ericsson.com;
x-originating-ip: [83.251.145.232]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: ec962dd5-f4ef-4933-15e4-08d8712f3139
x-ms-traffictypediagnostic: HE1PR0701MB2633:
x-microsoft-antispam-prvs: <HE1PR0701MB26332B36CD8760A930269FF1F4020@HE1PR0701MB2633.eurprd07.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: GVsMg9/neNJ9RIoMJt789jOozP5z9cRHqhidxuI0hvcTSpDFhLDWSZJqgXNxdBFBuzVTmclbmeBs9RiaTOPbzepjS2YL8Fv7c+3vS3PUDSJ99M5oHW8fmp20Fjww7UVo07XKcs8BerJhG6VrOY+qspCj2UUcTW38rB9kVcGOL0lHrIYarbhIh+I3W/X4nbnIgaUTpf963thJfLHgMut4UxUJ1hUc4XHI3nCwzBsV1XH96tpJkaQHcJirAQi9epWSY//otE/qWE3UG46EITkQx84gb2ocaCl/d0obNRcg2iTThL69R8SDXwZM/Khp8sYsMCkKUDyRyuadkkd8FQNr8REhPuw6yzpyytWzTcPXXGLTBuic97dHhpoQ3vuJjdZ/5XTW2HBcDJix2RJ/kg99/A==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3674.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(4636009)(39860400002)(136003)(376002)(346002)(366004)(396003)(186003)(8936002)(53546011)(6486002)(6506007)(71200400001)(6512007)(83380400001)(36756003)(66946007)(26005)(966005)(66446008)(85182001)(8676002)(66556008)(64756008)(76116006)(66476007)(33656002)(478600001)(110136005)(5660300002)(54906003)(85202003)(316002)(86362001)(4326008)(2616005)(2906002)(66574015); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: X+YIJ1WP/+3RjD45qKPgf3ZGSfLQQGfyR2Vvf2K9Rz460a6dTbo0uQUAL/dVpmYeBOJdBZLSBFTWckFN/2CTjgbBRQtNYdRdqBIpt6REUQkLtE24smavh9Sd4EmuDVnFDONe3IhnOIVKu8Z3cOdxcDX5WALiWqmISKbEGK6T1gZZXSvD5qM8Y52j6gEBadtj2UVzhAKXt9jL+BhbokWPPFxO/5CMhI7xNpKfzgtuk8p17qoxE/ZGlOlicU5pcdLN5z4CKEkyexB2gSkkePu9uktG4XQ92CkoWk5KtJ97gGj0yzrp7yA/mzV9BeTHQ58FsWozR1IJFCqAqtFtB4UVmbwk/cDnJ/S8hiTicgWwvRq/OfLu4QzClUME8+I4NPtC5IJ2vK2AADewbALMmrAXy5qO41m1R+Uy2MrQLKvFjyJqo5UbGlriwY5r8CRS6PfEqHmvdwjCJYZMb274O1Fr3HDfXzGHli1gRu/clVT8RKSd1dSrl5wlMjtUmfCkBZTTYw7XVeNAy6RnhHVWXftg3dvFfDp8o1xOYh3FHwxnmZn6CrcAnOsEiwSL+slIZ/23FOlgm6YojnoAe64AYQ3dC1o1qvfYKP+H8OWzh/7GIsRL9CYx98Yp6U0W/Z3ZzRJbxxNLBE/9BkNeBP7AvKEJNw==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <E31631E407C8EC4AB54E768FD61ADFA5@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3674.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: ec962dd5-f4ef-4933-15e4-08d8712f3139
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2020 17:24:37.5311 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: wRM62LAwLdYYcgx/4vLDwvbQDatAUmWUzaspycqiCqz+DVfEE9VSFZ6G75Daww5Jg1/Gn8azIdSOHw6nuGBtjuu8cXxvXITr6ZvKsZyfL8M=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2633
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/ljzzSCGYyrmpYmDHZMaH1YfB0OQ>
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: Thu, 15 Oct 2020 17:24:45 -0000

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