Re: [netconf] crypto-types fallback strategy

Kent Watsen <kent+ietf@watsen.net> Mon, 16 September 2019 16:49 UTC

Return-Path: <0100016d3afa694e-ce58ee3a-792f-4c0e-89bb-83d0128a5194-000000@amazonses.watsen.net>
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 F300B12011D for <netconf@ietfa.amsl.com>; Mon, 16 Sep 2019 09:49:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.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 5SpbD0JLnyCO for <netconf@ietfa.amsl.com>; Mon, 16 Sep 2019 09:49:14 -0700 (PDT)
Received: from a8-83.smtp-out.amazonses.com (a8-83.smtp-out.amazonses.com [54.240.8.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17639120046 for <netconf@ietf.org>; Mon, 16 Sep 2019 09:49:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568652552; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=XzAse/tUa/roVPVKHJYo0WfCE5lVYWGykaC0ARttHF0=; b=gKFBgwkG86/jRJWof0Q3Raon+b4YSWNH1Iop0EHZ8wb5HHePHooopZlw1mKNsZLG 8ttr54YNDuERJu+DcKrXaQX5rEqFZfXIuQJBRPAl9DceC1gfzhkY6eV9z7ckOJeg8ky fm/QQ3nobTDRNTHZ+4RimWCIUVuuLZfB4IcrUV9I=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100016d3afa694e-ce58ee3a-792f-4c0e-89bb-83d0128a5194-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_35DE00FD-3D4A-4CC4-AD2A-10AE1AC69E85"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Mon, 16 Sep 2019 16:49:12 +0000
In-Reply-To: <MN2PR11MB4366AE6CF9E03B15EBEA3A39B5B30@MN2PR11MB4366.namprd11.prod.outlook.com>
Cc: "netconf@ietf.org" <netconf@ietf.org>, Russ Housley <housley@vigilsec.com>, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, Sean Turner <sean@sn3rd.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <MN2PR11MB4366AE6CF9E03B15EBEA3A39B5B30@MN2PR11MB4366.namprd11.prod.outlook.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.09.16-54.240.8.83
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/cV15V-wafUN5dIDl4ueAf__CU_M>
Subject: Re: [netconf] crypto-types fallback strategy
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: Mon, 16 Sep 2019 16:49:16 -0000

Hi Rob,

 
> I think that using a numerical OID to identify crypto algorithms doesn’t seem like a great choice.  Seeing a config file say something like “rsaEncryption” instead of some OID string seems to be much more human friendly.  And as Martin says, using the OID name has no guarantees of being unique.

On only this very last point, I'm unsure about that.

 
> I wonder if changing from identifiers to enums was a mistake.  If we were to use YANG identifiers then we wouldn’t need to define them all now, and they wouldn’t all need to be defined in the same YANG module.  In fact, if we were to go back to using identifiers then perhaps NETCONF should restrict itself to only defining the identifiers that we actually need now, and leave the rest to the security folks to figure out, probably as separate modules defining the extra identifiers that they need, or as a bis version of the crypto-types draft if required. 

Seems like a reasonable approach, but I don't know how that differs, in the end, from the uber definition some folks have voiced a concern for.  Maybe we need to understand better what that concern is better.


 
> I’m not sure that I understand why we would always want to always use ASN.1 to describe the keys for all algorithms.  Could we just leave the algorithm identities to define what format they use?   If we were to go back to using identities when we could have the choice of using multiple inheritance and then have a separate set of identities to allow the key formats to be defined.  Note, I have no objection to ASN.1 being used for some/most the keys if that is the right encoding.

Perhaps we can do both, say that the field is parsed according to its "algorithm" value, but for now, all algorithm identifiers happen to point to ASN.1 structures.



> Hopefully the comments are useful, apologies if they are not!

All good.  Keep them coming.


Kent