Re: [Netconf] 答复: Adoption poll for crypto-types and trust-anchors

Kent Watsen <kwatsen@juniper.net> Sat, 19 May 2018 01:27 UTC

Return-Path: <kwatsen@juniper.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 5E6C7124D37 for <netconf@ietfa.amsl.com>; Fri, 18 May 2018 18:27:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 D1pD74xSaMOW for <netconf@ietfa.amsl.com>; Fri, 18 May 2018 18:27:38 -0700 (PDT)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 DB09A124BAC for <netconf@ietf.org>; Fri, 18 May 2018 18:27:37 -0700 (PDT)
Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4J1PZTZ020735; Fri, 18 May 2018 18:27:30 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=0r8c0CS2bTEqxt+4Jz8ZsBhb0bG4cjRqJIvR79LSeZ4=; b=Zq8Q3qkE9KQXeDmYj5Q9lDWcg/5z4+GFQ5wxUjfiVbavQ/xb+dwR3tHt+wwXcGByE8sk qsm8zyCWfkU1bWSBtto3cCOyUA1vvI2s21XQPq7Wo1+p2h/ouR3936acKolraHK/xgRX rqke1uONb2xpLFX5b6RoJ1mN7eyYzjAAIJ4Hq7hb/H1JoRgGpg4ZiQfI1WGlDQ6JZ4Z8 wp0ootnKAqMCQCP7OOL33DlqamRARu8XvA1GoU41c1VEn9MSQRyYm+5ukEGuNy5gbRDN dNqyt8xFg8SVMYg3e36dB1XIEZlSS5lRBFY/I6ijvzKbiMBnS1AYYfdHFsI1WNxM9aTC 5g==
Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0053.outbound.protection.outlook.com [216.32.180.53]) by mx0b-00273201.pphosted.com with ESMTP id 2j23un8j4j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 18 May 2018 18:27:30 -0700
Received: from BYAPR05MB4230.namprd05.prod.outlook.com (52.135.200.153) by BYAPR05MB4584.namprd05.prod.outlook.com (52.135.204.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.797.5; Sat, 19 May 2018 01:27:28 +0000
Received: from BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::5c50:c79f:dbd0:7a9a]) by BYAPR05MB4230.namprd05.prod.outlook.com ([fe80::5c50:c79f:dbd0:7a9a%13]) with mapi id 15.20.0776.008; Sat, 19 May 2018 01:27:28 +0000
From: Kent Watsen <kwatsen@juniper.net>
To: "Xialiang (Frank, Network Integration Technology Research Dept)" <frank.xialiang@huawei.com>, =?utf-8?B?QmFsw6F6cyBLb3bDoWNz?= <balazs.kovacs@ericsson.com>
CC: "netconf@ietf.org" <netconf@ietf.org>
Thread-Topic: =?utf-8?B?562U5aSNOiBbTmV0Y29uZl0gQWRvcHRpb24gcG9sbCBmb3IgY3J5cHRvLXR5?= =?utf-8?Q?pes_and_trust-anchors?=
Thread-Index: AQHT7xCMYeUaDbm+NUC/QOqIbx5ONw==
Date: Sat, 19 May 2018 01:27:28 +0000
Message-ID: <7B5EDDFB-644A-494D-BFCE-EA85C0E438FF@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BYAPR05MB4584; 7:wnddnc/GhS/RWPm0g/AMowkVIf1joDMDBab7udH5DYLx61VANWNkKHERg9qTJywrolh/fAuNN1k9UMpmDJvtm67qa9Y5JCTymewWaBK8GaaIG/YtW1kLzgTVK3ePbe+QcRMkyp1V4r79NRTlvw2AoghwIXcIxowYwJ7Br89fL6G+XAsFnRQdmk90D+e03/yNGm8GCkHFhQgUIoG63McILGFLYNkrxVOOP60xK9Mhbr6ycwBBzlOdG+FwnKpFoOKp
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4584;
x-ms-traffictypediagnostic: BYAPR05MB4584:
x-microsoft-antispam-prvs: <BYAPR05MB4584692F04422CEC04D74359A5970@BYAPR05MB4584.namprd05.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231254)(944501410)(52105095)(6055026)(149027)(150027)(6041310)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(6072148)(201708071742011)(7699016); SRVR:BYAPR05MB4584; BCL:0; PCL:0; RULEID:; SRVR:BYAPR05MB4584;
x-forefront-prvs: 0677FFABBF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(396003)(39860400002)(39380400002)(366004)(199004)(189003)(51444003)(26005)(82746002)(229853002)(186003)(316002)(106356001)(478600001)(5250100002)(99286004)(105586002)(83716003)(224303003)(5660300001)(6512007)(86362001)(66066001)(2906002)(53936002)(8936002)(68736007)(14454004)(3660700001)(33656002)(3846002)(3280700002)(7736002)(6116002)(6246003)(305945005)(486006)(36756003)(6506007)(110136005)(97736004)(59450400001)(2900100001)(6486002)(102836004)(58126008)(6436002)(25786009)(4326008)(81166006)(81156014)(2616005)(476003); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4584; H:BYAPR05MB4230.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: EBF2MxT94VPM+zFOFpq58Ebq4C1+ZHpn7NM88jS6a6L1O3XBCr1dbXQrcHf18BdzwNTP8Low/Lc9UzZXtR54bdQBaNFQU2pFR4+nsPM6KUiKTOjjhX2Ug06xUTFP9R7x9U5JcblhFtu3rihOiuHWzf5wIc+WNrZTM2SGsfP+67aYzy3+4Wu3OPVHTi9X3Zgg
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <9A1420A11D0BA049ABA1ED77ED08D65A@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: b1792eae-db42-4e86-a9be-08d5bd27af6a
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: b1792eae-db42-4e86-a9be-08d5bd27af6a
X-MS-Exchange-CrossTenant-originalarrivaltime: 19 May 2018 01:27:28.6389 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4584
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-18_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805190014
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/fUw2cJUdjZRg1pFFz-L-VPllpN8>
Subject: Re: [Netconf] =?utf-8?b?562U5aSNOiAgQWRvcHRpb24gcG9sbCBmb3IgY3J5cHRv?= =?utf-8?q?-types_and_trust-anchors?=
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Network Configuration WG mailing 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: Sat, 19 May 2018 01:27:40 -0000

Hi Frank,

I recall your speaking at the mic after my presentation in London.  You introduced yourself as being from the security area, thanks for jumping in here.


> 1. I second Balazs’s opinion of centralized keystore has more benefits for us
> as a vendor, which is more easy, secure and efficient in the management aspect;

Agreed, this is what I was thinking about originally.


> 2. My preference is to roll back to keystone -03 version for the design of 
> centralized keystore, and at the same time, defining the asymmetric-key-grouping
> and local-or-keystore-asymmetric-key-grouping (as below email) with better
> modelling reusability, more importantly, support both centralized and local
> identity implementation. In addition, the new trust-anchors draft is necessary
> as one individual model;

I'm also of this opinion now.  By moving the trust-anchors out of keystore into its own module, the remainder of what would be in the keystore module would truly be just for the storing of keys.  Also, as discussed earlier, it makes little difference to implementation complexity, on either the client or server sides.  Lastly, the individual that expressed concern for keystore before has since expressed non-interest in this topic, so I think that fully clears the way to do this.  To be clear, what's being discussed is to adopt the two new drafts and *keep* the keystore draft, but with all the drafts being changed in ways described below.


> 3. The relation with other netconf/ssh/tls client-server drafts: there are
> still a lot of duplicated key pair, certificate and trust-anchors definitions
> in these drafts, should they directly reference the uniformly defined models
> in these keystore related drafts in future?

Please note that the current versions of those drafts were updated to reflect the change in keystore from -03 to -04.  When we talk about rolling back the keystore draft, we're implicitly also rolling back those drafts to their previous versions, though perhaps we might use the new "local-or-keystore" key grouping (thoughts?).  Could you please check and confirm that this is what you're looking for?


> 4. For the crypto-types draft, maybe in further versions, we can consider
> more key algorithms, such as: DSA, ECDSA.

Absolutely, in the fullness of time.  Be aware that the current draft crypto-types draft is just what's needed to support the various client/server drafts, and I'd like to keep it close to that goal for its first publication.  I understand that you have some drafts in SACM that could/should also import the crypto-types module.  To this end, let's ensure the first publication of this module is in line with our/your plans for how it needs to be extended to support your drafts.  


Summarizing the changes to the various drafts:

a) the keystore draft would essentially rollback to its -03 version with the trust-anchor part deleted, while retaining the "asymmetric-key" grouping introduced in -04, and introducing a new "local-or-keystore" key grouping.

b) the crypto-types draft would remove the asymmetric-key grouping and also the certificate-expiration notification (both moved to the resurrected keystore draft).  This means that it would only have identities and typedefs remaining.

c) the trust-anchors draft would have just a small change, to import and use the crypto-types module.

d) all the client/server drafts would be updated to either only reference keystore keys or, maybe use the new "local-or-keystore" grouping discussed above.

In my view, upon doing this, all these drafts should then be ready for Last Call.

Could folks comment on this plan?   Would it help if I posted updates to all the drafts as described above?


Kent  // contributor