Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-crypto-types-18

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> Fri, 16 April 2021 11:50 UTC

Return-Path: <J.Schoenwaelder@jacobs-university.de>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A7023A22A9; Fri, 16 Apr 2021 04:50:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=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=jacobsuniversity.onmicrosoft.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 jPOkD5poujDR; Fri, 16 Apr 2021 04:50:10 -0700 (PDT)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80043.outbound.protection.outlook.com [40.107.8.43]) (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 111223A22A5; Fri, 16 Apr 2021 04:50:09 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ACsokFzmhfBxYgaE2KCeLm2pytlBqfy/mSc0WsOt+X4L6t8jqnSw9Gq3GO/dX94WohR+XtRT6ZRDwz/xzh+tq4f34oLSpUwPJnG/HjZmIsnXM6lOvDPu/+p6yqErDdMEkrnK9Ha7xhDIhs0f/GppANgMOqK6rrq9AnNmWkQmkl3qaBe/OM+V/N7wrUWXW3xCCCqnbobq/cGcW1lMzC/PAl5mN1Hlt9gjSoZxB7T5bmBm7AtPl2wVTmz/qq5e+5l3qTEjYq7O98G/9wul6/8pQw0DdKZ70JcSFt3NjUyWcAWFsx5aHp/QNG7qkDdyrWe0tGj42YiFkuZHTbi5CW0fHg==
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=Pa9O0ByLX1Y1vGIdOGjKQnuqSplt7mbl7OkDQQSxBz0=; b=AUKFFu/IJQT7qDsel+LFwMm7C43OenfI1SXeC79yX8pZgTvKINBS7wRF1bU2UdBsr6jkpZW254/sulmKixZ6faFZGduoZC1AP91qNXPRALVRK312nrU1dZc9llLarkOD6l91TJDZHGHobKn1zOMPLVPfjq5+RfEa0R7e72biFbeE02ozbsfCnDq20EBp8PkPXn2zkih4dTTeZCh9pg7cxY8pW4wlgjdrFCNT2T6sw+WKkY5pmXaVFmCZDmODiwx0ckd0LpC6rrfh9setaG1bGyIj4i7+b6HLrnZYfm9VoL0oGtU8PhbNIqh0vYMp/GROAd6loRpjaz0pe7Y1IVDv5w==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=jacobs-university.de; dmarc=pass action=none header.from=jacobs-university.de; dkim=pass header.d=jacobs-university.de; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jacobsuniversity.onmicrosoft.com; s=selector2-jacobsuniversity-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Pa9O0ByLX1Y1vGIdOGjKQnuqSplt7mbl7OkDQQSxBz0=; b=a4v8AK0lF9i3VfyT4Ursf6iAiZYbCCgllmvCgWGOG4rf+PkY75YH7z3dTPPe2XrY6PolGBRZ0easGiWHXSqYpYxvFYdU6xbwpnjM2UNM9uJTVwBC3AxlqLApKVLhusGuHdL699bCi+Qjuu0e56n1jGIvst6dyi1q0kU3gqW63pk=
Authentication-Results: watsen.net; dkim=none (message not signed) header.d=none;watsen.net; dmarc=none action=none header.from=jacobs-university.de;
Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23) by AM4P190MB0065.EURP190.PROD.OUTLOOK.COM (2603:10a6:200:62::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.19; Fri, 16 Apr 2021 11:50:07 +0000
Received: from AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6]) by AM0P190MB0641.EURP190.PROD.OUTLOOK.COM ([fe80::e8a2:9886:8dfa:41c6%4]) with mapi id 15.20.4042.019; Fri, 16 Apr 2021 11:50:07 +0000
Date: Fri, 16 Apr 2021 13:50:04 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: Kent Watsen <kent+ietf@watsen.net>
Cc: "netconf@ietf.org" <netconf@ietf.org>, YANG Doctors <yang-doctors@ietf.org>
Message-ID: <20210416115004.fqhitq6jofc6vjih@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: Kent Watsen <kent+ietf@watsen.net>, "netconf@ietf.org" <netconf@ietf.org>, YANG Doctors <yang-doctors@ietf.org>
References: <161045360252.14510.16755799701987783827@ietfa.amsl.com> <010001778e67638b-53d8c33f-82f6-4bda-881a-3cf881c06c95-000000@email.amazonses.com>
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <010001778e67638b-53d8c33f-82f6-4bda-881a-3cf881c06c95-000000@email.amazonses.com>
X-Originating-IP: [212.201.44.244]
X-ClientProxiedBy: PR0P264CA0188.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1c::32) To AM0P190MB0641.EURP190.PROD.OUTLOOK.COM (2603:10a6:208:194::23)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
Received: from localhost (212.201.44.244) by PR0P264CA0188.FRAP264.PROD.OUTLOOK.COM (2603:10a6:100:1c::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4042.16 via Frontend Transport; Fri, 16 Apr 2021 11:50:07 +0000
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 32b91ad8-525c-44d1-bdf4-08d900cdc7d9
X-MS-TrafficTypeDiagnostic: AM4P190MB0065:
X-MS-Exchange-Transport-Forked: True
X-Microsoft-Antispam-PRVS: <AM4P190MB00657F48D3E25ED6FCB7D2A7DE4C9@AM4P190MB0065.EURP190.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: KTuBBLrsQbxL8j3J0+SPkbQCMENl6FzBS1KWJss+TBVf2HNH+JPwX1UYqfepJFLHYQ36cYvEZBwxqyfkxRsjG/WgJeD6f9u7/CkOj/SNLbf2bCR0+yehpY7E106NyrXDlQmcKCiQGcPwE1VNnvY1ETxuJmV6RotGN1HZ39mNpQ8WNZZelgbqAQf/9XT4wVuv9oW2fFt8N4o5wL7zYAtfnpCcUpDGW9z2ZAkQGFF+rytJU3K9VD1EkEjcSGd4GEz/8KE8Xf6c80qQMfOcVguMcg43kXoXTR4oZXjKyJhsemoLO9QCjQjEFAjWxZMf+E9V9P+8YnjQfc6iLrYUZKg3kdg+rw9i7UVIQ9hT4Hhr4Tk9k334kyCP+QrVqFu9S9tHfarjeS/Ug7ftTsQdnR4mMe3xzAvbaIMs8H5ESq4B3BYekd/leTErfZNA7d5R61/HbkFMyZPjWrPVs+ILfbC+gOKaLYyS+YsjAOA8KHRb06D6FZGrrD6thAHKiZ2Lp2riyxqFRbV21N6szTF8kBvOxCT/hOzVXDXTeXSAmzcfDYamfb11JWeT10z3c6GZS+TnQKsV4pb/4c6/KGfgEBt3A2SaMBAMZwuK6Gg+4vJd0vsSqUWPPlClc1rT3CJKu03WJlSSiSvoEfRtvkaPs+/UMLkJ2RdxLAQL5Ed2Cxc1IqEKT4mJscqGVFF2o5c5WmJrzLyaqzuNSZc3ZZ0aJT048C+6nhJhJtjLw7J2cwa+mfjxM6CZMk/XbBcPdB6DZQFX
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM0P190MB0641.EURP190.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(376002)(39850400004)(346002)(136003)(366004)(396003)(54906003)(6666004)(786003)(316002)(66946007)(66556008)(86362001)(5660300002)(8676002)(8936002)(38100700002)(38350700002)(1076003)(478600001)(66476007)(52116002)(3450700001)(4326008)(956004)(16526019)(186003)(6496006)(6486002)(2906002)(83380400001)(26005); DIR:OUT; SFP:1101;
X-MS-Exchange-AntiSpam-MessageData: =?utf-8?B?NjhBYWloc0wySDBnWUdyNloxaHNLcFFlbDcvODBUZkRyS0VKRXZkd2JrYm9m?= =?utf-8?B?TXlVbU5EVjRVcFdVejVpWnhPeDVCYkhIMXQyWmdQc2VGUkVveDc0OGgxT2Q4?= =?utf-8?B?VUZZb0hSRStuNEFqNSs2NDN5Qk1UK2FNUkdiWUU0VkR0OWhXL3V1MlNpREpH?= =?utf-8?B?cmZ0UGJWbC9BMEsxNlZBU1J0R3orWHpocEVoY2p6cC9QZ05EbWwrNHVYYlJl?= =?utf-8?B?c21ta1ZEeUY1d0QrM0MxNVNVTHBvUXQ2cExpZmR2eVVKRjhBY3Y1MGhCUTNI?= =?utf-8?B?c2prblRzTXBLZzhDQVcreVV5Z0RKSmU4N0VEekpNTDkyRTFjQmJyQTM3OGsw?= =?utf-8?B?RVRWT3d1Qmg2cUlEbnZoU0xmQTY4Zk1OR0pvSVF5Slluc1hoVHRDQkxiVkZH?= =?utf-8?B?WStHTTBBMktqQXJaaCt3VG5qcVNZbHF5R2R1ODJJOEt2SFBIUGtPWnZiRnkx?= =?utf-8?B?NG9vMXduVkhCQkpLTEY3ekhmYjFQSk9rbTJpRXpaSDFCdnRYOVQyWkNzaEJW?= =?utf-8?B?L1BTSmJqc1ZxWERLTWQwN2hsb3kwckhrdWk2SHM5Q1h5UU5vT3JnQ1lzVkZQ?= =?utf-8?B?ZGxFY0hONi8zcjgvMnNQYk5nZXlzaktOaVZhN1RqYjg4L0Radnh4L1lUdVNS?= =?utf-8?B?WnhEVUdOc3NZeHB6VTVuSXZWRElGSDRqR2VQUTgwZ2dleXRiQm1ZM2JTeUtk?= =?utf-8?B?MW1wMjFNY1pzdjk2cXYwSVE2SVRHYVpvMEI1Y3NIZEpRQmwyelU0TDBFK1ZE?= =?utf-8?B?UzRSTGd6T2tnWXZVYzBJTFBqNDBiZm1POGNPSkxqM0FFOThZTVVpdTc5YmRv?= =?utf-8?B?THdZa0lYL1RabzVMWmovNHppc2xMM2lMNmlHTEExNkhRTXVXTzkrdkxEYmw5?= =?utf-8?B?aDZKN2lKMm1OVGp0dWhlWUxIblhPOTJLYnpUOFJkeEdKNEdmcHVGRGZ0OFpn?= =?utf-8?B?WmtBNVhOUFV0SzVyOHk0RkRiKzdqRUxSUVJ3L3JKaDhXak83OHFycUl2WEwv?= =?utf-8?B?SHJzd3VyUEFiYUJoUWJOLzgvLyt4T2xsR0liWnozWTBEeTZueXJtb0tRZDRZ?= =?utf-8?B?UW5FWmRSMXZ4Tis1ekNmYVM4L3lCZVZoV1hDUkg4ODQyYmZtZi9oeHMxVFl2?= =?utf-8?B?UXlualY2TmhxS1FJbHg2NnFBREIvbUJZVWNFVWVnTkpZdXNXN2JOMG14UnNU?= =?utf-8?B?Q2k3STErK3g4UlQrbjluTHNQZlB2aTRzbmlSUm5PKzJ3Rmc5c1hUUnF4YjlQ?= =?utf-8?B?UEZLYVphWHZSVDJ2eFVINVpaMjdUb091WXd4bEhqRzd0VmliakVGTUR5Nkhj?= =?utf-8?B?aEJ5MzdXckNwanpaa2lNMHRrUTc2V1NiTVl4ZUN6T1orWFZUTStSVmlwSzVk?= =?utf-8?B?TlFtUUNkL0pTcU40Q1Z1V0hKK1IrakhiRXU5WGRTYk1YaEsrWWNsTEdXUUE5?= =?utf-8?B?YkFoakJLWmdrdnVnanViZGNVUi9iOUVPMEIwQ0pZbUgzNHlsVDlJT1NDRlhR?= =?utf-8?B?QVh1dlNZbkttOHRxWm9NK01sRmNuTjRzS1hTdmlvenJiSnFZeUgvSDUrUFVV?= =?utf-8?B?ajA5cVYrU0NyNnA4NGR4RzloZlp1RUl0dnNFWjJGaUdTb1Q4MlEycjBOTlJq?= =?utf-8?B?eHNOUXpIejlLRldHc2ZCQ1VybHJDbmoxOUlIdWhXOTdWMkc3d3ZleEJVL1Az?= =?utf-8?B?ckV1eDNubS9HWHgvemZSRjZQY0xQNmhtbG5pUGNmeGZGcjJFY01hWWI2aU1I?= =?utf-8?Q?Pj62e6MLJh/RxHb8HAVAji9ROq2VbIntYbNJGmw?=
X-OriginatorOrg: jacobs-university.de
X-MS-Exchange-CrossTenant-Network-Message-Id: 32b91ad8-525c-44d1-bdf4-08d900cdc7d9
X-MS-Exchange-CrossTenant-AuthSource: AM0P190MB0641.EURP190.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Apr 2021 11:50:07.2191 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: f78e973e-5c0b-4ab8-bbd7-9887c95a8ebd
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: Aou9bSI0lG6bX2LD0KRyx/lkbp0HcBJhC9zkq3349rQoHaprdSJXtg0ZAAEBsYJ2GbeS0FBUwVda1s5u1L+H0fr6SGsME9HsQXOKI/dBIBQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4P190MB0065
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/wcotP9Y0oNLoDeWt7uWMGWwf6Vk>
Subject: Re: [netconf] Yangdoctors last call review of draft-ietf-netconf-crypto-types-18
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 16 Apr 2021 11:50:15 -0000

On Thu, Feb 11, 2021 at 12:04:36AM +0000, Kent Watsen wrote:
> Thank you for your review, Juergen!
> 
> Below are responses to your comments.
> 
> PS: this response took longer because I had to triage with Security Experts on a couple points.
> 

It always takes longer. ;-) I cut things resolved.
 
  > - Does it make sense to have a new notation like
> > 
> >      |  The diagram above uses syntax that is similar to but not
> >      |  defined in [RFC8340].
> > 
> >  or shall this simply become regular text?
> 
> I find using tree-diagram like notation for features, identities, and typedefs helpful, especially in showing the “if-feature” constraints and hierarchical relationships between items.  I recommend adding these enhancements to RFC 8340.  It would be helpful if someone could whip up an I-D so these documents could reference the I-D instead of having the "The diagram above uses syntax that is similar to but not defined in [RFC8340]” language.
> 
> That said, I also used a "rfc8340-like" diagram to list all the groupings in a module.  It seems like the consistent thing to do, but I can’t imagine the RFC 8340 being updated to support that output, so I replaced that diagram, with a normal "xml2rfc" list, in the entire suite of drafts.

I am sorry, I should have been clearer. My comment did not concern the
diagrams but the mere fact that you have

      |  The diagram above uses syntax that is similar to but not
      |  defined in [RFC8340].

instead of simply

   The diagram above uses syntax that is similar to but not
   defined in [RFC8340].

and this is really an editorial nit if at all. The diagram itself I
like, it would be nice to have them in RFC 8340bis.

> >  What is 'encoded in the format specified by the "format" identity' I
> >  assume this refers to the key value that is encrypted and stored in
> >  encrypted-value, no?
> 
> Not only was the solution unclear, but it was rather upside-down in terms of how to encode encrypted values.  Please see the “diffs” to get a sense for how the solution was changed.

I happily trust Russ here. ;-) 

> > - I wonder why this is a SHOULD and not a MUST:
> > 
> >           "Identifies the symmetric key's format.  Implementations
> >            SHOULD ensure that the incoming symmetric key value is
> >            encoded in the specified format.";
> > 
> >  This statement shows up several times when the key-format identities
> >  are used. I wonder what this means to an implementer. If I receive a
> >  key format (say one-symmetric-key-format) and a corresponding blob
> >  of data, do I have to decode this to see whether the format works
> >  out? If later the key-format is changed to something else (lets say
> >  octet-string-key-format), do I reject such a change or is it OK as
> >  long as the binary data I have would be a valid value given the new
> >  format? Perhaps this is implementation specific? Well, since we deal
> >  with keys, ...
> 
> It currently a "SHOULD” because some implementations may assume that clients always configure perfect values, and so it becomes squishy as to if they MUST.   If a server fails to validate the base64 contents (which are outside YANG validation) as they’re being applied, then the server may run into nasty exceptions when needing to use the value at runtime.  A nice system will decode the base64 values and verify that they contain valid values during the commit process.
> 
> Make sense?  - leave as SHOULD okay?

Thanks for the explanation. I am not religious about SHOULD vs MUST
here.

I have browsed through the diffs and they look good. I did not do
another full review again.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>