Re: [netconf] crypto-types fallback strategy

Kent Watsen <kent+ietf@watsen.net> Wed, 18 September 2019 17:03 UTC

Return-Path: <0100016d4553e645-9c5796b8-15da-4a51-b820-5ecef6575eff-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 60DEF120AF9 for <netconf@ietfa.amsl.com>; Wed, 18 Sep 2019 10:03:12 -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 0xliqs0VYMX4 for <netconf@ietfa.amsl.com>; Wed, 18 Sep 2019 10:03:11 -0700 (PDT)
Received: from a8-64.smtp-out.amazonses.com (a8-64.smtp-out.amazonses.com [54.240.8.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E48C8120AF2 for <netconf@ietf.org>; Wed, 18 Sep 2019 10:03:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568826189; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Message-Id:References:To:Feedback-ID; bh=y091mJWRTDKUloELQQReqp+WS/uWuvRDfZe6zeXleWc=; b=leZGz/fd8ucL2ab/j3LSP/95YqV7fyRnj4ctgn62Ko00rINufWyERlyTCnaXuL5R 7jo0mumA0+LmU/G4kRu+7uzvsAuzD/Z5St5xNdkKVMSGfY28WKmP9e0jnI/5XVOKq8v I0Agz0RtYmLBMx96T6mKw+GQC4Za0dWtBhn+LSTk=
Content-Type: multipart/alternative; boundary="Apple-Mail=_90920BF8-66F4-49CE-A2B2-3C19246CC770"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Kent Watsen <kent+ietf@watsen.net>
In-Reply-To: <MN2PR11MB436617082A8308A7A8928DDFB58E0@MN2PR11MB4366.namprd11.prod.outlook.com>
Date: Wed, 18 Sep 2019 17:03:09 +0000
Cc: "Salz, Rich" <rsalz@akamai.com>, "netconf@ietf.org" <netconf@ietf.org>, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>
Message-ID: <0100016d4553e645-9c5796b8-15da-4a51-b820-5ecef6575eff-000000@email.amazonses.com>
References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <MN2PR11MB4366AE6CF9E03B15EBEA3A39B5B30@MN2PR11MB4366.namprd11.prod.outlook.com> <0100016d3afa694e-ce58ee3a-792f-4c0e-89bb-83d0128a5194-000000@email.amazonses.com> <MN2PR11MB4366F63419F6BD4EF106766FB58F0@MN2PR11MB4366.namprd11.prod.outlook.com> <8053FDA0-77EA-488F-B5A7-F203359105E0@akamai.com> <MN2PR11MB43669B3A47A39FD93B47292FB58F0@MN2PR11MB4366.namprd11.prod.outlook.com> <6924CAD5-F740-4512-8689-E0307AF0BD88@akamai.com> <MN2PR11MB4366B5C09B4348FDAE33E2BCB58F0@MN2PR11MB4366.namprd11.prod.outlook.com> <99BFF357-6A2A-49E0-BB38-37C25DB04213@akamai.com> <MN2PR11MB4366F20EE2FD6DF04B965125B58E0@MN2PR11MB4366.namprd11.prod.outlook.com> <EBE4757D-E99E-41EB-A52B-A25F023BF4BC@akamai.com> <MN2PR11MB4366E4ECE10DFB018941BA5FB58E0@MN2PR11MB4366.namprd11.prod.outlook.com> <0100016d44bda220-51590a9a-0a15-4b63-a49d-47efe712e82e-000000@email.amazonses.com> <MN2PR11MB436617082A8308A7A8928DDFB58E0@MN2PR11MB4366.namprd11.prod.outlook.com>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.09.18-54.240.8.64
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/Ubw50QqbIBrxBU8uUjH8dNTiN0g>
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: Wed, 18 Sep 2019 17:03:12 -0000

[moving Russ and Sean to BCC, per Rich's action]



> Minor: Does the “string” in the description above mean “ASCII string” or “binary string”, RFC 4251 seemingly uses both definitions?

I don't know, but this is the language found for the "key-data" leaf in RFC 7317 (i.e., we've been living with this definition for awhile)


> Is putting the encrypted keys into DER-encoded OneSymmetricKey obviously the right thing to do?  Are there other choices?


Yes, if there was one thing that came out of my discussion with Russ and Sean is that OneSymmetricKey and OneAsymmetricKey SHOULD be used for encrypting key data.   Anything else would be a BIG effort.   

The real question is if we should also use the One*Key structures for unencrypted keys, which could help some ways, but I think that it's better to use the values provided by OpenSSL command line.  This approach pushes the complexity of using the One*Key structures to just the "advanced" case of when encryption is needed and, besides, it would primarily be for the NC/RC server to generate/parse; clients would rarely encrypt a key themselves, the only case I can think of when they might would be for the RMA workflow we discussed a few weeks back.


Kent