Re: [netconf] crypto-types: why symmetric keys?

"Salz, Rich" <rsalz@akamai.com> Fri, 04 October 2019 18:06 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 3838F1208F8 for <netconf@ietfa.amsl.com>; Fri, 4 Oct 2019 11:06:51 -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 Fw946JwYOENR for <netconf@ietfa.amsl.com>; Fri, 4 Oct 2019 11:06:49 -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 88ABB12089D for <netconf@ietf.org>; Fri, 4 Oct 2019 11:06:49 -0700 (PDT)
Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x94I3BuK027727; Fri, 4 Oct 2019 19:06:42 +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=ok3JetJAl01k4h+aGUJ8nrDl9/BFrXmGNjfsbfde5Dk=; b=BdX228yIkS5JDF58L29/31A6byydBWrg0Ir//gI2NDFWXBbdhkgTaMyyo8jeVFkVGXct NhslIGsgtwsHtWavUAvR3mDfTD0qc5DP4nbUxeH29fZoMWQ+Dl7e9iQcVtJjoEdX5VBW pSIMB5HGvVDJdR+z4/OEv2VQ3So0S4ZUazA/aFx8ecqqRmX9DqDczp8E0qLJUc6SgzHZ qvIi+tduLpex0i/r9g3n1CjDbsXGm0HOd6i1+klB35/AOGrzgcE0YIKDZ9fJK4SUbn5e dWx1eTi7+JMfIY1m9s0ztb8TPoscCRo6hEYVJF4655uJcWi6gUxAUP7b9b9yGVpNm0V/ Cg==
Received: from prod-mail-ppoint7 (prod-mail-ppoint7.akamai.com [96.6.114.121] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2vceft5sb2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 04 Oct 2019 19:06:41 +0100
Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x94I3tqU015686; Fri, 4 Oct 2019 14:06:38 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint7.akamai.com with ESMTP id 2va2v1gwqj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 04 Oct 2019 14:06:37 -0400
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 4 Oct 2019 14:06:36 -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; Fri, 4 Oct 2019 14:06:36 -0400
From: "Salz, Rich" <rsalz@akamai.com>
To: Kent Watsen <kent+ietf@watsen.net>
CC: Randy Presuhn <randy_presuhn@alumni.stanford.edu>, "netconf@ietf.org" <netconf@ietf.org>, Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Thread-Topic: [netconf] crypto-types: why symmetric keys?
Thread-Index: AQHVerjc4I0mNpxxdEmkYSi/07A3oqdK8zsA///BUgCAAFOAgP//v2yA
Date: Fri, 04 Oct 2019 18:06:35 +0000
Message-ID: <13627E1C-A6D0-49B9-8277-55713E1958BD@akamai.com>
References: <B840CB4A-3DF9-4C1B-825D-F24A72EFC90F@akamai.com> <84a2ff74-67fb-069b-a9bc-4bd4187ee1bc@alumni.stanford.edu> <017A9541-641B-4826-983B-7C47AFA1A3AD@akamai.com> <0100016d97eb99fe-d6ce4ac2-7c9d-4653-833b-cb9471591e68-000000@email.amazonses.com>
In-Reply-To: <0100016d97eb99fe-d6ce4ac2-7c9d-4653-833b-cb9471591e68-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.1e.0.191003
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.36.233]
Content-Type: multipart/alternative; boundary="_000_13627E1CA6D049B9827755713E1958BDakamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-10-04_11:, , 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=977 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1910040149
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-10-04_11:2019-10-03,2019-10-04 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 impostorscore=0 lowpriorityscore=0 suspectscore=0 clxscore=1011 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=962 malwarescore=0 adultscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1910040149
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/zqgUda1_WMv75jvhexaILm7nxEY>
Subject: Re: [netconf] crypto-types: why symmetric keys?
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, 04 Oct 2019 18:06:51 -0000

Thanks for the clarification.

I continue to urge development of small models that meet most (*not all*) needs of service configuration.  TLS’s PSK keys need to be shared by the server and client(s), so I am not sure about the utility of “so not even the administrator knows it”  I am ignorant if PSK’s are actually needed for enterprise use of TLS.