Re: [netconf] crypto-types fallback strategy

Kent Watsen <kent+ietf@watsen.net> Thu, 12 September 2019 17:46 UTC

Return-Path: <0100016d269570a7-1d38d4fb-97e7-43b5-9439-2f84deab2c83-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 3CAF71201C6 for <netconf@ietfa.amsl.com>; Thu, 12 Sep 2019 10:46:34 -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 1dVntCeONgh2 for <netconf@ietfa.amsl.com>; Thu, 12 Sep 2019 10:46:32 -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 9077E120178 for <netconf@ietf.org>; Thu, 12 Sep 2019 10:46:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=6gbrjpgwjskckoa6a5zn6fwqkn67xbtw; d=amazonses.com; t=1568310391; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=jaoGnW/ycokMgi1fp1K58FmE212KyuC77JEeEuZY8ZA=; b=GL545s2CXgi9bQcvjsRS4ReYXmco9uIRgmLmtbNawTS1yCNAIlyMWI6UQg4aZwRd domMvSLd8HDXHEzQRuhbaWiXurakuxTHwsIL2xhi3mrX8ScvVZ3aOMrqdiM67jpcl5s VVCfrta5+uo7I4o3w1E5j3DzC9gyYe7TFd5Z7mao=
From: Kent Watsen <kent+ietf@watsen.net>
Message-ID: <0100016d269570a7-1d38d4fb-97e7-43b5-9439-2f84deab2c83-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_D268A51B-9190-428A-BF7F-4DBF670E4707"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 12 Sep 2019 17:46:31 +0000
In-Reply-To: <65A6D989-0BA6-4755-AA76-21BACB8E0559@akamai.com>
Cc: Martin Bjorklund <mbj@tail-f.com>, "housley@vigilsec.com" <housley@vigilsec.com>, "netconf@ietf.org" <netconf@ietf.org>, "sean@sn3rd.com" <sean@sn3rd.com>, "rifaat.ietf@gmail.com" <rifaat.ietf@gmail.com>
To: "Salz, Rich" <rsalz@akamai.com>
References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <20190912.111242.323252506550752617.mbj@tail-f.com> <0100016d265824b0-313d5248-5aba-4b96-8f21-768be7784568-000000@email.amazonses.com> <65A6D989-0BA6-4755-AA76-21BACB8E0559@akamai.com>
X-Mailer: Apple Mail (2.3445.104.11)
X-SES-Outgoing: 2019.09.12-54.240.8.83
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/huKMqq5JaxFNRsWbwa_BeZ_1iTw>
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: Thu, 12 Sep 2019 17:46:34 -0000

Hi Rich,

> I think saying “used by TLS” is not a good reason, we should really talk about the applications we are trying to configure and manage. 

For reference, the full sentence was: ASN.1 is not TLS-specific, it just so happens to be heavily used by TLS.

The focus of this work is primarily to enable the configuration of NETCONF and RESTCONF servers.   NETCONF can use either SSH or TLS as a transport, and RESTCONF is always HTTPS.    The current structure of the suite of client-server drafts includes generic SSH and TLS layers (and likely a DTLS layer someday) that have already been adopted by other work-in-progress at the IETF (e.g., models for PCEP, Syslog, etc.), so the scope of the SSH and TLS layers is a little wider than just NETCONF and RESTCONF.  That said, I can't think of anything that has been done to date to cater to any external effort.


> Or am I hopelessly wrong about netconf?  That could be likely, I’m only here for the crypto objects dicussions.

Right.  My claim is that ASN.1 for storing keys is a pretty universal.   I don't think we give up much by formally claiming all the key values are ASN.1 structures but, importantly, by doing so, using OIDs becomes natural, thus obsoleting the need to define our own set of algorithm identifiers in YANG, which significantly motivates this thread.  Makes sense?


Kent