Re: [netconf] crypto-types fallback strategy

"Salz, Rich" <rsalz@akamai.com> Mon, 16 September 2019 17:10 UTC

Return-Path: <rsalz@akamai.com>
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 3B957120090 for <netconf@ietfa.amsl.com>; Mon, 16 Sep 2019 10:10:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 bJ_S6ZTzi47E for <netconf@ietfa.amsl.com>; Mon, 16 Sep 2019 10:10:28 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 7BA41120072 for <netconf@ietf.org>; Mon, 16 Sep 2019 10:10:28 -0700 (PDT)
Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.42/8.16.0.42) with SMTP id x8GH7OB5010334; Mon, 16 Sep 2019 18:10:14 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=iabnD/m2xy3XKODseuDmZujXBERAtNgMoKuzAPqOJOc=; b=eTffiftTUsycc+fiFrsFyoUZfuSPCwf0xQYxYhxM4EJMn++n2E3aRTYe8hy0HSf/KDHb +9xV0KfFLW50EHO8nh9/EwMncNOtYy/hooTKJ9C4k8GX9cUj9DGRamNAlG2a22E9CKCg jXw8TaA/QNrXE7s/oRogMWxOl65WJ+VfeKFZZbvJzxgYXdy315YDsq6+vCu4nmLabDGg 8YKy7dSIrGsh947/GBvAiP8j6akqDOFcDbWKHQd5OpM4hPJsK/GeJsYFY/cI2ri1FlfN jIKxoXqZk9vZt6z0ezvkrcKEdYQY59/vtErB1PKUrKAQWp0bxyScM9YF6LOchh7n+ILJ Vw==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2v0tehh716-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 16 Sep 2019 18:10:14 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x8GH3wbS017532; Mon, 16 Sep 2019 13:10:11 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2v0uhw07t0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 16 Sep 2019 13:10:10 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 16 Sep 2019 13:10:09 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Mon, 16 Sep 2019 13:10:09 -0400
From: "Salz, Rich" <rsalz@akamai.com>
To: Kent Watsen <kent+ietf@watsen.net>
CC: "Rob Wilton (rwilton)" <rwilton@cisco.com>, "netconf@ietf.org" <netconf@ietf.org>, Russ Housley <housley@vigilsec.com>, Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, Sean Turner <sean@sn3rd.com>
Thread-Topic: [netconf] crypto-types fallback strategy
Thread-Index: AQHVaNxGVhFlbERW30moo9Q8WhnpJqcpkUCAgAAOz4CABTEggP//wEiA
Date: Mon, 16 Sep 2019 17:10:09 +0000
Message-ID: <2F75E025-45AF-4F91-8E44-98B957DC9F32@akamai.com>
References: <0100016d21ee2101-fb4f3288-1975-4a7d-a499-cb42ff8d9e14-000000@email.amazonses.com> <MN2PR11MB4366AE6CF9E03B15EBEA3A39B5B30@MN2PR11MB4366.namprd11.prod.outlook.com> <D6740042-7CD9-466F-911A-BA4339042B5D@akamai.com> <0100016d3b02a96b-a8f419e4-09f7-45b4-927f-bb715bf4d5e8-000000@email.amazonses.com>
In-Reply-To: <0100016d3b02a96b-a8f419e4-09f7-45b4-927f-bb715bf4d5e8-000000@email.amazonses.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1d.0.190908
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.33.21]
Content-Type: multipart/alternative; boundary="_000_2F75E02545AF4F918E4498B957DC9F32akamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-16_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=774 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909160169
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-16_07:2019-09-11,2019-09-16 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 lowpriorityscore=0 malwarescore=0 spamscore=0 adultscore=0 mlxlogscore=766 priorityscore=1501 bulkscore=0 phishscore=0 impostorscore=0 suspectscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909160169
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/NlfTsGleTlKu-Q_S6RHeDHlLwMI>
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 17:10:33 -0000


  *   I believe that each OID has a common name that can be used.

You can use those names within a module that you are defining, but be prepared to handle collisions when you import multiple modules.  I am not aware of any, but there is absolutely no requirement that one module will not have something like:
                foo ::= OBJECT IDENTIFIER { 1 2 3 . . . }
and another will have
                foo ::= OBJECT IDENTIFIER { 1 2 5 . . . }


  *   Rich, can you explain why not try to define a unified module for all cryptography?   Is it because it is a monster effort?   Would many smaller efforts that, together, achieve the same thing be different in a meaningful way?

Two reasons:


  1.  The data structures are different, and the security communities are different.  There are many people familiar with HTTPS configuration and TLS, and there are many people familiar with SSH key management, but the overlap between those two communities is a fraction of either one.


  1.  I prefer bite-sized chunks rather than a boil the ocean effort.



  1.  They are separate things; TLS uses X509 and PKCS structures, generally; SSH often uses “raw” public keys.  See https://blog.oddbit.com/post/2011-05-08-converting-openssh-public-keys/ for an explanation.

Make sense?