From nobody Sun Jun 2 18:38:26 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59CEC1200D6; Sun, 2 Jun 2019 18:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 yGn236QMsk8J; Sun, 2 Jun 2019 18:38:14 -0700 (PDT) Received: from www.goatley.com (www.goatley.com [198.137.202.94]) (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 D7F7E12004E; Sun, 2 Jun 2019 18:38:11 -0700 (PDT) Received: from trixy.bergandi.net (cpe-76-93-146-89.san.res.rr.com [76.93.146.89]) by wwwlocal.goatley.com (PMDF V6.8-0 #1001) with ESMTP id <0PSI00BAE1VN4N@wwwlocal.goatley.com>; Sun, 02 Jun 2019 20:38:11 -0500 (CDT) Received: from thinny.local ([65.222.135.102]) by trixy.bergandi.net (PMDF V6.7-x01 #1001) with ESMTPSA id <0PSI0053O1RHMN@trixy.bergandi.net>; Sun, 02 Jun 2019 18:35:52 -0700 (PDT) Received: from unknown ([65.222.135.102] EXTERNAL) (EHLO thinny.local) with TLS/SSL by trixy.bergandi.net ([10.0.42.18]) (PreciseMail V3.3); Sun, 02 Jun 2019 18:35:52 -0700 Date: Sun, 02 Jun 2019 18:37:58 -0700 From: Dan Harkins To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-acme-ip.all@ietf.org Message-id: <2696ffe2-18b3-1609-774f-23a1fe4af856@lounge.org> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_tellhz+jTsp0UM8dcB1/Dg)" Content-language: en-US User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 X-PMAS-SPF: SPF check skipped for authenticated session (recv=trixy.bergandi.net, send-ip=65.222.135.102) X-PMAS-External-Auth: unknown [65.222.135.102] (EHLO thinny.local) X-PMAS-Software: PreciseMail V3.3 [190528b] (trixy.bergandi.net) X-PMAS-Allowed: system rule (rule allow header:X-PMAS-External noexists) Archived-At: Subject: [secdir] secdir last call review of draft-ietf-acme-ip X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2019 01:38:17 -0000 This is a multi-part message in MIME format. --Boundary_(ID_tellhz+jTsp0UM8dcB1/Dg) Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 8BIT   Greetings,  I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is READY. This draft adds two new ACME Validation Methods to allow for validation of IPv4 and IPv6 addresses in X.509 certificates. It is short, simple, and to the point. The Security Considerations are minimal (basically "see this other RFC") but given what is being added seem entirely fine. regards, Dan. --Boundary_(ID_tellhz+jTsp0UM8dcB1/Dg) Content-type: text/html; charset=utf-8 Content-transfer-encoding: 8BIT
  Greetings,

  I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.

  The summary of the review is READY.

  This draft adds two new ACME Validation Methods to allow for validation
of IPv4 and IPv6 addresses in X.509 certificates. It is short, simple,
and to the point. The Security Considerations are minimal (basically "see
this other RFC") but given what is being added seem entirely fine.

  regards,

  Dan.




--Boundary_(ID_tellhz+jTsp0UM8dcB1/Dg)-- From nobody Mon Jun 3 14:48:24 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DCB612085B; Mon, 3 Jun 2019 14:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.708 X-Spam-Level: X-Spam-Status: No, score=-2.708 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=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 VuMuU2VMmx6Y; Mon, 3 Jun 2019 14:48:12 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 7EF9C120857; Mon, 3 Jun 2019 14:48:12 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x53Lg11g015515; Mon, 3 Jun 2019 22:48:11 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=8gJTP4VTgimxUbAFztubN3Grvwy2tg5S8ydxWwxiEHg=; b=XZ1vsdDeq2ecUd27mE4PtuY7BaDC47z5cgTbLHVYZbQks3uwVvianeHVcBTJ/5+a+1St bawctx/AZtHhwCONdEddMCYx/dMoqeJAaVaBWxeE3yGvL0YSsBFk1yDG8LGa6xtXW9cS OGP2a0R4FwE7q03YTsaja1J5nI04+4g9aEGaCYOvzMUQ0+h6nShHLGVQZD4TNDoONoCJ dUq3ZQuQBgTaQQL+KOxT3xb1kIm5O4fqlpd7xpVr6lm41KJoh1RsMpk4/3TDfN2F05P2 nVGAKybkiiYUd0kg+Y2MkjnX7/IuM0T0nqes52pUSbrgixAy40ft4kvvsZO9zsZ94HmR Hw== Received: from prod-mail-ppoint4 (prod-mail-ppoint4.akamai.com [96.6.114.87] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 2swbkfg0xp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 03 Jun 2019 22:48:11 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x53LlNGw019377; Mon, 3 Jun 2019 17:48:10 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.30]) by prod-mail-ppoint4.akamai.com with ESMTP id 2sumpwwfh7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 03 Jun 2019 17:48:10 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb6.msg.corp.akamai.com (172.27.27.107) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 3 Jun 2019 14:48:08 -0700 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([::1]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([fe80::31b1:fe55:15cb:980e%18]) with mapi id 15.00.1473.003; Mon, 3 Jun 2019 16:48:08 -0500 From: "Salz, Rich" To: Dan Harkins , "iesg@ietf.org" , "secdir@ietf.org" , "draft-ietf-acme-ip.all@ietf.org" Thread-Topic: secdir last call review of draft-ietf-acme-ip Thread-Index: AQHVGa0GTuOoUx2v3EGRSR5lu25EiKaKiXiA Date: Mon, 3 Jun 2019 21:48:08 +0000 Message-ID: References: <2696ffe2-18b3-1609-774f-23a1fe4af856@lounge.org> In-Reply-To: <2696ffe2-18b3-1609-774f-23a1fe4af856@lounge.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190530 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.147] Content-Type: multipart/alternative; boundary="_000_C8D3D704E98B4CC78997290F83A1AEE7akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-03_17:, , 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=791 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906030146 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-03_17:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=819 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906030146 Archived-At: Subject: Re: [secdir] secdir last call review of draft-ietf-acme-ip X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Jun 2019 21:48:15 -0000 --_000_C8D3D704E98B4CC78997290F83A1AEE7akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciB0aGUgcmV2aWV3IERhbiENCg0KRnJvbTogRGFuIEhhcmtpbnMgPGRoYXJraW5z QGxvdW5nZS5vcmc+DQpEYXRlOiBTdW5kYXksIEp1bmUgMiwgMjAxOSBhdCA5OjM4IFBNDQpUbzog Imllc2dAaWV0Zi5vcmciIDxpZXNnQGlldGYub3JnPiwgInNlY2RpckBpZXRmLm9yZyIgPHNlY2Rp ckBpZXRmLm9yZz4sICJkcmFmdC1pZXRmLWFjbWUtaXAuYWxsQGlldGYub3JnIiA8ZHJhZnQtaWV0 Zi1hY21lLWlwLmFsbEBpZXRmLm9yZz4NClN1YmplY3Q6IHNlY2RpciBsYXN0IGNhbGwgcmV2aWV3 IG9mIGRyYWZ0LWlldGYtYWNtZS1pcA0KUmVzZW50LUZyb206IDxhbGlhcy1ib3VuY2VzQGlldGYu b3JnPg0KUmVzZW50LVRvOiBSb2xhbmQgU2hvZW1ha2VyIDxyb2xhbmRAbGV0c2VuY3J5cHQub3Jn PiwgUmljaCBTYWx6IDxyc2FsekBha2FtYWkuY29tPiwgWW9hdiBOaXIgPHluaXIuaWV0ZkBnbWFp bC5jb20+LCBSb21hbiBEYW55bGl3IDxyZGRAY2VydC5vcmc+LCBCZW5qYW1pbiBLYWR1ayA8a2Fk dWtAbWl0LmVkdT4sICJjcHVAbGV0c2VuY3J5cHQub3JnIiA8Y3B1QGxldHNlbmNyeXB0Lm9yZz4s ICJjcHVAbGV0c2VuY3J5cHQub3JnIiA8Y3B1QGxldHNlbmNyeXB0Lm9yZz4NClJlc2VudC1EYXRl OiBTdW5kYXksIEp1bmUgMiwgMjAxOSBhdCA5OjM4IFBNDQoNCg0KICBHcmVldGluZ3MsDQoNCiAg SSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGly ZWN0b3JhdGUncw0KDQpvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRz IGJlaW5nIHByb2Nlc3NlZCBieSB0aGUNCg0KSUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3Jp dHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZQ0KDQpzZWN1cml0eSBhcmVhIGRp cmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQNCg0K dGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQoN Cg0KDQogIFRoZSBzdW1tYXJ5IG9mIHRoZSByZXZpZXcgaXMgUkVBRFkuDQoNCg0KDQogIFRoaXMg ZHJhZnQgYWRkcyB0d28gbmV3IEFDTUUgVmFsaWRhdGlvbiBNZXRob2RzIHRvIGFsbG93IGZvciB2 YWxpZGF0aW9uDQoNCm9mIElQdjQgYW5kIElQdjYgYWRkcmVzc2VzIGluIFguNTA5IGNlcnRpZmlj YXRlcy4gSXQgaXMgc2hvcnQsIHNpbXBsZSwNCg0KYW5kIHRvIHRoZSBwb2ludC4gVGhlIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zIGFyZSBtaW5pbWFsIChiYXNpY2FsbHkgInNlZQ0KDQp0aGlzIG90 aGVyIFJGQyIpIGJ1dCBnaXZlbiB3aGF0IGlzIGJlaW5nIGFkZGVkIHNlZW0gZW50aXJlbHkgZmlu ZS4NCg0KDQoNCiAgcmVnYXJkcywNCg0KDQoNCiAgRGFuLg0KDQoNCg0KDQoNCg0KDQoNCg== --_000_C8D3D704E98B4CC78997290F83A1AEE7akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQp0dA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg UHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb25zb2xhcyIsc2VyaWY7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6 MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIHRoZSByZXZpZXcgRGFuITxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RGFuIEhhcmtpbnMgJmx0O2RoYXJr aW5zQGxvdW5nZS5vcmcmZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlN1bmRheSwgSnVuZSAyLCAyMDE5 IGF0IDk6MzggUE08YnI+DQo8Yj5UbzogPC9iPiZxdW90O2llc2dAaWV0Zi5vcmcmcXVvdDsgJmx0 O2llc2dAaWV0Zi5vcmcmZ3Q7LCAmcXVvdDtzZWNkaXJAaWV0Zi5vcmcmcXVvdDsgJmx0O3NlY2Rp ckBpZXRmLm9yZyZndDssICZxdW90O2RyYWZ0LWlldGYtYWNtZS1pcC5hbGxAaWV0Zi5vcmcmcXVv dDsgJmx0O2RyYWZ0LWlldGYtYWNtZS1pcC5hbGxAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVj dDogPC9iPnNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtYWNtZS1pcDxicj4N CjxiPlJlc2VudC1Gcm9tOiA8L2I+Jmx0O2FsaWFzLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PGJyPg0K PGI+UmVzZW50LVRvOiA8L2I+Um9sYW5kIFNob2VtYWtlciAmbHQ7cm9sYW5kQGxldHNlbmNyeXB0 Lm9yZyZndDssIFJpY2ggU2FseiAmbHQ7cnNhbHpAYWthbWFpLmNvbSZndDssIFlvYXYgTmlyICZs dDt5bmlyLmlldGZAZ21haWwuY29tJmd0OywgUm9tYW4gRGFueWxpdyAmbHQ7cmRkQGNlcnQub3Jn Jmd0OywgQmVuamFtaW4gS2FkdWsgJmx0O2thZHVrQG1pdC5lZHUmZ3Q7LCAmcXVvdDtjcHVAbGV0 c2VuY3J5cHQub3JnJnF1b3Q7ICZsdDtjcHVAbGV0c2VuY3J5cHQub3JnJmd0OywgJnF1b3Q7Y3B1 QGxldHNlbmNyeXB0Lm9yZyZxdW90OyAmbHQ7Y3B1QGxldHNlbmNyeXB0Lm9yZyZndDs8YnI+DQo8 Yj5SZXNlbnQtRGF0ZTogPC9iPlN1bmRheSwgSnVuZSAyLCAyMDE5IGF0IDk6MzggUE08bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsi Pjxicj4NCjx0dD4mbmJzcDsgR3JlZXRpbmdzLDwvdHQ+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHByZT4gJm5ic3A7SSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUg c2VjdXJpdHkgZGlyZWN0b3JhdGUncyA8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5vbmdvaW5nIGVm Zm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUg PG86cD48L286cD48L3ByZT4NCjxwcmU+SUVTRy4mbmJzcDsgVGhlc2UgY29tbWVudHMgd2VyZSB3 cml0dGVuIHByaW1hcmlseSBmb3IgdGhlIGJlbmVmaXQgb2YgdGhlIDxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPnNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiZuYnNwOyBEb2N1bWVudCBlZGl0b3JzIGFu ZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnRoZXNlIGNv bW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyBUaGUgc3Vt bWFyeSBvZiB0aGUgcmV2aWV3IGlzIFJFQURZLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyBUaGlzIGRyYWZ0IGFkZHMgdHdvIG5ldyBB Q01FIFZhbGlkYXRpb24gTWV0aG9kcyB0byBhbGxvdyBmb3IgdmFsaWRhdGlvbjxvOnA+PC9vOnA+ PC9wcmU+DQo8cHJlPm9mIElQdjQgYW5kIElQdjYgYWRkcmVzc2VzIGluIFguNTA5IGNlcnRpZmlj YXRlcy4gSXQgaXMgc2hvcnQsIHNpbXBsZSw8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5hbmQgdG8g dGhlIHBvaW50LiBUaGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgYXJlIG1pbmltYWwgKGJhc2lj YWxseSAmcXVvdDtzZWU8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT50aGlzIG90aGVyIFJGQyZxdW90 OykgYnV0IGdpdmVuIHdoYXQgaXMgYmVpbmcgYWRkZWQgc2VlbSBlbnRpcmVseSBmaW5lLjxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyBy ZWdhcmRzLDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8 cHJlPiZuYnNwOyBEYW4uPG86cD48L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48 L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+PG86cD4mbmJzcDs8L286 cD48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_C8D3D704E98B4CC78997290F83A1AEE7akamaicom_-- From nobody Mon Jun 3 23:05:21 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34AE21200A4 for ; Mon, 3 Jun 2019 23:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 cFbG5mnaQF1w for ; Mon, 3 Jun 2019 23:05:15 -0700 (PDT) Received: from smtp.outgoing.loopia.se (smtp.outgoing.loopia.se [194.9.95.112]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1950120877 for ; Mon, 3 Jun 2019 23:05:13 -0700 (PDT) Received: from s554.loopia.se (localhost [127.0.0.1]) by s554.loopia.se (Postfix) with ESMTP id 59AD01F1469D for ; Tue, 4 Jun 2019 08:05:00 +0200 (CEST) Received: from s499.loopia.se (unknown [172.21.200.97]) by s554.loopia.se (Postfix) with ESMTP id 3A5CE794051; Tue, 4 Jun 2019 08:05:00 +0200 (CEST) Received: from s470.loopia.se (unknown [172.21.200.36]) by s499.loopia.se (Postfix) with ESMTP id 2CCDB1349A45; Tue, 4 Jun 2019 08:05:00 +0200 (CEST) X-Virus-Scanned: amavisd-new at amavis.loopia.se Received: from s499.loopia.se ([172.22.191.6]) by s470.loopia.se (s470.loopia.se [172.22.190.10]) (amavisd-new, port 10024) with UTF8LMTP id oah77E4YsWkz; Tue, 4 Jun 2019 08:04:59 +0200 (CEST) X-Loopia-Auth: user X-Loopia-User: mailstore2@aaa-sec.com X-Loopia-Originating-IP: 85.235.7.89 Received: from [192.168.2.38] (gw.aaa-sec.ideon.se [85.235.7.89]) (Authenticated sender: mailstore2@aaa-sec.com) by s499.loopia.se (Postfix) with ESMTPSA id F40A21349A47; Tue, 4 Jun 2019 08:04:58 +0200 (CEST) User-Agent: Microsoft-MacOutlook/10.19.0.190512 Date: Tue, 04 Jun 2019 08:04:58 +0200 From: Stefan Santesson To: Tim Hollebeek , Jacob Hoffman-Andrews , "secdir@ietf.org" CC: "spasm@ietf.org" , "ietf@ietf.org" , "draft-ietf-lamps-rfc6844bis.all@ietf.org" Message-ID: <8AD60BC4-4A2D-4A13-BED5-B12E0E0FE42B@aaa-sec.com> Thread-Topic: Secdir last call review of draft-ietf-lamps-rfc6844bis-06 References: <155917666691.9144.10382733252232760132@ietfa.amsl.com> <3f60c58a-7923-d5da-e500-052588a294fb@eff.org> In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-lamps-rfc6844bis-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 06:05:20 -0000 Sounds great.=20 I just made a note. I do not call for any change. Stefan Santesson=20 =EF=BB=BFOn 2019-05-30, 20:40, "Tim Hollebeek" wrote= : Just to make it official, I'm the chair of the Validation Subcommittee = of the=20 Server Certificate Working Group of the CA/Browser Forum, and I intend = to=20 submit a ballot to make RFC 6844bis mandatory in the event it is publis= hed as=20 an IETF RFC. =20 -Tim =20 > -----Original Message----- > From: Jacob Hoffman-Andrews > Sent: Thursday, May 30, 2019 2:30 PM > To: Stefan Santesson ; secdir@ietf.org > Cc: spasm@ietf.org; ietf@ietf.org; draft-ietf-lamps-rfc6844bis.all@ie= tf.org > Subject: Re: Secdir last call review of draft-ietf-lamps-rfc6844bis-0= 6 > > On 5/29/19 5:37 PM, Stefan Santesson via Datatracker wrote: > > A common aspect of standards documents is that they only are releva= nt > > to those who declare compliance to the standard. This document is > > different as it relies on that all parties (CA:s) are aware of this > > standard and performs the stipulated checks. > > In practice this has been stipulated for public CAs by the CA/Browser= Forum > Baseline Requirements since September 2017: > https://cabforum.org/2017/03/08/ballot-187-make-caa-checking-mandator= y/. > > In other words, the CP for this particular community of trust incorpo= rates=20 > RFC > 6844, making it mandatory. The intent is that once RFC6844bis is=20 > standardized, > CA/Browser Forum will have a followup ballot incorporating it. =20 =20 From nobody Tue Jun 4 13:41:23 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C016D120614; Tue, 4 Jun 2019 13:40:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.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 5YakCdyVKpD4; Tue, 4 Jun 2019 13:40:47 -0700 (PDT) Received: from mail-lj1-x229.google.com (mail-lj1-x229.google.com [IPv6:2a00:1450:4864:20::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F6B4120634; Tue, 4 Jun 2019 13:40:47 -0700 (PDT) Received: by mail-lj1-x229.google.com with SMTP id t28so9911233lje.9; Tue, 04 Jun 2019 13:40:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=AYKgyIj9n1oAu/l0Hi6yXJGV0fClHcyso9ZiKqRFZiE=; b=RL7Rq4NHIpQlrT2a7gN3pDHl9usYvA8zA/4hFCxbgeY/l+RSAWNbkVPCGN3pC+2GfQ bdarTYYOyNyDViiCYfnkmztu5vLXMRSuIw8a9pWSiq0EXWwdieavLJ4Gb9GBxoGE2AY9 hp5A7JAlkD4IznNrFADpI9SPO6riQHrNPI4vbbG4sMWPomyL/XVLgwhJ5mFyTEiIBbmX aac+PFOVJd1Lw+i7qM7egAYkx0fNL1GqiCoXWIUKR6arYxNaJhQKWE05Y+x2yKnsFEbU TJwXJWp8b+jZsOHrROWs5wkHBijETW5ycGSyf1m4m+utlwvRkxP6X5q2P/OyXfDDPvyt iSxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=AYKgyIj9n1oAu/l0Hi6yXJGV0fClHcyso9ZiKqRFZiE=; b=nKUQzmGyLuS5U33xt/yAW8+nVEWE0Rsqw0GaGgwos0NIuP94TqkcY4mevUQ2EXV+B6 ng7Ybc4UpFPbUr8H6QiIuDZninkHE6zrX0OtLcGkpGton1hOb5bV1MQ4kXNwJHdBgKgl 1bsfzOjvTRQCiX8HWlzDSobXuYNM6JvgLHiZo6opdW2+5NWhreU/Wv/2V5u6Bozyk1hF 8HVW8JL3rhsgElmfkdU9smXr42gVHf73t5MuaJV841KqY4HHOOoII025NLjabYncxZAG F7PfrQXHp6CsekFGc1Tn+TEdz6uZLZXCeXSq8QDBwobG6D4dth/H1RaegGo+TPJII35m GZRA== X-Gm-Message-State: APjAAAVqZD0vCyM9P4VknHxRSjLQHicLyNWkko+MLp8t9Dhekw4EFzRL BwzS9xIU3YByQq3YxncaIJ0vXh1iBl3FOgxvrd8999fO X-Google-Smtp-Source: APXvYqwJFl0CUzspEOeR7Q7f3xa5iZ4VU/jkJThasfc5LVHbzkMgnn1Z6r/0GT5k2D+7vsXXeD15G1HoqtSmrN4xMII= X-Received: by 2002:a2e:56dd:: with SMTP id k90mr5496186lje.204.1559680845333; Tue, 04 Jun 2019 13:40:45 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Greg Mirsky Date: Tue, 4 Jun 2019 13:40:33 -0700 Message-ID: To: Shawn Emery Cc: secdir@ietf.org, draft-ietf-bfd-vxlan.all@ietf.org, Shawn Emery Content-Type: multipart/alternative; boundary="000000000000bfc74c058a857ea1" Archived-At: Subject: Re: [secdir] Review of draft-ietf-bfd-vxlan-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Jun 2019 20:41:00 -0000 --000000000000bfc74c058a857ea1 Content-Type: text/plain; charset="UTF-8" Hi Shawn, thank you for the review, clear, directed questions, and helpful suggestions. Please find answers, notes in-lined and tagged GIM>>. Regards, Greg On Fri, May 24, 2019 at 10:45 PM Shawn Emery wrote: > Reviewer: Shawn M. Emery > Review result: Ready with issues > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security > area directors. Document editors and WG chairs should treat these > comments just like any other last call comments. > > This draft specifies usage of the Bidirectional Forwarding Detection > (BFD) protocol on > Virtual eXtensible Local Area Network (VXLAN) tunnels. > > The security considerations section does exist and discusses the > introduction of a possible > DDoS attack due to the requirement of the protocol to set the IP TTL to > one hop. The prescription > outlined is to throttle this traffic. The section continues that BFD > sessions should also have an > upper limit, but does not give guidance on what is considered reasonable > to where it would affect > normal traffic vs. some form of DoS. > GIM>> The precise number would depend on many factors and thus we only recommend to have a knob to control the number of BFD sessions between a pair of VTEPs. Would the updated recommendation on the control of the number of concurrent sessions between a pair of VTEP as below address your concern: OLD TEXT: The implementation SHOULD have a reasonable upper bound on the number of BFD sessions that can be created between the same pair of VTEPs. NEW TEXT: If the implementation supports establishing multiple BFD sessions between the same pair of VTEPs, there SHOULD be a mechanism to control the maximum number of such session that can be active at the same time. > I believe that this section should also document the security > impact of deploying BFD on VXLANs for monitoring tunnel traffic. Which > additional information, > if any, can now be obtained with BFD usage? > GIM>> As stated in RFC 5880, BFD is designed to detect failures in the path between two BFD systems. BFD detects the loss of path continuity between forwarding engines used by BFD peers that participate in the given BFD session. As it is defined now, BFD is not used to monitor the tunnel traffic for possible performance degradation > > General comments: > > This standards track draft makes a normative reference to the base RFC, > 7348, which is informational. > Are there plans of making the base protocol a standards track > specification? Downward references > will need to be justified. > GIM>> As I understand, it is common practice to introduce to IETF process a de-facto standard as Informational track document and reference it as the normative document in a specification on the standard track. The flagged downref requires manual correction. > > Editorial comments: > > NVE is never expanded and not on the RFC Editors Abbreviation List. > GIM>> Thank you. Will expand as Network Virtualization Endpoint. > > Echo BFD is out of scope for the document, but does not describe the > reason for this or why state > this at all? > GIM>> I think that the main reason is that the BFD Echo mode is underspecified. RFC 5880 defined some of the mechanisms related to the Echo mode, but more standardization work may be required. > > Shawn. > -- > --000000000000bfc74c058a857ea1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Shawn,
thank you for the review, c= lear, directed questions, and helpful suggestions. Please find answers, not= es in-lined and tagged GIM>>.

Regards,
=
Greg

On Fri, May 24, 2019 at 10:45 PM Shawn Emery <shawn.emery@gmail.com&g= t; wrote:
Reviewer: Shawn M. Eme= ry
Re= view result:=C2=A0
Ready with issues

<= /div>I have reviewed this document as part= of the security directorate's
ongoing effort to review all=C2=A0IETF=C2=A0documents being pro= cessed by the IESG.
These comments were written primarily for the benefit of the= security
area directors. Document editors and WG chairs should treat these
comments = just like any other last call comments.

This draft specifies usage of= the=C2=A0Bidirectional Forwarding=C2=A0Detection (BFD) protocol on
Virtual eXtensible Local Area Networ= k (VXLAN)=C2=A0tunnels.

<= div>
The security considerations section doe= s exist and discusses the introduction of a possible
DDoS=C2=A0attack due to the= requirement of the protocol to set the IP TTL to one hop.=C2=A0 The prescr= iption
outlined is to throttle = this traffic.=C2=A0 The section continues that BFD sessions should also hav= e an
upper limit, but does not give gu= idance on what is considered reasonable to where it would affect
normal traffic vs. some form of DoS.=C2=A0
=
GIM>> The precise number would de= pend on many factors and thus we only recommend to have a knob to control t= he number of BFD sessions between a pair of VTEPs. Would the updated recomm= endation on the control of the number of concurrent sessions between a pair= of VTEP as below address your concern:
OLD TEXT:
= =C2=A0 =C2=A0The implementation SHOULD have a reasonable upper bound on the= number
=C2=A0 =C2=A0of BFD sessions that can be created between the sam= e pair of VTEPs.
NEW TEXT:
=C2=A0 =C2=A0If the impl= ementation supports establishing multiple BFD sessions
=C2=A0 =C2=A0betw= een the same pair of VTEPs, there SHOULD be a mechanism to control
=C2= =A0 =C2=A0the maximum number of such session that can be active at the same=
=C2=A0 =C2=A0time.
I believe that this section should also document the=C2=A0security
= impact of=C2=A0deploying BFD on VXLANs for monitoring tunnel traffic.=C2=A0 W= hich additional information,
if any,=C2=A0can now be=C2=A0obtained w= ith BFD usage?
GIM>> = As stated in RFC 5880, BFD is designed to detect failures in the path betwe= en two BFD systems. BFD detects the loss of path continuity between forward= ing engines used by BFD peers that participate in the given BFD session. As= it is defined now, BFD is not used to monitor the tunnel traffic for possi= ble performance degradation

General comments:

T= his standards track draft makes a normative reference to the base RFC, 7348= , which is informational.
Are there plans of making the base pr= otocol a standards track specification?=C2=A0 Downward references
will n= eed to be justified.
GIM>> As I un= derstand, it is common practice to introduce to IETF process a de-facto sta= ndard as Informational track document and reference it as the normative doc= ument in a specification on the standard track. The flagged downref require= s manual correction.

Editorial comments:

NV= E is never expanded and not on the RFC Editors Abbreviation List.
GIM>> Thank you. Will expand as=C2= =A0Network Virtualization Endpoint.=C2=A0

Echo BFD is out= of scope for the document, but does not describe the reason for this or wh= y state
this at all?
GIM>>= I think that the main reason is that the BFD Echo mode is underspecified. = RFC 5880 defined some of the mechanisms related to the Echo mode, but more = standardization work may be required.

Shawn.
--
--000000000000bfc74c058a857ea1-- From nobody Tue Jun 4 21:03:11 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 709AE1205D9; Tue, 4 Jun 2019 21:02:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christian Huitema via Datatracker To: Cc: draft-ietf-anima-bootstrapping-keyinfra.all@ietf.org, ietf@ietf.org, anima@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Christian Huitema Message-ID: <155970737536.28026.7190851289288084775@ietfa.amsl.com> Date: Tue, 04 Jun 2019 21:02:55 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-anima-bootstrapping-keyinfra-20 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2019 04:02:56 -0000 Reviewer: Christian Huitema Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I think the document is now "ready with nits". In my previous review of draft-ietf-anima-bootstrapping-keyinfra-16, I raised a number of concerns. The new version draft-ietf-anima-bootstrapping-keyinfra-20 addresses these concerns in two main ways: an applicability statement that restricts usage of the protocol to the "Autonomous Networking" scenario, and an improved security section. My main request is that the applicability discussion does not present the trade-off between between ease of bootstrap and increased manufacturer control. This should be easy to fix. The new version introduces applicability restriction in the Introduction, stating that the draft "provides for the needs of the ISP and Enterprise focused ANIMA Autonomic Control Plane (ACP)" and that other scenarios will require separate applicability statements. This is developed in section 8, "Applicability to the Autonomic Control Plane". This is a welcome change. It addresses some of the concerns raised in the previous review, such as use of BRSKI in consumer IOT scenarios. The previous review also raised a series of concerns related to the balance of power between manufacturer and owner of the device. These concerns are discussed in section 9, Privacy Considerations. The text in sections 9.2 points out that leakage of information is limited to the one-time bootstrap of the device. Section 9.3 addresses concerns expressed during the review about resale of devices, and points out that any mechanism intended to prevent theft will also prevent resale. That's true, but the mechanism designed to enable legitimate sales is only vaguely sketched: "the initial owner could inform the manufacturer of the sale, or the manufacturer may just permit resales unless told otherwise." Could and may, but there is no protocol element describing either option. Similarly, the section addresses manufacturer decisions to "end of life" a device by essentially stating that such devices will only be usable if they are never reset to factory default. Section 9.4 goes on explaining how the protocol can be used to thwart grey-market sales and resales, and simply state that it is legitimate for manufacturers to do that. As a whole, these three subsections of section 9 read very much like a justification of the original design. They could be summarized by stating that involving the manufacturer in the one-time bootstrapping provides new device owners with an automated and secure way to bootstrap devices, at the cost of increased manufacturer control on the devices' lifetime and resale. That trade-off may not be acceptable by every potental owner. Section 9.5 describes an interesting mitigation. It explains that manufacturer controls could be bypassed by replacing the certificate built in the device, and pointing it to a new MASA. That's obviously true, but I don't believe that the mechanisms for doing that are stated in the draft. In the absence of that mechanism, I would suggest to present the tradeoff between ease of bootstrap and increased manufacturer control in the introduction, perhaps in the same paragraph that states the domain of applicability of the draft. The security section covers several of the issues pointed out in the previous review. Section 10.1 explains how MASA availability issues (e.g. DoS attacks) are mitigated (10.1) by availability of nonceless vouchers. Section 10.2 explains how attacks by fake registrars could be detected by examining audit logs from the MASA. Section 10.3 discusses attacks by misbehaving MASA, and effectively conclude that they are not worse than if the device was bootstrapped without MASA. Continuous availability of MASA private key is discussed in 10.4. My previous review asked whether devices were expected to issue random numbers, and whether they should be equipped with appropriate random number generators. The protocol itself does not rely on random numbers generated by the device -- it only requires that the device be capable of generating a nonce. On the other hand, the protocol relies on HTTPS and thus TLS, which itself does require devices capable of generating cryptographically secure random numbers. The concern there is that BRSKI is engaged after the device is "reset to factory condition". This is probably easily mitigated, but might require a mention somewhere. A small nit about section 2.3 example:Text of first example says "The assertion leaf is indicated as 'proximity'", but there is no "assertion" leaf in the example voucher. Is this leftover from previous draft version? I also noticed a number of typos, especially in the added text. Running a spell check would help. From nobody Wed Jun 5 14:25:51 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B93A12013D; Wed, 5 Jun 2019 14:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 NH9kYiU682FV; Wed, 5 Jun 2019 14:25:49 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 1958B12008B; Wed, 5 Jun 2019 14:25:49 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id CABEF1E2D8; Wed, 5 Jun 2019 17:26:43 -0400 (EDT) Date: Wed, 5 Jun 2019 17:26:43 -0400 From: Jeffrey Haas To: Greg Mirsky Cc: Shawn Emery , secdir@ietf.org, draft-ietf-bfd-vxlan.all@ietf.org, Shawn Emery Message-ID: <20190605212643.GB15506@pfrc.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [secdir] Review of draft-ietf-bfd-vxlan-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2019 21:25:50 -0000 On Tue, Jun 04, 2019 at 01:40:33PM -0700, Greg Mirsky wrote: > > Echo BFD is out of scope for the document, but does not describe the > > reason for this or why state > > this at all? > > > GIM>> I think that the main reason is that the BFD Echo mode is > underspecified. RFC 5880 defined some of the mechanisms related to the Echo > mode, but more standardization work may be required. Speaking as a BFD chair, this is the relevant observation. BFD Echo is underspecified to the point where claiming compliance is difficult at best. In general, it relies on single-hop and the ability to have the remote Echo client loop the packets. This packet loop may not be practical for several encapsulations and thus is out of scope for such encapsulations. Whether this is practical for vxlan today, or in the presence of future extensions to vxlan is left out of scope for the core proposal. -- Jeff From nobody Thu Jun 6 02:24:38 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C7791200FB for ; Thu, 6 Jun 2019 02:24:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <155981307744.11626.16407737556283002841.idtracker@ietfa.amsl.com> Date: Thu, 06 Jun 2019 02:24:37 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 09:24:38 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-06-13 Reviewer LC end Draft Nancy Cam-Winget 2019-06-04 draft-ietf-sipcore-rejected-08 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Samuel Weiler 2019-05-13 draft-ietf-grow-wkc-behavior-05 Last calls: Reviewer LC end Draft Shaun Cooley 2019-03-13 draft-ietf-dots-data-channel-29 Roman Danyliw 2019-06-04 draft-ietf-rtgwg-enterprise-pa-multihoming-08 Daniel Franke 2019-03-18 draft-ietf-sidrops-https-tal-08 Daniel Gillmor 2018-03-19 draft-gutmann-scep-13 Russ Housley 2019-06-19 draft-ietf-mmusic-sdp-uks-05 Christian Huitema 2019-06-17 draft-ietf-mpls-egress-protection-framework-05 Catherine Meadows 2019-04-12 draft-ietf-mmusic-rfc4566bis-35 Matthew Miller 2019-04-08 draft-ietf-core-multipart-ct-03 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-08 Hilarie Orman R2019-04-10 draft-ietf-acme-caa-08 Tim Polk 2019-04-17 draft-ietf-isis-segment-routing-extensions-25 Carl Wallace R2019-05-13 draft-ietf-tsvwg-tinymt32-03 David Waltermire 2019-02-15 draft-ietf-rtcweb-ip-handling-11 Klaas Wierenga 2019-02-26 draft-ietf-mpls-sr-over-ip-06 Christopher Wood 2019-05-28 draft-ietf-tram-turnbis-25 Taylor Yu 2019-02-15 draft-ietf-rtcweb-security-arch-18 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-12 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Kathleen Moriarty 2019-04-08 draft-ietf-bmwg-ngfw-performance-00 Next in the reviewer rotation: Leif Johansson Benjamin Kaduk Charlie Kaufman Scott Kelly Stephen Kent Tero Kivinen Watson Ladd Ben Laurie Barry Leiba Chris Lonvick From nobody Thu Jun 6 10:53:06 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF3521200E9; Thu, 6 Jun 2019 10:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no 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 GNAWWJd36YlT; Thu, 6 Jun 2019 10:53:02 -0700 (PDT) Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A1AE9120165; Thu, 6 Jun 2019 10:52:55 -0700 (PDT) Received: from in01.mta.xmission.com ([166.70.13.51]) by out01.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1hYwZK-0005RX-7D; Thu, 06 Jun 2019 11:52:54 -0600 Received: from [166.70.232.207] (helo=rumpleteazer.rhmr.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1hYwZJ-0006cG-Nd; Thu, 06 Jun 2019 11:52:54 -0600 Received: from rumpleteazer.rhmr.com (localhost [127.0.0.1]) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id x56HqaV8031119; Thu, 6 Jun 2019 11:52:36 -0600 Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id x56HqZHh031114; Thu, 6 Jun 2019 11:52:35 -0600 Date: Thu, 6 Jun 2019 11:52:35 -0600 Message-Id: <201906061752.x56HqZHh031114@rumpleteazer.rhmr.com> From: "Hilarie Orman" Reply-To: "Hilarie Orman" To: secdir@ietf.org Cc: iesg@ietf.org, draft-ietf-acme-caa.all@tools.ietf.org X-XM-SPF: eid=1hYwZJ-0006cG-Nd; ; ; mid=<201906061752.x56HqZHh031114@rumpleteazer.rhmr.com>; ; ; hst=in01.mta.xmission.com; ; ; ip=166.70.232.207; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-AID: U2FsdGVkX1/6ryiUF7MXMKfrDl15Skoq X-SA-Exim-Connect-IP: 166.70.232.207 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa01 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: *;secdir@ietf.org X-Spam-Relay-Country: X-Spam-Timing: total 301 ms - load_scoreonly_sql: 0.03 (0.0%), signal_user_changed: 2.4 (0.8%), b_tie_ro: 1.70 (0.6%), parse: 0.54 (0.2%), extract_message_metadata: 2.5 (0.8%), get_uri_detail_list: 0.72 (0.2%), tests_pri_-1000: 2.2 (0.7%), tests_pri_-950: 1.05 (0.4%), tests_pri_-900: 0.89 (0.3%), tests_pri_-90: 16 (5.3%), check_bayes: 15 (4.9%), b_tokenize: 3.6 (1.2%), b_tok_get_all: 5 (1.7%), b_comp_prob: 1.56 (0.5%), b_tok_touch_all: 3.0 (1.0%), b_finish: 0.51 (0.2%), tests_pri_0: 268 (89.0%), check_dkim_signature: 0.51 (0.2%), check_dkim_adsp: 40 (13.1%), poll_dns_idle: 34 (11.3%), tests_pri_10: 1.76 (0.6%), tests_pri_500: 4.2 (1.4%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Archived-At: Subject: [secdir] Security review of draft-ietf-acme-caa-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 17:53:05 -0000 Security review of CAA Record Extensions for Account URI and ACME Method Binding draft-ietf-acme-caa-08 Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The subject of this document is DNS records describing certificate issuance policies and how the policies can be made more granular through the use of two new parameters: accounturi and validationmethods. The first parameter designates particular accounts that can act as CAs for a domain, the second parameter names the methods that can be used for validation. This version is laudable in its amplification of the security considerations section. Section 5.6 discusses the case in which the CA does not use DNSSEC and is vulnerable to MITM attacks. The final paragraph says that the new parameters are still effective in this case. I do not think that it is the intent of the authors to support the idea of a CA not using DNSSEC, but the text has a positive slant to it, which might be interpreted as a recommendation. Some slight wordsmithing would be helpful. As nearly as I can tell, there are no security problems. The phrase "as such" is used 4 times in section 5. It has no effect on the meaning of the sentence, and I recommend universal deletion. Hilarie From nobody Fri Jun 7 15:31:08 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6A4120114; Fri, 7 Jun 2019 15:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 2lilEG931FAS; Fri, 7 Jun 2019 15:31:04 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D357C1201D3; Fri, 7 Jun 2019 15:31:03 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id o13so3037766lji.5; Fri, 07 Jun 2019 15:31:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=QBjcaJEZF/ZRfuK8pCWRW6yPagMAS7U+hf4nFceMa/U=; b=AtDErEmYP0pvWZ94VFIyQrg07zLlWAsUiucUBMBsXSqvSUa1t+fOmj7ef/y85TxPNn Ksra7deShKkjCuYbe5kxWkQ/Upwj0u4QY1krDBQIbpCScpCpx1QBaVHbKsnsTtd1RT/I pgIvWlu7vF++q+Io3IE4VQ6LbdN0M/VaPI4vHGBEKiHvxXgD6v0GTqANLLdLB3Yb21Ny 6HbVMA8DBCyDSeEZcYHY32aUfvKGNsY84ED8uJ4OSD8ZLRx1ZlODdPhZ5qvgbExwDzNs +2uEiUMRSDifow3AXfx/ZsxJT7uV4ObNa9NAh4DxVyF7l5x6nm2c/2Z0DP4zXk1wXUZl eXSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=QBjcaJEZF/ZRfuK8pCWRW6yPagMAS7U+hf4nFceMa/U=; b=BBm0esJ1qUAqktw5DGbHEboa3E6Zo4dO5vfdV7NOXeZ6zz50bqPnB8OQ4OKq+FdL1A bKhai249YMaJ4XFxP5hGkH90VHgQvbkGhAg7kicfz1BTU8Eyp559UyEbXP9+MWMg5ufs zNz+aJch3Vt9lLpSAv/ffNu9Z9hZmhSYKER3z9Vhi0pJktMirPa+G020XG8e+Ep2o4EG +LrtUgLBTdsdJTTD3KAvwY2LRvL4bTK91dAh+/f4b2eEQfIx+8SOaoHWb75Wh1J4vw6q R+l/RHfdp44KFkOEDzq/1lkFVMjxhulwaOPhmDfCA6G/BKx0ccytzPo/cg8xk7smYRpO r2lg== X-Gm-Message-State: APjAAAUnQ4JjjwkFieNQK6pJYfGlzNeAj2dA5vcRwvESP5kRTiMnwVS2 UbJERYyIrwCL2lH+JIWgXd65FG3nkXmp/660aos= X-Google-Smtp-Source: APXvYqxdV4mnh7nWJWkZtcvhaKZvkonWF9oboI7jSn5/jAWt52NHR2RQmV7mSAQRBoVXnEMBRY7xjhX+NI73Z9gXmCI= X-Received: by 2002:a2e:f1a:: with SMTP id 26mr22346104ljp.37.1559946661898; Fri, 07 Jun 2019 15:31:01 -0700 (PDT) MIME-Version: 1.0 References: <20190605212643.GB15506@pfrc.org> In-Reply-To: <20190605212643.GB15506@pfrc.org> From: Shawn Emery Date: Fri, 7 Jun 2019 16:30:50 -0600 Message-ID: To: Jeffrey Haas Cc: Greg Mirsky , secdir@ietf.org, draft-ietf-bfd-vxlan.all@ietf.org, Shawn Emery Content-Type: multipart/alternative; boundary="000000000000a6b2f5058ac36201" Archived-At: Subject: Re: [secdir] Review of draft-ietf-bfd-vxlan-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2019 22:31:08 -0000 --000000000000a6b2f5058ac36201 Content-Type: text/plain; charset="UTF-8" Comments begin with SME... On Tue, Jun 4, 2019 at 2:40 PM Greg Mirsky wrote: > Hi Shawn, > thank you for the review, clear, directed questions, and helpful > suggestions. Please find answers, notes in-lined and tagged GIM>>. > > Regards, > Greg > > On Fri, May 24, 2019 at 10:45 PM Shawn Emery > wrote: > >> Reviewer: Shawn M. Emery >> Review result: Ready with issues >> >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the IESG. >> These comments were written primarily for the benefit of the security >> area directors. Document editors and WG chairs should treat these >> comments just like any other last call comments. >> >> This draft specifies usage of the Bidirectional Forwarding Detection >> (BFD) protocol on >> Virtual eXtensible Local Area Network (VXLAN) tunnels. >> >> The security considerations section does exist and discusses the >> introduction of a possible >> DDoS attack due to the requirement of the protocol to set the IP TTL to >> one hop. The prescription >> outlined is to throttle this traffic. The section continues that BFD >> sessions should also have an >> upper limit, but does not give guidance on what is considered reasonable >> to where it would affect >> normal traffic vs. some form of DoS. >> > GIM>> The precise number would depend on many factors and thus we only > recommend to have a knob to control the number of BFD sessions between a > pair of VTEPs. Would the updated recommendation on the control of the > number of concurrent sessions between a pair of VTEP as below address your > concern: > OLD TEXT: > The implementation SHOULD have a reasonable upper bound on the number > of BFD sessions that can be created between the same pair of VTEPs. > NEW TEXT: > If the implementation supports establishing multiple BFD sessions > between the same pair of VTEPs, there SHOULD be a mechanism to control > the maximum number of such session that can be active at the same > time. > SME: Yes, I think that this recommendation helps in resolving the issue. > I believe that this section should also document the security >> impact of deploying BFD on VXLANs for monitoring tunnel traffic. Which >> additional information, >> if any, can now be obtained with BFD usage? >> > GIM>> As stated in RFC 5880, BFD is designed to detect failures in the > path between two BFD systems. BFD detects the loss of path continuity > between forwarding engines used by BFD peers that participate in the given > BFD session. As it is defined now, BFD is not used to monitor the tunnel > traffic for possible performance degradation. > SME: OK, I'm fine with the response that no additional information is disclosed that could lead to confidentiality, integrity, or DoS exposure. > >> General comments: >> >> This standards track draft makes a normative reference to the base RFC, >> 7348, which is informational. >> Are there plans of making the base protocol a standards track >> specification? Downward references >> will need to be justified. >> > GIM>> As I understand, it is common practice to introduce to IETF process > a de-facto standard as Informational track document and reference it as the > normative document in a specification on the standard track. The flagged > downref requires manual correction. > SME: OK, I'll let the IESG deal with this aspect of the document. > >> Editorial comments: >> >> NVE is never expanded and not on the RFC Editors Abbreviation List. >> > GIM>> Thank you. Will expand as Network Virtualization Endpoint. > >> >> Echo BFD is out of scope for the document, but does not describe the >> reason for this or why state >> this at all? >> > GIM>> I think that the main reason is that the BFD Echo mode is > underspecified. RFC 5880 defined some of the mechanisms related to the Echo > mode, but more standardization work may be required. > SME: Could you use Jeff's text below to help with why BFD Echo is out of scope for this draft? Thanks, Shawn. -- On Wed, Jun 5, 2019 at 3:25 PM Jeffrey Haas wrote: > On Tue, Jun 04, 2019 at 01:40:33PM -0700, Greg Mirsky wrote: > > > Echo BFD is out of scope for the document, but does not describe the > > > reason for this or why state > > > this at all? > > > > > GIM>> I think that the main reason is that the BFD Echo mode is > > underspecified. RFC 5880 defined some of the mechanisms related to the > Echo > > mode, but more standardization work may be required. > > Speaking as a BFD chair, this is the relevant observation. BFD Echo is > underspecified to the point where claiming compliance is difficult at best. > In general, it relies on single-hop and the ability to have the remote Echo > client loop the packets. > > This packet loop may not be practical for several encapsulations and thus > is > out of scope for such encapsulations. Whether this is practical for vxlan > today, or in the presence of future extensions to vxlan is left out of > scope > for the core proposal. > > -- Jeff > --000000000000a6b2f5058ac36201 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Comments begin with SME...

On Tue, Jun 4, 2019 at 2:4= 0 PM Greg Mirsky <gregimirsky@gmail.com> wrote:
Hi Shawn,
t= hank you for the review, clear, directed questions, and helpful suggestions= . Please find answers, notes in-lined and tagged GIM>>.
Regards,
Greg

On Fri, May 24, 2019 at 10:45 PM S= hawn Emery <s= hawn.emery@gmail.com> wrote:
Reviewer: Shawn M. Emery
Review result:=C2=A0
Ready with issues

I have revi= ewed this document as part of the security directorate's
ongoing effort to r= eview all=C2=A0IETF=C2=A0documents being pro= cessed by the IESG.
These comments were written primarily for the benefit of the= security
area directors. Document editors and WG chairs should treat these
comments = just like any other last call comments.

This draft specifies usage of= the=C2=A0Bidirectional Forwarding=C2=A0Detection (BFD) protocol on
Virtual eXtensible Local Area Networ= k (VXLAN)=C2=A0tunnels.

<= div>
The security considerations section doe= s exist and discusses the introduction of a possible
DDoS=C2=A0attack due to the= requirement of the protocol to set the IP TTL to one hop.=C2=A0 The prescr= iption
outlined is to throttle = this traffic.=C2=A0 The section continues that BFD sessions should also hav= e an
upper limit, but does not give gu= idance on what is considered reasonable to where it would affect
normal traffic vs. some form of DoS.=C2=A0
=
GIM>> The precise number would de= pend on many factors and thus we only recommend to have a knob to control t= he number of BFD sessions between a pair of VTEPs. Would the updated recomm= endation on the control of the number of concurrent sessions between a pair= of VTEP as below address your concern:
OLD TEXT:
= =C2=A0 =C2=A0The implementation SHOULD have a reasonable upper bound on the= number
=C2=A0 =C2=A0of BFD sessions that can be created between the sam= e pair of VTEPs.
NEW TEXT:
=C2=A0 =C2=A0If the impl= ementation supports establishing multiple BFD sessions
=C2=A0 =C2=A0betw= een the same pair of VTEPs, there SHOULD be a mechanism to control
=C2= =A0 =C2=A0the maximum number of such session that can be active at the same=
=C2=A0 =C2=A0time.

<= div>SME: Yes, I think that this recommendation helps in resolving the issue= .
=C2=A0
<= div dir=3D"ltr">
I believe that this section should also document the=C2=A0security
impact of=C2=A0deploying BFD on VXLANs for monitoring tunnel traffic= .=C2=A0 Which additional information,
if any,=C2=A0can now be=C2=A0o= btained with BFD usage?
GIM= >> As stated in RFC 5880, BFD is designed to detect failures in the p= ath between two BFD systems. BFD detects the loss of path continuity betwee= n forwarding engines used by BFD peers that participate in the given BFD se= ssion. As it is defined now, BFD is not used to monitor the tunnel traffic = for possible performance degradation.
SME: OK, I'm fine with the response that no additional inf= ormation is disclosed that could lead to confidentiality, integrity, or DoS= exposure.
=C2=A0

General co= mments:

This standards track draft makes a normative reference to= the base RFC, 7348, which is informational.
Are there plans of= making the base protocol a standards track specification?=C2=A0 Downward r= eferences
will need to be justified.
= GIM>> As I understand, it is common practice to introduce to IETF pro= cess a de-facto standard as Informational track document and reference it a= s the normative document in a specification on the standard track. The flag= ged downref requires manual correction.
=
SME: OK, I'll let the IESG deal with this aspect of the = document.
=C2=A0
=
Editorial comments:
<= /div>

NVE is never expanded and not on the RFC Editors Abb= reviation List.
GIM>> Thank= you. Will expand as=C2=A0Network Virtualization Endpoint.=C2=A0

Echo BFD is out of scope for the document, but does not describe th= e reason for this or why state
= this at all?
GIM>> I think that the main reason is that the BFD Echo m= ode is underspecified. RFC 5880 defined some of the mechanisms related to t= he Echo mode, but more standardization work may be required.

SME: Could you use Jeff's text belo= w to help with why BFD Echo is out of scope for this draft?

<= /div>
Thanks,

Shawn.
--=C2=A0
<= /div>
On We= d, Jun 5, 2019 at 3:25 PM Jeffrey Haas <jhaas@pfrc.org> wrote:
On Tue, Jun 04, 2019 at 01:40:33PM -0700,= Greg Mirsky wrote:
> > Echo BFD is out of scope for the document, but does not describe = the
> > reason for this or why state
> > this at all?
> >
> GIM>> I think that the main reason is that the BFD Echo mode is<= br> > underspecified. RFC 5880 defined some of the mechanisms related to the= Echo
> mode, but more standardization work may be required.

Speaking as a BFD chair, this is the relevant observation.=C2=A0 BFD Echo i= s
underspecified to the point where claiming compliance is difficult at best.=
In general, it relies on single-hop and the ability to have the remote Echo=
client loop the packets.

This packet loop may not be practical for several encapsulations and thus i= s
out of scope for such encapsulations.=C2=A0 Whether this is practical for v= xlan
today, or in the presence of future extensions to vxlan is left out of scop= e
for the core proposal.

-- Jeff
--000000000000a6b2f5058ac36201-- From nobody Fri Jun 7 17:41:53 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F153E120058; Fri, 7 Jun 2019 17:41:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 MKULc7HBDx8u; Fri, 7 Jun 2019 17:41:50 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 729EF12004D; Fri, 7 Jun 2019 17:41:50 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B163D1E2F1; Fri, 7 Jun 2019 20:42:47 -0400 (EDT) Date: Fri, 7 Jun 2019 20:42:47 -0400 From: Jeffrey Haas To: Shawn Emery Cc: Greg Mirsky , secdir@ietf.org, draft-ietf-bfd-vxlan.all@ietf.org, Shawn Emery Message-ID: <20190608004247.GE15506@pfrc.org> References: <20190605212643.GB15506@pfrc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [secdir] Review of draft-ietf-bfd-vxlan-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2019 00:41:52 -0000 Shawn, On Fri, Jun 07, 2019 at 04:30:50PM -0600, Shawn Emery wrote: > SME: Could you use Jeff's text below to help with why BFD Echo is out of > scope for this draft? > [...] > > Speaking as a BFD chair, this is the relevant observation. BFD Echo is > > underspecified to the point where claiming compliance is difficult at best. > > In general, it relies on single-hop and the ability to have the remote Echo > > client loop the packets. > > > > This packet loop may not be practical for several encapsulations and thus > > is > > out of scope for such encapsulations. Whether this is practical for vxlan > > today, or in the presence of future extensions to vxlan is left out of > > scope > > for the core proposal. To ask the question succinctly: Can vxlan support such a packet loop? If not, bfd echo is out of scope. -- Jeff From nobody Sat Jun 8 13:29:07 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 68319120099; Sat, 8 Jun 2019 13:29:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Housley via Datatracker To: Cc: draft-ietf-mmusic-sdp-uks.all@ietf.org, ietf@ietf.org, mmusic@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Russ Housley Message-ID: <156002574538.10095.7918697870650906635@ietfa.amsl.com> Date: Sat, 08 Jun 2019 13:29:05 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-mmusic-sdp-uks-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Jun 2019 20:29:06 -0000 Reviewer: Russ Housley Review result: Has Issues I reviewed this document as part of the Security Directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the Security Area Directors. Document authors, document editors, and WG chairs should treat these comments just like any other IETF Last Call comments. Document: draft-ietf-mmusic-sdp-uks-05 Reviewer: Russ Housley Review Date: 2019-06-08 IETF LC End Date: 2019-06-19 IESG Telechat date: unknown Summary: Has Issues Major Concerns: In Section 2 (and other places), explaining the attack, the authors correctly explain that a malicious participant in a protocol claims to control a key that is in reality controlled by some other actor. The confidentiality and access control implications need to be explained. The malicious actor cannot decrypt the traffic. However, victum may release information to the wrong party because of the authentication failure. Please add text in Section 2, Section 3.1, and Section 4.1 on this topic. In Section 3.2, SHA-256 is the only supported hash function. In some manner algorithm agility needs to be provided. This could be done by using the same hash function as TLS is negotiating elsewhere, by including a hash algorithm identifier, or explicitly stating that a new TLS extension will be defined for use with another hash function if flaws are found in SHA-256. Minor Concerns: The title page header and the Introduction indicate that this document updates RFC 8122, but the Abstract does not mention this. Please add this to the Abstract. In Section 3.2, I think that [SHA] should be an informative reference. If a normative reference for SHA-256 is needed, please cite FIPS 180. Nits: Section 3: I suggested rewording: OLD: Both SIP and WebRTC identity providers are not required to perform this validation. This is not an issue because verifying control of the associated keys is not a necessary condition for a secure protocol, nor would it be sufficient to prevent attack [SIGMA]. NEW: Neither SIP nor WebRTC identity providers are required to perform this validation; however, this is not an issue because verifying control of the associated keys is not a necessary condition for a secure protocol, nor would it be sufficient to prevent attack [SIGMA]. From nobody Sat Jun 8 18:16:05 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8664512011E; Sat, 8 Jun 2019 18:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 oXEvkfmsepVh; Sat, 8 Jun 2019 18:15:45 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B1ED1200B5; Sat, 8 Jun 2019 18:15:45 -0700 (PDT) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x591FeJp068825 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 8 Jun 2019 20:15:41 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1560042943; bh=8fMpHMECg3wL4y3Dozi6O9eTsA9TMdQoYgM/JkpVTo0=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=LN9D0Ay/e7mVwQbRkSe37cGDiMbVRGQkqf07NID38JOuifE3LvjOFlYDnsOjsz3rT fghA4BzXhRSKmTMhOLZIF188fyTeRkLnlZA2vABobx3sAvmim1NGwh4TJAk5LBPOF8 FYYwS/Dymo03Iekmr3M9Zv2t/a39idFz7jimFH/U= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Russ Housley , secdir@ietf.org Cc: draft-ietf-mmusic-sdp-uks.all@ietf.org, ietf@ietf.org, mmusic@ietf.org References: <156002574538.10095.7918697870650906635@ietfa.amsl.com> From: Adam Roach Message-ID: Date: Sat, 8 Jun 2019 20:15:34 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <156002574538.10095.7918697870650906635@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-mmusic-sdp-uks-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2019 01:15:48 -0000 On 6/8/19 3:29 PM, Russ Housley via Datatracker wrote: > In Section 3.2, SHA-256 is the only supported hash function. In some > manner algorithm agility needs to be provided. This could be done by > using the same hash function as TLS is negotiating elsewhere, by > including a hash algorithm identifier, or explicitly stating that a > new TLS extension will be defined for use with another hash function > if flaws are found in SHA-256. Addressing just this point, as I think it was an oversight. Section 3.2 contains the text: >    Note:  Should SHA-256 prove to be inadequate at some point in the >       future (see [AGILITY]), a new TLS extension can be defined that >       uses a different hash function. /a From nobody Sat Jun 8 18:24:41 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44AD3120052; Sat, 8 Jun 2019 18:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.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 es2O7aih4T3y; Sat, 8 Jun 2019 18:24:22 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A06941200C1; Sat, 8 Jun 2019 18:24:22 -0700 (PDT) Received: from MacBook-Pro.roach.at (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x591OJpI070141 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Sat, 8 Jun 2019 20:24:21 -0500 (CDT) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1560043462; bh=7NhwZ618HsxzuEg7X1ArEIdw8bIDvWP3eKm3Hvsmww0=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=lVqm8w0/AU/nws+Mn3Raa7hYdAT9mL+o7s63Ii055E7turTDjziBXUnjMjkYpksH2 3PjJ9YStzWQ01iRuRysNMjHXaHoAQ8+c9sSS9Eu5RDhhv/SDawTBVjpCulgn3co533 Z/1Ti5a8Tsb3VcxZ+i8esSA0lEuHET22cxbTk8uE= X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be MacBook-Pro.roach.at To: Russ Housley , secdir@ietf.org Cc: draft-ietf-mmusic-sdp-uks.all@ietf.org, ietf@ietf.org, mmusic@ietf.org References: <156002574538.10095.7918697870650906635@ietfa.amsl.com> From: Adam Roach Message-ID: <58bd274d-7411-d507-761f-32368874598e@nostrum.com> Date: Sat, 8 Jun 2019 20:24:14 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <156002574538.10095.7918697870650906635@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-mmusic-sdp-uks-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2019 01:24:25 -0000 On 6/8/19 3:29 PM, Russ Housley via Datatracker wrote: > In Section 3.2, I think that [SHA] should be an informative reference. > If a normative reference for SHA-256 is needed, please cite FIPS 180. Russ -- can you explain this suggestion further? RFC 6234 has been in the downref registry [1] since 2013, and is frequently referenced normatively by Standards-Track RFCs. Is there something special about the UKS document that makes this common practice inappropriate for it? To be clear, I specifically considered this reference when processing the UKS document, and believe the second paragraph of section 3 of RFC 3967 to be applicable. /a ____ [1] https://datatracker.ietf.org/doc/downref/ From nobody Mon Jun 10 20:59:50 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFCE1120092; Mon, 10 Jun 2019 20:59:32 -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=lowentropy.net header.b=qVWfTLcL; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=uqZscGUP 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 BCx8LaAI2iIF; Mon, 10 Jun 2019 20:59:30 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F4FA12001A; Mon, 10 Jun 2019 20:59:30 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 6EA7822502; Mon, 10 Jun 2019 23:59:28 -0400 (EDT) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Mon, 10 Jun 2019 23:59:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm2; bh=b6lxHbp0TKVAExiW7wF6xIWKmcYK TChAyLkbQvZ8GCc=; b=qVWfTLcL46FIWKrlPX9kiNXCCZGvX7kIKgeI7qnhaO+r ZYill8khDbQzvEgu0VnReHvzpdep6nUwq9safbkm4ODpLiNepeykYUK6UAxfrPfr FqyvaClxXrrtcJdHZ7ndOspDFFXzPgxggUhUZH6Evkjuo/pPg1A7obcjrKbjOlVy pzBUMev/KLS3pNPsfIT7Gea6XK4n/vnkIMOCMwQzaosz9RcBxGXJ/5fTHg89ngJr 8ERVZAU/oWvnASJoalbhM4I4Skt2aV08R49+l/itQ2lOdi9CQ9iijj+PbbzrSGFW V1IgcjmNm/nNhvetJP4ShDaVloMGwYDH8yw0WT5yLQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=b6lxHb p0TKVAExiW7wF6xIWKmcYKTChAyLkbQvZ8GCc=; b=uqZscGUPy4NV+hBWl55Yxn YRyTsJ20IxoELozV3z/xqBoOcEbiSvdEkYk1AzNIh6xiKBfChNDacNKfvdg+63kP v3iXvE8qvR37+BlweVSoUugZlehPJSb5xYtm+Ms9BMKktV4Ovs4KshqPMJUclJY9 OiQNES+b5hMcNjQjPbPTgh5YSQyWKIg2FrmQobM4tqmvOqY1ModLXZ5Lrg9g4nz3 So2RLyCbanVWJnXAGRJ9lewueDaM6ZFTOVtYexRuqoJ5CR4gs6XLS7FbT6RZ18SX RSa8RRo52yLMjY1cv0onTEJzvGymjP9tgUy54o26EcuvKQ6iE9SSLZRkta19E0Aw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduuddrudehfedgjeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreertdenucfhrhhomhepfdforghr thhinhcuvfhhohhmshhonhdfuceomhhtsehlohifvghnthhrohhphidrnhgvtheqnecuff homhgrihhnpehgihhthhhusgdrtghomhenucfrrghrrghmpehmrghilhhfrhhomhepmhht sehlohifvghnthhrohhphidrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9C59DE00A1; Mon, 10 Jun 2019 23:59:27 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-663-gf46ad30-fmstable-20190607v1 Mime-Version: 1.0 Message-Id: In-Reply-To: <156002574538.10095.7918697870650906635@ietfa.amsl.com> References: <156002574538.10095.7918697870650906635@ietfa.amsl.com> Date: Tue, 11 Jun 2019 13:59:31 +1000 From: "Martin Thomson" To: "Russ Housley" , secdir@ietf.org Cc: draft-ietf-mmusic-sdp-uks.all@ietf.org, ietf@ietf.org, mmusic Content-Type: text/plain Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-mmusic-sdp-uks-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2019 03:59:33 -0000 Thanks Russ! I've staged changes based on your review. You can see those here: https://github.com/martinthomson/sdp-uks/pull/10 On Sun, Jun 9, 2019, at 06:29, Russ Housley via Datatracker wrote: > In Section 2 (and other places), explaining the attack, the authors > correctly explain that a malicious participant in a protocol claims to > control a key that is in reality controlled by some other actor. The > confidentiality and access control implications need to be explained. > The malicious actor cannot decrypt the traffic. However, victum may > release information to the wrong party because of the authentication > failure. Please add text in Section 2, Section 3.1, and Section 4.1 > on this topic. Thanks for catching this. It's definitely an important point. I've added this to S2, and added shorter statements to the other sections. An unknown key-share attack does not result in the attacker having access to any confidential information exchanged between victims. However, the failure in mutual authentication can enable other attacks. A victim might send information to the wrong entity as a result. Where information is interpreted in context, misrepresenting that context could lead to the information being misinterpreted. > In Section 3.2, SHA-256 is the only supported hash function. In some > manner algorithm agility needs to be provided. This could be done by > using the same hash function as TLS is negotiating elsewhere, by > including a hash algorithm identifier, or explicitly stating that a > new TLS extension will be defined for use with another hash function > if flaws are found in SHA-256. As Adam observed, this is mentioned specifically. We discussed this point at some length and the document lists the "new extension" path as a way of addressing the need for agility. > Minor Concerns: > > The title page header and the Introduction indicate that this document > updates RFC 8122, but the Abstract does not mention this. Please add > this to the Abstract. Done. > In Section 3.2, I think that [SHA] should be an informative reference. > If a normative reference for SHA-256 is needed, please cite FIPS 180. Adam covered this, I think. I don't know what the rules are here and will be guided by others. From nobody Tue Jun 11 16:04:36 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7944E1201A1; Tue, 11 Jun 2019 11:58:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1560279497; bh=wWJQZ0afEg4t8/dvjc9D7Vn3JCCJkpu6Hh/0RwCKrec=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=Ih4mSewYwbX4z9XIYQGWekY1IJ/gObrar6rjtOrJszXVCL/1HTaN33rqt7pTAFGe7 HLbg08asOeYwT+UFCuKAQ1aozBUdNamLRyiweJUzh31TOxAW0I+1RIP82mbdbrP0iK 977srMl0J2U7xZljOFxdqlwkRFHqMIwihV7pSWK0= X-Mailbox-Line: From new-work-bounces@ietf.org Tue Jun 11 11:58:17 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D690B120114; Tue, 11 Jun 2019 11:58:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1560279496; bh=/1t4RfYaHvd8p3vcFctqfnPVZcdm+KWSb+pkFjmlW1M=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:Cc; b=cpmxj+9ubTzysmklt4ex3/Tx0P2OAYE5fGV4UTNz4fnHBh9pAcKHS0rVM7tBmm48o YlVPSmkN62tTI3wYypJd2VpizzxsBvXnBOSt2fgF0eriDuOQdfpepm97d0QyJb4eNc J7oCvnyJmD3clMNkDlGkz8fs8J6EMQmCt9KpGWxI= X-Original-To: new-work@ietfa.amsl.com Delivered-To: new-work@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3126A120114 for ; Tue, 11 Jun 2019 11:58:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.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 zjeo44j4J_x2 for ; Tue, 11 Jun 2019 11:58:12 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C47E1200CE for ; Tue, 11 Jun 2019 11:58:12 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id i125so8357067qkd.6 for ; Tue, 11 Jun 2019 11:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version:thread-index :content-language; bh=yw9wuFQZA04kORr8UL6ff+2nbqo3p4H7Zjeca932Hq0=; b=cHv5Le8O2JroYteqmpa9Os3enNVudClYTd6Tlmf62Lgy6D5RRcG+MwxU5Jzoz34CFB g5EGJyW5shTPtLyGz+Ig+zvKnlszm9/12QyIdw8/UTpObRXVKOcJI66yP2AMt+2kWfQu eQ3SXJcKjfVAJcKMzvAMsyjvlm7JM4EFUXSHLJqMInwg9Pg9iR8nDGGRlqOOcY7xaaBX O3XA92l/If2X04sClCzh3D28IMhm8z3pu5WgtkbDgTJsWZjAN4MXnJDYzNhrapwXSFK1 vYqfSBTIAvrSXEuwuowsvhs2NwJoZ5kM2g7hlW1fVJlgacwgG9MlWi4AY8R5yhRV7fgl YOlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :thread-index:content-language; bh=yw9wuFQZA04kORr8UL6ff+2nbqo3p4H7Zjeca932Hq0=; b=K8Vg9VN/Qc6Ecfvzyvf7Ka0Qj1lvO5GfqUviCjupVmZXKNeiGTKx9kmAKdRV/yvXXL T/2yn5Gc7DmIh37hv8HPeliifPLPCxcM9K3hXVKXcp9h43TWBHAbk3xGULZ1kMpk+fZi +xEbG/C46BG7rabwiibX1sZtOZJbYZB2L35Nst6JF8HUb0++yP9ZnmkPl89/POnB4nuz vN5Ra+vuqK7DhPXPC+I2PwBhOVwcPgoQkrXUlxKdFa2KuQQzAYgMiW0kOVKXP4/XqsKk Z5RhJ79M2OVpzLLp+6fd++h6WCM5WDSRU6a9PiNNTkg334GqeKnHvQSKkdLmfclX+Qis z9lg== X-Gm-Message-State: APjAAAWNavHkr7yiOssx/aMMPtIyfh82wo+L6iFL7Sp7+FxC1twltMMa 03HdFDzXLHl3OlzCog3/OxA= X-Google-Smtp-Source: APXvYqxlLs8HueO1uxev4mTspDtPZp/XtfEzvr3EcPFh730ENEnjkYDkVt7ncurFufSzMqNK8XrOBw== X-Received: by 2002:a37:5d44:: with SMTP id r65mr43640624qkb.221.1560279491693; Tue, 11 Jun 2019 11:58:11 -0700 (PDT) Received: from DESKTOP6VF5FH7 ([152.208.106.92]) by smtp.gmail.com with ESMTPSA id l6sm6971611qkf.83.2019.06.11.11.58.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 11 Jun 2019 11:58:11 -0700 (PDT) From: To: Date: Tue, 11 Jun 2019 14:58:10 -0400 Message-ID: <08db01d52087$9e8b9800$dba2c800$@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdUgh5zR4lGKN6YoTei7R0kgLp/0AQ== Content-Language: en-us Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Cc: "'Stanley, Dorothy'" , p.nikolich@ieee.org Content-Type: multipart/mixed; boundary="===============2114375290189598794==" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Tue, 11 Jun 2019 16:04:36 -0700 Subject: [secdir] [new-work] IEEE 802 July 2019 PARs Under Consideration X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2019 18:58:20 -0000 This is a multipart message in MIME format. --===============2114375290189598794== Content-Type: multipart/alternative; boundary="----=_NextPart_000_08DC_01D52066.177B7EA0" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_08DC_01D52066.177B7EA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, The following Project Authorization Requests (PARs) will be considered at the IEEE 802 July 2019 Plenary: * 802.1ABdh -Amendment - Support for Multiframe Protocol Data Units, PAR and CSD * 802.1Qdj - Amendment - Configuration Enhancements, PAR and CSD * 802.1Qcj - Amendment - Automatic Attachment to Provider Backbone Bridging (PBB) services, PAR extension * 802.3cv - Amendment - Maintenance #15: Power over Ethernet, PAR * 802.11ay - Amendment - Enhanced Throughput for Operation in License-Exempt Bands Above 45 GHz, PAR Extension * 802.11az - Amendment - Next Generation Positioning (NGP), PAR Extension 802.15.9ma- Standard, Transport of Key Management Protocol (KMP) Datagram, PAR and CSD The PARs and ICAID can be found at http://www.ieee802.org/PARs.shtml along with the supporting IEEE 802 Criteria for Standards Development, or CSD, (which includes the 5 criteria, i.e. the explanations of how they fit the IEEE 802 criteria for initiating new work). Any comments on a proposed PAR / ICAID should be sent to the Working Group chair identified on the respective document to be received by 6:30 PM CEST, Tuesday, July 16. Regards, John D'Ambrosia Recording Secretary, IEEE 802 LMSC ------=_NextPart_000_08DC_01D52066.177B7EA0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

The following = Project Authorization Requests (PARs) will be considered at the IEEE = 802 July 2019 = Plenary:

  • 802.1ABdh = -Amendment - Support for Multiframe Protocol Data Units,  PAR and CSD
  • 802.1Qdj = - Amendment - Configuration Enhancements, PAR and CSD
  • 802.1Qcj = - Amendment - Automatic Attachment to Provider Backbone Bridging (PBB) = services, PAR extension
  • 802.3cv - = Amendment - Maintenance #15: Power over Ethernet, PAR
  • 802.11ay = - Amendment -  Enhanced Throughput for Operation in License-Exempt = Bands Above 45 GHz, PAR Extension
  • 802.11az - = Amendment - Next Generation Positioning (NGP), PAR Extension = 802.15.9ma- Standard, Transport of Key Management Protocol (KMP) = Datagram,  PAR and CSD

The = PARs and ICAID can be found at http://www.ieee802.org/PARs.shtml = along with the supporting IEEE 802 Criteria for Standards Development, = or CSD, (which includes the 5 criteria, i.e. the explanations of how = they fit the IEEE 802 criteria for initiating new = work).

Any = comments on a proposed PAR / ICAID should be sent to the Working Group = chair identified on the respective document to be received by 6:30 PM = CEST, Tuesday, July 16. 

Regards,

John = D’Ambrosia

Recording Secretary, IEEE 802 LMSC =

 

------=_NextPart_000_08DC_01D52066.177B7EA0-- --===============2114375290189598794== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work --===============2114375290189598794==-- From nobody Sat Jun 15 09:47:28 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FFB612004D; Sat, 15 Jun 2019 09:47:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CK_HELO_DYNAMIC_SPLIT_IP=0.001, CK_HELO_GENERIC=0.249, HELO_MISC_IP=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TVD_RCVD_IP=0.001] autolearn=no autolearn_force=no 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 482r69f5j7U3; Sat, 15 Jun 2019 09:47:18 -0700 (PDT) Received: from 69-77-154-174.static.skybest.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C788712001B; Sat, 15 Jun 2019 09:47:18 -0700 (PDT) Received: from [172.20.3.36] (66-50-27-132.prtc.net [66.50.27.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by 69-77-154-174.static.skybest.com (Postfix) with ESMTPSA id 7BBAE32405; Sat, 15 Jun 2019 12:47:17 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3554.18.2\)) From: Tom Pusateri In-Reply-To: <233D5D9C-F966-4D3D-A06B-841203564C61@bangj.com> Date: Sat, 15 Jun 2019 12:47:16 -0400 Cc: draft-ietf-dnssd-push.all@ietf.org, dnssd@ietf.org, IETF , secdir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <3E95DD9D-9C10-4575-B927-68ECF8E1C41C@bangj.com> References: <155807923913.14794.15819590021470228961@ietfa.amsl.com> <233D5D9C-F966-4D3D-A06B-841203564C61@bangj.com> To: Liang Xia X-Mailer: Apple Mail (2.3554.18.2) Archived-At: Subject: Re: [secdir] [dnssd] Secdir telechat review of draft-ietf-dnssd-push-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2019 16:47:21 -0000 Does this address your concerns? > On May 17, 2019, at 11:59 AM, Tom Pusateri wrote: >=20 > Will also address TLS comments. >=20 >> 3. In the section of Security Considerations: >> 1) you should also mention that TLS provides the anti-replay = protection >> service for DNS Push; I have added a 4th security service in the Security section: Anti-replay protection: TLS provides for the detection of and prevention against messages sent previously over a TLS connection (such as DNS Push Notifications). Prior messages cannot be re- sent at a later time as a form of a man-in-the-middle attack. >> 2) maybe you need to consider the client >> authentication to achieve policy control and detect illegal client; I have added a new paragraph in the Security section: As a consequence of requiring TLS, client certificate authentication and verification may also be enforced by the server for stronger client-server security or end-to-end security. However, recommendations for security in particular deployment scenarios are outside the scope of this document. >> 3) TLS >> WG are specifying the SNI encryption mechanism, will it influence = your TLS >> name authentication? SNI encryption has no effect on our use of TLS name authentication. Thanks, Tom From nobody Sat Jun 15 10:21:26 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CF6B12002F for ; Sat, 15 Jun 2019 10:21:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 AyPc8BEJJO-3 for ; Sat, 15 Jun 2019 10:21:12 -0700 (PDT) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E576D1200B5 for ; Sat, 15 Jun 2019 10:21:09 -0700 (PDT) Received: by mail-qt1-x82b.google.com with SMTP id y57so6261342qtk.4 for ; Sat, 15 Jun 2019 10:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4dCaNZw1sxGBf0ruUELsCrt5oPhqAbeY0QtJLIYR8xU=; b=YCZ3TuVl9kFipgEavgeyJHo+hc65/hMRcaK/2wbOTw+Cy12eWg/8BDx+py16uPP9AT QLrfSXhe0u2/e7869fDvgTaPcE1L95g8wVcYZJc+ehzVQnTvZ4nD10yVTy410KM37RGB hfNQelZPEM3BLimAPCXKjVgcDWUwCEPjLZYZJoGWWHHQeqfqJcYdRKIungKiEr6OR92V By8ZA0MExpSnb8DVQEK20CspZyGOUik6i5p0vAtc0TncPw7wO327yrenFXPGKg1JyFZF sRwwVimpZDFgkQ0U9i6+Bl2hPbN4tBhfTJrxFzEb5jiGYUATlNOHNbUYJkyt3g+j5B9n aMSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=4dCaNZw1sxGBf0ruUELsCrt5oPhqAbeY0QtJLIYR8xU=; b=myyg6r2MBh73suLrdQrOt+O8fdqDpYTk1aKNXE7Bx+g7pZ1XKRIpWfTxuyuF7/Qoq3 tIQ9h46rtTkQnSIdHNuKuFOjKYeZfGdrTb1ytmtFa3C8BtnXDpuKXnOPAWTaoAb8gjEB i4xMEZ7/bHU71TXcF5POr+Wt6pFuxkuZFqCmJIAykb+rNhloNKpWMW3J6MFnR3tktOGR tLWVNmUyCdZDf8uW9kZOcwsjMvwuP+O+9uQmVyMZbGBC/NC3UY5SLa3OI9ajLJE15mrU nf60+RcwxFU/lYsFS6wII0oQASKHOquEtIxb7kQwQ0tIDyIPRE4CxNPHxTFS7o00/ytM 2lkg== X-Gm-Message-State: APjAAAXVnEvfrPAx2mFQ1oR/dqODG7880WOMjgmW9NDtFrsLLAiPASXR ykI8sm0KxXcIQBbY9N0NxoUeo08fu70= X-Google-Smtp-Source: APXvYqzj3s+iK/1/f2K5OAaHI0LK38owYcR4+0t3KF5zxcZgCS0H7XNziqK6Q8Oa2jSAjLL39BV6Xw== X-Received: by 2002:ac8:2809:: with SMTP id 9mr89368109qtq.4.1560619268852; Sat, 15 Jun 2019 10:21:08 -0700 (PDT) Received: from [10.0.30.11] (c-73-186-137-119.hsd1.ma.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id y24sm1089873qty.96.2019.06.15.10.21.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Jun 2019 10:21:08 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Ted Lemon X-Mailer: iPhone Mail (16G48) In-Reply-To: <3E95DD9D-9C10-4575-B927-68ECF8E1C41C@bangj.com> Date: Sat, 15 Jun 2019 13:21:06 -0400 Cc: Liang Xia , draft-ietf-dnssd-push.all@ietf.org, dnssd@ietf.org, IETF , secdir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <155807923913.14794.15819590021470228961@ietfa.amsl.com> <233D5D9C-F966-4D3D-A06B-841203564C61@bangj.com> <3E95DD9D-9C10-4575-B927-68ECF8E1C41C@bangj.com> To: Tom Pusateri Archived-At: Subject: Re: [secdir] [dnssd] Secdir telechat review of draft-ietf-dnssd-push-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2019 17:21:14 -0000 The primary motivation for using tls is opportunistic security. Authenticati= on would be interesting to add. SNI encryption would be interesting but I th= ink is a separate topic.=20 Client authorization might be useful in some cases, but generally is not don= e in DNS servers. To address these would require a security analysis of much= broader scope than is appropriate for this document. We=E2=80=99ve talked a= bout this in the context of homenet.=20 Sent from my iPhone > On Jun 15, 2019, at 12:47 PM, Tom Pusateri wrote: >=20 > Does this address your concerns? >=20 >> On May 17, 2019, at 11:59 AM, Tom Pusateri wrote: >>=20 >> Will also address TLS comments. >>=20 >>> 3. In the section of Security Considerations: >>> 1) you should also mention that TLS provides the anti-replay protection= >>> service for DNS Push; >=20 > I have added a 4th security service in the Security section: >=20 > Anti-replay protection: TLS provides for the detection of and > prevention against messages sent previously over a TLS connection > (such as DNS Push Notifications). Prior messages cannot be re- > sent at a later time as a form of a man-in-the-middle attack. >=20 >>> 2) maybe you need to consider the client >>> authentication to achieve policy control and detect illegal client; >=20 > I have added a new paragraph in the Security section: >=20 > As a consequence of requiring TLS, client certificate authentication > and verification may also be enforced by the server for stronger > client-server security or end-to-end security. However, > recommendations for security in particular deployment scenarios are > outside the scope of this document. >=20 >>> 3) TLS >>> WG are specifying the SNI encryption mechanism, will it influence your T= LS >>> name authentication? >=20 > SNI encryption has no effect on our use of TLS name authentication. >=20 > Thanks, > Tom >=20 >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd From nobody Sat Jun 15 10:34:49 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B95611200B3; Sat, 15 Jun 2019 10:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CK_HELO_DYNAMIC_SPLIT_IP=0.001, CK_HELO_GENERIC=0.249, HELO_MISC_IP=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TVD_RCVD_IP=0.001] autolearn=no autolearn_force=no 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 WYAew6WLjhWL; Sat, 15 Jun 2019 10:34:40 -0700 (PDT) Received: from 69-77-154-174.static.skybest.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53571120075; Sat, 15 Jun 2019 10:34:40 -0700 (PDT) Received: from [172.20.3.36] (66-50-27-132.prtc.net [66.50.27.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by 69-77-154-174.static.skybest.com (Postfix) with ESMTPSA id 191DA32415; Sat, 15 Jun 2019 13:34:39 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3554.18.2\)) From: Tom Pusateri In-Reply-To: Date: Sat, 15 Jun 2019 13:34:38 -0400 Cc: Liang Xia , draft-ietf-dnssd-push.all@ietf.org, dnssd@ietf.org, IETF , secdir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <155807923913.14794.15819590021470228961@ietfa.amsl.com> <233D5D9C-F966-4D3D-A06B-841203564C61@bangj.com> <3E95DD9D-9C10-4575-B927-68ECF8E1C41C@bangj.com> To: Ted Lemon X-Mailer: Apple Mail (2.3554.18.2) Archived-At: Subject: Re: [secdir] [dnssd] Secdir telechat review of draft-ietf-dnssd-push-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2019 17:34:42 -0000 I agree with your comments and think my additional text (in combination = with what was already there) is also in the spirit of your comments and = does not conflict. Are you suggesting there is a conflict? Thanks, Tom > On Jun 15, 2019, at 1:21 PM, Ted Lemon wrote: >=20 > The primary motivation for using tls is opportunistic security. = Authentication would be interesting to add. SNI encryption would be = interesting but I think is a separate topic.=20 >=20 > Client authorization might be useful in some cases, but generally is = not done in DNS servers. To address these would require a security = analysis of much broader scope than is appropriate for this document. = We=E2=80=99ve talked about this in the context of homenet.=20 >=20 > Sent from my iPhone >=20 >> On Jun 15, 2019, at 12:47 PM, Tom Pusateri = wrote: >>=20 >> Does this address your concerns? >>=20 >>> On May 17, 2019, at 11:59 AM, Tom Pusateri = wrote: >>>=20 >>> Will also address TLS comments. >>>=20 >>>> 3. In the section of Security Considerations: >>>> 1) you should also mention that TLS provides the anti-replay = protection >>>> service for DNS Push; >>=20 >> I have added a 4th security service in the Security section: >>=20 >> Anti-replay protection: TLS provides for the detection of and >> prevention against messages sent previously over a TLS connection >> (such as DNS Push Notifications). Prior messages cannot be re- >> sent at a later time as a form of a man-in-the-middle attack. >>=20 >>>> 2) maybe you need to consider the client >>>> authentication to achieve policy control and detect illegal client; >>=20 >> I have added a new paragraph in the Security section: >>=20 >> As a consequence of requiring TLS, client certificate authentication >> and verification may also be enforced by the server for stronger >> client-server security or end-to-end security. However, >> recommendations for security in particular deployment scenarios are >> outside the scope of this document. >>=20 >>>> 3) TLS >>>> WG are specifying the SNI encryption mechanism, will it influence = your TLS >>>> name authentication? >>=20 >> SNI encryption has no effect on our use of TLS name authentication. >>=20 >> Thanks, >> Tom >>=20 >>=20 >> _______________________________________________ >> dnssd mailing list >> dnssd@ietf.org >> https://www.ietf.org/mailman/listinfo/dnssd From nobody Sat Jun 15 10:40:31 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB89120075; Sat, 15 Jun 2019 10:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CK_HELO_DYNAMIC_SPLIT_IP=0.001, CK_HELO_GENERIC=0.249, HELO_MISC_IP=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, TVD_RCVD_IP=0.001] autolearn=no autolearn_force=no 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 MpZFJAOKGTSH; Sat, 15 Jun 2019 10:40:12 -0700 (PDT) Received: from 69-77-154-174.static.skybest.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9855D120052; Sat, 15 Jun 2019 10:40:12 -0700 (PDT) Received: from [172.20.3.36] (66-50-27-132.prtc.net [66.50.27.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by 69-77-154-174.static.skybest.com (Postfix) with ESMTPSA id 57EB332418; Sat, 15 Jun 2019 13:40:11 -0400 (EDT) From: Tom Pusateri Message-Id: <892F5AD2-8012-4127-9BD4-8DA57771E347@bangj.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4AAFBA5B-3A49-4163-BF6E-7FBC42DB0700" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3554.18.2\)) Date: Sat, 15 Jun 2019 13:40:10 -0400 In-Reply-To: Cc: Liang Xia , draft-ietf-dnssd-push.all@ietf.org, dnssd@ietf.org, IETF , secdir@ietf.org To: Ted Lemon References: <155807923913.14794.15819590021470228961@ietfa.amsl.com> <233D5D9C-F966-4D3D-A06B-841203564C61@bangj.com> <3E95DD9D-9C10-4575-B927-68ECF8E1C41C@bangj.com> X-Mailer: Apple Mail (2.3554.18.2) Archived-At: Subject: Re: [secdir] [dnssd] Secdir telechat review of draft-ietf-dnssd-push-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2019 17:40:15 -0000 --Apple-Mail=_4AAFBA5B-3A49-4163-BF6E-7FBC42DB0700 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 By the way, you can see the updated version in context here (ignore the = date): https://github.com/pusateri/draft-ietf-dnssd-push = Thanks, Tom > On Jun 15, 2019, at 1:34 PM, Tom Pusateri wrote: >=20 > I agree with your comments and think my additional text (in = combination with what was already there) is also in the spirit of your = comments and does not conflict. Are you suggesting there is a conflict? >=20 > Thanks, > Tom >=20 >> On Jun 15, 2019, at 1:21 PM, Ted Lemon wrote: >>=20 >> The primary motivation for using tls is opportunistic security. = Authentication would be interesting to add. SNI encryption would be = interesting but I think is a separate topic.=20 >>=20 >> Client authorization might be useful in some cases, but generally is = not done in DNS servers. To address these would require a security = analysis of much broader scope than is appropriate for this document. = We=E2=80=99ve talked about this in the context of homenet.=20 >>=20 >> Sent from my iPhone >>=20 >>> On Jun 15, 2019, at 12:47 PM, Tom Pusateri = wrote: >>>=20 >>> Does this address your concerns? >>>=20 >>>> On May 17, 2019, at 11:59 AM, Tom Pusateri = wrote: >>>>=20 >>>> Will also address TLS comments. >>>>=20 >>>>> 3. In the section of Security Considerations: >>>>> 1) you should also mention that TLS provides the anti-replay = protection >>>>> service for DNS Push; >>>=20 >>> I have added a 4th security service in the Security section: >>>=20 >>> Anti-replay protection: TLS provides for the detection of and >>> prevention against messages sent previously over a TLS connection >>> (such as DNS Push Notifications). Prior messages cannot be re- >>> sent at a later time as a form of a man-in-the-middle attack. >>>=20 >>>>> 2) maybe you need to consider the client >>>>> authentication to achieve policy control and detect illegal = client; >>>=20 >>> I have added a new paragraph in the Security section: >>>=20 >>> As a consequence of requiring TLS, client certificate authentication >>> and verification may also be enforced by the server for stronger >>> client-server security or end-to-end security. However, >>> recommendations for security in particular deployment scenarios are >>> outside the scope of this document. >>>=20 >>>>> 3) TLS >>>>> WG are specifying the SNI encryption mechanism, will it influence = your TLS >>>>> name authentication? >>>=20 >>> SNI encryption has no effect on our use of TLS name authentication. >>>=20 >>> Thanks, >>> Tom >>>=20 >>>=20 >>> _______________________________________________ >>> dnssd mailing list >>> dnssd@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnssd >=20 --Apple-Mail=_4AAFBA5B-3A49-4163-BF6E-7FBC42DB0700 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 By = the way, you can see the updated version in context here (ignore the = date):


Thanks,
Tom

On Jun 15, 2019, at 1:34 PM, Tom Pusateri = <pusateri@bangj.com> wrote:

I = agree with your comments and think my additional text (in combination = with what was already there) is also in the spirit of your comments and = does not conflict. Are you suggesting there is a conflict?

Thanks,
Tom

On Jun 15, 2019, at 1:21 = PM, Ted Lemon <mellon@fugue.com> wrote:

The primary motivation for using tls is opportunistic = security. Authentication would be interesting to add. SNI encryption = would be interesting but I think is a separate topic.

Client authorization might be useful in some cases, but = generally is not done in DNS servers. To address these would require a = security analysis of much broader scope than is appropriate for this = document. We=E2=80=99ve talked about this in the context of homenet.

Sent from my iPhone

On Jun 15, 2019, at = 12:47 PM, Tom Pusateri <pusateri@bangj.com> wrote:

Does this address your concerns?

On May 17, 2019, at = 11:59 AM, Tom Pusateri <pusateri@bangj.com> wrote:

Will also address TLS comments.

3. In the section of = Security Considerations:
1) you should also mention that = TLS provides the anti-replay protection
service for DNS = Push;

I have = added a 4th security service in the Security section:

Anti-replay protection:  TLS provides for the detection = of and
   prevention against messages sent = previously over a TLS connection
   (such = as DNS Push Notifications).  Prior messages cannot be re-
   sent at a later time as a form of a = man-in-the-middle attack.

2) maybe = you need to consider the client
authentication to achieve = policy control and detect illegal client;

I have added a new = paragraph in the Security section:

As a = consequence of requiring TLS, client certificate authentication
and verification may also be enforced by the server for = stronger
client-server security or end-to-end security. =  However,
recommendations for security in particular = deployment scenarios are
outside the scope of this = document.

3) TLS
WG = are specifying the SNI encryption mechanism, will it influence your = TLS
name authentication?

SNI encryption has = no effect on our use of TLS name authentication.

Thanks,
Tom


_______________________________________________
dnssd mailing list
dnssd@ietf.org
https://www.ietf.org/mailman/listinfo/dnssd


= --Apple-Mail=_4AAFBA5B-3A49-4163-BF6E-7FBC42DB0700-- From nobody Sat Jun 15 10:43:43 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AAF0120052 for ; Sat, 15 Jun 2019 10:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.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 0xhqGZpTcC0S for ; Sat, 15 Jun 2019 10:43:25 -0700 (PDT) Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E01D1200B9 for ; Sat, 15 Jun 2019 10:43:23 -0700 (PDT) Received: by mail-qk1-x72b.google.com with SMTP id m14so3757926qka.10 for ; Sat, 15 Jun 2019 10:43:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=L6JkDM0c7cg50KHUlIW4+W16hKht+6/B0J+vQbTEtuE=; b=dfnJa9AQchq4U9iZfyZ0DTKJjEola7ve+M6XMzsuqYmmC4BzOvZCdKxJIsw0SYQXzF ksUeHqYjD/ZhuFbxBOaMr0c6gS87alfiTRxauazhqhnYyiDSfDxI+DfV3U1JvXryYO2u o/R+x5qGqTl7psayYRgGZu+yBTlvIJB0OYf6XOX75n+9jxFd9gMjeXXIK5SS/NDiCjCx JgEJYsufJ0Fu5INC0pixgf1OwzAgIobWCB8MQipholYNhbvTCtD7z5V4S8ItEJe+90Ql 8/mlRbRp7iXwSSZXFW6N489KjyOfk2mfLJ3bY0AsnV4R8H0gqOaUvitMIne+de9xEUhq F0KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=L6JkDM0c7cg50KHUlIW4+W16hKht+6/B0J+vQbTEtuE=; b=fgM8yzTneruUmhU0YQ6FQrbZ1VsNLskp6tG0OcDuaSKIXOJGd2Z78hZrmZGD2/ixcF /kEjWwkAQqjMHlf9NBiVFV6lxGT3EDJDmAcAAu1rieEdQbYW8UN9WeXhDffqcadD0xp7 iGicqAv3EhxVDQVV3svlUl4gzGzBn4r3DsXsjMTKXyiPHFoBkon7jMQNo47VF+poBbT9 0oH9uYSVJsZTv2kbc5rcpTuDX2Y584/cOjRujjMVopCkAqihfNwX4uQbjWSzCwo9RqEm 7+3B/gepBWEnOCkHsQja3aw4aaJdIwcxqTjq02GrV4IhmnYNDJdmmmIBvTAgWL4V1479 DYNQ== X-Gm-Message-State: APjAAAWFpyEjmNomBWZwGVck7ZEBtzvFLJPTTFJANRaZqkkd9L+UovZ6 Ei4XB08ZFG7zggO2WVCkG/q7Ifp6cbY= X-Google-Smtp-Source: APXvYqxduMz/F4VLBvCq/u8InKOsH++SzrIXasMbWzAYZHKqluiJ/Q5CviuyBsxyY6z7rDIGQCKxIg== X-Received: by 2002:a05:620a:124c:: with SMTP id a12mr82150473qkl.336.1560620601971; Sat, 15 Jun 2019 10:43:21 -0700 (PDT) Received: from [10.0.30.11] (c-73-186-137-119.hsd1.ma.comcast.net. [73.186.137.119]) by smtp.gmail.com with ESMTPSA id k7sm2766294qth.88.2019.06.15.10.43.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 15 Jun 2019 10:43:21 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Ted Lemon X-Mailer: iPhone Mail (16G48) In-Reply-To: Date: Sat, 15 Jun 2019 13:43:20 -0400 Cc: Liang Xia , draft-ietf-dnssd-push.all@ietf.org, dnssd@ietf.org, IETF , secdir@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <155807923913.14794.15819590021470228961@ietfa.amsl.com> <233D5D9C-F966-4D3D-A06B-841203564C61@bangj.com> <3E95DD9D-9C10-4575-B927-68ECF8E1C41C@bangj.com> To: Tom Pusateri Archived-At: Subject: Re: [secdir] [dnssd] Secdir telechat review of draft-ietf-dnssd-push-19 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2019 17:43:28 -0000 No, just chiming in. This was something I had to think about during the impl= ementation, so it=E2=80=99s familiar territory.=20 Sent from my iPhone > On Jun 15, 2019, at 1:34 PM, Tom Pusateri wrote: >=20 > I agree with your comments and think my additional text (in combination wi= th what was already there) is also in the spirit of your comments and does n= ot conflict. Are you suggesting there is a conflict? >=20 > Thanks, > Tom >=20 >> On Jun 15, 2019, at 1:21 PM, Ted Lemon wrote: >>=20 >> The primary motivation for using tls is opportunistic security. Authentic= ation would be interesting to add. SNI encryption would be interesting but I= think is a separate topic.=20 >>=20 >> Client authorization might be useful in some cases, but generally is not d= one in DNS servers. To address these would require a security analysis of mu= ch broader scope than is appropriate for this document. We=E2=80=99ve talked= about this in the context of homenet.=20 >>=20 >> Sent from my iPhone >>=20 >>> On Jun 15, 2019, at 12:47 PM, Tom Pusateri wrote: >>>=20 >>> Does this address your concerns? >>>=20 >>>> On May 17, 2019, at 11:59 AM, Tom Pusateri wrote: >>>>=20 >>>> Will also address TLS comments. >>>>=20 >>>>> 3. In the section of Security Considerations: >>>>> 1) you should also mention that TLS provides the anti-replay protectio= n >>>>> service for DNS Push; >>>=20 >>> I have added a 4th security service in the Security section: >>>=20 >>> Anti-replay protection: TLS provides for the detection of and >>> prevention against messages sent previously over a TLS connection >>> (such as DNS Push Notifications). Prior messages cannot be re- >>> sent at a later time as a form of a man-in-the-middle attack. >>>=20 >>>>> 2) maybe you need to consider the client >>>>> authentication to achieve policy control and detect illegal client; >>>=20 >>> I have added a new paragraph in the Security section: >>>=20 >>> As a consequence of requiring TLS, client certificate authentication >>> and verification may also be enforced by the server for stronger >>> client-server security or end-to-end security. However, >>> recommendations for security in particular deployment scenarios are >>> outside the scope of this document. >>>=20 >>>>> 3) TLS >>>>> WG are specifying the SNI encryption mechanism, will it influence your= TLS >>>>> name authentication? >>>=20 >>> SNI encryption has no effect on our use of TLS name authentication. >>>=20 >>> Thanks, >>> Tom >>>=20 >>>=20 >>> _______________________________________________ >>> dnssd mailing list >>> dnssd@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnssd >=20 From nobody Mon Jun 17 09:04:32 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5831202C6; Mon, 17 Jun 2019 09:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.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 nRPDqsfbpvU4; Mon, 17 Jun 2019 09:04:28 -0700 (PDT) Received: from mail-vs1-xe2d.google.com (mail-vs1-xe2d.google.com [IPv6:2607:f8b0:4864:20::e2d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 524911202DF; Mon, 17 Jun 2019 09:04:23 -0700 (PDT) Received: by mail-vs1-xe2d.google.com with SMTP id 190so6450986vsf.9; Mon, 17 Jun 2019 09:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2CNVjeEokIn1F/ibRD6MNIkwo35+rXUvXxaB2U7R5x4=; b=px6vSa36qveaLC7cVURcQILjfVH1J3HwquIXSy9HDLnuq85wyFPX60W1GFwBzD92o0 hyaasIUCkfa3mmorFYKCebFrBvdS3Nd9neYbffxotrOFm7q1zVbS0wpbfslcSr6EnCGx LkmY3u1badSta2I1QrzGU8DGAG1+kwBW+VnyYavlXnHX1hDJ5FyhDYxiCVCNPCkDNMUr hKBkNrTVAcxdbB/wzn5u8iMQlib1r1rcb69QBvFxnzCT1yMqr4b+gFm3b9OpQ8rnSf7m hSKxqn2S0m/UQlZh8ZVCKe4hxHOuopz8qgkc1NxxIbyZw/7YIrqFBcpNZVzD8yL1+1YY CFQA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2CNVjeEokIn1F/ibRD6MNIkwo35+rXUvXxaB2U7R5x4=; b=hLt/3Va1/cBLuxG+fbPg6i5bi0qVMAy8OPOS+hCvGmdDbdNgIQkR7tDUUcHX3s6GrV XPwWPMiA87Kki+CqD2beeOEHe61aZY0cP00PocfjBI/7yljbJbIYjd+QsP2B1X07o+Y3 P9CNvoL8fIYXdh6CfuJz80BmppMKvi4ZZTRNFwhdwf1Mnxrz+TRgawQjF48JRJTaXJq3 9OyJy9yHzLch3sb/RjHGwP9b7aRCpEkWtVSaKYftCxSCii1VGvTIfo30kC+V1+5PSAsf cVay/KZv9znuLK53VB310JFZb4KePR8SdwuZnQPUxM+deqMVdh0aui++TgobTQkagoWv /Wdw== X-Gm-Message-State: APjAAAWpmyaCcoIyi9dL59wGG9kc/BSEj2vjYcmO80SAw7M65IBBEo/m wnYDdvE/TZv2V6uur/c3yWcMlO4lwnMpT17xl4o= X-Google-Smtp-Source: APXvYqxsJ5k9wgrWuBSi0M1XQg23BgXTuhY1ynZIT+IYM2+URTzyQU0pDvx6t+Qrx4Tw+e6xZ5dun6cA+g3/37+9/UA= X-Received: by 2002:a67:7d83:: with SMTP id y125mr25936498vsc.126.1560787462296; Mon, 17 Jun 2019 09:04:22 -0700 (PDT) MIME-Version: 1.0 References: <155900970362.650.8194184838834826261@ietfa.amsl.com> In-Reply-To: <155900970362.650.8194184838834826261@ietfa.amsl.com> From: Andy Hutton Date: Mon, 17 Jun 2019 17:04:15 +0100 Message-ID: To: Sean Turner Cc: secdir@ietf.org, sipbrandy@ietf.org, draft-ietf-sipbrandy-osrtp.all@ietf.org, ietf@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [secdir] [Sipbrandy] Secdir last call review of draft-ietf-sipbrandy-osrtp-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2019 16:04:30 -0000 Thanks for the comments, see below. Andy On Tue, 28 May 2019 at 03:15, Sean Turner via Datatracker wrote: > > Reviewer: Sean Turner > Review result: Has Issues > > I had a read of the draft as well as the GENART and TSVART reviews (to avoid > duplicating comments). > > Summary: Ready with (minor) issues > > Issues: > > 0) I assume that the mismatch the TSVART refers to in the security > considerations has to do with 1) changing 4568 to require encryption but not > fail if authentication is not available, 2) pointing out that 4568's > requirement is routinely ignore for end-to-end encryption because using TLS > with intermediaries won't protect the SDP key, and 3) and reference errors (see > the next issue). On 1, that's kind the point of OSRTP - take the encryption > you can get. On 2, because it's the security considerations this document is > just saying don't expect to get end-to-end. Assuming, I've interpreted this I > think this draft is okay. > > 1) I think these are just reference errors, but it would be good to double > check these (and I hadn't seen a response yet - might have missed it): > > S4: Not sure about these references too RFC7435. Maybe they should be to RFC > 4568 instead? > > s/The security considerations of [RFC7435] apply to OSRTP, > /The security considerations of [RFC4568] apply to OSRTP, > > s/Section 8.3 of [RFC7435]/Section 8.3 of [RFC4568] > > s/understood that the [RFC7435]/understood that the [RFC4568] > Yes these are reference errors and I will fix as you describe. > Bikesheds: > > 0) The fact that it's Informational struck me as odd. > > 1) The fact there are no updates listed also strikes me as odd. > Ben Campbell gave the answer to this in his mail on 28th May it is a very long story and we were made to jump through many hoops and and in the end this is what had to be done. > Nits: > > 0) s2: Nits reports an error with the para. I think it's: > > s/RFC 2119 [RFC2119] RFC 8174 [RFC8174] > /RFC 2119 [RFC2119] [RFC8174] > > 1) s1, 2nd para: s/[RFC5939] ./[RFC5939]. Thanks. > > _______________________________________________ > Sipbrandy mailing list > Sipbrandy@ietf.org > https://www.ietf.org/mailman/listinfo/sipbrandy From nobody Mon Jun 17 18:39:55 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 982B3120179; Mon, 17 Jun 2019 18:39:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Christian Huitema via Datatracker To: Cc: draft-ietf-mpls-egress-protection-framework.all@ietf.org, ietf@ietf.org, mpls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Christian Huitema Message-ID: <156082197755.22389.14803953372788869090@ietfa.amsl.com> Date: Mon, 17 Jun 2019 18:39:37 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-mpls-egress-protection-framework-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2019 01:39:38 -0000 Reviewer: Christian Huitema Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I think the document is almost ready, although I would like some considerations of a potential attack through the customer equipment. I reviewed draft-ietf-mpls-egress-protection-framework-05, MPLS Egress Protection Framework. The document specifies a framework for implementing protection of an MPLS tunnel against failure of the egress router or the egress link. The implementation of the framework relies on the control functions of the MPLS network, and the security considerations correctly state that the security of the implementation relies on the security of these protocols. The security consideration also point out the need for special establishment of trust if the nodes involved are not under the same administrative authority. These general security considerations are correct, but I am concerned that the egress links between the MPLS network routers and the customer could also become a point of attack. Attackers that gain control of a customer's equipment might use it to simulate link failures and trigger the backup mechanism. They could do so in a coordinated fashion across a large number of customer equipments, to try overload the control plane or try create cascading effects in the network. It may well be that in the absence of the local backup mechanism, the attackers could mount the same type of attack and trigger an other type of control plane activity. The defenses against that might also defend against the attack listed in the previous paragraph. But it might be good to state it. From nobody Sat Jun 22 01:44:16 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 68E40120026 for ; Sat, 22 Jun 2019 01:44:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <156119305435.16383.1448658890326827009.idtracker@ietfa.amsl.com> Date: Sat, 22 Jun 2019 01:44:14 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2019 08:44:15 -0000 [I am on vacation now, so my assignments might come bit irregularly, so be time to do reviews might be bit shorter than normally. Also remember to go and mark your vacation times to the datatracker (end of https://datatracker.ietf.org/accounts/review/ page) so you will not be assigned documents during your vacation.] Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-06-27 Reviewer LC end Draft Roman Danyliw 2019-06-04 draft-ietf-rtgwg-enterprise-pa-multihoming-08 Brian Weis R2019-05-21 draft-ietf-roll-efficient-npdao-12 Last calls: Reviewer LC end Draft Nancy Cam-Winget 2019-06-04 draft-ietf-sipcore-rejected-08 Shaun Cooley 2019-03-13 draft-ietf-dots-data-channel-29 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Daniel Gillmor 2018-03-19 draft-gutmann-scep-14 Leif Johansson 2019-07-08 draft-ietf-manet-dlep-latency-extension-04 Charlie Kaufman 2019-07-04 draft-ietf-babel-rfc6126bis-10 Scott Kelly 2019-07-04 draft-ietf-babel-applicability-06 Watson Ladd 2019-07-03 draft-ietf-lamps-cms-shakes-11 Chris Lonvick 2019-06-28 draft-ietf-v6ops-nat64-deployment-06 Aanchal Malhotra 2019-06-26 draft-ietf-ipwave-ipv6-over-80211ocb-46 David Mandelberg 2019-06-26 draft-ietf-6tisch-architecture-21 Catherine Meadows 2019-06-25 draft-ietf-grow-bmp-adj-rib-out-05 Catherine Meadows 2019-04-12 draft-ietf-mmusic-rfc4566bis-36 Daniel Migault 2019-07-03 draft-ietf-lamps-cms-shakes-11 Matthew Miller 2019-07-04 draft-ietf-intarea-frag-fragile-12 Matthew Miller 2019-04-08 draft-ietf-core-multipart-ct-03 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-08 Robert Sparks R2019-07-04 draft-ietf-babel-hmac-07 Sean Turner R2019-07-04 draft-ietf-babel-dtls-05 David Waltermire 2019-02-15 draft-ietf-rtcweb-ip-handling-11 Klaas Wierenga 2019-02-26 draft-ietf-mpls-sr-over-ip-07 Christopher Wood 2019-05-28 draft-ietf-tram-turnbis-25 Liang Xia R2019-07-05 draft-ietf-dnssd-push-20 Taylor Yu 2019-02-15 draft-ietf-rtcweb-security-arch-18 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-12 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Kathleen Moriarty 2019-04-08 draft-ietf-bmwg-ngfw-performance-00 Next in the reviewer rotation: Adam Montville Kathleen Moriarty Russ Mundy Sandra Murphy Yoav Nir Magnus Nystrom Hilarie Orman Radia Perlman Derrell Piper Tim Polk From nobody Sat Jun 22 09:52:03 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CFAD120048; Sat, 22 Jun 2019 09:52:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Watson Ladd via Datatracker To: Cc: spasm@ietf.org, draft-ietf-lamps-cms-shakes.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Watson Ladd Message-ID: <156122232142.16338.1971827361341363218@ietfa.amsl.com> Date: Sat, 22 Jun 2019 09:52:01 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-lamps-cms-shakes-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2019 16:52:02 -0000 Reviewer: Watson Ladd Review result: Ready I have looked at this document as part of the secdir LC review and it looks fine. From nobody Sun Jun 23 18:22:20 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB31120274 for ; Sun, 23 Jun 2019 18:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mandelberg.org 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 mIg7D22I-deB for ; Sun, 23 Jun 2019 18:22:12 -0700 (PDT) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 25FFF120277 for ; Sun, 23 Jun 2019 18:22:11 -0700 (PDT) X_CMAE_Category: , , X-CNFS-Analysis: v=2.2 cv=R/9BIpZX c=1 sm=1 tr=0 a=OXtaa+9CFT7WVSERtyqzJw==:117 a=OXtaa+9CFT7WVSERtyqzJw==:17 a=KGjhK52YXX0A:10 a=IkcTkHD0fZMA:10 a=NTnny0joGdQA:10 a=dq6fvYVFJ5YA:10 a=bmmO2AaSJ7QA:10 a=TPLd9O6Y13ttJ8cbTIcA:9 a=QEXdDO2ut3YA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: ZHNlb21uQHJjbi5jb20= Authentication-Results: smtp02.rcn.cmh.synacor.com header.DKIM-Signature=@mandelberg.org; dkim=pass Authentication-Results: smtp02.rcn.cmh.synacor.com header.from=david@mandelberg.org; sender-id=softfail Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.mail=david@mandelberg.org; spf=softfail; sender-id=softfail Authentication-Results: smtp02.rcn.cmh.synacor.com smtp.user=dseomn@rcn.com; auth=pass (LOGIN) Received: from [209.6.43.168] ([209.6.43.168:57666] helo=uriel.mandelberg.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=DHE-RSA-AES256-GCM-SHA384) id C5/8D-10370-0C5201D5; Sun, 23 Jun 2019 21:22:08 -0400 Received: from [192.168.1.152] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 96ACE1C6033; Sun, 23 Jun 2019 21:22:07 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mandelberg.org; s=201903; t=1561339327; bh=vKvzmMyf+feWiGZawMkmTKLriSf5CnXz7BniIuGDAzc=; h=To:From:Subject:Date:From; b=YjY597BJ8SQpV+MRulGR7doCz0jqRbL53xlqbsqK1/E1Nkd44aYbNCz3iaMW0LdX9 PiAqgWXJ7hG23baBC5Eu+5WUH87JiVNtWKKPMlM7xY3pWjvbdxmjWpn2DoTdIV2KTm ljKlWtDx4HPvwRemFCuEMiA5osbmYTC/xoRlp09JLycz+Npg3NNZoJnGLNw9V/RE7v Ox4YQ09rrYHYFU7MyC+AwjuNUPsSiH2GMGG8oSOq6QhKO7rW5dUfEaUGZkET2RrKM3 cav1I755pnUPK3C8ThnTKLKjFWlshwIikFXGqS+b/62H6pVmDfNCjPJbpvCShpu7FQ RwI5ntMr2rYFw== To: secdir@ietf.org, iesg@ietf.org, draft-ietf-6tisch-architecture.all@ietf.org From: David Mandelberg Message-ID: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> Date: Sun, 23 Jun 2019 21:22:05 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [secdir] secdir review of draft-ietf-6tisch-architecture-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 01:22:13 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready with nits. The review deadline for this was really short, so I didn't have a chance to read this as closely as I would have liked. That said, from skimming the document and reading the sections that looked most interesting, it looks pretty good. The security considerations section covers what I expected it to. I have only one question/concern: Sections 4.2.1 and 4.3.4 talk about the security of joining a network, and time synchronization, respectively. Do any of the security mechanisms in 4.2.1 rely on having an accurate clock? (E.g., to distrust old/expired keys.) Is time synchronization done before the join process, and is there any way to exploit time synchronization in order to cause a node to join a malicious network? From nobody Mon Jun 24 00:55:21 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314721200EB; Mon, 24 Jun 2019 00:55:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 NKNGkm7G0tzL; Mon, 24 Jun 2019 00:55:04 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 1C2B5120088; Mon, 24 Jun 2019 00:55:04 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id C4498432CF4F5A995E43; Mon, 24 Jun 2019 08:55:01 +0100 (IST) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 24 Jun 2019 08:55:01 +0100 Received: from DGGEMM511-MBX.china.huawei.com ([169.254.1.140]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0439.000; Mon, 24 Jun 2019 15:53:58 +0800 From: "Xialiang (Frank, Network Standard & Patent Dept)" To: Tom Pusateri CC: "draft-ietf-dnssd-push.all@ietf.org" , "dnssd@ietf.org" , IETF , "secdir@ietf.org" Thread-Topic: [dnssd] Secdir telechat review of draft-ietf-dnssd-push-19 Thread-Index: AQHVDMmJ76Sy5YjtmUawwK/ZaNP/bKaclEoAgA4VfBA= Date: Mon, 24 Jun 2019 07:53:58 +0000 Message-ID: References: <155807923913.14794.15819590021470228961@ietfa.amsl.com> <233D5D9C-F966-4D3D-A06B-841203564C61@bangj.com> <3E95DD9D-9C10-4575-B927-68ECF8E1C41C@bangj.com> In-Reply-To: <3E95DD9D-9C10-4575-B927-68ECF8E1C41C@bangj.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.159.76] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [secdir] =?gb2312?b?tPC4tDogW2Ruc3NkXSBTZWNkaXIgdGVsZWNoYXQgcmV2?= =?gb2312?b?aWV3IG9mIGRyYWZ0LWlldGYtZG5zc2QtcHVzaC0xOQ==?= X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 07:55:06 -0000 SGkgVG9tLA0KU29ycnkgZm9yIHJlc3BvbmRpbmcgeW91ciByZXNwb25zZSBlbWFpbCBwcm9tcHRs eS4NCg0KSSBoYXZlIGNoZWNrZWQgdGhlIGxhdGVzdCB2ZXJzaW9uIC0yMCBkcmFmdCwgYW5kIHRo b3VnaHQgaXQgaGF2ZSBhZGRyZXNzZWQgYWxsIG15IHNlY3VyaXR5IGlzc3Vlcy4NClRoYW5rcyEN Cg0KQi5SLg0KRnJhbmsNCg0KDQotLS0tLdPKvP7Urbz+LS0tLS0NCreivP7IyzogVG9tIFB1c2F0 ZXJpIFttYWlsdG86cHVzYXRlcmlAYmFuZ2ouY29tXSANCreiy83KsbzkOiAyMDE5xOo21MIxNsjV IDA6NDcNCsrVvP7IyzogWGlhbGlhbmcgKEZyYW5rLCBOZXR3b3JrIFN0YW5kYXJkICYgUGF0ZW50 IERlcHQpIDxmcmFuay54aWFsaWFuZ0BodWF3ZWkuY29tPg0Ks63LzTogZHJhZnQtaWV0Zi1kbnNz ZC1wdXNoLmFsbEBpZXRmLm9yZzsgZG5zc2RAaWV0Zi5vcmc7IElFVEYgPGlldGZAaWV0Zi5vcmc+ OyBzZWNkaXJAaWV0Zi5vcmcNCtb3zOI6IFJlOiBbZG5zc2RdIFNlY2RpciB0ZWxlY2hhdCByZXZp ZXcgb2YgZHJhZnQtaWV0Zi1kbnNzZC1wdXNoLTE5DQoNCkRvZXMgdGhpcyBhZGRyZXNzIHlvdXIg Y29uY2VybnM/DQoNCj4gT24gTWF5IDE3LCAyMDE5LCBhdCAxMTo1OSBBTSwgVG9tIFB1c2F0ZXJp IDxwdXNhdGVyaUBiYW5nai5jb20+IHdyb3RlOg0KPiANCj4gV2lsbCBhbHNvIGFkZHJlc3MgVExT IGNvbW1lbnRzLg0KPiANCj4+IDMuIEluIHRoZSBzZWN0aW9uIG9mIFNlY3VyaXR5IENvbnNpZGVy YXRpb25zOg0KPj4gICAxKSB5b3Ugc2hvdWxkIGFsc28gbWVudGlvbiB0aGF0IFRMUyBwcm92aWRl cyB0aGUgYW50aS1yZXBsYXkgcHJvdGVjdGlvbg0KPj4gICBzZXJ2aWNlIGZvciBETlMgUHVzaDsN Cg0KSSBoYXZlIGFkZGVkIGEgNHRoIHNlY3VyaXR5IHNlcnZpY2UgaW4gdGhlIFNlY3VyaXR5IHNl Y3Rpb246DQoNCkFudGktcmVwbGF5IHByb3RlY3Rpb246ICBUTFMgcHJvdmlkZXMgZm9yIHRoZSBk ZXRlY3Rpb24gb2YgYW5kDQogICAgICBwcmV2ZW50aW9uIGFnYWluc3QgbWVzc2FnZXMgc2VudCBw cmV2aW91c2x5IG92ZXIgYSBUTFMgY29ubmVjdGlvbg0KICAgICAgKHN1Y2ggYXMgRE5TIFB1c2gg Tm90aWZpY2F0aW9ucykuICBQcmlvciBtZXNzYWdlcyBjYW5ub3QgYmUgcmUtDQogICAgICBzZW50 IGF0IGEgbGF0ZXIgdGltZSBhcyBhIGZvcm0gb2YgYSBtYW4taW4tdGhlLW1pZGRsZSBhdHRhY2su DQoNCj4+IDIpIG1heWJlIHlvdSBuZWVkIHRvIGNvbnNpZGVyIHRoZSBjbGllbnQNCj4+ICAgYXV0 aGVudGljYXRpb24gdG8gYWNoaWV2ZSBwb2xpY3kgY29udHJvbCBhbmQgZGV0ZWN0IGlsbGVnYWwg Y2xpZW50Ow0KDQpJIGhhdmUgYWRkZWQgYSBuZXcgcGFyYWdyYXBoIGluIHRoZSBTZWN1cml0eSBz ZWN0aW9uOg0KDQpBcyBhIGNvbnNlcXVlbmNlIG9mIHJlcXVpcmluZyBUTFMsIGNsaWVudCBjZXJ0 aWZpY2F0ZSBhdXRoZW50aWNhdGlvbg0KICAgYW5kIHZlcmlmaWNhdGlvbiBtYXkgYWxzbyBiZSBl bmZvcmNlZCBieSB0aGUgc2VydmVyIGZvciBzdHJvbmdlcg0KICAgY2xpZW50LXNlcnZlciBzZWN1 cml0eSBvciBlbmQtdG8tZW5kIHNlY3VyaXR5LiAgSG93ZXZlciwNCiAgIHJlY29tbWVuZGF0aW9u cyBmb3Igc2VjdXJpdHkgaW4gcGFydGljdWxhciBkZXBsb3ltZW50IHNjZW5hcmlvcyBhcmUNCiAg IG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoaXMgZG9jdW1lbnQuDQoNCj4+IDMpIFRMUw0KPj4gICBX RyBhcmUgc3BlY2lmeWluZyB0aGUgU05JIGVuY3J5cHRpb24gbWVjaGFuaXNtLCB3aWxsIGl0IGlu Zmx1ZW5jZSB5b3VyIFRMUw0KPj4gICBuYW1lIGF1dGhlbnRpY2F0aW9uPw0KDQpTTkkgZW5jcnlw dGlvbiBoYXMgbm8gZWZmZWN0IG9uIG91ciB1c2Ugb2YgVExTIG5hbWUgYXV0aGVudGljYXRpb24u DQoNClRoYW5rcywNClRvbQ0KDQoNCg== From nobody Mon Jun 24 00:56:12 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B8A120088; Mon, 24 Jun 2019 00:56:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Liang Xia via Datatracker To: Cc: draft-ietf-dnssd-push.all@ietf.org, dnssd@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Liang Xia Message-ID: <156136297038.17643.5252253391883114885@ietfa.amsl.com> Date: Mon, 24 Jun 2019 00:56:10 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-dnssd-push-20 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 07:56:11 -0000 Reviewer: Liang Xia Review result: Ready The draft is ready. No more issues left from my side. From nobody Mon Jun 24 00:58:00 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51E22120114; Mon, 24 Jun 2019 00:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=GVjcm3zV; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Hzw7BUbG 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 4DfYpFcSmsgE; Mon, 24 Jun 2019 00:57:56 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABA201200F1; Mon, 24 Jun 2019 00:57:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=404; q=dns/txt; s=iport; t=1561363076; x=1562572676; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=k435bWaKja/YW9yDTBWtQkFfwQesRYanuHnztkOGMtg=; b=GVjcm3zVGUCE3y5J7HkjntjLnAHo4WzTMwq8CWc51ahDmOMzsXy85uVb aPq+aSSEzpZ46KTQim44IHW5bHDKC+yXIAX3S85nuWOjvBD+t1WarZ0Ke FyzzZCCvL4ciwCTd0zOohckd9uDXaBfEkHZd41RRxF16dj4LjElQYx054 E=; IronPort-PHdr: =?us-ascii?q?9a23=3AUPoaQxeiEE9cI7DxfK4QwGchlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwGRD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFn?= =?us-ascii?q?pnwd4TgxRmBceEDUPhK/u/YjIrGs9BWXdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAAD5gRBd/4kNJK1lGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUwYBAQELAYFDUAOBPyAECyiEFoNHA4RSig+aE4EugSQDVAkBAQE?= =?us-ascii?q?MAQEtAgEBhEACF4JPIzQJDgEDAQEEAQECAQVtijcMhUsCBBIREQwBATcBDwI?= =?us-ascii?q?BCA4MAiYCAgIwFRACBAENBSKDAIFrAx0BApduAoE4iF9xgTGCeQEBBYJHgjM?= =?us-ascii?q?YghEJgQwoAYtdF4FAP4E4H4JMPoREF4JzMoImjk6bPwkCghSPeINqG4IYAZU?= =?us-ascii?q?ujSaXAwIEAgQFAg4BAQWBUDiBWHAVZQGCQYJBg3CKU3KBKY8HAQE?= X-IronPort-AV: E=Sophos;i="5.63,411,1557187200"; d="scan'208";a="288387054" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jun 2019 07:57:55 +0000 Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x5O7vtoo030325 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 24 Jun 2019 07:57:55 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 24 Jun 2019 02:57:55 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 24 Jun 2019 02:57:55 -0500 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 24 Jun 2019 02:57:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k435bWaKja/YW9yDTBWtQkFfwQesRYanuHnztkOGMtg=; b=Hzw7BUbGprSJOfb+1JIYkA3uFBr2nKdnjyDlPPxGugPxzlgmH4J198+N1NQo+FqBGH+So3/VYlMJPf4bXXYYsEGP3RLkTDIXYZu1dsTT7MbdS06TjlmJzKBYL+/sFMeJMJWtDvajwLgAFu4seOTa0K80lLrfQZEYRnHlsQ0DBY8= Received: from MN2PR11MB4144.namprd11.prod.outlook.com (20.179.150.210) by MN2PR11MB3904.namprd11.prod.outlook.com (10.255.180.79) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.13; Mon, 24 Jun 2019 07:57:54 +0000 Received: from MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::b179:dc88:3c29:4474]) by MN2PR11MB4144.namprd11.prod.outlook.com ([fe80::b179:dc88:3c29:4474%6]) with mapi id 15.20.2008.014; Mon, 24 Jun 2019 07:57:54 +0000 From: "Eric Vyncke (evyncke)" To: Liang Xia , "secdir@ietf.org" CC: "draft-ietf-dnssd-push.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-dnssd-push-20 Thread-Index: AQHVKmJNUB7IICAAwE+zUzXmk0vj/Kaqkc+A Date: Mon, 24 Jun 2019 07:57:53 +0000 Message-ID: References: <156136297038.17643.5252253391883114885@ietfa.amsl.com> In-Reply-To: <156136297038.17643.5252253391883114885@ietfa.amsl.com> Accept-Language: fr-BE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 authentication-results: spf=none (sender IP is ) smtp.mailfrom=evyncke@cisco.com; x-originating-ip: [2001:420:c0c1:36:e198:ec4e:e008:2d11] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ecfdc42e-6dc7-4093-9c82-08d6f879a9ad x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3904; x-ms-traffictypediagnostic: MN2PR11MB3904: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 007814487B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(366004)(136003)(376002)(346002)(189003)(199004)(558084003)(2906002)(6246003)(76116006)(91956017)(73956011)(7736002)(6116002)(305945005)(66946007)(81166006)(81156014)(8676002)(8936002)(64756008)(66556008)(66476007)(66446008)(186003)(99286004)(76176011)(2501003)(478600001)(14454004)(229853002)(6486002)(102836004)(6506007)(53936002)(6436002)(6512007)(256004)(36756003)(486006)(68736007)(5660300002)(316002)(110136005)(58126008)(33656002)(476003)(4326008)(86362001)(46003)(25786009)(71200400001)(446003)(2616005)(11346002)(71190400001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3904; H:MN2PR11MB4144.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 4klI1szyPR6+m3RknLNILt6I0eRgqUIK9f1p3K8Du9Sh+6aiinAVORoECm9N6yNwMPwh23ohJT8oLohAxc/ND/GcuCh8XCJEPDN/AP/qLO+Iyo5ncijvx3JUDC7QWRlJoq/0rhbqt9ppkKl3Izqf0vosVfq2Yk1JBiVHNSbTm5a9gfbG8iC64kHLej+CgC//pCT2DTBcEqc7zmTwZ6obfv2ZdOBKqlNPNHul1gYYCq71mtURiaiDksU92aNPfuaWQL4r9OYXlluTE8cR+O3CeyJZ1WBRiUr1Wt+3+ua8KZbT84h4meXdWORlJm3JT2rfrxVsX5Nzzeo/N4SI8izikPyOXj3JTnUyFoME3Z1VRrZJaHGodVqrMnE0nX7R3NmNKnCOPZwJX2LrvJ1p3E7nfDZvvy+O/0ybyGc6EIDnJx0= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ecfdc42e-6dc7-4093-9c82-08d6f879a9ad X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2019 07:57:53.9083 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: evyncke@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3904 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.28, xch-aln-018.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-dnssd-push-20 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 07:57:58 -0000 VGhhbmsgeW91IHZlcnkgbXVjaCBMaWFuZyBmb3IgdGhlIHJldmlld2VkIG9mIHRoZSByZXZpc2Vk IHJldmlzaW9uDQoNCi3DqXJpYw0KDQrvu79PbiAyNC8wNi8yMDE5LCAwOTo1NiwgIkxpYW5nIFhp YSB2aWEgRGF0YXRyYWNrZXIiIDxub3JlcGx5QGlldGYub3JnPiB3cm90ZToNCg0KICAgIFJldmll d2VyOiBMaWFuZyBYaWENCiAgICBSZXZpZXcgcmVzdWx0OiBSZWFkeQ0KICAgIA0KICAgIFRoZSBk cmFmdCBpcyByZWFkeS4gTm8gbW9yZSBpc3N1ZXMgbGVmdCBmcm9tIG15IHNpZGUuDQogICAgDQog ICAgDQoNCg== From nobody Mon Jun 24 01:20:37 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A881200FE; Mon, 24 Jun 2019 01:20:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=b7MRzlZJ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Cv1rXQwb 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 6WTMYdVPSYsj; Mon, 24 Jun 2019 01:20:27 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFFFC120048; Mon, 24 Jun 2019 01:20:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6348; q=dns/txt; s=iport; t=1561364427; x=1562574027; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=HAzIYY9V5elj0jCrSO+WfeWX7BLw2M83ifiMa5MFags=; b=b7MRzlZJbHDUyKZETQvmuo6uWvjW1FYoZF7fbW8jTk2rQkTu7QrG1GHK r6KhqsWSlT3RZgnsLYHIX5kW0hGJqmMY/GoA/7BV0m52FZ+TRmgFJEZS1 MJviKFk8PLQU35eJlgl62XbFfTS8SKYRPEFMNDR/UNI08AWDtMiiWdtXe Q=; IronPort-PHdr: =?us-ascii?q?9a23=3AhRYVThIp56ZhdooywdmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXFXnLOPgYjYmNM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BtBQA3hxBd/4wNJK1kHAEBAQQBAQc?= =?us-ascii?q?EAQGBZ4FEKScDgT8gBAsoCoQMg0cDjmGCW5c4gUKBEANUCQEBAQwBAS0CAQG?= =?us-ascii?q?EQAIXgk8jOBMBAwEBBAEBAgEFbYo3DIVKAQEBAwESEREMAQE4BAcEAgEIEQE?= =?us-ascii?q?DAQEDAiYCAgIwFQIGCAIEARIIGoI1gjYDDg8BApgOAoE4iF9xgTGCeQEBBYE?= =?us-ascii?q?FAQGDcxiCEQmBDCiEcYQkdoFTF4FAP4ERRoJMPoQIJBqDCDKCJot0DIJOhyC?= =?us-ascii?q?TOmUJAoIUiy+IToIoixeKCI0mlwMCBAIEBQIOAQEFgWchgVhwFYMngUl4DBe?= =?us-ascii?q?DTYocATZygSmNZgGBIAEB?= X-IronPort-AV: E=Sophos;i="5.63,411,1557187200"; d="scan'208";a="290801253" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jun 2019 08:20:25 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x5O8KPQF011553 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 24 Jun 2019 08:20:25 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 24 Jun 2019 03:20:24 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 24 Jun 2019 04:20:23 -0400 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 24 Jun 2019 03:20:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HAzIYY9V5elj0jCrSO+WfeWX7BLw2M83ifiMa5MFags=; b=Cv1rXQwbUNEjpsjamMaicDVdng1k6FodzGOkaMzdHg7OTRXWyBIsouhu4V5WOe+XVJvZBGemnI9PI6v+/Uce6vf8nRyRSzLNotV1yCC0M5jLFG399IRjur0YKneh3qRxz6E2ZHdCR2RzkKaOtDpDNAorgv8kYnszh7t/f9R2r8I= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4126.namprd11.prod.outlook.com (20.179.150.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Mon, 24 Jun 2019 08:20:22 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2008.014; Mon, 24 Jun 2019 08:20:21 +0000 From: "Pascal Thubert (pthubert)" To: David Mandelberg , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-6tisch-architecture.all@ietf.org" , Thomas Watteyne , Michael Richardson , =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= Thread-Topic: secdir review of draft-ietf-6tisch-architecture-21 Thread-Index: AQHVKitVZAMqDsUZHEuS/CYS/vDUhKaqVH6w Date: Mon, 24 Jun 2019 08:20:12 +0000 Deferred-Delivery: Mon, 24 Jun 2019 08:20:04 +0000 Message-ID: References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> In-Reply-To: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [173.38.220.59] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 860f3817-4efb-4bf8-531e-08d6f87cccf7 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4126; x-ms-traffictypediagnostic: MN2PR11MB4126: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 007814487B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(39860400002)(396003)(136003)(376002)(13464003)(199004)(189003)(55674003)(2906002)(55016002)(7696005)(2501003)(3846002)(81166006)(33656002)(478600001)(81156014)(102836004)(316002)(110136005)(8936002)(186003)(26005)(66066001)(68736007)(53546011)(6506007)(229853002)(99286004)(76176011)(6116002)(76116006)(9686003)(14444005)(305945005)(5660300002)(52536014)(476003)(256004)(486006)(7736002)(86362001)(25786009)(446003)(11346002)(6436002)(6246003)(73956011)(66476007)(66446008)(64756008)(66556008)(66946007)(71190400001)(71200400001)(8676002)(2201001)(6666004)(53936002)(74316002)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4126; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Xrw4SOeHN6WTXwneIL493m4ec2th+pumq5Q5OoJWjrAljPubbn6xNAbsg5AReBWXSB+jzv4tQWhvmnPk/fNS1xH3kDgv5HNqFKy+6vYW/TcLLR726l21zDSPH77PMSnMAIqDMYfwLTGXBcpwzpYZUaESpOfpbzMUHQxQe9XJLY6971Iwg2ZUz6Bm/cxiJ/hAnLZn6r4VPlFRVNvoDGsaTGbxmNt4dY8N8ldLZJ5Tu962kyde89USAbTd5F8jNzbrH520xGTiPcpEsBee+DWMc7RtCnXw3+Du/GOqN5lRB7eIJxPNPWfog2Ph+WhDuwkyvftgUFkFACNTIY8pqCztTEWqx5lf1eB6Pc5Yc17EXys9I58bnGuC4zkhMOxQGt1vf1K/dxeB3oW+Qce++3X3hE7cLJZZh1y7Ehqe4FGRrYM= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 860f3817-4efb-4bf8-531e-08d6f87cccf7 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2019 08:20:21.5419 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4126 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 08:20:28 -0000 SGVsbG8gRGF2aWQ6DQoNCk1hbnkgdGhhbmtzIGZvciB5b3VyIHJldmlldy4gSSBkbyBob3BlIHRo YXQgeW91IGZvdW5kIGl0IGludGVyZXN0aW5nLg0KDQo+IFNlY3Rpb25zIDQuMi4xIGFuZCA0LjMu NCB0YWxrIGFib3V0IHRoZSBzZWN1cml0eSBvZiBqb2luaW5nIGEgbmV0d29yaywgYW5kIHRpbWUN Cj4gc3luY2hyb25pemF0aW9uLCByZXNwZWN0aXZlbHkuIERvIGFueSBvZiB0aGUgc2VjdXJpdHkg bWVjaGFuaXNtcyBpbiA0LjIuMSByZWx5DQo+IG9uIGhhdmluZyBhbiBhY2N1cmF0ZSBjbG9jaz8g KEUuZy4sIHRvIGRpc3RydXN0IG9sZC9leHBpcmVkIGtleXMuKSBJcyB0aW1lDQo+IHN5bmNocm9u aXphdGlvbiBkb25lIGJlZm9yZSB0aGUgam9pbiBwcm9jZXNzLCBhbmQgaXMgdGhlcmUgYW55IHdh eSB0byBleHBsb2l0DQo+IHRpbWUgc3luY2hyb25pemF0aW9uIGluIG9yZGVyIHRvIGNhdXNlIGEg bm9kZSB0byBqb2luIGEgbWFsaWNpb3VzIG5ldHdvcms/DQoNClRoaXMgaXMgcmVhbGx5IGEgTUFD IGxheWVyIHF1ZXN0aW9uIGZvciBJRUVFLiBJJ20gY2MnaW5nIFRob21hcyB3aG8gd2FzIG9uZSBv ZiB0aGUgaW52ZW50b3JzIG9mIFRTQ0gsIGFzIHdlbGwgYXMgTWljaGFlbCBhbmQgTWFsaXNhIHdo byBsZWQgdGhlIGpvaW4gcHJvY2VzcyBzdHVkeS4NCg0KVGltZSBzeW5jaHJvbml6YXRpb24gKGRh dGUpOg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkZvciBhbGwgSSBr bm93LCB0aGUgdGltZSBzeW5jIGlzIGFib3V0IGdpdmluZyBhIGVwb2NoIHRpbWUgZnJvbSB3aGlj aCBhbiBBYnNvbHV0ZSBTbG90IE51bWJlciAoQVNOLCBleHByZXNzZWQgaW4gc2xvdCBkdXJhdGlv biBlLmcuLCAxMG1zKSBpcyBkZXJpdmVkLg0KQVNOIHBsYXlzIGEga2V5IHJvbGUgYXMgaXQgaXMg dXNlZCBpbiBOT05DRS4gQW4gYXR0YWNrIHRoYXQgb25lIGNvdWxkIHRoaW5rIG9mIHdvdWxkIGJl IHRvIGZvb2wgdGhlIG5ldyBub2RlIGludG8gdGhpbmtpbmcgdGhhdCBBU04gaXMgZWFybGllci4g VGhpcyBjb3VsZCBoYXBwZW4gYmVmb3JlIHRoZSBrZXlzIGFyZSBleGNoYW5nZWQsIG9yIGlmIGFu IGF1dGhvcml6ZWQgcGVlciBpcyBjb21wcm9taXNlZC4NCkZvciB0aGUgZm9ybWVyLCBJJ2xsIGRl ZmVyIHRvIHRoZSBvdGhlcnMgdG8gYW5zd2VyIGZ1bGx5IGhvdyB3ZSBwcm90ZWN0IHRoZSBuZXcg Y29tZXIuIA0KRm9yIHRoZSBsYXR0ZXIsIDZUaVNDSCBwcm92aWRlcyBhbiBhZGRpdGlvbmFsIHBy b3RlY3Rpb24gc2luY2Ugd2UgZGVyaXZlIHRpbWUgZnJvbSBhIFJQTCBwYXJlbnQuIFJQTCBoYXMg aXRzIG93biBwcm90ZWN0aW9ucywgc29tZSBvZiB0aGVtIGluIHRoZSBzdGFuZGFyZCBpdHNlbGYs IHNvbWUgb2YgdGhlbSBpbiB6ZXJvdHJ1c3QgcGFwZXJzIHRoYXQgbmVlZCBwdWJsaXNoaW5nLiAN Cg0KVGltZSBzeW50aG9uaXphdGlvbiAocHJlY2lzZSB0aWMsIGhvdXJsZXNzKQ0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgaXMg dGhlIHByb2Nlc3Mgd2hlcmVieSBhIG5vZGUgY29ycmVjdHMgaXRzIHRpYyB0byByZWFsaWduIHdp dGggdGhlIHBhcmVudC4gQVNOIGlzIG5vdCBjaGFuZ2VkIGJ1dCB0aGUgZHJpZnQgb2YgY3J5c3Rh bHMgaXMgY29tcGVuc2F0ZWQuDQpBbiBhdHRhY2tlciBjb3VsZCB0cnkgdG8gaW5qZWN0IGEgc2Vu c2Ugb2YgdGltZSB0aGF0IGl0IHNsaWdodGx5IHNoaWZ0ZWQgdG8gdGhlIHBvaW50IHRoYXQgdGhl IG5vZGUgbG9zZSBzeW5jIHdpdGggdGhlIHJlc3Qgb2YgdGhlIG5ldHdvcmsgKHRoZSBndWFyZCB0 aW1lIGlzIGxpa2UgYW4gZXZlbnQgaG9yaXpvbikuIFRoZW4gYWdhaW4sIFJQTCBwcm92aWRlcyBh biBhZGRpdGlvbmFsIHByb3RlY3Rpb24gb24gdG9wIG9mIHRoZSBNQUMgcHJvdmlzaW9ucy4NCg0K DQpJbiB0aGUgbWVhbnRpbWUgeW91ciByZW1hcmsgcmVzZXJ2ZXMgc29tZSB0ZXh0LiBOb3RlIHRo YXQgdGhlIGRlcGVuZGVuY3kgb24gdGltZSBpcyBpbmhlcml0ZWQgZnJvbSBEZXROZXQgYW5kIFRT TiwgYW5kIERldE5ldCBoYXMgdGV4dCBhYm91dCBpdCB0aGF0IHdlIGNhbiByZWZlcmVuY2UuDQoN CkluIGNvbmp1bmN0aW9uIHdpdGggQW5kcmV3J3MgcmV2aWV3IEknZCBwcm9wb3NlOg0KIg0KICAg IFRoZSBvcGVyYXRpb24gb2YgNlRpU0NIIFRyYWNrcyBpbmhlcml0cyBpdHMgaGlnaCBsZXZlbCBv cGVyYXRpb24gZnJvbSBEZXROZXQNCiAgICBhbmQgaXMgc3ViamVjdCB0byB0aGUgb2JzZXJ2YXRp b25zIGluIHNlY3Rpb24gNSBvZiBbaWV0Zi1kZXRuZXQtYXJjaGl0ZWN0dXJlXS4NCiAgICBBcyBk aXNjdXNzZWQgdGhlcmUsIG1lYXN1cmVzICBtdXN0IGJlIHRha2VuIHRvIHByb3RlY3QgdGhlIHRp bWUgDQogICAgc3luY2hyb25pemF0aW9uLCBhbmQgZm9yIDZUaVNDSCB0aGlzIGluY2x1ZGVzIGVu c3VyaW5nIHRoYXQgdGhlIEFTTiwgd2hpY2ggaXMNCiAgICB1c2VkIGZvciB0aGUgY29tcHV0YXRp b24gb2YgTk9OQ0UsIGlzIG5vdCBjb21wcm9taXNlZC4gQWxzbywgdGhlIGluc3RhbGxhdGlvbg0K ICAgIGFuZCBtYWludGVuYW5jZSBvZiA2VGlTQ0ggVHJhY2tzIGRlcGVuZHMgaW4gdGhlIGF2YWls YWJpbGl0eSBvZiBhIGNvbnRyb2xsZXINCiAgICB3aXRoIGEgUENFIHRvIGNvbXB1dGUgYW5kIHB1 c2ggdGhlbSBpbiB0aGUgbmV0d29yay4gV2hlbiB0aGF0IGNvbm5lY3Rpdml0eQ0KICAgIGlzIGxv c3QsIGV4aXN0aW5nIFRyYWNrcyBtYXkgY29udGludWUgdG8gb3BlcmF0ZSB1bnRpbCB0aGUgZW5k IG9mIHRoZWlyDQogICAgbGlmZXRpbWUsIGJ1dCBjYW5ub3QgYmUgcmVtb3ZlZCBvciB1cGRhdGVk LCBhbmQgbmV3IFRyYWNrcyBjYW5ub3QgYmUNCiAgICBpbnN0YWxsZWQuIEFzIHdpdGggRGV0TmV0 IGluIGdlbmVyYWwsIHRoZSBjb21tdW5pY2F0aW9uIHdpdGggdGhlIFBDRSBtdXN0IGJlDQogICAg c2VjdXJlZCBhbmQgc2hvdWxkIGJlIHByb3RlY3RlZCBhZ2FpbnN0IERvUyBhdHRhY2tzLCBhbmQg dGhlIGRpc2N1c3Npb24gb24NCiAgICB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgZGVmaW5l ZCBmb3IgQWJzdHJhY3Rpb24gYW5kIENvbnRyb2wgb2YgVHJhZmZpYw0KICAgIEVuZ2luZWVyZWQg TmV0d29ya3MgKEFDVE4pIGFwcGxpZXMgZXF1YWxseSB0byA2VGlTQ0guDQoiDQoNCkRvZXMgdGhh dCBzb3VuZCBnb29kPw0KDQpQYXNjYWwNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBEYXZpZCBNYW5kZWxiZXJnIDxkYXZpZEBtYW5kZWxiZXJnLm9yZz4NCj4gU2VudDog bHVuZGkgMjQganVpbiAyMDE5IDAzOjIyDQo+IFRvOiBzZWNkaXJAaWV0Zi5vcmc7IGllc2dAaWV0 Zi5vcmc7IGRyYWZ0LWlldGYtNnRpc2NoLWFyY2hpdGVjdHVyZS5hbGxAaWV0Zi5vcmcNCj4gU3Vi amVjdDogc2VjZGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLTZ0aXNjaC1hcmNoaXRlY3R1cmUtMjEN Cj4gDQo+IEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3Vy aXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZw0KPiBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRv Y3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZQ0KPiBjb21tZW50cyB3 ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJl YSBkaXJlY3RvcnMuDQo+IERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJl YXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueQ0KPiBvdGhlciBsYXN0IGNhbGwgY29tbWVu dHMuDQo+IA0KPiBUaGUgc3VtbWFyeSBvZiB0aGUgcmV2aWV3IGlzIFJlYWR5IHdpdGggbml0cy4N Cj4gDQo+IFRoZSByZXZpZXcgZGVhZGxpbmUgZm9yIHRoaXMgd2FzIHJlYWxseSBzaG9ydCwgc28g SSBkaWRuJ3QgaGF2ZSBhIGNoYW5jZSB0byByZWFkDQo+IHRoaXMgYXMgY2xvc2VseSBhcyBJIHdv dWxkIGhhdmUgbGlrZWQuIFRoYXQgc2FpZCwgZnJvbSBza2ltbWluZyB0aGUgZG9jdW1lbnQNCj4g YW5kIHJlYWRpbmcgdGhlIHNlY3Rpb25zIHRoYXQgbG9va2VkIG1vc3QgaW50ZXJlc3RpbmcsIGl0 IGxvb2tzIHByZXR0eSBnb29kLiBUaGUNCj4gc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlv biBjb3ZlcnMgd2hhdCBJIGV4cGVjdGVkIGl0IHRvLiBJIGhhdmUgb25seSBvbmUNCj4gcXVlc3Rp b24vY29uY2VybjoNCj4gDQo+IFNlY3Rpb25zIDQuMi4xIGFuZCA0LjMuNCB0YWxrIGFib3V0IHRo ZSBzZWN1cml0eSBvZiBqb2luaW5nIGEgbmV0d29yaywgYW5kIHRpbWUNCj4gc3luY2hyb25pemF0 aW9uLCByZXNwZWN0aXZlbHkuIERvIGFueSBvZiB0aGUgc2VjdXJpdHkgbWVjaGFuaXNtcyBpbiA0 LjIuMSByZWx5DQo+IG9uIGhhdmluZyBhbiBhY2N1cmF0ZSBjbG9jaz8gKEUuZy4sIHRvIGRpc3Ry dXN0IG9sZC9leHBpcmVkIGtleXMuKSBJcyB0aW1lDQo+IHN5bmNocm9uaXphdGlvbiBkb25lIGJl Zm9yZSB0aGUgam9pbiBwcm9jZXNzLCBhbmQgaXMgdGhlcmUgYW55IHdheSB0byBleHBsb2l0DQo+ IHRpbWUgc3luY2hyb25pemF0aW9uIGluIG9yZGVyIHRvIGNhdXNlIGEgbm9kZSB0byBqb2luIGEg bWFsaWNpb3VzIG5ldHdvcms/DQo= From nobody Mon Jun 24 16:45:49 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FEEF12013E; Mon, 24 Jun 2019 16:45:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=ham autolearn_force=no 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 iYgdIIb2Bwpy; Mon, 24 Jun 2019 16:45:44 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.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 3004B12007C; Mon, 24 Jun 2019 16:45:42 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x5ONjGM3013645 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 25 Jun 2019 02:45:16 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x5ONjGjw021956; Tue, 25 Jun 2019 02:45:16 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23825.24715.882644.180316@fireball.acr.fi> Date: Tue, 25 Jun 2019 02:45:15 +0300 From: Tero Kivinen To: "Pascal Thubert \(pthubert\)" Cc: David Mandelberg , "secdir\@ietf.org" , "iesg\@ietf.org" , "draft-ietf-6tisch-architecture.all\@ietf.org" , Thomas Watteyne , Michael Richardson , =?iso-8859-2?Q?Mali=B9a_Vu=E8ini=E6?= In-Reply-To: References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 25 min X-Total-Time: 24 min Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 23:45:48 -0000 Pascal Thubert (pthubert) writes: > Hello David: > > Many thanks for your review. I do hope that you found it interesting. > > > Sections 4.2.1 and 4.3.4 talk about the security of joining a > > network, and time synchronization, respectively. Do any of the > > security mechanisms in 4.2.1 rely on having an accurate clock? > > (E.g., to distrust old/expired keys.) Is time synchronization done > > before the join process, and is there any way to exploit time > > synchronization in order to cause a node to join a malicious > > network? > > This is really a MAC layer question for IEEE. I'm cc'ing Thomas who > was one of the inventors of TSCH, as well as Michael and Malisa who > led the join process study. > > Time synchronization (date): > -------------------------------------- > For all I know, the time sync is about giving a epoch time from > which an Absolute Slot Number (ASN, expressed in slot duration e.g., > 10ms) is derived. ASN plays a key role as it is used in NONCE. An > attack that one could think of would be to fool the new node into > thinking that ASN is earlier. This could happen before the keys are > exchanged, or if an authorized peer is compromised. For the former, > I'll defer to the others to answer fully how we protect the new > comer. For the latter, 6TiSCH provides an additional protection > since we derive time from a RPL parent. RPL has its own protections, > some of them in the standard itself, some of them in zerotrust > papers that need publishing. In normal TSCH in 802.15.4 the joining node will listen to beacons sent by the nodes already part of the network, and they will find out the ASN from there. As they do not yet have keys for the network they cannot verify the message integrity code authenticating the beacon, and even if they did have the keys, they still cannot verify it as it could be replay by attacker. After they find out the ASN, they need to authenticate themself to the network using some mechanism outside the 802.15.4. This authentication step must be such that it cannot be replayed by attacker, i.e., they must not trust ASN giving them any protection. Note, that in general 802.15.4 TSCH DOES NOT provide replay protection at all. I.e., attacker can cause legimite node to retransmit its previous message by destroying ack, and upper layer protocol must provide way to detect replays and cope with them. During the authentication the JRC needs to provide the keying material to the joining node, but that does NOT provide protection against spoofed ASN. After the node has actual keys used in the network it still needs to verify the ASN by sending some message to JRC using authentication and verify that JRC replies to that. If this 2nd step is omitted attacker do following attack: Joining node (JN) attacker JRC <- beacon for ASN=23 <- beacon for ASN=44 See beacon from attacker, assume ASN=23. Auth->JRC (no security) Check authentication Return keys keys->JN Receive keys send first frame using keys using ASN=23-> Now, if JN is using extended address to generate nonce, the nonce will be different for all other nonces ever used, even the ASN is faked, and has been used before. On the other hand if JN also receives short address assignment from the JRC, JRC needs to make sure that short address has not been assigned to anybody else before, as if it was used by someone else, and frame sent by JN is encrypted, then attacker will now have two packets with same ASN, and short address, meaning same nonce, and it can now decrypt packets. Note, that attacker might be able to replay valid ACKs for the frame sent by the JN, provided that the JRC (or whoever JN sent the message to) happened to ack message using the same ASN attacker faked for JN. If JN sends message to JRC which only JRC can reply, and uses wrong ASN, the JRC will not be able to decrypt/validate that frame because of wrong ASN in nonce, and will drop it silently, so if JN uses wrong ASN it might be getting ACKs, but it will not get any real reply frames back from real participants in the network. After it will not receive confirmation from JRC that it has proper keys and ASN, it knows something went wrong. > Time synthonization (precise tic, hourless) > -------------------------------------------------------- > This is the process whereby a node corrects its tic to realign with > the parent. ASN is not changed but the drift of crystals is > compensated. An attacker could try to inject a sense of time that it > slightly shifted to the point that the node lose sync with the rest > of the network (the guard time is like an event horizon). Then > again, RPL provides an additional protection on top of the MAC > provisions. Those time syncronization IEs are also protected by MAC level authentication, so attackers who do not know the keys cannot generate them. Attackers who do know keys can do whatever they like anyways... Btw, I will be leaving for vacation tomorrow, so I might not be able to reply any messages related to this until I get back end of next week. -- kivinen@iki.fi From nobody Mon Jun 24 17:30:58 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B25DE120221 for ; Mon, 24 Jun 2019 17:30:49 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mandelberg.org 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 iAYoHlyJZTEH for ; Mon, 24 Jun 2019 17:30:48 -0700 (PDT) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 37C611201F2 for ; Mon, 24 Jun 2019 17:30:46 -0700 (PDT) X_CMAE_Category: , , X-CNFS-Analysis: v=2.2 cv=aKGykv1m c=1 sm=1 tr=0 a=OXtaa+9CFT7WVSERtyqzJw==:117 a=OXtaa+9CFT7WVSERtyqzJw==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=KGjhK52YXX0A:10 a=IkcTkHD0fZMA:10 a=NTnny0joGdQA:10 a=dq6fvYVFJ5YA:10 a=bmmO2AaSJ7QA:10 a=i4AJ2F3t6UaJ7r-B2GQA:9 a=jsRDIoaMY1qESba-:21 a=4RfiEPLOIeMVhr81:21 a=q1x0MaV35-B7teMi:21 a=QEXdDO2ut3YA:10 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: ZHNlb21uQHJjbi5jb20= Authentication-Results: smtp03.rcn.cmh.synacor.com header.DKIM-Signature=@mandelberg.org; dkim=pass Authentication-Results: smtp03.rcn.cmh.synacor.com smtp.mail=david@mandelberg.org; spf=softfail; sender-id=softfail Authentication-Results: smtp03.rcn.cmh.synacor.com header.from=david@mandelberg.org; sender-id=softfail Authentication-Results: smtp03.rcn.cmh.synacor.com smtp.user=dseomn@rcn.com; auth=pass (LOGIN) Received: from [209.6.43.168] ([209.6.43.168:57964] helo=uriel.mandelberg.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=DHE-RSA-AES256-GCM-SHA384) id 2B/35-13517-43B611D5; Mon, 24 Jun 2019 20:30:44 -0400 Received: from [192.168.1.152] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 28BA91C6033; Mon, 24 Jun 2019 20:30:43 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mandelberg.org; s=201903; t=1561422643; bh=QT9ECKM4HatKLifWDr9rUeOWW/+Kw3lFa+7Qwq3cCd8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=YsBsJNWl9sAOiUrGG9tlFLENWaDxPsnqx6Aft2wihSRdEzereQz1sUPPbAsq5dyGa yNXkcf22na2PabNezpUpYTF9euseTFa4YOj4Jpx9P9JuYxpbtmkyX5ZmKwjLZ9AR1/ cb98iCCKpDA/6N9qt3SBZUCJaQgpkN4FBF0e3u1Mhbq+hh0275kMpzhkwbpFt1oRWP XqHXg4VQvPCPZSmzly2mkU+yHV/oPZuih7oIELubCx+Da93ikAKAXAysiK4o+WkQAK cX/ClJ395WwGi+Lb4GVHJtLbvRKLk7MMwGx+0+FqYH9ZsDMVj7hIeSg0k6SNHwTxZV RtOzMiLzRVizg== To: Tero Kivinen , "Pascal Thubert (pthubert)" Cc: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-6tisch-architecture.all@ietf.org" , Thomas Watteyne , Michael Richardson , =?UTF-8?B?TWFsacWhYSBWdcSNaW5p?= =?UTF-8?B?xIc=?= References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> <23825.24715.882644.180316@fireball.acr.fi> From: David Mandelberg Message-ID: <5229f400-076c-80e3-e0dc-a7cf3998abed@mandelberg.org> Date: Mon, 24 Jun 2019 20:30:40 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <23825.24715.882644.180316@fireball.acr.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 00:30:50 -0000 On 6/24/19 7:45 PM, Tero Kivinen wrote: > Pascal Thubert (pthubert) writes: >> Hello David: >> >> Many thanks for your review. I do hope that you found it interesting. >> >>> Sections 4.2.1 and 4.3.4 talk about the security of joining a >>> network, and time synchronization, respectively. Do any of the >>> security mechanisms in 4.2.1 rely on having an accurate clock? >>> (E.g., to distrust old/expired keys.) Is time synchronization done >>> before the join process, and is there any way to exploit time >>> synchronization in order to cause a node to join a malicious >>> network? >> >> This is really a MAC layer question for IEEE. I'm cc'ing Thomas who >> was one of the inventors of TSCH, as well as Michael and Malisa who >> led the join process study. >> >> Time synchronization (date): >> -------------------------------------- >> For all I know, the time sync is about giving a epoch time from >> which an Absolute Slot Number (ASN, expressed in slot duration e.g., >> 10ms) is derived. ASN plays a key role as it is used in NONCE. An >> attack that one could think of would be to fool the new node into >> thinking that ASN is earlier. This could happen before the keys are >> exchanged, or if an authorized peer is compromised. For the former, >> I'll defer to the others to answer fully how we protect the new >> comer. For the latter, 6TiSCH provides an additional protection >> since we derive time from a RPL parent. RPL has its own protections, >> some of them in the standard itself, some of them in zerotrust >> papers that need publishing. > > In normal TSCH in 802.15.4 the joining node will listen to beacons > sent by the nodes already part of the network, and they will find out > the ASN from there. As they do not yet have keys for the network they > cannot verify the message integrity code authenticating the beacon, > and even if they did have the keys, they still cannot verify it as it > could be replay by attacker. > > After they find out the ASN, they need to authenticate themself to the > network using some mechanism outside the 802.15.4. This authentication > step must be such that it cannot be replayed by attacker, i.e., they > must not trust ASN giving them any protection. > > Note, that in general 802.15.4 TSCH DOES NOT provide replay protection > at all. I.e., attacker can cause legimite node to retransmit its > previous message by destroying ack, and upper layer protocol must > provide way to detect replays and cope with them. > > During the authentication the JRC needs to provide the keying material > to the joining node, but that does NOT provide protection against > spoofed ASN. After the node has actual keys used in the network it > still needs to verify the ASN by sending some message to JRC using > authentication and verify that JRC replies to that. > > If this 2nd step is omitted attacker do following attack: > > Joining node (JN) attacker JRC > <- beacon for ASN=23 <- beacon for ASN=44 > See beacon > from attacker, > assume ASN=23. > > Auth->JRC > (no security) Check authentication > Return keys > keys->JN > > Receive keys > send first > frame using > keys using ASN=23-> > > > Now, if JN is using extended address to generate nonce, the nonce will > be different for all other nonces ever used, even the ASN is faked, > and has been used before. On the other hand if JN also receives short > address assignment from the JRC, JRC needs to make sure that short > address has not been assigned to anybody else before, as if it was > used by someone else, and frame sent by JN is encrypted, then attacker > will now have two packets with same ASN, and short address, meaning > same nonce, and it can now decrypt packets. Is this discussion of nonce reuse in any relevant documents already, or is it something that should be added somewhere? > Note, that attacker might be able to replay valid ACKs for the frame > sent by the JN, provided that the JRC (or whoever JN sent the message > to) happened to ack message using the same ASN attacker faked for JN. > > If JN sends message to JRC which only JRC can reply, and uses wrong > ASN, the JRC will not be able to decrypt/validate that frame because > of wrong ASN in nonce, and will drop it silently, so if JN uses wrong > ASN it might be getting ACKs, but it will not get any real reply > frames back from real participants in the network. After it will not > receive confirmation from JRC that it has proper keys and ASN, it > knows something went wrong. > > >> Time synthonization (precise tic, hourless) >> -------------------------------------------------------- >> This is the process whereby a node corrects its tic to realign with >> the parent. ASN is not changed but the drift of crystals is >> compensated. An attacker could try to inject a sense of time that it >> slightly shifted to the point that the node lose sync with the rest >> of the network (the guard time is like an event horizon). Then >> again, RPL provides an additional protection on top of the MAC >> provisions. > > Those time syncronization IEs are also protected by MAC level > authentication, so attackers who do not know the keys cannot generate > them. Attackers who do know keys can do whatever they like anyways... > > Btw, I will be leaving for vacation tomorrow, so I might not be able > to reply any messages related to this until I get back end of next > week. > From nobody Mon Jun 24 17:31:33 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE5611201EC for ; Mon, 24 Jun 2019 17:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mandelberg.org 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 IG6422dT3Eic for ; Mon, 24 Jun 2019 17:31:23 -0700 (PDT) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 B82BC1201F2 for ; Mon, 24 Jun 2019 17:31:21 -0700 (PDT) X_CMAE_Category: , , X-CNFS-Analysis: v=2.2 cv=aKGykv1m c=1 sm=1 tr=0 a=OXtaa+9CFT7WVSERtyqzJw==:117 a=OXtaa+9CFT7WVSERtyqzJw==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=KGjhK52YXX0A:10 a=IkcTkHD0fZMA:10 a=NTnny0joGdQA:10 a=dq6fvYVFJ5YA:10 a=bmmO2AaSJ7QA:10 a=BTUBnpS-AAAA:8 a=48vgC7mUAAAA:8 a=vwySBmwHaG1wzrNIqKwA:9 a=QEXdDO2ut3YA:10 a=pblkFgjdBCuYZ9-HdJ6i:22 a=w1C3t2QeGrPiZgrLijVG:22 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: ZHNlb21uQHJjbi5jb20= Authentication-Results: smtp03.rcn.cmh.synacor.com header.from=david@mandelberg.org; sender-id=softfail Authentication-Results: smtp03.rcn.cmh.synacor.com smtp.mail=david@mandelberg.org; spf=softfail; sender-id=softfail Authentication-Results: smtp03.rcn.cmh.synacor.com header.DKIM-Signature=@mandelberg.org; dkim=pass Authentication-Results: smtp03.rcn.cmh.synacor.com smtp.user=dseomn@rcn.com; auth=pass (LOGIN) Received: from [209.6.43.168] ([209.6.43.168:57966] helo=uriel.mandelberg.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=DHE-RSA-AES256-GCM-SHA384) id CE/35-13517-75B611D5; Mon, 24 Jun 2019 20:31:19 -0400 Received: from [192.168.1.152] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 3B0B21C6033; Mon, 24 Jun 2019 20:31:19 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mandelberg.org; s=201903; t=1561422679; bh=feiuZd2h+wr8Z9AWKBJETKF0Wbbt2djMCh4oyJ7+Xj0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=p97J6yRbMV2DaeB8jvTvy8liL7xT6H0oz2cIFawomAJb9Hyp1x7tChThWpibHu1O2 npb9Fpaa8fWTcdyawRQGsydjnSwRpd+40J8b3uOfhFj+sa0hte1g5djyaBtRLnQvfI gfITAevt2QFsTTgCemxXBy7K0D7NL+XsdlN6RwEVTPdnwQr7TIFwIfbGk5bEv6E0U2 3p8HcVnCrWpTiYsokppgjuTQ6OBe+Zoa5gEsNZ3DK76COaVZq3INi4uSLGfzizgEjH 3+eJs2x58wf0pc2ufIHKt5ZODfZ43l6ktMAKuohrg9wXErE0vcHaVJyF6CNd7vdceS JrH5CS/qoaoEA== To: "Pascal Thubert (pthubert)" , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-6tisch-architecture.all@ietf.org" , Thomas Watteyne , Michael Richardson , =?UTF-8?B?TWFsacWhYSBWdcSNaW5p?= =?UTF-8?B?xIc=?= References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> From: David Mandelberg Message-ID: Date: Mon, 24 Jun 2019 20:31:17 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 00:31:25 -0000 On 6/24/19 4:20 AM, Pascal Thubert (pthubert) wrote: > Hello David: > > Many thanks for your review. I do hope that you found it interesting. > >> Sections 4.2.1 and 4.3.4 talk about the security of joining a network, and time >> synchronization, respectively. Do any of the security mechanisms in 4.2.1 rely >> on having an accurate clock? (E.g., to distrust old/expired keys.) Is time >> synchronization done before the join process, and is there any way to exploit >> time synchronization in order to cause a node to join a malicious network? > > This is really a MAC layer question for IEEE. I'm cc'ing Thomas who was one of the inventors of TSCH, as well as Michael and Malisa who led the join process study. > > Time synchronization (date): > -------------------------------------- > For all I know, the time sync is about giving a epoch time from which an Absolute Slot Number (ASN, expressed in slot duration e.g., 10ms) is derived. > ASN plays a key role as it is used in NONCE. An attack that one could think of would be to fool the new node into thinking that ASN is earlier. This could happen before the keys are exchanged, or if an authorized peer is compromised. > For the former, I'll defer to the others to answer fully how we protect the new comer. > For the latter, 6TiSCH provides an additional protection since we derive time from a RPL parent. RPL has its own protections, some of them in the standard itself, some of them in zerotrust papers that need publishing. > > Time synthonization (precise tic, hourless) > -------------------------------------------------------- > This is the process whereby a node corrects its tic to realign with the parent. ASN is not changed but the drift of crystals is compensated. > An attacker could try to inject a sense of time that it slightly shifted to the point that the node lose sync with the rest of the network (the guard time is like an event horizon). Then again, RPL provides an additional protection on top of the MAC provisions. > > > In the meantime your remark reserves some text. Note that the dependency on time is inherited from DetNet and TSN, and DetNet has text about it that we can reference. > > In conjunction with Andrew's review I'd propose: > " > The operation of 6TiSCH Tracks inherits its high level operation from DetNet > and is subject to the observations in section 5 of [ietf-detnet-architecture]. > As discussed there, measures must be taken to protect the time > synchronization, and for 6TiSCH this includes ensuring that the ASN, which is > used for the computation of NONCE, is not compromised. Also, the installation > and maintenance of 6TiSCH Tracks depends in the availability of a controller > with a PCE to compute and push them in the network. When that connectivity > is lost, existing Tracks may continue to operate until the end of their > lifetime, but cannot be removed or updated, and new Tracks cannot be > installed. As with DetNet in general, the communication with the PCE must be > secured and should be protected against DoS attacks, and the discussion on > the security considerations defined for Abstraction and Control of Traffic > Engineered Networks (ACTN) applies equally to 6TiSCH. > " > > Does that sound good? Yup, sounds good to me. > Pascal > >> -----Original Message----- >> From: David Mandelberg >> Sent: lundi 24 juin 2019 03:22 >> To: secdir@ietf.org; iesg@ietf.org; draft-ietf-6tisch-architecture.all@ietf.org >> Subject: secdir review of draft-ietf-6tisch-architecture-21 >> >> I have reviewed this document as part of the security directorate's ongoing >> effort to review all IETF documents being processed by the IESG. These >> comments were written primarily for the benefit of the security area directors. >> Document editors and WG chairs should treat these comments just like any >> other last call comments. >> >> The summary of the review is Ready with nits. >> >> The review deadline for this was really short, so I didn't have a chance to read >> this as closely as I would have liked. That said, from skimming the document >> and reading the sections that looked most interesting, it looks pretty good. The >> security considerations section covers what I expected it to. I have only one >> question/concern: >> >> Sections 4.2.1 and 4.3.4 talk about the security of joining a network, and time >> synchronization, respectively. Do any of the security mechanisms in 4.2.1 rely >> on having an accurate clock? (E.g., to distrust old/expired keys.) Is time >> synchronization done before the join process, and is there any way to exploit >> time synchronization in order to cause a node to join a malicious network? From nobody Mon Jun 24 18:04:03 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF80E1200B6; Mon, 24 Jun 2019 18:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=gmail.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 q82q7njtrWrB; Mon, 24 Jun 2019 18:03:59 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB85D1201EC; Mon, 24 Jun 2019 18:03:59 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id r21so15522086otq.6; Mon, 24 Jun 2019 18:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=B11eldTt8wf/GW8uv6rY71lLguAzcSifcjZAKwpqHzU=; b=L1w58vO+kVzFlv67sTIcGVqzJyQWQAsbl0tav+a5BllXgvMjs9OOIpa7xKJiBQ8d99 mvWS2/cWT06o2Zj7kpqkbZQSBe81ncN77WJ7BLvJKeDr46GrBzWjKJ0NdmzDU92a7w8y NmhSmgAoHcMyuSSK2m6vk5r3rcqzZPRVSp0I5SjEZSt8WrTbSdKVTviO/p2vtSb38mvE M0gZBiT28wYRd4fSUzq+8+vlBM1fVewJ8RsuumJ2B04gqR/+Na6uxUUgCT4A1mBb10cE /3Z5M7DH3YNIUyox+SVueQojhq1JlEirFJAP3VlPNL6ZQw+hjcq9Ps1+oaaikFjvf36S nCMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=B11eldTt8wf/GW8uv6rY71lLguAzcSifcjZAKwpqHzU=; b=Od3hyDF5M55fAyEvid+349NGtJcPgF3L2FY7KNDh8O/8rr7TkFbxzX1BP3lebZjZN3 kbqrzlGx3roHXH+pfiim7Ql36b25/GSDlFHlWO7a3MOSepIq7gk+kjWEBJtNGLAJZkL5 bnrpoT5Jb8YUIww+AaqLNqmHWE3w9muuhzJyx6RgzGhb2J5KXuRQVEvzkg5sPKbBbLG/ vaNmydmUbDrLQvMdP1gAoXE1DGVlMftC/a8r7cvj1FPKyAt9uCtTeQbgZGfNtH//fhkO o4HgH/86ew6UIb5TPpzwPduvV2Qf43C+EIjM4GEp0CcptmacC/9/4J03orYr61c2/kuQ jNag== X-Gm-Message-State: APjAAAX8fD+425qralhcTgDdVMUaBwp7gO7r5cshFBxwkHuposqps66Z wkdWAjjMRFPtx6WCMsEJKvUaa9GC X-Google-Smtp-Source: APXvYqwzpiW25m/8n9va+43bUbuPSO4Q5+EjeRwPxNOvEFlVotAS2xRLtktfzZNSwE7e76eKb0uv8w== X-Received: by 2002:a9d:6216:: with SMTP id g22mr979722otj.349.1561424638806; Mon, 24 Jun 2019 18:03:58 -0700 (PDT) Received: from Chriss-Air.attlocal.net ([2600:1700:12b0:adf0:7454:7fd8:6edc:9f93]) by smtp.googlemail.com with ESMTPSA id y83sm4835790oig.41.2019.06.24.18.03.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Jun 2019 18:03:58 -0700 (PDT) To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-v6ops-nat64-deployment.all@ietf.org From: Chris Lonvick Message-ID: Date: Mon, 24 Jun 2019 20:03:57 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [secdir] SECDIR review of draft-ietf-v6ops-nat64-deployment-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 01:04:02 -0000 Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is READY. I mostly skimmed this informational document. It appears to be well laid out and complete. The Security Considerations section is succinct and offers, "This document does not have new specific security considerations beyond those already reported by each of the documents cited." I believe that is sufficient for this document. Regards, Chris From nobody Mon Jun 24 23:36:56 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E05951200E9; Mon, 24 Jun 2019 23:36:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 I_vJDhjLeLPh; Mon, 24 Jun 2019 23:36:44 -0700 (PDT) Received: from NAM04-CO1-obe.outbound.protection.outlook.com (mail-oln040092010088.outbound.protection.outlook.com [40.92.10.88]) (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 713A8120058; Mon, 24 Jun 2019 23:36:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zxImLkGPboD1+cVtgVSA+AECxw59IGqifs7bUSR22AY=; b=sPfkqWUg+VV9kDZ6SvME0vB9QZC4cyhrML5zYxpjkZifllNZ7gekv50s7v29DedG1XSdGsrmUCShiFK0cfu2Zag3n0C3zX9Zdu/DHfAlIDIWRHQ1R5LOxLD8R2ADSMELt23ZgJCIcIml89AmhJF6aWEEPPCBZoEstaTviwRDwNtF1ytOep5/+0CYMe0Auzu+5zWA3fO5v/Vj2BLHvxDyylICBTsZpXWUKzr9Pk7fetnzaGw7EgmGPCpL29QqlXhDUYUesn0XneFzaOiit2oZwShrlmDItsvIto4Q2OKokrVY++dKhOw7xtZysxDClgZjkIH8eKOfXtZzlcfipeeSBw== Received: from CO1NAM04FT017.eop-NAM04.prod.protection.outlook.com (10.152.90.58) by CO1NAM04HT236.eop-NAM04.prod.protection.outlook.com (10.152.91.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1987.11; Tue, 25 Jun 2019 06:36:43 +0000 Received: from MWHPR04MB0367.namprd04.prod.outlook.com (10.152.90.57) by CO1NAM04FT017.mail.protection.outlook.com (10.152.90.127) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.13 via Frontend Transport; Tue, 25 Jun 2019 06:36:43 +0000 Received: from MWHPR04MB0367.namprd04.prod.outlook.com ([fe80::d065:4f8e:21ae:a5cb]) by MWHPR04MB0367.namprd04.prod.outlook.com ([fe80::d065:4f8e:21ae:a5cb%7]) with mapi id 15.20.2008.014; Tue, 25 Jun 2019 06:36:43 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-babel-rfc6126.all@ietf.org" Thread-Topic: Secdir review of draft-ietf-babel-rfc6126bis-10 Thread-Index: AQHVKyAba4vbfAj2M0OH8XFeSZSYGg== Date: Tue, 25 Jun 2019 06:36:43 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:A2EE77A2688B2E800CE0D05A3E88374AC938A6BCD9093F52771C1F24D3E518CB; UpperCasedChecksum:C3CA495343B70FD40285B79D221E98415EC064C44930188522DF94DD44D78213; SizeAsReceived:6788; Count:40 x-tmn: [9RjHdfIBdXYm0ukjP+qxlpn/fMgHZBefhXiKcjfM2uuOG1dZfPcExPeZRk2ODYoC] x-ms-publictraffictype: Email x-incomingheadercount: 40 x-eopattributedmessage: 0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(5050001)(7020095)(20181119110)(201702061078)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031322404)(2017031323274)(2017031324274)(1601125500)(1603101475)(1701031045); SRVR:CO1NAM04HT236; x-ms-traffictypediagnostic: CO1NAM04HT236: x-microsoft-antispam-message-info: aBxBF1VCa7ACPNsYMo+KB61ntOZ6vl2ijT8xPBbqEA4D48CTf5IToRDUDFGUHxYcNdI1hMNaIdCne9+6vn1uF+zKzmOJDLzZebwLDTMwXPtjgH2TYzvdUJ4PHtLduI3SvR6g7IUwkwFEmMbQSJlAhhgCFrLlll6W5mFWpignzy6SHWLsi6NKVq7Y51qhi8+p Content-Type: multipart/alternative; boundary="_000_MWHPR04MB036703F78E8A43D6BD456605DFE30MWHPR04MB0367namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 8541116f-96ab-4fe9-cd95-08d6f9377cc5 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2019 06:36:43.0949 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1NAM04HT236 Archived-At: Subject: [secdir] Secdir review of draft-ietf-babel-rfc6126bis-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 06:36:47 -0000 --_000_MWHPR04MB036703F78E8A43D6BD456605DFE30MWHPR04MB0367namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. This document defines the Babel Routing Protocol, a distance vector protoco= l designed for use in networks with a high degree of mobility and fast-chan= ging connectivity such as an ad-hoc wireless network with no fixed connecti= on points. As a procedural matter, I don't know whether rfc6126bis is the right name f= or this thing. RFC6126 specifies Babel as an experimental protocol, and I w= ould assume this I-D is an update to that document, probably still as an ex= perimental protocol. Or perhaps it is now going to be a proposed standard, = though without including a viable security mechanism (see below) that seems= problematic. As noted in the Security Considerations, as specified Babel is a completely= insecure protocol. It appears that any hostile node within the network can= cause essentially all connectivity to fail. It even appears that when usin= g IPv4, if the network is connected to the Internet then any hostile node a= nywhere on the Internet can cause essentially all connectivity to fail. Tha= t's because security depends on the use of link-local IP addresses, a conce= pt that does not exist in IPv4. I would think that this protocol could spec= ify that that routers participating in this protocol maintain a list of IP = addresses associated with the subnet that are considered link local for pur= poses of running this protocol. There are two proposals (currently Internet Drafts) to improve security: dr= aft-ietf-babel-dtls-04 and draft-ietf-babel-hmac-04. I have not reviewed th= ose proposals, but would note that there recursion challenges using DTLS wh= en neither end is connected to services like DNS and OCSP. Babel users mult= icast, so this protocol would probably be best secured using a single key s= hared by all nodes participating in the subnet with some facility to period= ically roll it over. Even with the proposed security enhancements, the protocol provides no prot= ection against a hostile "insider". It only protects against rogue nodes th= at happen to share the same physical link (likely wireless, so that is impo= rtant). Adding protection against insider threats would be difficult and pe= rhaps impossible given the distance vector nature of the protocol. It could= not use the sort of layered digital signatures that is proposed for use wi= th BGP. That limits the scalability of the system. The Security Considerations section notes that connectivity in a wireless s= pace can reveal physical location, and that for privacy reasons nodes might= want to use randomly chosen IP addresses and change them periodically. Tha= t is almost certainly not realistic with IPv4 given the growing shortage of= addresses. There is no mention of whether this protocol could somehow inte= ract with DHCP in a useful way. It would certainly introduce new challenges= . --Charlie --_000_MWHPR04MB036703F78E8A43D6BD456605DFE30MWHPR04MB0367namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security directorate's on= going effort to review all IETF documents being processed by the IESG. = ; These comments were written primarily for the benefit of the security are= a directors.  Document editors and WG chairs should treat these comments just like any other last call comments.=

This document defines the Babel Routing Protocol, a distance vector pr= otocol designed for use in networks with a high degree of mobility and fast= -changing connectivity such as an ad-hoc wireless network with no fixed con= nection points.

As a procedural matter, I don't know whether rfc6126bis is the right n= ame for this thing. RFC6126 specifies Babel as an experimental protocol, an= d I would assume this I-D is an update to that document, probably still as = an experimental protocol. Or perhaps it is now going to be a proposed standard, though without including a viab= le security mechanism (see below) that seems problematic.

As noted in the Security Considerations, as specified Babel is a compl= etely insecure protocol. It appears that any hostile node within the networ= k can cause essentially all connectivity to fail. It even appears that when= using IPv4, if the network is connected to the Internet then any hostile node anywhere on the Internet can cause e= ssentially all connectivity to fail. That's because security depends on the= use of link-local IP addresses, a concept that does not exist in IPv4. I w= ould think that this protocol could specify that that routers participating in this protocol maintain a list o= f IP addresses associated with the subnet that are considered link local fo= r purposes of running this protocol.

There are two proposals (currently Internet Drafts) to improve securit= y: draft-ietf-babel-dtls-04 and draft-ietf-babel-hmac-04. I have not review= ed those proposals, but would note that there recursion challenges using DT= LS when neither end is connected to services like DNS and OCSP. Babel users multicast, so this protocol wou= ld probably be best secured using a single key shared by all nodes particip= ating in the subnet with some facility to periodically roll it over.

Even with the proposed security enhancements, the protocol provides no= protection against a hostile "insider". It only protects against= rogue nodes that happen to share the same physical link (likely wireless, = so that is important). Adding protection against insider threats would be difficult and perhaps impossible given the distan= ce vector nature of the protocol. It could not use the sort of layered digi= tal signatures that is proposed for use with BGP. That limits the scalabili= ty of the system.

The Security Considerations section notes that connectivity in a wirel= ess space can reveal physical location, and that for privacy reasons nodes = might want to use randomly chosen IP addresses and change them periodically= . That is almost certainly not realistic with IPv4 given the growing shortage of addresses. There is no mention of = whether this protocol could somehow interact with DHCP in a useful way. It = would certainly introduce new challenges.


 --Charlie

--_000_MWHPR04MB036703F78E8A43D6BD456605DFE30MWHPR04MB0367namp_-- From nobody Tue Jun 25 00:05:24 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 570F9120232; Tue, 25 Jun 2019 00:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=hpUuBhsz; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=k01D5Guq 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 A6eZ-F5VjJnp; Tue, 25 Jun 2019 00:05:12 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDE4E1200FB; Tue, 25 Jun 2019 00:05:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8782; q=dns/txt; s=iport; t=1561446311; x=1562655911; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=nqmJY8D5UhT4bRLV0dXkf254lEf5aAydL4kEeYiFCkM=; b=hpUuBhszpI11RBiZMXtFMimfUsALht2mO5hUAajkkZQGtgkdqx6eBRJ1 bdC3EtIvojzPxQRoD5DwctGtbyXZ4nPDyD9OrFn2MaCuYaIV8clCdIp/g LF00mOpvW9bExh3q4l1pBaO6mL+M+XEyQ6QIp0cBl6szFv3JaXElsbLiT Y=; IronPort-PHdr: =?us-ascii?q?9a23=3A8sMVpRFZ6EXdm0dshwn1op1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeb2bzEwEd5efFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B7AAAAxxFd/5BdJa1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBZ4FEKScDgT8gBAsohBaDRwOOYUyCD5c4glIDVAkBAQE?= =?us-ascii?q?MAQEtAgEBhEACF4JbIzgTAQMBAQQBAQIBBW2KNwyFSgEBAQEDEhEEDQwBATc?= =?us-ascii?q?BCwQCAQgRAQMBAQECAiYCAgIwFQIGCAIEAQ0FCBqCNYI2Ax0BApl0AoE4iF9?= =?us-ascii?q?xfjOCeQEBBYUCGIIRCYEMKIRxhCR2gTYdF4FAP4ERRoFOfj6ERoMIMoImi3k?= =?us-ascii?q?Mgk6HIJM+ZQkCghSLMYhRl0qNKJcLAgQCBAUCDgEBBYFnIYFYcBWDJ4JBDBe?= =?us-ascii?q?DTYpTcoEpjCICAyEHgiUBAQ?= X-IronPort-AV: E=Sophos;i="5.63,415,1557187200"; d="scan'208";a="579748425" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Jun 2019 07:05:08 +0000 Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x5P758MT006389 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Jun 2019 07:05:08 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 25 Jun 2019 02:05:07 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 25 Jun 2019 03:05:07 -0400 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 25 Jun 2019 02:05:07 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nqmJY8D5UhT4bRLV0dXkf254lEf5aAydL4kEeYiFCkM=; b=k01D5GuqMYs4uoFcfvple2HE0Ea5sexnKJjvhLIKsw5YeiELlzIHvCvNlpRPvOLKqR382DFmDXiZLzbqcpvtjrcjzM4HdPDGNrQipZVWTttWViTjMxIx3uPgB7c8f4cBjzCR+EdusTlrrglDneMv7TobftvLUmp1OL9xITc+wLE= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3552.namprd11.prod.outlook.com (20.178.251.97) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Tue, 25 Jun 2019 07:05:06 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2008.014; Tue, 25 Jun 2019 07:05:06 +0000 From: "Pascal Thubert (pthubert)" To: David Mandelberg , Tero Kivinen CC: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-6tisch-architecture.all@ietf.org" , Thomas Watteyne , Michael Richardson , =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= Thread-Topic: [secdir] secdir review of draft-ietf-6tisch-architecture-21 Thread-Index: AQHVKitVZAMqDsUZHEuS/CYS/vDUhKaqVH6wgAEk6YCAAAywAIAAbXDg Date: Tue, 25 Jun 2019 07:04:38 +0000 Deferred-Delivery: Tue, 25 Jun 2019 07:04:11 +0000 Message-ID: References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> <23825.24715.882644.180316@fireball.acr.fi> <5229f400-076c-80e3-e0dc-a7cf3998abed@mandelberg.org> In-Reply-To: <5229f400-076c-80e3-e0dc-a7cf3998abed@mandelberg.org> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:44f3:1300:552f:ff32:b86:aad7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8e037d64-4ff1-4411-a882-08d6f93b73df x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3552; x-ms-traffictypediagnostic: MN2PR11MB3552: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0079056367 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(136003)(396003)(376002)(346002)(366004)(13464003)(199004)(189003)(11346002)(256004)(478600001)(6246003)(66574012)(74316002)(73956011)(53936002)(14444005)(102836004)(305945005)(86362001)(5660300002)(110136005)(316002)(6436002)(486006)(186003)(446003)(55016002)(229853002)(9686003)(6116002)(25786009)(54906003)(68736007)(476003)(7736002)(66476007)(53546011)(52536014)(46003)(4326008)(66446008)(7696005)(14454004)(71200400001)(71190400001)(8676002)(81156014)(8936002)(81166006)(6666004)(66556008)(6506007)(64756008)(76176011)(2906002)(99286004)(76116006)(33656002)(66946007); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3552; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: rIHRnJtdP0ctWH0dxDVmV7G+S1QHcgQ2NgNYfpzqPaka5LFVEOsUlmvTPqovP8xMsnDn6bERqML94u06Y5DwmsEibAbvl7XuUfN9jZvzNqcntKkJkMKjpLDZWGC9hoKqRh9PluUTSr0oBJPAjUpidnqu4wo3/YlDcBO/QxcZX9BUsMEuDN4HpVbuXMAWAV07l4RGxX8FT1+UTQms2USLV0lwr6xuupKwhgs7tgqdY0zMoPMQaVAaqDTOz8QFhSNYYcpQ5pKQER+f8ASO3BTRst8uHRfH2afWPHv9seZFxDwGaxzN2Fiky6a62QNHSDxWZ80cMAD0lecbr/nNm5uwB3V7vULtIbo7s6vIesigALSksKvX0mMkcszKa0p8cLvJBQmYHtrV0Hx/hWFwjGWDD/ZWoYqgxbOTKMqwYK6z77k= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8e037d64-4ff1-4411-a882-08d6f93b73df X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2019 07:05:05.9729 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3552 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.21, xch-rcd-011.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 07:05:15 -0000 VGhpcyBpcyBncmVhdCBhbmQgY29uY2lzZSBpbmZvcm1hdGlvbjsgSSdkIGJlIGhhcHB5IHRvIGFk ZCBpdCBpbiB0aGUgc2VjdXJpdHkgc2VjdGlvbiBldmVuIGlmIGl0IGlzIGF2YWlsYWJsZSBlbHNl d2hlcmUuLi4NCg0KQWxsIHRoZSBiZXN0LA0KDQpQYXNjYWwNCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBEYXZpZCBNYW5kZWxiZXJnIDxkYXZpZEBtYW5kZWxiZXJnLm9y Zz4NCj4gU2VudDogbWFyZGkgMjUganVpbiAyMDE5IDAyOjMxDQo+IFRvOiBUZXJvIEtpdmluZW4g PGtpdmluZW5AaWtpLmZpPjsgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KQ0KPiA8cHRodWJlcnRA Y2lzY28uY29tPg0KPiBDYzogc2VjZGlyQGlldGYub3JnOyBpZXNnQGlldGYub3JnOyBkcmFmdC1p ZXRmLTZ0aXNjaC1hcmNoaXRlY3R1cmUuYWxsQGlldGYub3JnOw0KPiBUaG9tYXMgV2F0dGV5bmUg PHRob21hcy53YXR0ZXluZUBpbnJpYS5mcj47IE1pY2hhZWwgUmljaGFyZHNvbg0KPiA8bWNyK2ll dGZAc2FuZGVsbWFuLmNhPjsgTWFsacWhYSBWdcSNaW5pxIcgPG1hbGlzYXZAYWMubWU+DQo+IFN1 YmplY3Q6IFJlOiBbc2VjZGlyXSBzZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtNnRpc2NoLWFy Y2hpdGVjdHVyZS0yMQ0KPiANCj4gDQo+IA0KPiBPbiA2LzI0LzE5IDc6NDUgUE0sIFRlcm8gS2l2 aW5lbiB3cm90ZToNCj4gPiBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIHdyaXRlczoNCj4gPj4g SGVsbG8gRGF2aWQ6DQo+ID4+DQo+ID4+IE1hbnkgdGhhbmtzIGZvciB5b3VyIHJldmlldy4gSSBk byBob3BlIHRoYXQgeW91IGZvdW5kIGl0IGludGVyZXN0aW5nLg0KPiA+Pg0KPiA+Pj4gU2VjdGlv bnMgNC4yLjEgYW5kIDQuMy40IHRhbGsgYWJvdXQgdGhlIHNlY3VyaXR5IG9mIGpvaW5pbmcgYQ0K PiA+Pj4gbmV0d29yaywgYW5kIHRpbWUgc3luY2hyb25pemF0aW9uLCByZXNwZWN0aXZlbHkuIERv IGFueSBvZiB0aGUNCj4gPj4+IHNlY3VyaXR5IG1lY2hhbmlzbXMgaW4gNC4yLjEgcmVseSBvbiBo YXZpbmcgYW4gYWNjdXJhdGUgY2xvY2s/DQo+ID4+PiAoRS5nLiwgdG8gZGlzdHJ1c3Qgb2xkL2V4 cGlyZWQga2V5cy4pIElzIHRpbWUgc3luY2hyb25pemF0aW9uIGRvbmUNCj4gPj4+IGJlZm9yZSB0 aGUgam9pbiBwcm9jZXNzLCBhbmQgaXMgdGhlcmUgYW55IHdheSB0byBleHBsb2l0IHRpbWUNCj4g Pj4+IHN5bmNocm9uaXphdGlvbiBpbiBvcmRlciB0byBjYXVzZSBhIG5vZGUgdG8gam9pbiBhIG1h bGljaW91cw0KPiA+Pj4gbmV0d29yaz8NCj4gPj4NCj4gPj4gVGhpcyBpcyByZWFsbHkgYSBNQUMg bGF5ZXIgcXVlc3Rpb24gZm9yIElFRUUuIEknbSBjYydpbmcgVGhvbWFzIHdobw0KPiA+PiB3YXMg b25lIG9mIHRoZSBpbnZlbnRvcnMgb2YgVFNDSCwgYXMgd2VsbCBhcyBNaWNoYWVsIGFuZCBNYWxp c2Egd2hvDQo+ID4+IGxlZCB0aGUgam9pbiBwcm9jZXNzIHN0dWR5Lg0KPiA+Pg0KPiA+PiBUaW1l IHN5bmNocm9uaXphdGlvbiAoZGF0ZSk6DQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tDQo+ID4+IEZvciBhbGwgSSBrbm93LCB0aGUgdGltZSBzeW5jIGlzIGFib3V0 IGdpdmluZyBhIGVwb2NoIHRpbWUgZnJvbSB3aGljaA0KPiA+PiBhbiBBYnNvbHV0ZSBTbG90IE51 bWJlciAoQVNOLCBleHByZXNzZWQgaW4gc2xvdCBkdXJhdGlvbiBlLmcuLA0KPiA+PiAxMG1zKSBp cyBkZXJpdmVkLiBBU04gcGxheXMgYSBrZXkgcm9sZSBhcyBpdCBpcyB1c2VkIGluIE5PTkNFLiBB bg0KPiA+PiBhdHRhY2sgdGhhdCBvbmUgY291bGQgdGhpbmsgb2Ygd291bGQgYmUgdG8gZm9vbCB0 aGUgbmV3IG5vZGUgaW50bw0KPiA+PiB0aGlua2luZyB0aGF0IEFTTiBpcyBlYXJsaWVyLiBUaGlz IGNvdWxkIGhhcHBlbiBiZWZvcmUgdGhlIGtleXMgYXJlDQo+ID4+IGV4Y2hhbmdlZCwgb3IgaWYg YW4gYXV0aG9yaXplZCBwZWVyIGlzIGNvbXByb21pc2VkLiBGb3IgdGhlIGZvcm1lciwNCj4gPj4g SSdsbCBkZWZlciB0byB0aGUgb3RoZXJzIHRvIGFuc3dlciBmdWxseSBob3cgd2UgcHJvdGVjdCB0 aGUgbmV3DQo+ID4+IGNvbWVyLiBGb3IgdGhlIGxhdHRlciwgNlRpU0NIIHByb3ZpZGVzIGFuIGFk ZGl0aW9uYWwgcHJvdGVjdGlvbiBzaW5jZQ0KPiA+PiB3ZSBkZXJpdmUgdGltZSBmcm9tIGEgUlBM IHBhcmVudC4gUlBMIGhhcyBpdHMgb3duIHByb3RlY3Rpb25zLCBzb21lDQo+ID4+IG9mIHRoZW0g aW4gdGhlIHN0YW5kYXJkIGl0c2VsZiwgc29tZSBvZiB0aGVtIGluIHplcm90cnVzdCBwYXBlcnMg dGhhdA0KPiA+PiBuZWVkIHB1Ymxpc2hpbmcuDQo+ID4NCj4gPiBJbiBub3JtYWwgVFNDSCBpbiA4 MDIuMTUuNCB0aGUgam9pbmluZyBub2RlIHdpbGwgbGlzdGVuIHRvIGJlYWNvbnMNCj4gPiBzZW50 IGJ5IHRoZSBub2RlcyBhbHJlYWR5IHBhcnQgb2YgdGhlIG5ldHdvcmssIGFuZCB0aGV5IHdpbGwg ZmluZCBvdXQNCj4gPiB0aGUgQVNOIGZyb20gdGhlcmUuIEFzIHRoZXkgZG8gbm90IHlldCBoYXZl IGtleXMgZm9yIHRoZSBuZXR3b3JrIHRoZXkNCj4gPiBjYW5ub3QgdmVyaWZ5IHRoZSBtZXNzYWdl IGludGVncml0eSBjb2RlIGF1dGhlbnRpY2F0aW5nIHRoZSBiZWFjb24sDQo+ID4gYW5kIGV2ZW4g aWYgdGhleSBkaWQgaGF2ZSB0aGUga2V5cywgdGhleSBzdGlsbCBjYW5ub3QgdmVyaWZ5IGl0IGFz IGl0DQo+ID4gY291bGQgYmUgcmVwbGF5IGJ5IGF0dGFja2VyLg0KPiA+DQo+ID4gQWZ0ZXIgdGhl eSBmaW5kIG91dCB0aGUgQVNOLCB0aGV5IG5lZWQgdG8gYXV0aGVudGljYXRlIHRoZW1zZWxmIHRv IHRoZQ0KPiA+IG5ldHdvcmsgdXNpbmcgc29tZSBtZWNoYW5pc20gb3V0c2lkZSB0aGUgODAyLjE1 LjQuIFRoaXMgYXV0aGVudGljYXRpb24NCj4gPiBzdGVwIG11c3QgYmUgc3VjaCB0aGF0IGl0IGNh bm5vdCBiZSByZXBsYXllZCBieSBhdHRhY2tlciwgaS5lLiwgdGhleQ0KPiA+IG11c3Qgbm90IHRy dXN0IEFTTiBnaXZpbmcgdGhlbSBhbnkgcHJvdGVjdGlvbi4NCj4gPg0KPiA+IE5vdGUsIHRoYXQg aW4gZ2VuZXJhbCA4MDIuMTUuNCBUU0NIIERPRVMgTk9UIHByb3ZpZGUgcmVwbGF5IHByb3RlY3Rp b24NCj4gPiBhdCBhbGwuIEkuZS4sIGF0dGFja2VyIGNhbiBjYXVzZSBsZWdpbWl0ZSBub2RlIHRv IHJldHJhbnNtaXQgaXRzDQo+ID4gcHJldmlvdXMgbWVzc2FnZSBieSBkZXN0cm95aW5nIGFjaywg YW5kIHVwcGVyIGxheWVyIHByb3RvY29sIG11c3QNCj4gPiBwcm92aWRlIHdheSB0byBkZXRlY3Qg cmVwbGF5cyBhbmQgY29wZSB3aXRoIHRoZW0uDQo+ID4NCj4gPiBEdXJpbmcgdGhlIGF1dGhlbnRp Y2F0aW9uIHRoZSBKUkMgbmVlZHMgdG8gcHJvdmlkZSB0aGUga2V5aW5nIG1hdGVyaWFsDQo+ID4g dG8gdGhlIGpvaW5pbmcgbm9kZSwgYnV0IHRoYXQgZG9lcyBOT1QgcHJvdmlkZSBwcm90ZWN0aW9u IGFnYWluc3QNCj4gPiBzcG9vZmVkIEFTTi4gQWZ0ZXIgdGhlIG5vZGUgaGFzIGFjdHVhbCBrZXlz IHVzZWQgaW4gdGhlIG5ldHdvcmsgaXQNCj4gPiBzdGlsbCBuZWVkcyB0byB2ZXJpZnkgdGhlIEFT TiBieSBzZW5kaW5nIHNvbWUgbWVzc2FnZSB0byBKUkMgdXNpbmcNCj4gPiBhdXRoZW50aWNhdGlv biBhbmQgdmVyaWZ5IHRoYXQgSlJDIHJlcGxpZXMgdG8gdGhhdC4NCj4gPg0KPiA+IElmIHRoaXMg Mm5kIHN0ZXAgaXMgb21pdHRlZCBhdHRhY2tlciBkbyBmb2xsb3dpbmcgYXR0YWNrOg0KPiA+DQo+ ID4gSm9pbmluZyBub2RlIChKTikgICBhdHRhY2tlcgkgICAgIAkJICBKUkMNCj4gPiAJCSAgICA8 LSBiZWFjb24gZm9yIEFTTj0yMwkgIDwtIGJlYWNvbiBmb3IgQVNOPTQ0DQo+ID4gU2VlIGJlYWNv bg0KPiA+IGZyb20gYXR0YWNrZXIsDQo+ID4gYXNzdW1lIEFTTj0yMy4NCj4gPg0KPiA+IEF1dGgt PkpSQw0KPiA+IChubyBzZWN1cml0eSkJCQkJCSAgQ2hlY2sgYXV0aGVudGljYXRpb24NCj4gPiAJ CQkJCQkgIFJldHVybiBrZXlzDQo+ID4gCQkJCQkJICBrZXlzLT5KTg0KPiA+DQo+ID4gUmVjZWl2 ZSBrZXlzDQo+ID4gc2VuZCBmaXJzdA0KPiA+IGZyYW1lIHVzaW5nDQo+ID4ga2V5cyB1c2luZyBB U049MjMtPg0KPiA+DQo+ID4NCj4gPiBOb3csIGlmIEpOIGlzIHVzaW5nIGV4dGVuZGVkIGFkZHJl c3MgdG8gZ2VuZXJhdGUgbm9uY2UsIHRoZSBub25jZSB3aWxsDQo+ID4gYmUgZGlmZmVyZW50IGZv ciBhbGwgb3RoZXIgbm9uY2VzIGV2ZXIgdXNlZCwgZXZlbiB0aGUgQVNOIGlzIGZha2VkLA0KPiA+ IGFuZCBoYXMgYmVlbiB1c2VkIGJlZm9yZS4gT24gdGhlIG90aGVyIGhhbmQgaWYgSk4gYWxzbyBy ZWNlaXZlcyBzaG9ydA0KPiA+IGFkZHJlc3MgYXNzaWdubWVudCBmcm9tIHRoZSBKUkMsIEpSQyBu ZWVkcyB0byBtYWtlIHN1cmUgdGhhdCBzaG9ydA0KPiA+IGFkZHJlc3MgaGFzIG5vdCBiZWVuIGFz c2lnbmVkIHRvIGFueWJvZHkgZWxzZSBiZWZvcmUsIGFzIGlmIGl0IHdhcw0KPiA+IHVzZWQgYnkg c29tZW9uZSBlbHNlLCBhbmQgZnJhbWUgc2VudCBieSBKTiBpcyBlbmNyeXB0ZWQsIHRoZW4gYXR0 YWNrZXINCj4gPiB3aWxsIG5vdyBoYXZlIHR3byBwYWNrZXRzIHdpdGggc2FtZSBBU04sIGFuZCBz aG9ydCBhZGRyZXNzLCBtZWFuaW5nDQo+ID4gc2FtZSBub25jZSwgYW5kIGl0IGNhbiBub3cgZGVj cnlwdCBwYWNrZXRzLg0KPiANCj4gSXMgdGhpcyBkaXNjdXNzaW9uIG9mIG5vbmNlIHJldXNlIGlu IGFueSByZWxldmFudCBkb2N1bWVudHMgYWxyZWFkeSwgb3IgaXMgaXQNCj4gc29tZXRoaW5nIHRo YXQgc2hvdWxkIGJlIGFkZGVkIHNvbWV3aGVyZT8NCj4gDQo+ID4gTm90ZSwgdGhhdCBhdHRhY2tl ciBtaWdodCBiZSBhYmxlIHRvIHJlcGxheSB2YWxpZCBBQ0tzIGZvciB0aGUgZnJhbWUNCj4gPiBz ZW50IGJ5IHRoZSBKTiwgcHJvdmlkZWQgdGhhdCB0aGUgSlJDIChvciB3aG9ldmVyIEpOIHNlbnQg dGhlIG1lc3NhZ2UNCj4gPiB0bykgaGFwcGVuZWQgdG8gYWNrIG1lc3NhZ2UgdXNpbmcgdGhlIHNh bWUgQVNOIGF0dGFja2VyIGZha2VkIGZvciBKTi4NCj4gPg0KPiA+IElmIEpOIHNlbmRzIG1lc3Nh Z2UgdG8gSlJDIHdoaWNoIG9ubHkgSlJDIGNhbiByZXBseSwgYW5kIHVzZXMgd3JvbmcNCj4gPiBB U04sIHRoZSBKUkMgd2lsbCBub3QgYmUgYWJsZSB0byBkZWNyeXB0L3ZhbGlkYXRlIHRoYXQgZnJh bWUgYmVjYXVzZQ0KPiA+IG9mIHdyb25nIEFTTiBpbiBub25jZSwgYW5kIHdpbGwgZHJvcCBpdCBz aWxlbnRseSwgc28gaWYgSk4gdXNlcyB3cm9uZw0KPiA+IEFTTiBpdCBtaWdodCBiZSBnZXR0aW5n IEFDS3MsIGJ1dCBpdCB3aWxsIG5vdCBnZXQgYW55IHJlYWwgcmVwbHkNCj4gPiBmcmFtZXMgYmFj ayBmcm9tIHJlYWwgcGFydGljaXBhbnRzIGluIHRoZSBuZXR3b3JrLiBBZnRlciBpdCB3aWxsIG5v dA0KPiA+IHJlY2VpdmUgY29uZmlybWF0aW9uIGZyb20gSlJDIHRoYXQgaXQgaGFzIHByb3BlciBr ZXlzIGFuZCBBU04sIGl0DQo+ID4ga25vd3Mgc29tZXRoaW5nIHdlbnQgd3JvbmcuDQo+ID4NCj4g Pg0KPiA+PiBUaW1lIHN5bnRob25pemF0aW9uIChwcmVjaXNlIHRpYywgaG91cmxlc3MpDQo+ID4+ IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQo+ID4+IFRoaXMgaXMgdGhlIHByb2Nlc3Mgd2hlcmVieSBhIG5vZGUgY29ycmVjdHMgaXRzIHRp YyB0byByZWFsaWduIHdpdGgNCj4gPj4gdGhlIHBhcmVudC4gQVNOIGlzIG5vdCBjaGFuZ2VkIGJ1 dCB0aGUgZHJpZnQgb2YgY3J5c3RhbHMgaXMNCj4gPj4gY29tcGVuc2F0ZWQuIEFuIGF0dGFja2Vy IGNvdWxkIHRyeSB0byBpbmplY3QgYSBzZW5zZSBvZiB0aW1lIHRoYXQgaXQNCj4gPj4gc2xpZ2h0 bHkgc2hpZnRlZCB0byB0aGUgcG9pbnQgdGhhdCB0aGUgbm9kZSBsb3NlIHN5bmMgd2l0aCB0aGUg cmVzdA0KPiA+PiBvZiB0aGUgbmV0d29yayAodGhlIGd1YXJkIHRpbWUgaXMgbGlrZSBhbiBldmVu dCBob3Jpem9uKS4gVGhlbiBhZ2FpbiwNCj4gPj4gUlBMIHByb3ZpZGVzIGFuIGFkZGl0aW9uYWwg cHJvdGVjdGlvbiBvbiB0b3Agb2YgdGhlIE1BQyBwcm92aXNpb25zLg0KPiA+DQo+ID4gVGhvc2Ug dGltZSBzeW5jcm9uaXphdGlvbiBJRXMgYXJlIGFsc28gcHJvdGVjdGVkIGJ5IE1BQyBsZXZlbA0K PiA+IGF1dGhlbnRpY2F0aW9uLCBzbyBhdHRhY2tlcnMgd2hvIGRvIG5vdCBrbm93IHRoZSBrZXlz IGNhbm5vdCBnZW5lcmF0ZQ0KPiA+IHRoZW0uIEF0dGFja2VycyB3aG8gZG8ga25vdyBrZXlzIGNh biBkbyB3aGF0ZXZlciB0aGV5IGxpa2UgYW55d2F5cy4uLg0KPiA+DQo+ID4gQnR3LCBJIHdpbGwg YmUgbGVhdmluZyBmb3IgdmFjYXRpb24gdG9tb3Jyb3csIHNvIEkgbWlnaHQgbm90IGJlIGFibGUN Cj4gPiB0byByZXBseSBhbnkgbWVzc2FnZXMgcmVsYXRlZCB0byB0aGlzIHVudGlsIEkgZ2V0IGJh Y2sgZW5kIG9mIG5leHQNCj4gPiB3ZWVrLg0KPiA+DQo= From nobody Tue Jun 25 04:05:32 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41E251205B5; Tue, 25 Jun 2019 04:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 36OnLBfNttB3; Tue, 25 Jun 2019 04:05:16 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.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 59BC01204ED; Tue, 25 Jun 2019 04:05:14 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x5PB4Ylh024389 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 25 Jun 2019 14:04:34 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x5PB4X0H007415; Tue, 25 Jun 2019 14:04:33 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23825.65473.306890.930708@fireball.acr.fi> Date: Tue, 25 Jun 2019 14:04:33 +0300 From: Tero Kivinen To: David Mandelberg Cc: "Pascal Thubert \(pthubert\)" , "secdir\@ietf.org" , "iesg\@ietf.org" , "draft-ietf-6tisch-architecture.all\@ietf.org" , Thomas Watteyne , Michael Richardson , =?utf-8?Q?Mali=C5=A1a_Vu=C4=8Dini=C4=87?= In-Reply-To: <5229f400-076c-80e3-e0dc-a7cf3998abed@mandelberg.org> References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> <23825.24715.882644.180316@fireball.acr.fi> <5229f400-076c-80e3-e0dc-a7cf3998abed@mandelberg.org> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 2 min Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 11:05:23 -0000 David Mandelberg writes: > > During the authentication the JRC needs to provide the keying material > > to the joining node, but that does NOT provide protection against > > spoofed ASN. After the node has actual keys used in the network it > > still needs to verify the ASN by sending some message to JRC using > > authentication and verify that JRC replies to that. > > > > If this 2nd step is omitted attacker do following attack: > > > > Joining node (JN) attacker JRC > > <- beacon for ASN=23 <- beacon for ASN=44 > > See beacon > > from attacker, > > assume ASN=23. > > > > Auth->JRC > > (no security) Check authentication > > Return keys > > keys->JN > > > > Receive keys > > send first > > frame using > > keys using ASN=23-> > > > > > > Now, if JN is using extended address to generate nonce, the nonce will > > be different for all other nonces ever used, even the ASN is faked, > > and has been used before. On the other hand if JN also receives short > > address assignment from the JRC, JRC needs to make sure that short > > address has not been assigned to anybody else before, as if it was > > used by someone else, and frame sent by JN is encrypted, then attacker > > will now have two packets with same ASN, and short address, meaning > > same nonce, and it can now decrypt packets. > > Is this discussion of nonce reuse in any relevant documents already, or > is it something that should be added somewhere? All 802.15.4 documents assume that ASN is already distributed securely to the nodes having keys. I.e., this attack is not considered by those documents, as it is outside the scope of them... -- kivinen@iki.fi From nobody Tue Jun 25 05:46:19 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1173B1200F8; Tue, 25 Jun 2019 05:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 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_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=nGiRDYRs; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=DMTHokLf 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 jyxZ_esJnokO; Tue, 25 Jun 2019 05:46:06 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FE95120025; Tue, 25 Jun 2019 05:46:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1933; q=dns/txt; s=iport; t=1561466766; x=1562676366; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=kmZC0DSMAW0H6fIclMv6aFJQY3l41WoHjKkA1PD69J0=; b=nGiRDYRsA4pXDj3Wz3ZLvPR62NY91jUm4oM7xbWttXDmHbPk3Xhl7HLc lJ/biYJd1zrfuJjw1hEQur8x9qDGKz1BYZhNe9rEv5vOxKSiZSkc6ZXBG HXcU7Zl8sOgQkJF0YbOXaUfAhlwBqgVkIDYARjgAcxKH92umXUDqY+9vt I=; IronPort-PHdr: =?us-ascii?q?9a23=3AbUzttRRbvVvLut8zdKh89A80qtpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjQmHNlIWUV513q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AkAACFFhJd/51dJa1mGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBVAUBAQELAYFDUAOBPyAECyiHXQOOYUyCD5c4gS6BJANUCQEBAQw?= =?us-ascii?q?BAS0CAQGEQAKCdCM1CA4BAwEBBAEBAgEFbYo3DIVKAQEBAQIBEi4BATcBBAs?= =?us-ascii?q?CAQgSNDIXDgIEDg0ahGsDDg8BApoMAoE4iF+CIoJ5AQEFhQAYghEJgTQBhHC?= =?us-ascii?q?GUB0XgUA/gVeCTD6ERoM6giaOJZtzCQKCFZQGl06kNgIEAgQFAg4BAQWBUgM?= =?us-ascii?q?zgVhwFYMngkGDcIpTcoEpjCIrgiUBAQ?= X-IronPort-AV: E=Sophos;i="5.63,415,1557187200"; d="scan'208";a="584993555" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Jun 2019 12:46:04 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x5PCk3XP014286 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Jun 2019 12:46:03 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 25 Jun 2019 07:46:02 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 25 Jun 2019 07:46:02 -0500 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 25 Jun 2019 07:46:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kmZC0DSMAW0H6fIclMv6aFJQY3l41WoHjKkA1PD69J0=; b=DMTHokLf14phsLMwpXbetkYwKj3Tmo3nRzzKpNOzC3GWWgTJ3lyGO5tIq5NKYeBHT04HnPfmrqP8CTVNrLVwkSrKk1wNsK9Dx6ltVdBKCgm40FFyRl9x9YR7YYY7whkvOvTd1k0ISY+EgYoDs9deDTQwymGs6hlrQjgq7PvJOpw= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4046.namprd11.prod.outlook.com (20.179.149.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Tue, 25 Jun 2019 12:46:00 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2008.017; Tue, 25 Jun 2019 12:46:00 +0000 From: "Pascal Thubert (pthubert)" To: Tero Kivinen CC: David Mandelberg , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-6tisch-architecture.all@ietf.org" , Thomas Watteyne , Michael Richardson , =?iso-8859-2?Q?Mali=B9a_Vu=E8ini=E6?= Thread-Topic: [secdir] secdir review of draft-ietf-6tisch-architecture-21 Thread-Index: AQHVKitVZAMqDsUZHEuS/CYS/vDUhKaqVH6wgAEk6YCAAHyKMA== Date: Tue, 25 Jun 2019 12:45:55 +0000 Deferred-Delivery: Tue, 25 Jun 2019 12:44:56 +0000 Message-ID: References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> <23825.24715.882644.180316@fireball.acr.fi> In-Reply-To: <23825.24715.882644.180316@fireball.acr.fi> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:44f3:1300:552f:ff32:b86:aad7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 74f9fce0-2c34-4d54-2efb-08d6f96b13c2 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB4046; x-ms-traffictypediagnostic: MN2PR11MB4046: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0079056367 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(376002)(39860400002)(396003)(136003)(189003)(199004)(71190400001)(81156014)(2906002)(66476007)(81166006)(54906003)(66556008)(14454004)(8676002)(305945005)(73956011)(74316002)(6436002)(316002)(99286004)(5660300002)(66946007)(76176011)(8936002)(186003)(6116002)(6506007)(66446008)(86362001)(476003)(229853002)(11346002)(446003)(76116006)(6916009)(9686003)(33656002)(55016002)(25786009)(4326008)(53936002)(68736007)(256004)(46003)(486006)(14444005)(71200400001)(7696005)(478600001)(102836004)(52536014)(6666004)(6246003)(64756008)(7736002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4046; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: eaxeLxHlj0BjMicF1iMRKb+XEl194L8XSrFoqpSKV8iY5nBIXSiXoLmAUh9b4q9khCm2Jx1hGWvYDFMpSUauwx5UnxEnvCSeSoIy2hkP6eOqIYPZSEWMnqEVjIBPAA6x0H9KH8dyXNOd8kTuj2u3rJILGAmJZLxGordi50L2DcRni1gdSDIbLc15ymTRq5xlf9R46izRPj9EjzmUEEDG26/L/frcPO9GuMpZ4wW/xgv3WVhWvMTu6gtN+LasmMH0/Lbgbr79qxnPn63RacmdQOQYDwT7aLETGBGzVsrbxDNqx0Whq4fF7rlpXGRfjCyNfkcGN6V0KKNX5WdW8Fsb+sY5dnRvOSBgYHsAhTEZKWtLdQeARvIIo3SYS3Mw7KK0XJptiLtH1ZiNuSQfXevMHOrAkNSvM0AqtJQknHpV+aU= Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 74f9fce0-2c34-4d54-2efb-08d6f96b13c2 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2019 12:46:00.6524 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4046 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 12:46:09 -0000 Hello Tero: Some clarification questions below: > Now, if JN is using extended address to generate nonce, the nonce will be > different for all other nonces ever used, even the ASN is faked, and has = been This is assuming that the attacker is not attacking the same device twice, = isn't it? > used before. On the other hand if JN also receives short address assignme= nt > from the JRC, JRC needs to make sure that short address has not been > assigned to anybody else before, as if it was used by someone else, and f= rame > sent by JN is encrypted, then attacker will now have two packets with sam= e > ASN, and short address, meaning same nonce, and it can now decrypt packet= s. That's unless new keys are given if the short address is reattributed, corr= ect? > Note, that attacker might be able to replay valid ACKs for the frame sent= by > the JN, provided that the JRC (or whoever JN sent the message > to) happened to ack message using the same ASN attacker faked for JN. Your mean that the faked ASN is only slightly in the future, so the attacke= r can repeat messages from the pledge after that delay? > If JN sends message to JRC which only JRC can reply, and uses wrong ASN, = the > JRC will not be able to decrypt/validate that frame because of wrong ASN = in > nonce, and will drop it silently, so if JN uses wrong ASN it might be get= ting > ACKs, but it will not get any real reply frames back from real participan= ts in the > network. After it will not receive confirmation from JRC that it has prop= er keys > and ASN, it knows something went wrong. I'm not sure about the status of sync'ing the JRC with the network. Minimal= -security does not discuss it. Talking to Malisa to improve that piece proa= ctively to the sec-dir review. I'll propose text based on your reply and Malisa's separately. Many thanks for your clarifications! Pascal From nobody Tue Jun 25 06:37:17 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B09F91200D8; Tue, 25 Jun 2019 06:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=UR4dNTWl; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=iBIRbCbE 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 MEf6bUgJAisF; Tue, 25 Jun 2019 06:37:06 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0918712008F; Tue, 25 Jun 2019 06:37:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7440; q=dns/txt; s=iport; t=1561469826; x=1562679426; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RSuZY1J6lNofrJ7MEjB/jRJbo4tZH1nwbl0iZbOToD8=; b=UR4dNTWlVTUmhQM40Y1+XMvOdyo1hKexf32mSxEySl2yv0uKVQmeQyeF MPHj42MbopeV4vENBORAGtuKRnOLkT4YM2uAqPT5vSnGuTG4E1z7m/ZAg SOYzu4OkE+Z3emnNZUpOHnzeNFFIPb0iB7eGgMjf3xIkmJMl7v9mocPNv 4=; IronPort-PHdr: =?us-ascii?q?9a23=3Ao9qqRxET8sKy0JpQVXhIWJ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeb2bzEwEd5efFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CqAADHIhJd/5pdJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBZ4FEUAOBPyAECyiEFoNHA45hgluXOIJSA1QJAQEBDAEBLQI?= =?us-ascii?q?BAYRAAheCXiM4EwEDAQEEAQECAQVtijcMhUoBAQEBAxIREQwBATcBCwQCAQg?= =?us-ascii?q?RAQMBAQMCJgICAjAVAgYIAgQBDQUIGoRrAx0BApoNAoE4iF9xgTGCeQEBBYU?= =?us-ascii?q?AGIIRCYEMKIkVdoE2HReBQD+BEUaCTD6ERoMIMoImi3qCWocglCQJAoIVizK?= =?us-ascii?q?IVIIphw6EC4oMjSiXDgIEAgQFAg4BAQWBZyGBWHAVgyeBSXgMF4NNilNygSm?= =?us-ascii?q?MIiuCJQEB?= X-IronPort-AV: E=Sophos;i="5.63,416,1557187200"; d="scan'208";a="361772157" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Jun 2019 13:37:04 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x5PDb4RT022702 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 25 Jun 2019 13:37:04 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 25 Jun 2019 08:37:03 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 25 Jun 2019 09:37:02 -0400 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 25 Jun 2019 08:37:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=RSuZY1J6lNofrJ7MEjB/jRJbo4tZH1nwbl0iZbOToD8=; b=iBIRbCbEpWWDNdOUGKMhT3diDk+3bbVRyhE8fmQNkzLeeyE/FlvKa5MXWwnslniwh0yXFxZcygATHHbKEOnZNcHS05u6y8VMoN8V8zLeaOf8FcVmf/5S4mw1J0RgGD3vj/2BFDW4HldXdkuNHKD6T2QvfmZsCWCWt+/PmAIpDWs= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3549.namprd11.prod.outlook.com (20.178.250.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Tue, 25 Jun 2019 13:37:01 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2008.017; Tue, 25 Jun 2019 13:37:01 +0000 From: "Pascal Thubert (pthubert)" To: David Mandelberg , =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= , Tero Kivinen , Michael Richardson CC: "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-6tisch-architecture.all@ietf.org" Thread-Topic: secdir review of draft-ietf-6tisch-architecture-21 Thread-Index: AQHVKitVZAMqDsUZHEuS/CYS/vDUhKasV4Dg Date: Tue, 25 Jun 2019 13:36:34 +0000 Deferred-Delivery: Tue, 25 Jun 2019 13:36:22 +0000 Message-ID: References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> In-Reply-To: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:44f3:1300:552f:ff32:b86:aad7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5b1b7f4c-46f9-4fc9-1aa8-08d6f97233f4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3549; x-ms-traffictypediagnostic: MN2PR11MB3549: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0079056367 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(366004)(136003)(39860400002)(396003)(376002)(189003)(199004)(13464003)(54906003)(7696005)(110136005)(46003)(316002)(68736007)(99286004)(478600001)(71190400001)(76176011)(71200400001)(52536014)(73956011)(486006)(76116006)(66446008)(256004)(66556008)(66476007)(14444005)(446003)(11346002)(64756008)(6666004)(14454004)(5024004)(33656002)(476003)(66946007)(53936002)(81166006)(86362001)(8676002)(6436002)(2906002)(81156014)(55016002)(6246003)(9686003)(8936002)(74316002)(305945005)(7736002)(5660300002)(229853002)(25786009)(186003)(53546011)(102836004)(4326008)(6506007)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3549; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 9xyGPLoWZ2CgUzQWnPermIdniD8rLHQ3d9R/OoDNvfIlerbnN6tlytedn6xmKhRQ/K6cbnnOI9BMQgeSxkrVCabCvfaAEoFHSYhr1OM/tHCK1vLgehJ83VsAVSW1yY2c9WVux91Kxru6YKVLrO/j+1nCKlSlOZjb5ISuWkrEaZG4H6kld6p4pN+JkNL5KVYbam5XiDIWKEeaujt3JczfBaVZ7MGwy1y1feeVChhMg+ItLQOPdbriO61Og1/Xx99ojU5qj/f7FiJ3IHO3JRs1tfdG7v+fb8dSRhKclcWO6BzdqRwaJ8RNUnoWHnNJJDVIu1k/PZKLQeCICGNZyhqt7BRfrTnigH4pYdpWxytawSm1A08y/PJio70DqmV67Ccs79rRaaUnk0GmPtfG/PGye8u7cctsgl3ff15Ed34XRzs= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5b1b7f4c-46f9-4fc9-1aa8-08d6f97233f4 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2019 13:37:01.1358 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3549 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.26, xch-rcd-016.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 13:37:09 -0000 T2sgc28gd2Ugd2VudCB0aHJvdWdoIGEgbG90IGJhc2VkIG9uIHRoaXMgQVNOIGRpc2N1c3Npb24u DQpJIHByb2R1Y2VkIHRoZSBmb2xsb3dpbmcuDQpNaWNoYWVsLCBNYWxpc2EgYW5kIFRlcm8gcGxl YXNlIGNvbmZpcm0gdGhhdCBpdCBsb29rcyBnb29kIC8gaGVscCBtZSBmaXggaXQgOiApDQoNCiIN CiAgVGhlIG9wZXJhdGlvbiBvZiA2VGlTQ0ggVHJhY2tzIGluaGVyaXRzIGl0cyBoaWdoIGxldmVs IG9wZXJhdGlvbiBmcm9tDQogICBEZXROZXQgYW5kIGlzIHN1YmplY3QgdG8gdGhlIG9ic2VydmF0 aW9ucyBpbiBzZWN0aW9uIDUgb2YNCiAgIFtJLUQuaWV0Zi1kZXRuZXQtYXJjaGl0ZWN0dXJlXS4g IEFzIGRpc2N1c3NlZCB0aGVyZSwgbWVhc3VyZXMgbXVzdCBiZQ0KICAgdGFrZW4gdG8gcHJvdGVj dCB0aGUgdGltZSBzeW5jaHJvbml6YXRpb24sIGFuZCBmb3IgNlRpU0NIIHRoaXMNCiAgIGluY2x1 ZGVzIGVuc3VyaW5nIHRoYXQgdGhlIEFic29sdXRlIFNsb3QgTnVtYmVyIChBU04pLCB3aGljaCBp cyB1c2VkDQogICBhcyBldmVyIGluY3JlbWVudGluZyBjb3VudGVyIGZvciB0aGUgY29tcHV0YXRp b24gb2YgdGhlIExpbmstTGF5ZXINCiAgIHNlY3VyaXR5IG5vbmNlLCBpcyBub3QgY29tcHJvbWlz ZWQsIG1vcmUgYmVsb3cgb24gdGhpcy4gIA0KDQo8c25pcD4NCg0KICAgSW4gYSBUU0NIIG5ldHdv cmsgYXMgc3BlY2lmaWVkIGJ5IElFRUUgU3RkLiA4MDIuMTUuNCBbSUVFRTgwMjE1NF0sDQogICB0 aGUgbm9uY2UgdGhhdCBpcyB1c2VkIHRvIHNlY3VyZSBMaW5rLUxheWVyIGV4Y2hhbmdlcyBpbmNs dWRlcyBhbg0KICAgYWRkcmVzcyBvZiB0aGUgc291cmNlIGFuZCB0aGUgQVNOLiAgVGhlIEFTTiBp dHNlbGYgaXMgc3VwcG9zZWQgdG8gYmUNCiAgIGRpc3RyaWJ1dGVkIHNlY3VyZWx5IGJ5IG90aGVy IG1lYW5zLiAgSWYgdGhlIEFTTiBpcyBjb21wcm9taXNlZCBhbmQgYQ0KICAgc2hvcnQgYWRkcmVz cyBpcyByZXVzZWQsIHRoZW4gYSBub25jZS1yZXVzZSBhdHRhY2sgYmVjb21lcyBwb3NzaWJsZS4N Cg0KICAgV2l0aCA2VGlTQ0gsIHRoZSBwbGVkZ2UgZGlzY292ZXJzIGEgdGVudGF0aXZlIEFTTiBp biBiZWFjb25zIHNlbnQgYnkNCiAgIG5vZGVzIHRoYXQgaGF2ZSBhbHJlYWR5IGpvaW5lZCB0aGUg bmV0d29yay4gIEFzIHRoZSBwbGVkZ2UgaXMgbm90IGluDQogICBwb3NzZXNzaW9uIG9mIExpbmst TGF5ZXIga2V5cyBmb3IgdGhlIHZpc2l0ZWQgbmV0d29yaywgaXQgY2Fubm90DQogICB2ZXJpZnkg dGhlIG1lc3NhZ2UgaW50ZWdyaXR5IGNvZGUgKE1JQykgYXV0aGVudGljYXRpbmcgdGhlIGJlYWNv bi4NCiAgIEV2ZW4gaWYgaXQgZGlkIGhhdmUgdGhlIGtleXMsIGl0IHN0aWxsIGNvdWxkIG5vdCB2 ZXJpZnkgdGhlIGJlYWNvbiBhcw0KICAgaXQgY291bGQgYmUgYSByZXBsYXkgYnkgYW4gYXR0YWNr ZXIgYW5kIHRodXMgY291bGQgc3RpbGwgYW5ub3VuY2UgYW4NCiAgIEFTTiB0aGF0IHJlcHJlc2Vu dHMgYSB0aW1lIGluIHRoZSBwYXN0LiAgVGhhdCB0aW1lIHdvdWxkIG1hdGNoIGENCiAgIHZhbGlk IHRpbWVzbG90IGl0IGlmIGlzIGNvcnJlY3QgbW9kdWxvIHRoZSBudW1iZXIgb2YgY2hhbm5lbHMg dXNlZCBmb3INCiAgIGhvcHBpbmcuDQoNCiAgIEFmdGVyIG9idGFpbmluZyB0aGF0IHRlbnRhdGl2 ZSBBU04sIHRoZSBwbGVkZ2UgYXV0aGVudGljYXRlcyBpdHNlbGYNCiAgIHRvIHRoZSBuZXR3b3Jr IHVzaW5nIHNvbWUgbWVjaGFuaXNtIG91dHNpZGUgb2YgSUVFRSBTdGQgODAyLjE1LjQuDQogICBX aXRoIDZUaVNDSCwgYSBKb2luIFByb3h5IChKUCkgaGVscHMgdGhlIHBsZWRnZSBmb3IgdGhlIGpv aW4NCiAgIHByb2NlZHVyZSBieSByZWxheWluZyB0aGUgbGluay1zY29wZSBKb2luIFJlcXVlc3Qg b3ZlciB0aGUgSVAgbmV0d29yaw0KICAgdG8gYSBKb2luIFJlZ2lzdHJhci9Db29yZGluYXRvciAo SlJDKSB0aGF0IGNhbiBhdXRoZW50aWNhdGUgdGhlDQogICBwbGVkZ2UgYW5kIHZhbGlkYXRlIHRo YXQgaXQgaXMgYXR0YWNoZWQgdG8gdGhlIGFwcHJvcHJpYXRlIG5ldHdvcmsuDQogICBBcyBhIHJl c3VsdCBvZiB0aGlzIGV4Y2hhbmdlIHRoZSBwbGVkZ2UgaXMgaW4gcG9zc2Vzc2lvbiBvZiBhIExp bmstDQogICBMYXllciBtYXRlcmlhbCBpbmNsdWRpbmcgYSBrZXkgYW5kIGEgc2hvcnQgYWRkcmVz cywgYW5kIGFzc3VtaW5nIHRoYXQNCiAgIHRoZSBBU04gaXMgY29ycmVjdCwgYWxsIHRyYWZmaWMg Y2FuIGJlIHNlY3VyZWQgYXQgdGhlIExpbmstTGF5ZXIuDQoNCiAgIFRoaXMgYXV0aGVudGljYXRp b24gc3RlcHMgbXVzdCBiZSBzdWNoIHRoYXQgdGhleSBjYW5ub3QgYmUgcmVwbGF5ZWQNCiAgIGJ5 IGFuIGF0dGFja2VyLCBhbmQgaXQgbXVzdCBub3QgZGVwZW5kIG9uIHRoIHRlbnRhdGl2ZSBBU04g YmVpbmcNCiAgIHZhbGlkLiAgTm90ZSB0aGF0IElFRUUgc3RkLiA4MDIuMTUuNCBUU0NIIGRvZXMg bm90IHByb3ZpZGUgcmVwbGF5DQogICBwcm90ZWN0aW9uIGF0IGFsbCwgYW5kIHRoYXQgZm9yIGlu c3RhbmNlIGF0dGFja2VyIGNhbiBjYXVzZSBhDQogICBsZWdpdGltYXRlIG5vZGUgdG8gcmV0cmFu c21pdCBhIHByZXZpb3VzIG1lc3NhZ2UgYnkgZGVzdHJveWluZyBhbg0KICAgYWNrLiBJdCByZXN1 bHRzIGFuZCB1cHBlciBsYXllciBwcm90b2NvbCBtdXN0IHByb3ZpZGUgYSB3YXkgdG8gZGV0ZWN0 DQogICByZXBsYXllZCBtZXNzYWdlcyBhbmQgY29wZSB3aXRoIHRoZW0uDQoNCiAgIER1cmluZyB0 aGUgYXV0aGVudGljYXRpb24gdGhlIGtleWluZyBtYXRlcmlhbCB0aGF0IHRoZSBwbGVkZ2Ugb2J0 YWlucw0KICAgZnJvbSB0aGUgSlJDIGRvZXMgTk9UIHByb3ZpZGUgcHJvdGVjdGlvbiBhZ2FpbnN0 IHNwb29mZWQgQVNOLiAgT25jZQ0KICAgdGhlIHBsZWRnZSBoYXMgb2J0YWluZWQgdGhlIGtleXMg dG8gdXNlIGluIHRoZSBuZXR3b3JrLCBpdCBzdGlsbA0KICAgbmVlZHMgdG8gdmVyaWZ5IHRoZSBB U04uICBJZiB0aGUgbm9uY2UgdXNlZCBpbiB0aGUgTGF5ZXItMiBzZWN1cml0eQ0KICAgZGVyaXZl cyBmcm9tIHRoZSBleHRlbmRlZCAoTUFDLTY0KSBhZGRyZXNzLCB0aGVuIHJlcGxheWluZyB0aGUg QVNODQogICBhbG9uZSBjYW5ub3QgZW5hYmxlIGEgbm9uY2UtcmV1c2UgYXR0YWNrIHVubGVzcyB0 aGUgc2FtZSBub2RlIGlzDQogICBhdHRhY2tlZCB0d2ljZSBhbmQgbG9zZXMgYWxsIHN0YXRlIGlu LWJldHdlZW4uICBCdXQgaWYgdGhlIG5vbmNlDQogICBkZXJpdmVzIGZyb20gdGhlIHNob3J0IGFk ZHJlc3MgKGUuZy4sIGFzc2lnbmVkIGJ5IHRoZSBKUkMpIHRoZW4gdGhlDQogICBub25jZS1yZXVz ZSBhdHRhY2tzIGFyZSBwb3NzaWJsZSwgYW5kIHRoZSBKUkMgbXVzdCBlbnN1cmUgdGhhdCBpdA0K ICAgbmV2ZXIgYXNzaWducyBzaG9ydCBhZGRyZXNzZXMgdGhhdCB3ZXJlIGFscmVhZHkgZ2l2ZW4g dG8gdGhpcyBvcg0KICAgb3RoZXIgbm9kZXMgd2l0aCB0aGUgc2FtZSBrZXlzLg0KDQogICBBdCB0 aGF0IHBvaW50LCBhbiBhZGRpdGlvbmFsIHN0ZXAgbWF5IGJlIHJlcXVpcmVkIHRvIGVuc3VyZSB0 aGF0IHRoZQ0KICAgQVNOIGlzIGNvcnJlY3QuICBGb3IgaW5zdGFuY2UsIHRoZSBwbGVkZ2UgY291 bGQgcGVyZm9ybSBhIGZpcnN0DQogICBleGNoYW5nZSB3aXRoIGEgcGVlciBub2RlIHRoYXQgaXMg dHJ1c3RlZCBhbmQgaGFzIGFscmVhZHkgam9pbmVkLA0KICAgZS5nLiwgaXRzIFJQTCB0aW1lIHBh cmVudCwgYW5kIHRoZSBtZXNzYWdlIHNob3VsZCBub3QgYmUgZW5jcnlwdGVkDQogICBidXQgb25s eSBhdXRoZW50aWNhdGVkIGF0IHRoZSBMaW5rLUxheWVyLiAgVGhlIHJlcXVlc3QgZnJvbSB0aGUN CiAgIHBsZWRnZSBzaG91bGQgY29udGFpbiBhIG5vbmNlIHdpdGggYSByYW5kb20gcGFydCB0aGF0 IGlzIG5vdCBBU04sIGFuZA0KICAgdGhlIGF1dGhlbnRpY2F0ZWQgcmVzcG9uc2Ugc2hvdWxkIGNv bnRhaW4gdGhlIGN1cnJlbnQgQVNOIGFuZCBlY2hvDQogICB0aGUgbm9uY2UuDQoNCg0KIg0KDQpB bGwgdGhlIGJlc3QsDQoNClBhc2NhbA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IEZyb206IERhdmlkIE1hbmRlbGJlcmcgPGRhdmlkQG1hbmRlbGJlcmcub3JnPg0KPiBTZW50OiBs dW5kaSAyNCBqdWluIDIwMTkgMDM6MjINCj4gVG86IHNlY2RpckBpZXRmLm9yZzsgaWVzZ0BpZXRm Lm9yZzsgZHJhZnQtaWV0Zi02dGlzY2gtYXJjaGl0ZWN0dXJlLmFsbEBpZXRmLm9yZw0KPiBTdWJq ZWN0OiBzZWNkaXIgcmV2aWV3IG9mIGRyYWZ0LWlldGYtNnRpc2NoLWFyY2hpdGVjdHVyZS0yMQ0K PiANCj4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJp dHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nDQo+IGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9j dW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUgSUVTRy4gIFRoZXNlDQo+IGNvbW1lbnRzIHdl cmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVh IGRpcmVjdG9ycy4NCj4gRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVh dCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55DQo+IG90aGVyIGxhc3QgY2FsbCBjb21tZW50 cy4NCj4gDQo+IFRoZSBzdW1tYXJ5IG9mIHRoZSByZXZpZXcgaXMgUmVhZHkgd2l0aCBuaXRzLg0K PiANCj4gVGhlIHJldmlldyBkZWFkbGluZSBmb3IgdGhpcyB3YXMgcmVhbGx5IHNob3J0LCBzbyBJ IGRpZG4ndCBoYXZlIGEgY2hhbmNlIHRvIHJlYWQNCj4gdGhpcyBhcyBjbG9zZWx5IGFzIEkgd291 bGQgaGF2ZSBsaWtlZC4gVGhhdCBzYWlkLCBmcm9tIHNraW1taW5nIHRoZSBkb2N1bWVudA0KPiBh bmQgcmVhZGluZyB0aGUgc2VjdGlvbnMgdGhhdCBsb29rZWQgbW9zdCBpbnRlcmVzdGluZywgaXQg bG9va3MgcHJldHR5IGdvb2QuDQo+IFRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9u IGNvdmVycyB3aGF0IEkgZXhwZWN0ZWQgaXQgdG8uIEkgaGF2ZSBvbmx5DQo+IG9uZSBxdWVzdGlv bi9jb25jZXJuOg0KPiANCj4gU2VjdGlvbnMgNC4yLjEgYW5kIDQuMy40IHRhbGsgYWJvdXQgdGhl IHNlY3VyaXR5IG9mIGpvaW5pbmcgYSBuZXR3b3JrLCBhbmQgdGltZQ0KPiBzeW5jaHJvbml6YXRp b24sIHJlc3BlY3RpdmVseS4gRG8gYW55IG9mIHRoZSBzZWN1cml0eSBtZWNoYW5pc21zIGluIDQu Mi4xIHJlbHkNCj4gb24gaGF2aW5nIGFuIGFjY3VyYXRlIGNsb2NrPyAoRS5nLiwgdG8gZGlzdHJ1 c3Qgb2xkL2V4cGlyZWQga2V5cy4pIElzIHRpbWUNCj4gc3luY2hyb25pemF0aW9uIGRvbmUgYmVm b3JlIHRoZSBqb2luIHByb2Nlc3MsIGFuZCBpcyB0aGVyZSBhbnkgd2F5IHRvIGV4cGxvaXQNCj4g dGltZSBzeW5jaHJvbml6YXRpb24gaW4gb3JkZXIgdG8gY2F1c2UgYSBub2RlIHRvIGpvaW4gYSBt YWxpY2lvdXMgbmV0d29yaz8NCg== From nobody Tue Jun 25 06:38:08 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A272212008F; Tue, 25 Jun 2019 06:37:54 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 sorEmBsAlWcC; Tue, 25 Jun 2019 06:37:52 -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 BBC9F12003F; Tue, 25 Jun 2019 06:37:52 -0700 (PDT) Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x5PDTKqw019582; Tue, 25 Jun 2019 06:37:44 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=hkg6FlyLJ/xNqHV64uFJeKMsWq6a9TeMHsPDWfL0cCE=; b=pd5+H0BuITLKbWuNNRYfLC9Iz756OyvI85hAoNdnBvVlXOBIZC+ZNlzsgKUlGrVqs+Xo y4O1POgrq9DIfGBNmaqlezC7XW9My4yWuiiZLiDkUL70O3r9VuCwLIaFll2/fngEMIQK 4Vxli2sueS0GV8j4ZzaMHS7h7ThZVkkvNPIm19NpG8lENOnypMDHoYx6yi7YB+bXFBzQ PCvRBa7YgYLQ9PuSPXRYl0DxnUphZU8nG4rGwsZVrf0IA5DqNIEcHiWpwcDgyYK22/Az +riTjMNAIeDl3fNXWazA5nTHo5LQRFnn4GznkOMXg0a+RsWeKegudTFZdJ3OjR8bUdDc cw== Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp2053.outbound.protection.outlook.com [104.47.41.53]) by mx0b-00273201.pphosted.com with ESMTP id 2tbee4gqcg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 25 Jun 2019 06:37:43 -0700 Received: from BYAPR05MB5256.namprd05.prod.outlook.com (20.177.231.94) by BYAPR05MB4104.namprd05.prod.outlook.com (52.135.199.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.13; Tue, 25 Jun 2019 13:37:41 +0000 Received: from BYAPR05MB5256.namprd05.prod.outlook.com ([fe80::9888:79c2:fa09:2995]) by BYAPR05MB5256.namprd05.prod.outlook.com ([fe80::9888:79c2:fa09:2995%7]) with mapi id 15.20.2008.007; Tue, 25 Jun 2019 13:37:41 +0000 From: Yimin Shen To: Christian Huitema , "secdir@ietf.org" CC: "draft-ietf-mpls-egress-protection-framework.all@ietf.org" , "ietf@ietf.org" , "mpls@ietf.org" , "BRUNGARD, DEBORAH A" Thread-Topic: Secdir last call review of draft-ietf-mpls-egress-protection-framework-05 Thread-Index: AQHVJXazPgjNq5VAq0WZnhgezs45zqasKFUA Date: Tue, 25 Jun 2019 13:37:41 +0000 Message-ID: References: <156082197755.22389.14803953372788869090@ietfa.amsl.com> In-Reply-To: <156082197755.22389.14803953372788869090@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.a.190512 x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 241c1b0e-1e7b-4a9f-a697-08d6f9724c0d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:BYAPR05MB4104; x-ms-traffictypediagnostic: BYAPR05MB4104: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0079056367 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(39860400002)(136003)(366004)(346002)(199004)(189003)(33656002)(186003)(6116002)(3846002)(25786009)(8936002)(8676002)(478600001)(4326008)(5660300002)(26005)(71190400001)(71200400001)(53936002)(54906003)(14444005)(256004)(66446008)(76116006)(73956011)(66946007)(66476007)(66556008)(64756008)(76176011)(6486002)(36756003)(6436002)(99286004)(446003)(305945005)(7736002)(476003)(486006)(2906002)(2501003)(14454004)(2616005)(86362001)(102836004)(316002)(58126008)(110136005)(66574012)(6246003)(81166006)(81156014)(6506007)(68736007)(229853002)(11346002)(6512007)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4104; H:BYAPR05MB5256.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-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Faa8NnCQTGSijo4sMQ10OgBUq1Gacw5zl2hQXWDixocWBhIwfSjGLgGus/+Pm7n5cefsQHFKN2Ek5QDSEwfJkRlsHLmXuRXKVwXKDn6bgpjZcGnL4Xiao9lwisL4EoK91XocrlXFsi2VglgNXVS8teJULDdqBczfxHQR6Y3Knpw0q82s7Tf4ODvz9KJDbzzlB+Yhq+F6IbfVNlJlALN7tLQ50XGrrZ+tqeOb4qHOAbGLnq+ddZ6md/w8m0vZ+4jTJKCQA+YPJOR/gGrEWuw2qb5c7YYtZq4hfuuzto0pWR25OiwpP0MeuZYwOb4+G73H0kLj/SMas5UaVk87dSj2AZV4c8X61vsShxrtgFhWpmdwlvSLY1Gh35rIdNzduOx3g+4rHqMuXIeYzBc9O0M/TL3D4AbN57k27QUiN8gmU9M= Content-Type: text/plain; charset="utf-8" Content-ID: <99313D75F222A24F84ACE1C489F8CA73@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 241c1b0e-1e7b-4a9f-a697-08d6f9724c0d X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Jun 2019 13:37:41.5076 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yshen@juniper.net X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4104 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-25_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-1810050000 definitions=main-1906250106 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-mpls-egress-protection-framework-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 13:37:55 -0000 SGkgQ2hyaXN0aWFuLA0KDQpUaGFua3MgdmVyeSBtdWNoIGZvciB5b3VyIHNlY3VyaXR5IHJldmll dyBmb3IgdGhpcyBkcmFmdCENCg0KV2UgYWdyZWUgd2l0aCB5b3Ugb24gdGhlIHBvc3NpYmlsaXR5 IG9mIGF0dGFjayB2aWEgYSBDRSBvciBjdXN0b21lciBzaXRlLiBBcyB5b3UgaGF2ZSBtZW50aW9u ZWQsIHN1Y2gga2luZCBvZiBhdHRhY2sgbWF5IHdlbGwgaGFwcGVuIHRvIGEgbmV0d29yayBpbiB0 aGUgYWJzZW5jZSBvZiB0aGUgZWdyZXNzIHByb3RlY3Rpb24gaW4gdGhpcyBkcmFmdC4gT3VyIHZp ZXcgaXMgdGhhdCB0aGUgbmV0d29yayBzaG91bGQgZ2VuZXJhbGx5IGJlIGRlZmVuZGVkIGJ5IHVz aW5nIGEgZGFtcGluZyBtZWNoYW5pc20gb24gZWdyZXNzIHJvdXRlcnMsIHNvIHRoYXQgdGhlIHNl cnZpY2UgZGVzdGluYXRpb25zIGFzc29jaWF0ZWQgd2l0aCBhIGNvbnN0YW50bHkgZmxhcHBpbmcg bGluayBhcmUgc3VwcHJlc3NlZCBmcm9tIGJlaW5nIGFjY2VwdGVkLCByZWNvZ25pemVkLCBhbmQg YWR2ZXJ0aXNlZCB0byBvdGhlciBlZ3Jlc3Mgcm91dGVycy4gVGhpcyBzaG91bGQgYmUgYWJsZSB0 byBkZWZlYXQgdGhlIHJvb3QgY2F1c2Ugb2YgdGhlIGF0dGFjaywgYW5kIHByZXZlbnQgaXQgZnJv bSB0cmlnZ2VyaW5nIGNvbnRyb2wgcGxhbmUgYWN0aXZpdGllcyBpbiB0aGUgTVBMUyBuZXR3b3Jr LCBpbmNsdWRpbmcgdGhlIGVncmVzcyBwcm90ZWN0aW9uIGFjdGl2aXRpZXMuIEZyb20gdGhhdCBw ZXJzcGVjdGl2ZSwgdGhlIGVncmVzcyBwcm90ZWN0aW9uIGluIHRoaXMgZHJhZnQgZG9lcyBub3Qg bWFrZSBhIG5ldHdvcmsgbW9yZSB2dWxuZXJhYmxlIHRvIHN1Y2ggYXR0YWNrLiBXZSBjYW4gYWRk IHRleHQgdG8gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb24gc2VjdGlvbiB0byBjbGFyaWZ5IHRo aXMuDQoNClRoYW5rcywNCg0KLS0gWWltaW4gU2hlbg0KDQoNCu+7v09uIDYvMTcvMTksIDk6Mzkg UE0sICJDaHJpc3RpYW4gSHVpdGVtYSB2aWEgRGF0YXRyYWNrZXIiIDxub3JlcGx5QGlldGYub3Jn PiB3cm90ZToNCg0KICAgIFJldmlld2VyOiBDaHJpc3RpYW4gSHVpdGVtYQ0KICAgIFJldmlldyBy ZXN1bHQ6IEhhcyBOaXRzDQogICAgDQogICAgSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQg YXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nDQogICAgZWZmb3J0 IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNH LiAgVGhlc2UNCiAgICBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVu ZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuDQogICAgRG9jdW1lbnQgZWRpdG9y cyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55 IG90aGVyDQogICAgbGFzdCBjYWxsIGNvbW1lbnRzLg0KICAgIA0KICAgIEkgdGhpbmsgdGhlIGRv Y3VtZW50IGlzIGFsbW9zdCByZWFkeSwgYWx0aG91Z2ggSSB3b3VsZCBsaWtlIHNvbWUgY29uc2lk ZXJhdGlvbnMNCiAgICBvZiBhIHBvdGVudGlhbCBhdHRhY2sgdGhyb3VnaCB0aGUgY3VzdG9tZXIg ZXF1aXBtZW50Lg0KICAgIA0KICAgIEkgcmV2aWV3ZWQgZHJhZnQtaWV0Zi1tcGxzLWVncmVzcy1w cm90ZWN0aW9uLWZyYW1ld29yay0wNSwgTVBMUyBFZ3Jlc3MgUHJvdGVjdGlvbiBGcmFtZXdvcmsu DQogICAgVGhlIGRvY3VtZW50IHNwZWNpZmllcyBhIGZyYW1ld29yayBmb3IgaW1wbGVtZW50aW5n IHByb3RlY3Rpb24gb2YgYW4gTVBMUyB0dW5uZWwgYWdhaW5zdA0KICAgIGZhaWx1cmUgb2YgdGhl IGVncmVzcyByb3V0ZXIgb3IgdGhlIGVncmVzcyBsaW5rLiANCiAgICANCiAgICBUaGUgaW1wbGVt ZW50YXRpb24gb2YgdGhlIGZyYW1ld29yayByZWxpZXMgb24gdGhlIGNvbnRyb2wgZnVuY3Rpb25z IG9mIHRoZSBNUExTIG5ldHdvcmssDQogICAgYW5kIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9u cyBjb3JyZWN0bHkgc3RhdGUgdGhhdCB0aGUgc2VjdXJpdHkgb2YgdGhlIGltcGxlbWVudGF0aW9u IHJlbGllcyBvbg0KICAgIHRoZSBzZWN1cml0eSBvZiB0aGVzZSBwcm90b2NvbHMuIFRoZSBzZWN1 cml0eSBjb25zaWRlcmF0aW9uIGFsc28gcG9pbnQgb3V0IHRoZSBuZWVkIGZvcg0KICAgIHNwZWNp YWwgZXN0YWJsaXNobWVudCBvZiB0cnVzdCBpZiB0aGUgbm9kZXMgaW52b2x2ZWQgYXJlIG5vdCB1 bmRlciB0aGUgc2FtZSBhZG1pbmlzdHJhdGl2ZQ0KICAgIGF1dGhvcml0eS4NCiAgICANCiAgICBU aGVzZSBnZW5lcmFsIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGFyZSBjb3JyZWN0LCBidXQgSSBh bSBjb25jZXJuZWQgdGhhdCB0aGUgZWdyZXNzDQogICAgbGlua3MgYmV0d2VlbiB0aGUgTVBMUyBu ZXR3b3JrIHJvdXRlcnMgYW5kIHRoZSBjdXN0b21lciBjb3VsZCBhbHNvIGJlY29tZSBhIHBvaW50 IG9mDQogICAgYXR0YWNrLiBBdHRhY2tlcnMgdGhhdCBnYWluIGNvbnRyb2wgb2YgYSBjdXN0b21l cidzIGVxdWlwbWVudCBtaWdodCB1c2UgaXQgdG8gc2ltdWxhdGUNCiAgICBsaW5rIGZhaWx1cmVz IGFuZCB0cmlnZ2VyIHRoZSBiYWNrdXAgbWVjaGFuaXNtLiBUaGV5IGNvdWxkIGRvIHNvIGluIGEg Y29vcmRpbmF0ZWQgZmFzaGlvbg0KICAgIGFjcm9zcyBhIGxhcmdlIG51bWJlciBvZiBjdXN0b21l ciBlcXVpcG1lbnRzLCB0byB0cnkgb3ZlcmxvYWQgdGhlIGNvbnRyb2wgcGxhbmUgb3IgdHJ5DQog ICAgY3JlYXRlIGNhc2NhZGluZyBlZmZlY3RzIGluIHRoZSBuZXR3b3JrLg0KICAgIA0KICAgIEl0 IG1heSB3ZWxsIGJlIHRoYXQgaW4gdGhlIGFic2VuY2Ugb2YgdGhlIGxvY2FsIGJhY2t1cCBtZWNo YW5pc20sIHRoZSBhdHRhY2tlcnMgY291bGQgbW91bnQNCiAgICB0aGUgc2FtZSB0eXBlIG9mIGF0 dGFjayBhbmQgdHJpZ2dlciBhbiBvdGhlciB0eXBlIG9mIGNvbnRyb2wgcGxhbmUgYWN0aXZpdHku IFRoZSBkZWZlbnNlcw0KICAgIGFnYWluc3QgdGhhdCBtaWdodCBhbHNvIGRlZmVuZCBhZ2FpbnN0 IHRoZSBhdHRhY2sgbGlzdGVkIGluIHRoZSBwcmV2aW91cyBwYXJhZ3JhcGguIEJ1dA0KICAgIGl0 IG1pZ2h0IGJlIGdvb2QgdG8gc3RhdGUgaXQuDQogICAgDQogICAgDQogICAgDQogICAgDQoNCg== From nobody Tue Jun 25 08:31:31 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3F01205DE; Tue, 25 Jun 2019 08:31:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 E8VFguW80XoS; Tue, 25 Jun 2019 08:31:27 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4BD61205FE; Tue, 25 Jun 2019 08:31:13 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 75F3D3808A; Tue, 25 Jun 2019 11:29:29 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 81558109C; Tue, 25 Jun 2019 11:31:11 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7E8D09BC; Tue, 25 Jun 2019 11:31:11 -0400 (EDT) From: Michael Richardson To: Tero Kivinen cc: "Pascal Thubert \(pthubert\)" , David Mandelberg , "secdir\@ietf.org" , "iesg\@ietf.org" , "draft-ietf-6tisch-architecture.all\@ietf.org" , Thomas Watteyne , =?us-ascii?Q?=3D=3Fiso-8859-2=3FQ=3FMali=3DB9a=5FVu=3DE8ini=3DE6=3F=3D?= In-Reply-To: <23825.24715.882644.180316@fireball.acr.fi> References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> <23825.24715.882644.180316@fireball.acr.fi> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 15:31:30 -0000 --=-=-= Content-Type: text/plain Tero Kivinen wrote: > During the authentication the JRC needs to provide the keying material > to the joining node, but that does NOT provide protection against > spoofed ASN. After the node has actual keys used in the network it > still needs to verify the ASN by sending some message to JRC using > authentication and verify that JRC replies to that. I thought that the 6LRs could provide authentication of the beacons with the network-wide-key, and that we could (after the join process), verify the beacon we saw, using the key(s) that the JRC provided. > If this 2nd step is omitted attacker do following attack: >Joining node (JN) attacker JRC > <- beacon for ASN=23 <- beacon for ASN=44 >See beacon >from attacker, >assume ASN=23. So this is a replay of the valid beacon with ASN=23. > Now, if JN is using extended address to generate nonce, the nonce will > be different for all other nonces ever used, even the ASN is faked, and > has been used before. On the other hand if JN also receives short > address assignment from the JRC, JRC needs to make sure that short > address has not been assigned to anybody else before, as if it was used > by someone else, and frame sent by JN is encrypted, then attacker will > now have two packets with same ASN, and short address, meaning same > nonce, and it can now decrypt packets. I thought that we have text in 6tisch-minimal about needing to rekey the network if we run out of short-addresses for this reason. Well, no. We explain how to rekey well, but not why to rekey :-) Are you suggesting that we need to put this in the architecture document too? Maybe we should have included the ASN as an attribute in the JRC response. > If JN sends message to JRC which only JRC can reply, and uses wrong > ASN, the JRC will not be able to decrypt/validate that frame because of > wrong ASN in nonce, and will drop it silently, so if JN uses wrong ASN > it might be getting ACKs, but it will not get any real reply frames > back from real participants in the network. After it will not receive > confirmation from JRC that it has proper keys and ASN, it knows > something went wrong. Still, that's more code to implement a heuristic. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0SPj4ACgkQgItw+93Q 3WXh8wf/Qgy3UjjfEaa2GCrsgaDoRISXelS5LKGxeRPXY4BXdeNptRniuXHqh4bc in9BtOTHPwPgY5LqqxaIQ3KgeghEsS2W2ML4C399XxAEIAT+c+4LmsCfEWGuWj+J GHdXC8l/AV5qAUORhLgqIl34RbCLhJ0dA0UGWw5TthRpt3ESgkEbBhX39BGvXScJ kPQc0AonWxVk0NWeWO5xidHVkm+AOxry74LcfdZpwXYbrlv54UNVgDVAIbnbAXu6 uIdb1UkVsB0F7uIW/+PMSXVHXvhSDnvLuIr+ChjLFIYiuqWNXRbh+C1BYu+lAVvc u61soXJ0/ej+aJa/xCUdBNqgc/Ygyg== =kngR -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 25 08:39:36 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8442412016E; Tue, 25 Jun 2019 08:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 0uXum6GWn1lp; Tue, 25 Jun 2019 08:39:26 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED1AC120131; Tue, 25 Jun 2019 08:39:25 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id BB4F43808A; Tue, 25 Jun 2019 11:37:42 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id CFD99109C; Tue, 25 Jun 2019 11:39:24 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id CD5109BC; Tue, 25 Jun 2019 11:39:24 -0400 (EDT) From: Michael Richardson To: "Pascal Thubert \(pthubert\)" cc: Tero Kivinen , David Mandelberg , "secdir\@ietf.org" , "iesg\@ietf.org" , "draft-ietf-6tisch-architecture.all\@ietf.org" , Thomas Watteyne , =?us-ascii?Q?=3D=3Fiso-8859-2=3FQ=3FMali=3DB9a=5FVu=3DE8ini=3DE6=3F=3D?= In-Reply-To: References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> <23825.24715.882644.180316@fireball.acr.fi> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 15:39:28 -0000 --=-=-= Content-Type: text/plain Tero: >> Note, that attacker might be able to replay valid ACKs for the frame >> sent by the JN, provided that the JRC (or whoever JN sent the message >> to) happened to ack message using the same ASN attacker faked for JN. Pascal Thubert (pthubert) wrote: > Your mean that the faked ASN is only slightly in the future, so the > attacker can repeat messages from the pledge after that delay? The faked ASN is always in the past. So the L2-ACKs can be faked, was the point. The best scenario would be to distribute the ASN within the JRC reply (CoJP), but (as Malisa has pointed out) that also has the problem that it requires the JRC to get ASN coordination/update messages from the 6LBR if they are not co-located. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0SQCwACgkQgItw+93Q 3WWcsQf/SkxTLN0ZB6wia8VWmJr9EQBW+OCRc0uE1iHH5GLjVAPE36WR4EEmHWzK rISuyPmvBrc0mwHBhxV2USn6l1A/AQepupxpDnqXl2ggR1raFCY8ZUPfddCxUkYy hI04jv8F7iwcmmb9kCrHu43D1jQR4CRD2Rhx/+RMux7oCOQhAcuidzKfBeszz00m VHdnaND67OYzc6VO5C2jBbDiQfaF1k+NIy0mUmk422kFeCkM0nilnwTsCYuRerdy vCnBtW+I0IAG9Vh+id827R3n1utIxEEY+BBpuR7rFeY8gmjBE27Y/XbuzGVyKBMC PedkXZYWA6kGaX5iMZW6CMcay93XRw== =8PgP -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 25 08:45:25 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5553D12065B; Tue, 25 Jun 2019 08:45:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 J2QzRPOFzP42; Tue, 25 Jun 2019 08:45:11 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70DA212067A; Tue, 25 Jun 2019 08:45:10 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 97F033808A; Tue, 25 Jun 2019 11:43:27 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A79E6109C; Tue, 25 Jun 2019 11:45:09 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A538BDF1; Tue, 25 Jun 2019 11:45:09 -0400 (EDT) From: Michael Richardson To: "Pascal Thubert \(pthubert\)" cc: David Mandelberg , =?us-ascii?Q?=3D=3Futf-8=3FB=3FTWFsacWhYSBWdcSNaW5pxIc=3D=3F=3D?= , Tero Kivinen , "secdir\@ietf.org" , "iesg\@ietf.org" , "draft-ietf-6tisch-architecture.all\@ietf.org" In-Reply-To: References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 15:45:14 -0000 --=-=-= Content-Type: text/plain Pascal Thubert (pthubert) wrote: > the following. Michael, Malisa and Tero please confirm that it looks > good / help me fix it : ) ... > In a TSCH network as specified by IEEE Std. 802.15.4 [IEEE802154], > the nonce that is used to secure Link-Layer exchanges includes an > address of the source and the ASN. The ASN itself is supposed to be > distributed securely by other means. If the ASN is compromised and a > short address is reused, then a nonce-reuse attack becomes possible. > With 6TiSCH, the pledge discovers a tentative ASN in beacons sent by > nodes that have already joined the network. As the pledge is not in > possession of Link-Layer keys for the visited network, it cannot verify > the message integrity code (MIC) authenticating the beacon. - Even if it - did have the keys, it still could not verify the beacon as it could be - a replay by an attacker and thus could still announce an ASN that - represents a time in the past. That time would match a valid timeslot - it if is correct modulo the number of channels used for hopping. + Even after the join process, when it does have the keys, it still could not + verify the freshness of the the beacon as it could be + a replay by an attacker and thus could still announce an ASN that + represents a time in the past. That time would match a valid timeslot + it if is correct modulo the number of channels used for hopping. > This authentication steps must be such that they cannot be replayed + by an attacker, and it must not depend on the tentative ASN being valid. > Note that IEEE std. 802.15.4 TSCH does not provide replay protection at > all, and that for instance attacker can cause a legitimate node to - retransmit a previous message by destroying an ack. It results and + retransmit a previous message by destroying an ack. If this results an > upper layer protocol must provide a way to detect replayed messages and > cope with them. > During the authentication the keying material that the pledge > obtains from the JRC does NOT provide protection against spoofed ASN. > Once the pledge has obtained the keys to use in the network, it still > needs to verify the ASN. If the nonce used in the Layer-2 security > derives from the extended (MAC-64) address, then replaying the ASN > alone cannot enable a nonce-reuse attack unless the same node is > attacked twice and loses all state in-between. But if the nonce > derives from the short address (e.g., assigned by the JRC) then the > nonce-reuse attacks are possible, and the JRC must ensure that it never > assigns short addresses that were already given to this or other nodes > with the same keys. I think that in this place, the note about rekeying the network must occur before running out of short addresses. > At that point, an additional step may be required to ensure that the > ASN is correct. For instance, the pledge could perform a first > exchange with a peer node that is trusted and has already joined, e.g., > its RPL time parent, and the message should not be encrypted but only > authenticated at the Link-Layer. The request from the pledge should > contain a nonce with a random part that is not ASN, and the > authenticated response should contain the current ASN and echo the > nonce. I think that we need to be explicit, not "for instance" {please forgive me being behind on email. Summer cold and family responsabilities} -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0SQYUACgkQgItw+93Q 3WX6FAgAqsppKe3/ECqDQMMjVSDS11M8vP7xNh7Lf+7UM7rZ+/REu99bkV8d4tGS ZrWeMusN0Ydiyv0PxvPIwh1fLWlZ3sHtWACz/gHqGMGkUYocC4P+wnbeRkZbv3ve pMQE4tQUYJUlKW5FHRduuC+i8Ye1YvPjN4uqvQbdlu+o7GIMnTveGYUZLOvIS9y5 8+YAVZkScj8cRomOobrPVi3aBJeSWW9E96gKRqBORzlfsSOoSmhIWmR68DLCdKzp LTua78ehZYD2PPXu8+0xRf/As0szYJaC1d2tCxuzjBX3Js5AWzRIVImzW8jrgMJF F9BYDV/P6nhir0O0nBKvPmCVBZ8Drw== =J3H7 -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jun 25 11:57:53 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA9E120BE5 for ; Tue, 25 Jun 2019 11:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 nzkJLgqcJKT8 for ; Tue, 25 Jun 2019 11:57:42 -0700 (PDT) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9921A120BEF for ; Tue, 25 Jun 2019 11:57:42 -0700 (PDT) Received: by mail-wm1-x329.google.com with SMTP id c66so3922254wmf.0 for ; Tue, 25 Jun 2019 11:57:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=5zzav9dORTs0pGeg2C18Abm8cE9o0WZXkFAFYprsZdE=; b=Gguaa77D/NauVOpRAM8bQq5s39FlbXv4oVk1snIl5VGYgr89hcfzbOQL1t83y/tfrN xAJDvdLm7sSACsp1KFZRy3PX5uH8I8vaRgXVpaRQWiyRrizZeeSTP0niuo5tgk4Jz43x 5jvvQcel9SA1m/o2nyQhr29o/w3YXLQhaJqeXgNMW34xMXbqJ21Jo8vP35K3MwWKiF9g usMhtBhSM5zDCgFlk1siOKkiOACOjYCCx42gfCdZgGQJI+tHTDlOgiQGrdqSdSFMvdEt 9AhlBPihS4LhKAt1j2uobK6MX8x2exs5SwsBsmlmTCI6OlmIb1dKacryr214AwzHWTaq O3Ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=5zzav9dORTs0pGeg2C18Abm8cE9o0WZXkFAFYprsZdE=; b=SUay1WPqi8b5TV0pLc8l92Diiv4If7dPVx8mOg1q5tHXhz4GcwbV+t0ZpsP5cnyDhj xeadiTRlpBokjgELDCDmDRQK6CYa6T2BCuBxg/5Mnox/gBF7ZxLFSHHEtafcfhkqMkGG vldrfq9dULA6QKPGRKiYf1C3pQTn1iCkM9J9oF7LfcJyDZF7E7brT+XitQrqp2R82TJc Ae/yKnfukoE5+WEbGf0OKkO5zJlyRLDTVAUrFJJ3Y9Hfh8BQ9bnCiW/vgCIdLctT62F0 BXQOjb1QC5uxD6WqWPQ2vAuqwAQNhQxr3YSJnjYlHUDfa2mONGSS+Lu6u31nyXNXl3rq a4Tw== X-Gm-Message-State: APjAAAW8e+xvdzC6iSCIgrdYxpyDhJzkD4koBKwfLYkNJUpE5UHNPa3N h1XU0NHwS++70Uj1kIQutAX3RDx5 X-Google-Smtp-Source: APXvYqy+gT9dnoQxXsGB+wXl0BbB6v5QcTco2WGV3M2nAMjMA647564N9F/7tzrKOIpwW3IDzhfx7w== X-Received: by 2002:a05:600c:206:: with SMTP id 6mr19666482wmi.73.1561489060743; Tue, 25 Jun 2019 11:57:40 -0700 (PDT) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id i11sm3619132wmi.33.2019.06.25.11.57.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Jun 2019 11:57:40 -0700 (PDT) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_F4EFF181-3E74-4D7F-92F0-FEB9F49E48B8" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Message-Id: Date: Tue, 25 Jun 2019 21:57:38 +0300 To: secdir X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [secdir] Writing Security Considerations X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2019 18:57:52 -0000 --Apple-Mail=_F4EFF181-3E74-4D7F-92F0-FEB9F49E48B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, all If you=E2=80=99ve had a look at the draft agenda = (https://datatracker.ietf.org/meeting/105/agenda.html = ), we have a = Writing Security Considerations tutorial on Sunday, which Linda Dunbar = and I will be doing. The idea is to get people writing drafts to know what they should do for = a smooth interaction with us SecDir people. The slides do not exist yet, but we have a rough outline on github: = https://github.com/IETF-SAAG/SecurityConsiderationsTutorial = So if there=E2=80=99s missing or wrong stuff, we=E2=80=99d like to hear = about it, preferably in the form of PRs. But most of all, we=E2=80=99re looking for more examples in the examples = page: = https://github.com/IETF-SAAG/SecurityConsiderationsTutorial/blob/master/ex= amples.md = So any horror story, war story, stuff that=E2=80=99s terribly wrong, or = even something that=E2=80=99s surprisingly right will be welcome. Thanks in advance Linda & Yoav --Apple-Mail=_F4EFF181-3E74-4D7F-92F0-FEB9F49E48B8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = all

If you=E2=80=99ve = had a look at the draft agenda (https://datatracker.ietf.org/meeting/105/agenda.html), we = have a Writing Security Considerations tutorial on Sunday, which Linda = Dunbar and I will be doing.

The idea is to get people writing drafts to know what they = should do for a smooth interaction with us SecDir people.

The slides do not exist = yet, but we have a rough outline on github: https://github.com/IETF-SAAG/SecurityConsiderationsTutorial=

So if = there=E2=80=99s missing or wrong stuff, we=E2=80=99d like to hear about = it, preferably in the form of PRs.

But most of all, we=E2=80=99re looking = for more examples in the examples page: https://github.com/IETF-SAAG/SecurityConsiderationsTutorial/blo= b/master/examples.md

So any horror story, war story, stuff that=E2=80=99s terribly = wrong, or even something that=E2=80=99s surprisingly right will be = welcome.

Thanks = in advance

Linda= & Yoav

= --Apple-Mail=_F4EFF181-3E74-4D7F-92F0-FEB9F49E48B8-- From nobody Tue Jun 25 23:57:52 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1D51202DE for ; Tue, 25 Jun 2019 23:57:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 KwYSTAC4t-HM for ; Tue, 25 Jun 2019 23:57:47 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 E2CD2120122 for ; Tue, 25 Jun 2019 23:57:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.63,418,1557180000"; d="scan'208,217";a="389096212" Received: from moucherotte.inrialpes.fr ([194.199.28.14]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jun 2019 08:57:44 +0200 From: Vincent Roca Message-Id: <421EA63E-CD5F-4BCC-AA24-3BDBD7182B24@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_2996B550-99C0-44D9-9992-5D355F3525CD" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Wed, 26 Jun 2019 08:57:44 +0200 In-Reply-To: Cc: Vincent Roca , secdir To: Yoav Nir References: X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [secdir] Writing Security Considerations X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 06:57:50 -0000 --Apple-Mail=_2996B550-99C0-44D9-9992-5D355F3525CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Yoav and Linda, Good initiative. Since you=E2=80=99re looking for stories, here is a proposal, rooted in = real life. RFC6520 (https://tools.ietf.org/html/rfc6520 = ) on TLS heartbeat extension has a = pretty simple security considerations section: it says=20 it does not introduce any new security consideration and it refers to = two existing RFCs. We all know this TLS heartbeat extension has been the cause of the = famous heartbleed OpenSSL vulnerability and associated attack. Of course the major problem comes from an erroneous implementation of = the mechanism in OpenSSL: = https://git.openssl.org/gitweb/?p=3Dopenssl.git;a=3Dcommitdiff;h=3D96db902= 3b881d7cd9f379b0c154650d6c108e9a3 = The goal is not to blame anybody in person, especially as the RFC = describes what should be done to prevent any problem. But I also think this is a document where we all (i.e., = authors/secdir/IESG) should have highlighted the associated risk of = badly implementing the response message in the Security Considerations = section. As always in such a situation, it=E2=80=99s easier to say = afterwards! I think there is a way to say that in a positive way (lessons learned) = and tell an interesting story many people heard about without knowing the details. Cheers, Vincent > Le 25 juin 2019 =C3=A0 20:57, Yoav Nir a =C3=A9cri= t : >=20 > Hi, all >=20 > If you=E2=80=99ve had a look at the draft agenda = (https://datatracker.ietf.org/meeting/105/agenda.html = ), we have a = Writing Security Considerations tutorial on Sunday, which Linda Dunbar = and I will be doing. >=20 > The idea is to get people writing drafts to know what they should do = for a smooth interaction with us SecDir people. >=20 > The slides do not exist yet, but we have a rough outline on github: = https://github.com/IETF-SAAG/SecurityConsiderationsTutorial = >=20 > So if there=E2=80=99s missing or wrong stuff, we=E2=80=99d like to = hear about it, preferably in the form of PRs. >=20 > But most of all, we=E2=80=99re looking for more examples in the = examples page: = https://github.com/IETF-SAAG/SecurityConsiderationsTutorial/blob/master/ex= amples.md = >=20 > So any horror story, war story, stuff that=E2=80=99s terribly wrong, = or even something that=E2=80=99s surprisingly right will be welcome. >=20 > Thanks in advance >=20 > Linda & Yoav >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --Apple-Mail=_2996B550-99C0-44D9-9992-5D355F3525CD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello= Yoav and Linda,

Good = initiative.

Since you=E2=80=99re looking for stories, here is a proposal, = rooted in real life.
RFC6520 (https://tools.ietf.org/html/rfc6520) on TLS heartbeat = extension has a pretty simple security considerations section: it = says 
it does not introduce any new security = consideration and it refers to two existing RFCs.
We all know this TLS heartbeat = extension has been the cause of the famous heartbleed OpenSSL = vulnerability and associated attack.
Of course the = major problem comes from an erroneous implementation of the mechanism in = OpenSSL:

The goal is not to blame anybody in = person, especially as the RFC describes what should be done to prevent = any problem.
But I also think this = is a document where we all (i.e., authors/secdir/IESG) should have = highlighted the associated risk of badly
implementing= the response message in the Security Considerations section. As always = in such a situation, it=E2=80=99s easier to say afterwards!

I think there is a way = to say that in a positive way (lessons learned) and tell an interesting = story many people heard about without knowing
the = details.

Cheers,

  Vincent


Le 25 juin 2019 =C3=A0 20:57, Yoav Nir <ynir.ietf@gmail.com>= a =C3=A9crit :

Hi, = all

If you=E2=80=99ve = had a look at the draft agenda (https://datatracker.ietf.org/meeting/105/agenda.html), we = have a Writing Security Considerations tutorial on Sunday, which Linda = Dunbar and I will be doing.

The idea is to get people writing drafts to know what they = should do for a smooth interaction with us SecDir people.

The slides do not exist = yet, but we have a rough outline on github: https://github.com/IETF-SAAG/SecurityConsiderationsTutorial=

So if = there=E2=80=99s missing or wrong stuff, we=E2=80=99d like to hear about = it, preferably in the form of PRs.

But most of all, we=E2=80=99re looking = for more examples in the examples page: https://github.com/IETF-SAAG/SecurityConsiderationsTutorial/blo= b/master/examples.md

So any horror story, war story, stuff that=E2=80=99s terribly = wrong, or even something that=E2=80=99s surprisingly right will be = welcome.

Thanks = in advance

Linda= & Yoav

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wiki: = http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

= --Apple-Mail=_2996B550-99C0-44D9-9992-5D355F3525CD-- From nobody Wed Jun 26 01:58:45 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E248D120251; Wed, 26 Jun 2019 01:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=theipv6company.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 dOpBEO0u42W4; Wed, 26 Jun 2019 01:58:33 -0700 (PDT) Received: from consulintel.es (mail.consulintel.es [IPv6:2001:470:1f09:495::5]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29A1B12022E; Wed, 26 Jun 2019 01:58:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=theipv6company.com; s=MDaemon; t=1561539510; x=1562144310; i=jordi.palet@theipv6company.com; q=dns/txt; h=User-Agent:Date: Subject:From:To:Message-ID:Thread-Topic:References:In-Reply-To: Mime-version:Content-type:Content-transfer-encoding; bh=0Uxb113s xFZi/YhVlAwLAw49O1nZR2/53ftjiI0t4OE=; b=p2r6LSreVU2eP1zRL4a1yaVb 0hWU30SHR0N2/y/ZPw+o0VOXZGXSUGqPLRojYn8L0OJ/SevjudvlGQ4JFXFHqtze 0MyirYm6puqACZsA52a48ak//nnp4PQ7fvUNP6RNymVgwlFtbxa5SUKWlQIrXbJk uOLiz1fj9MXsErIXeZM= X-MDAV-Result: clean X-MDAV-Processed: consulintel.es, Wed, 26 Jun 2019 10:58:30 +0200 X-Spam-Processed: consulintel.es, Wed, 26 Jun 2019 10:58:30 +0200 Received: from [10.10.10.139] by consulintel.es (MDaemon PRO v16.5.2) with ESMTPA id md50006307373.msg; Wed, 26 Jun 2019 10:58:29 +0200 X-MDRemoteIP: 2001:470:1f09:495:21d1:fd8f:d52a:2bc5 X-MDHelo: [10.10.10.139] X-MDArrival-Date: Wed, 26 Jun 2019 10:58:29 +0200 X-Authenticated-Sender: jordi.palet@theipv6company.com X-Return-Path: prvs=1080c7f748=jordi.palet@theipv6company.com X-Envelope-From: jordi.palet@theipv6company.com User-Agent: Microsoft-MacOutlook/10.10.b.190609 Date: Wed, 26 Jun 2019 10:58:26 +0200 From: Jordi Palet =?UTF-8?B?TWFydMOtbmV6?= To: Chris Lonvick , "secdir@ietf.org" , "iesg@ietf.org" , Message-ID: Thread-Topic: SECDIR review of draft-ietf-v6ops-nat64-deployment-06 References: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-v6ops-nat64-deployment-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 08:58:36 -0000 Hi Chris, Thanks a lot for your review! Regards, Jordi @jordipalet =20 =EF=BB=BFEl 25/6/19 3:04, "Chris Lonvick" escribi= =C3=B3: Hi, =20 I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the IESG= .=20 These comments were written primarily for the benefit of the security= =20 area directors. Document editors and WG chairs should treat these=20 comments just like any other last call comments. =20 The summary of the review is READY. =20 I mostly skimmed this informational document. It appears to be well lai= d=20 out and complete. The Security Considerations section is succinct and= =20 offers, "This document does not have new specific security=20 considerations beyond those already reported by each of the documents= =20 cited." I believe that is sufficient for this document. =20 Regards, Chris =20 =20 =20 ********************************************** IPv4 is over Are you ready for the new Internet ? http://www.theipv6company.com The IPv6 Company This electronic message contains information which may be privileged or con= fidential. The information is intended to be for the exclusive use of the i= ndividual(s) named above and further non-explicilty authorized disclosure, = copying, distribution or use of the contents of this information, even if p= artially, including attached files, is strictly prohibited and will be cons= idered a criminal offense. If you are not the intended recipient be aware t= hat any disclosure, copying, distribution or use of the contents of this in= formation, even if partially, including attached files, is strictly prohibi= ted, will be considered a criminal offense, so you must reply to the origin= al sender to inform about this communication and delete it. From nobody Wed Jun 26 05:22:55 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAA2120142; Wed, 26 Jun 2019 05:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=N42ydIPM; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=TnEo+Vxg 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 KTi-kA_j_YoN; Wed, 26 Jun 2019 05:22:51 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A65521200FA; Wed, 26 Jun 2019 05:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5006; q=dns/txt; s=iport; t=1561551770; x=1562761370; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zI+Gvw21eFoCUkE0B6f+JiBtXaf1TVsRylLvsFIZzDg=; b=N42ydIPMQq4L/zaaO7xDo4H9JoRp+kHuEQliZk4o8RZYWR+9KwMQrFvi /CTfr8i6hMQ3tQci6B8vMHZkvjF7eA6p8URAEzJZCG9f3mCKFk7KI3Lsf r9NwrSCvrxytzJid+Q/lMz+jQ5TPGihc1CFt4sbo13id3QFrYXl/xuMip s=; IronPort-PHdr: =?us-ascii?q?9a23=3A8WsJ5RSztlnOaaoV22b6NIScstpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjQmHNlIWUV513q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BMAQCXYhNd/5pdJa1lHAEBAQQBAQc?= =?us-ascii?q?EAQGBVgQBAQsBgUNQA4E/IAQLKAqHUgOOWoJblz2BQoEQA1QJAQEBDAEBLQI?= =?us-ascii?q?BAYFLgnUCgn0jNwYOAQMBAQQBAQIBBW2KNwyFSgEBAQMBEhUZAQE3AQ8CAQg?= =?us-ascii?q?SNDIXDgIEDgUIGoRrAw4PAQKaUAKBOIhfgW8zgnkBAQWFBRiCEQmBNAGJFII?= =?us-ascii?q?sHReBQD+BEUaCTD6EEQESASGDOoImjimFS5YsCQKCFpQLgiqHEo4ZoHaDSwI?= =?us-ascii?q?EAgQFAg4BAQWBZiJncXAVgyeCQQwXg02KU3KBKYwJDRcHgQQBgSABAQ?= X-IronPort-AV: E=Sophos;i="5.63,419,1557187200"; d="scan'208";a="580881943" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Jun 2019 12:22:49 +0000 Received: from XCH-RCD-018.cisco.com (xch-rcd-018.cisco.com [173.37.102.28]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x5QCMnkn026607 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Jun 2019 12:22:49 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-018.cisco.com (173.37.102.28) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 26 Jun 2019 07:22:49 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 26 Jun 2019 07:22:48 -0500 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 26 Jun 2019 07:22:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ONePemvYW89NAipsZxNIo2Nf4e2JEzB73EOr7ROupkU=; b=TnEo+VxgshNDTj33/xafKgDwCntr12bh7ZEv4CyirHRzJDNVHSA48rmxJj3Gauggy6IzNuMxrvD2vV+J8SbIWs35jeablk4lmmeI6xVMBuJ5Z8fxjaU4GB6pU21BAILcUa8T4tWB6k5fzTcSZOwV53LWwZXerxqss4NMspq6LrI= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3854.namprd11.prod.outlook.com (20.178.252.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Wed, 26 Jun 2019 12:22:47 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2008.017; Wed, 26 Jun 2019 12:22:47 +0000 From: "Pascal Thubert (pthubert)" To: Michael Richardson CC: David Mandelberg , =?iso-8859-2?Q?Mali=B9a_Vu=E8ini=E6?= , Tero Kivinen , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-6tisch-architecture.all@ietf.org" Thread-Topic: secdir review of draft-ietf-6tisch-architecture-21 Thread-Index: AQHVKitVZAMqDsUZHEuS/CYS/vDUhKasV4DggAAuGICAAVVrIA== Date: Wed, 26 Jun 2019 12:22:21 +0000 Deferred-Delivery: Wed, 26 Jun 2019 12:22:00 +0000 Message-ID: References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> <30360.1561477509@localhost> In-Reply-To: <30360.1561477509@localhost> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [173.38.220.49] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 336d7bf9-6f8b-4f5a-6ad4-08d6fa30ffbb x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3854; x-ms-traffictypediagnostic: MN2PR11MB3854: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00808B16F3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(136003)(366004)(39860400002)(396003)(189003)(199004)(51444003)(7736002)(66066001)(256004)(99286004)(7696005)(305945005)(6506007)(76176011)(8936002)(8676002)(81156014)(81166006)(33656002)(561944003)(74316002)(25786009)(54906003)(316002)(6246003)(55016002)(11346002)(446003)(53936002)(68736007)(14454004)(71190400001)(478600001)(5660300002)(14444005)(3846002)(6116002)(9686003)(476003)(486006)(229853002)(6436002)(66446008)(66556008)(66476007)(2906002)(66946007)(86362001)(4326008)(186003)(26005)(6666004)(73956011)(52536014)(64756008)(76116006)(71200400001)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3854; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: kYO8q+CN50Bhllk7ldbWcBwCeN3mW5WCy4Ze8j/bsta5/KUNMyANcjM2H/Kr7iycisYfk/9BnEyg/0YY/geh+S8l4wHn2mQus2YD28/NmW0LXeeW+OnB4856VpLwTjHVPgIsHVix1I5/u/XoB38wcowJGRNPJ2Tv2udaENnRVpqI5/Tv7IQYw2RvHd9uzKBrFOGEY2PNYAdQwI8uyYRLLK4awz8np81/oKyk1560ZmyVkqvdLrzNhCEqx3ZpoeHnQS61aNsMSJfJft/NPVIewvlx3aebOrU00bsfa32Hsy56EpFPBT04op/Ptu3IiBFGN3Iiz4AelTh01ubeLT9EpP1RweVh7G1eDfnZa+Iwa62en4lA6g149rPjsdT97YEyFe850cO0SwdIbZC+/xagtavGoWl5eDFSOUyBLkBIBhU= Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 336d7bf9-6f8b-4f5a-6ad4-08d6fa30ffbb X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2019 12:22:47.4731 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3854 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.28, xch-rcd-018.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 12:22:53 -0000 Many thanks Michael I'm unclear whether implementations actually have to check the ASN before r= esponding and what actions they would take should that occur. I guess we are in IEEE land at that point bit I understand that the IEEE di= d not specify a method to validate ASN.=20 I incorporated your recommendations below, please see: =20 >=20 > - Even if it > - did have the keys, it still could not verify the beacon as it could be > - a replay by an attacker and thus could still announce an ASN that > - represents a time in the past. That time would match a valid timeslot > - it if is correct modulo the number of channels used for hopping. >=20 > + Even after the join process, when it does have the keys, it still > + could not verify the freshness of the the beacon as it could be a > + replay by an attacker and thus could still announce an ASN that > + represents a time in the past. That time would match a valid timeslot > + it if is correct modulo the number of channels used for hopping. Done >=20 >=20 > > This authentication steps must be such that they cannot be repla= yed > + by an attacker, and it must not depend on the tentative ASN being v= alid. > > Note that IEEE std. 802.15.4 TSCH does not provide replay protectio= n at > > all, and that for instance attacker can cause a legitimate node to Fixed > - retransmit a previous message by destroying an ack. It results and > + retransmit a previous message by destroying an ack. If this results= an > > upper layer protocol must provide a way to detect replayed messages= and > > cope with them. >=20 Sorry I cannot parse the resulting sentence with your proposal. My mistake was only and -> an but I'm sure that the sentence can be better = written. I changed to " This authentication steps must be such that they cannot be replayed by = an attacker, and it must not depend on the tentative ASN being valid. Note= that IEEE std. 802.15.4 TSCH does not provide replay protection at all, and = that=20 an ack may be lost, which can cause a legitimate node to retransmit a f= rame. Upper layer protocols must thus provide a way to detect duplicates and = cope with them. " >=20 > > During the authentication the keying material that the pledge > > obtains from the JRC does NOT provide protection against spoofed AS= N. > > Once the pledge has obtained the keys to use in the network, it sti= ll > > needs to verify the ASN. If the nonce used in the Layer-2 security > > derives from the extended (MAC-64) address, then replaying the ASN > > alone cannot enable a nonce-reuse attack unless the same node is > > attacked twice and loses all state in-between. But if the nonce > > derives from the short address (e.g., assigned by the JRC) then the > > nonce-reuse attacks are possible, and the JRC must ensure that it n= ever > > assigns short addresses that were already given to this or other no= des > > with the same keys. >=20 > I think that in this place, the note about rekeying the network must occu= r > before running out of short addresses. >=20 Added " assigns short addresses that were already given to this or other node= s with + the same keys. In other words, the network must be rekeyed before the = JRC + runs out of short addresses. " > > At that point, an additional step may be required to ensure that= the > > ASN is correct. For instance, the pledge could perform a first > > exchange with a peer node that is trusted and has already joined, e= .g., > > its RPL time parent, and the message should not be encrypted but on= ly > > authenticated at the Link-Layer. The request from the pledge shoul= d > > contain a nonce with a random part that is not ASN, and the > > authenticated response should contain the current ASN and echo the > > nonce. >=20 > I think that we need to be explicit, not "for instance" >=20 Proposed new text: " At that point, an additional step may be required to ensure that the AS= N is correct. If the ASN is not guaranteed to be correct by other means, the pledge should perform a first exchange with a peer node that is trusted= and has already joined, e.g., its RPL time parent, and the message should n= ot be encrypted but only authenticated at the Link-Layer. The request from the pledge should contain a nonce with a random part t= hat is not ASN, and the authenticated response should contain the current A= SN and echo the nonce. " > {please forgive me being behind on email. Summer cold and family > responsabilities} You're always helpful, Michael, how could one complain? Many thanks Pascal > -- > Michael Richardson , Sandelman Software Works - > =3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Wed Jun 26 05:31:04 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 075FD12013A; Wed, 26 Jun 2019 05:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=SaOWejW3; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=BlhRdFzG 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 QRLIRX2IOBZb; Wed, 26 Jun 2019 05:30:53 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EA701200A3; Wed, 26 Jun 2019 05:30:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1607; q=dns/txt; s=iport; t=1561552252; x=1562761852; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=coVxX2isCtiwckl1G2lev9Qy1c/bf4DUFrI/f04AwqE=; b=SaOWejW3+G9kMakzSlPxzO0PpIDQ445RhPYoThrLJrNmgl8Ll1s0f/mc MQdnU2AKiKVIAhS26joTC5Jzo6nCnKT7KjYs5KBjXCB5kUwx+S54RCnJa FBwjKwSsQxlZlVHBr3J22DYdOEozp6TMF45ugWLzg294fhg214jUAt4i5 w=; IronPort-PHdr: =?us-ascii?q?9a23=3A6b7xzxHMMXmiDMfEOwvESZ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeb2bzEwEd5efFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAADRZBNd/5BdJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVQMBAQEBCwGBQ1ADgT8gBAsoCodSA45aTIIPlz2BLoEkA1Q?= =?us-ascii?q?JAQEBDAEBLQIBAYFLgnUCgn0jNgcOAQMBAQQBAQIBBW2KNwyFSgEBAQMBEi4?= =?us-ascii?q?BATcBBAsCAQgSBi4yFw4CBA4FCBEJhGsDDg8BAppPAoE4iF+CIoJ5AQEFhQU?= =?us-ascii?q?YghEJgTQBi10XgUA/gVeCTD6ERoM6giaOKZt3CQKCFpQLgiqVK40lgTSVaAI?= =?us-ascii?q?EAgQFAg4BAQWBVwEwgVhwFYMngkEJGoNNilNygSmNOAGBIAEB?= X-IronPort-AV: E=Sophos;i="5.63,419,1557187200"; d="scan'208";a="495909111" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Jun 2019 12:30:51 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x5QCUp7L007644 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 26 Jun 2019 12:30:51 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 26 Jun 2019 07:30:50 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 26 Jun 2019 07:30:50 -0500 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 26 Jun 2019 07:30:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KTN8MOWwvEJkJNbvMphNHreraqdDZqenjdkrKGIX108=; b=BlhRdFzG2eHOzNfyD40mR4nAvYxp+0Mn2VjGWcqKvjeA2Qdahl9gVAAoFxfIU7aZR24/KRRf/N0NmEM6SIKmEEzDWQBKTFZ2sfKGt2oLLcOv2P+gO9kYDGCI1mmFyyuKadNgw44PVe71vcL529btdP5u65Iz9jOOdzMEyJOF/ro= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3664.namprd11.prod.outlook.com (20.178.252.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Wed, 26 Jun 2019 12:30:47 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2008.017; Wed, 26 Jun 2019 12:30:47 +0000 From: "Pascal Thubert (pthubert)" To: Michael Richardson CC: Tero Kivinen , David Mandelberg , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-6tisch-architecture.all@ietf.org" , Thomas Watteyne , =?iso-8859-2?Q?Mali=B9a_Vu=E8ini=E6?= Thread-Topic: [secdir] secdir review of draft-ietf-6tisch-architecture-21 Thread-Index: AQHVKitVZAMqDsUZHEuS/CYS/vDUhKaqVH6wgAEk6YCAAHyKMIAAjgwAgAFa8pA= Date: Wed, 26 Jun 2019 12:30:33 +0000 Deferred-Delivery: Wed, 26 Jun 2019 12:30:11 +0000 Message-ID: References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> <23825.24715.882644.180316@fireball.acr.fi> <28910.1561477164@localhost> In-Reply-To: <28910.1561477164@localhost> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [173.38.220.49] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 69a15d53-a48f-4089-3282-08d6fa321dea x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3664; x-ms-traffictypediagnostic: MN2PR11MB3664: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00808B16F3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(376002)(346002)(39860400002)(136003)(189003)(199004)(7736002)(52536014)(2906002)(74316002)(102836004)(68736007)(256004)(86362001)(6506007)(64756008)(66556008)(66446008)(66946007)(66476007)(229853002)(5660300002)(305945005)(6436002)(76116006)(76176011)(478600001)(14444005)(55016002)(54906003)(9686003)(316002)(26005)(33656002)(4326008)(3846002)(8936002)(6116002)(14454004)(71200400001)(81166006)(8676002)(53936002)(66066001)(73956011)(446003)(6246003)(81156014)(71190400001)(7696005)(486006)(25786009)(186003)(6666004)(476003)(99286004)(11346002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3664; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: KDsHVmJLAJjahb93/q6Cj5ZzNVKTShDa1PicaG9IkUMGfiSjF/09vIMjvOyJ61rQRS/65J4s2Ir/u2if0ncCQ63Sx1QVmiEZWQ4XWcEzieQca4/VUDX2GJlzdNHfB+JLjW6glc+6vW/yJfb9f9yYXtMg2At6tw954NFZpTShH2P7y3PVXSQnAkJ4cSZ66Ju6D8acaq1kbd8Jf0jl3N6HsIJfjsH4JhbVuCtf/Lzw0xmsJ2PPAVnGXDRwTCjQcynYLUkzYig8YKRcfmfQbJIPytHMN4egaIcAuAt946pmPY3yPKSjt9ukPPT86yHN5qhUAUT1RfjMohCjEeqV5Uk1ajuARh8UO5vMho7mRm1LaiM9UFpvL0N6ITVtE1d5OoQ3vq1GPtf9FE9/L811/I2zXhwac6Tj/C4O+gjZVNmJBgA= Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 69a15d53-a48f-4089-3282-08d6fa321dea X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2019 12:30:47.5281 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3664 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.25, xch-rcd-015.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 12:30:55 -0000 >=20 > Tero: > >> Note, that attacker might be able to replay valid ACKs for the fra= me > >> sent by the JN, provided that the JRC (or whoever JN sent the mess= age > >> to) happened to ack message using the same ASN attacker faked for = JN. >=20 > Pascal Thubert (pthubert) wrote: > > Your mean that the faked ASN is only slightly in the future, so the > > attacker can repeat messages from the pledge after that delay? >=20 > The faked ASN is always in the past. Do you mean the replayed ones? When the pledge does not have the keys, the = attacker can forge the beacon with any ASN, and place random bytes in the M= IC, can't it? If the attacker fakes an ASN that is tomorrow and intercepts a join request= , it could make the pledge seem to appear now on the network tomorrow even = if the real pledge is long gone. > So the L2-ACKs can be faked, was the point. I can see that an ACK can be replayed. But the ACK that was stored in advan= ce can only work if the attacked node speaks on the very ASN for which the = attacker intercepted an ACK in the past. The attacker is not in control of = that and that makes its life harder. >=20 > The best scenario would be to distribute the ASN within the JRC reply (Co= JP), > but (as Malisa has pointed out) that also has the problem that it require= s the > JRC to get ASN coordination/update messages from the 6LBR if they are not > co-located. >=20 > -- > Michael Richardson , Sandelman Software Works - > =3D IPv6 IoT consulting =3D- >=20 >=20 From nobody Wed Jun 26 08:51:51 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 040F3120374; Wed, 26 Jun 2019 08:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 wrGmKrhCNXq1; Wed, 26 Jun 2019 08:51:48 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9B82120371; Wed, 26 Jun 2019 08:51:47 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 1E341380BE; Wed, 26 Jun 2019 11:50:03 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 9C9BDE68; Wed, 26 Jun 2019 11:51:46 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 9A467E37; Wed, 26 Jun 2019 11:51:46 -0400 (EDT) From: Michael Richardson To: "Pascal Thubert \(pthubert\)" cc: David Mandelberg , =?us-ascii?Q?=3D=3Fiso-8859-2=3FQ=3FMali=3DB9a=5FVu=3DE8ini=3DE6=3F=3D?= , Tero Kivinen , "secdir\@ietf.org" , "iesg\@ietf.org" , "draft-ietf-6tisch-architecture.all\@ietf.org" In-Reply-To: References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> <30360.1561477509@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 15:51:50 -0000 --=-=-= Content-Type: text/plain Pascal Thubert (pthubert) wrote: >> - retransmit a previous message by destroying an ack. It results and >> + retransmit a previous message by destroying an ack. If this results an >> > upper layer protocol must provide a way to detect replayed messages and >> > cope with them. >> > Sorry I cannot parse the resulting sentence with your proposal. > My mistake was only and -> an but I'm sure that the sentence can be better written. > I changed to > " > This authentication steps must be such that they cannot be replayed by an > attacker, and it must not depend on the tentative ASN being valid. Note that > IEEE std. 802.15.4 TSCH does not provide replay protection at all, and that > an ack may be lost, which can cause a legitimate node to retransmit a frame. > Upper layer protocols must thus provide a way to detect duplicates and cope > with them. > " Good, I like it fine. > Proposed new text: > " > At that point, an additional step may be required to ensure that the ASN is > correct. If the ASN is not guaranteed to be correct by other means, the > pledge should perform a first exchange with a peer node that is trusted and > has already joined, e.g., its RPL time parent, and the message should not be > encrypted but only authenticated at the Link-Layer. > The request from the pledge should contain a nonce with a random part that > is not ASN, and the authenticated response should contain the current ASN > and echo the nonce. > " okay. Tero? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0TlJIACgkQgItw+93Q 3WU4Ugf/TwGuIv9/EDjEudaufHaQ3bBEnwBnbDVD328pXkNd5wzIzpyM3OIJjZbs 9KPx7+DfS+gnv09CyYagzo3H819s8/48dM5X1OyEfpO5govlUSDXE1oNzYp+eeDU XVC7rnWnxXs6A38HXaw0a0Y20p948ucjuiagwoGR1rfKlUnALw/CcK9UuHTzVr6N MolNrG4xb/RTa2y1ALdwxF6YeHMpylsjB8Yioi9lmeeqGYzOoW0JXRGmnCk8gaBI N0ZESQeY+TtgSunRxs4lHNh2p2v4Gp5yB+8NVO1zsku2fxiW+Ke4pFKswxcg+0Ca cNVnfTrnKRos8Bnn2vyABD/nHv0Yww== =7Nfq -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 26 08:54:30 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FFC712041C; Wed, 26 Jun 2019 08:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 3lRO0We0FYyk; Wed, 26 Jun 2019 08:54:23 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C60EE1203C4; Wed, 26 Jun 2019 08:54:20 -0700 (PDT) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2:56b2:3ff:fe0b:d84]) by tuna.sandelman.ca (Postfix) with ESMTP id 3DBEC3808A; Wed, 26 Jun 2019 11:52:35 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B8974E68; Wed, 26 Jun 2019 11:54:18 -0400 (EDT) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B7205E37; Wed, 26 Jun 2019 11:54:18 -0400 (EDT) From: Michael Richardson To: "Pascal Thubert \(pthubert\)" cc: Tero Kivinen , David Mandelberg , "secdir\@ietf.org" , "iesg\@ietf.org" , "draft-ietf-6tisch-architecture.all\@ietf.org" , Thomas Watteyne , =?us-ascii?Q?=3D=3Fiso-8859-2=3FQ=3FMali=3DB9a=5FVu=3DE8ini=3DE6=3F=3D?= In-Reply-To: References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> <23825.24715.882644.180316@fireball.acr.fi> <28910.1561477164@localhost> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 15:54:29 -0000 --=-=-= Content-Type: text/plain Pascal Thubert (pthubert) wrote: >> Tero: >> >> Note, that attacker might be able to replay valid ACKs for the frame >> >> sent by the JN, provided that the JRC (or whoever JN sent the message >> >> to) happened to ack message using the same ASN attacker faked for JN. >> >> Pascal Thubert (pthubert) wrote: >> > Your mean that the faked ASN is only slightly in the future, so the >> > attacker can repeat messages from the pledge after that delay? >> >> The faked ASN is always in the past. > Do you mean the replayed ones? When the pledge does not have the keys, > the attacker can forge the beacon with any ASN, and place random bytes > in the MIC, can't it? Yes, the replayed one has a "fake" ASN that is in the past. > If the attacker fakes an ASN that is tomorrow and intercepts a join > request, it could make the pledge seem to appear now on the network > tomorrow even if the real pledge is long gone. But that one won't validate. >> So the L2-ACKs can be faked, was the point. > I can see that an ACK can be replayed. But the ACK that was stored in > advance can only work if the attacked node speaks on the very ASN for > which the attacker intercepted an ACK in the past. The attacker is not > in control of that and that makes its life harder. When I said faked, I should have said replayed. I think that we don't need to do this: just wait for a beacon. If the attacker can block and replay them all, then they absolutely win, and the network can not form. Such an attacker probably can also put faraday cages around all the nodes. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl0TlSoACgkQgItw+93Q 3WVNOwf+Pz7tR5lRRrgIdHLsNTFcgE7vt7RN4XjA5aJwzA6r3eqD+u3fGsfEZRzf qXxkuyzj+l4Lms+63VrLwgrt2JlcOis3MtYtWYQ6EG0vDnAzemzDY34FCUF6yMp7 iEAU+U2r3Nm27JZGIN/FRd91j5NTHFeZk0GcBWJv3PfaQjNh3iplPr4+Kv+tm+I9 SEAWaCCG4qeGLFIwjFwj1cmvFN+bqQx5196qW3yUrRy6dNCpfHZRmma/XvVlEqzl eimT7hsoF5Ss0xeFCKwTjbAavZKrnRwmirMy8zfOlWDAGYqYpeWX7uw/mEAlTlFU 0JG6VnO2tm7jzd7RZp1SZbWpEClkUg== =9BsX -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Jun 26 16:13:03 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AAE13120314; Wed, 26 Jun 2019 16:12:46 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Brian Weis via Datatracker To: Cc: draft-ietf-roll-efficient-npdao.all@ietf.org, roll@ietf.org, iesg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Brian Weis Message-ID: <156159076663.20249.2660341271739856150@ietfa.amsl.com> Date: Wed, 26 Jun 2019 16:12:46 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-roll-efficient-npdao-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2019 23:12:47 -0000 Reviewer: Brian Weis Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I previously reviewed draft version 10, and asked that some text should be added to describe a new risk that the new NPDAO message adds to ROLL. Draft version 12 adds that text, and I don't have any further comments. From nobody Wed Jun 26 21:33:16 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83710120137 for ; Wed, 26 Jun 2019 21:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 sNhKdliSPZpE for ; Wed, 26 Jun 2019 21:33:13 -0700 (PDT) Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0690A120124 for ; Wed, 26 Jun 2019 21:33:13 -0700 (PDT) Received: by mail-wr1-x435.google.com with SMTP id n9so819319wru.0 for ; Wed, 26 Jun 2019 21:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=51UdQdPrDtJ6sT4XNqFRvs2IWMfAazYtlzE/2fArwhg=; b=PnngcTrczy1vbFhLYAikWLt4SZonZMoFTdpSrh0Gb9r2vd9cAPl3I3xaBY8kwtbRsH kfX6Vb38qEtKVzaH5blVDiqodo9Sumb7V3TJJkEoNax+Je3/k97l+yp+FbWPKlbBengQ ttNLW4Qe5F4xVv+JBeMfO2lWZ014s+WlF2RD4iXBw8gne9YriyizoytUBErSK/kUgELq nQP9HyflzN3AskjQwzJEJXr9Tnr7SZgKOPCkAZjPH5EuEAXnsKS8DHBxXoF5M0IDUVM2 ELK3+V/i8iQP0OTddowY9bRxFjtYNFUr5HsrtzMztJ7CwzuDXGM840pIPr+27jEqmwWo rVCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=51UdQdPrDtJ6sT4XNqFRvs2IWMfAazYtlzE/2fArwhg=; b=WudNiUvhKgrU26nQVf3zAnkXNmrzF91kS2F+87FcQe7Sg63yQMAA1hYBRQPUNpsgtP 2JV7wuHWJRqvoZ+TmB6MgLj+iLaE88bGn8T51RxQSyjnuK4h4MMq74i0WTeAgXB92suJ IvbvPgFQibX7SePTM0AH2jLWeWjtu8JkISWvUr3N6L3i6ibeTNRppx4E/+VpNpRXMk5t qLV2VaJo38HfVDiXekHYkyUADjPYWmSyEHzqNpqgJPyXiQxfyAk7pzw62+aMmTayfHHF HFW6WZzzV/5E5TEXafN3Cg2FnJqq8PJ6oIRuk7+qmPmGQptHUYwt43qo2Ocdiajmd4zw 5e3A== X-Gm-Message-State: APjAAAVu89VE41g+DeV55V/wNQI73ike2dFwnBUpPTMYYw5BOODjvvxD HJnALymsXiQVDvG4/4KC1jo= X-Google-Smtp-Source: APXvYqx4Q2FhZ4y2XaP9oYEAfkSDNZKzOVZ31C5ViymLgwh1IhsyUmyPVTEJghQxqdQCM74c69cUrg== X-Received: by 2002:a5d:46ce:: with SMTP id g14mr1122963wrs.203.1561609991475; Wed, 26 Jun 2019 21:33:11 -0700 (PDT) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id y133sm6375310wmg.5.2019.06.26.21.33.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Jun 2019 21:33:10 -0700 (PDT) From: Yoav Nir Message-Id: <558A448D-E5EE-4E3C-9B0A-F5B5490E793C@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6199880D-63AD-4E63-85A2-12A1FB935BE5" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 27 Jun 2019 07:33:07 +0300 In-Reply-To: <421EA63E-CD5F-4BCC-AA24-3BDBD7182B24@inria.fr> Cc: secdir To: Vincent Roca References: <421EA63E-CD5F-4BCC-AA24-3BDBD7182B24@inria.fr> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [secdir] Writing Security Considerations X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 04:33:16 -0000 --Apple-Mail=_6199880D-63AD-4E63-85A2-12A1FB935BE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Vincent. Thanks, but I don=E2=80=99t know what kind of lesson there is in this = for the general RFC-writing audience. Always call out when you have internal length fields because that can be = done dangerously in C? I think mis-handling length fields has been an issue with protocols as = long as protocols have been implemented. Yoav > On 26 Jun 2019, at 9:57, Vincent Roca wrote: >=20 > Hello Yoav and Linda, >=20 > Good initiative. >=20 > Since you=E2=80=99re looking for stories, here is a proposal, rooted = in real life. > RFC6520 (https://tools.ietf.org/html/rfc6520 = ) on TLS heartbeat extension has a = pretty simple security considerations section: it says=20 > it does not introduce any new security consideration and it refers to = two existing RFCs. >=20 > We all know this TLS heartbeat extension has been the cause of the = famous heartbleed OpenSSL vulnerability and associated attack. > Of course the major problem comes from an erroneous implementation of = the mechanism in OpenSSL: > = https://git.openssl.org/gitweb/?p=3Dopenssl.git;a=3Dcommitdiff;h=3D96db902= 3b881d7cd9f379b0c154650d6c108e9a3 = >=20 > The goal is not to blame anybody in person, especially as the RFC = describes what should be done to prevent any problem. > But I also think this is a document where we all (i.e., = authors/secdir/IESG) should have highlighted the associated risk of = badly > implementing the response message in the Security Considerations = section. As always in such a situation, it=E2=80=99s easier to say = afterwards! >=20 > I think there is a way to say that in a positive way (lessons learned) = and tell an interesting story many people heard about without knowing > the details. >=20 > Cheers, >=20 > Vincent >=20 >=20 >> Le 25 juin 2019 =C3=A0 20:57, Yoav Nir > a =C3=A9crit : >>=20 >> Hi, all >>=20 >> If you=E2=80=99ve had a look at the draft agenda = (https://datatracker.ietf.org/meeting/105/agenda.html = ), we have a = Writing Security Considerations tutorial on Sunday, which Linda Dunbar = and I will be doing. >>=20 >> The idea is to get people writing drafts to know what they should do = for a smooth interaction with us SecDir people. >>=20 >> The slides do not exist yet, but we have a rough outline on github: = https://github.com/IETF-SAAG/SecurityConsiderationsTutorial = >>=20 >> So if there=E2=80=99s missing or wrong stuff, we=E2=80=99d like to = hear about it, preferably in the form of PRs. >>=20 >> But most of all, we=E2=80=99re looking for more examples in the = examples page: = https://github.com/IETF-SAAG/SecurityConsiderationsTutorial/blob/master/ex= amples.md = >>=20 >> So any horror story, war story, stuff that=E2=80=99s terribly wrong, = or even something that=E2=80=99s surprisingly right will be welcome. >>=20 >> Thanks in advance >>=20 >> Linda & Yoav >>=20 >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview >=20 --Apple-Mail=_6199880D-63AD-4E63-85A2-12A1FB935BE5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi, = Vincent.

Thanks, but = I don=E2=80=99t know what kind of lesson there is in this for the = general RFC-writing audience.

Always call out when you have internal = length fields because that can be done dangerously in C?

I think mis-handling = length fields has been an issue with protocols as long as protocols have = been implemented.

Yoav

On 26 Jun 2019, at 9:57, = Vincent Roca <vincent.roca@inria.fr> wrote:

Hello Yoav and = Linda,

Good = initiative.

Since you=E2=80=99re looking for stories, here is a proposal, = rooted in real life.
RFC6520 (https://tools.ietf.org/html/rfc6520) on TLS heartbeat = extension has a pretty simple security considerations section: it = says 
it does not introduce any new security = consideration and it refers to two existing RFCs.
We all know this TLS heartbeat = extension has been the cause of the famous heartbleed OpenSSL = vulnerability and associated attack.
Of course the = major problem comes from an erroneous implementation of the mechanism in = OpenSSL:

The goal is not to blame anybody in = person, especially as the RFC describes what should be done to prevent = any problem.
But I also think this = is a document where we all (i.e., authors/secdir/IESG) should have = highlighted the associated risk of badly
implementing= the response message in the Security Considerations section. As always = in such a situation, it=E2=80=99s easier to say afterwards!

I think there is a way = to say that in a positive way (lessons learned) and tell an interesting = story many people heard about without knowing
the = details.

Cheers,

  Vincent


Le 25 juin 2019 =C3=A0 20:57, Yoav Nir <ynir.ietf@gmail.com>= a =C3=A9crit :

Hi, = all

If you=E2=80=99ve = had a look at the draft agenda (https://datatracker.ietf.org/meeting/105/agenda.html), we = have a Writing Security Considerations tutorial on Sunday, which Linda = Dunbar and I will be doing.

The idea is to get people writing drafts to know what they = should do for a smooth interaction with us SecDir people.

The slides do not exist = yet, but we have a rough outline on github: https://github.com/IETF-SAAG/SecurityConsiderationsTutorial=

So if = there=E2=80=99s missing or wrong stuff, we=E2=80=99d like to hear about = it, preferably in the form of PRs.

But most of all, we=E2=80=99re looking = for more examples in the examples page: https://github.com/IETF-SAAG/SecurityConsiderationsTutorial/blo= b/master/examples.md

So any horror story, war story, stuff that=E2=80=99s terribly = wrong, or even something that=E2=80=99s surprisingly right will be = welcome.

Thanks = in advance

Linda= & Yoav

_______________________________________________
secdir mailing list
secdir@ietf.org
https://www.ietf.org/mailman/listinfo/secdir
wiki: = http://tools.ietf.org/area/sec/trac/wiki/SecDirReview


= --Apple-Mail=_6199880D-63AD-4E63-85A2-12A1FB935BE5-- From nobody Thu Jun 27 05:15:18 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F7D1200C5 for ; Thu, 27 Jun 2019 05:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 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, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 kjeE7TJOEzVq for ; Thu, 27 Jun 2019 05:15:13 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::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 878B9120026 for ; Thu, 27 Jun 2019 05:15:13 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x5RCCZah028867; Thu, 27 Jun 2019 13:15:12 +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=q0lOlc6cHBrhBVi4GqGCKHZIt+FKS7tfctWKfooRN4w=; b=OLkfFFdP0f64org3c1AraVA/V4x8LxsfWEndwLqI5jBT0CqINmYjEKLYhDzg4fqVCkni Nvho6osgU6lI73CX5DXp4qpyZgttJHW28PcweNPEfr+AA1GE7/hs76SoKG3KoYzp+INc 0YrOxgXBSvzRYvO3uE4H+UlEiAwvYhx8QYOYaj6+n8us29Q+hbKXqPgT78XpNFOAoHTc kJM3ve96A2WWnK5VFh43WtcDXdrXgmhKuSCHGVAI0p4QxH+bEkBcsLko/ClAMCt9ZChS zNMXHLkUHK7p3MFqcf3ir+SZI6xiqGdXlwflsxV331GEG+VbwGTMDdev990uEgBGyBrf EQ== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2tcfsm2nmb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Jun 2019 13:15:12 +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 x5RC29Fl006404; Thu, 27 Jun 2019 08:15:11 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2tccwpabdt-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 27 Jun 2019 08:15:11 -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 Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 27 Jun 2019 08:15:10 -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.004; Thu, 27 Jun 2019 08:15:10 -0400 From: "Salz, Rich" To: Yoav Nir , Vincent Roca CC: secdir Thread-Topic: [secdir] Writing Security Considerations Thread-Index: AQHVK4f+79E03v9Qr0aD3weHumEHZaatxOYAgAFp7YCAAD4JgA== Date: Thu, 27 Jun 2019 12:15:09 +0000 Message-ID: <7D1A00B2-3A6F-4B54-AE8F-9BB7771E6189@akamai.com> References: <421EA63E-CD5F-4BCC-AA24-3BDBD7182B24@inria.fr> <558A448D-E5EE-4E3C-9B0A-F5B5490E793C@gmail.com> In-Reply-To: <558A448D-E5EE-4E3C-9B0A-F5B5490E793C@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1a.0.190609 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.41] Content-Type: multipart/alternative; boundary="_000_7D1A00B23A6F4B54AE8F9BB7771E6189akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-27_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=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1906270141 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-06-27_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1810050000 definitions=main-1906270144 Archived-At: Subject: Re: [secdir] Writing Security Considerations X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 12:15:17 -0000 --_000_7D1A00B23A6F4B54AE8F9BB7771E6189akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2VsbCB0aGVyZeKAmXMgYWxzbyB0aGUgZmFjdCB0aGF0IGl0IHdhcyBpbXBsZW1lbnRlZCBpbiBU TFMgYnV0IG9ubHkgaW50ZW5kZWQgZm9yIERUTFMuDQoNCkJ1dCB5ZWFoLCBJ4oCZbSBzdGlsbCBu b3Qgc3VyZSB3aGF0IHRoZSBsZXNzb24gbGVhcm5lZCBpcy4NCg0KRnJvbTogWW9hdiBOaXIgPHlu aXIuaWV0ZkBnbWFpbC5jb20+DQpEYXRlOiBUaHVyc2RheSwgSnVuZSAyNywgMjAxOSBhdCAxMjoz MyBBTQ0KVG86IFZpbmNlbnQgUm9jYSA8dmluY2VudC5yb2NhQGlucmlhLmZyPg0KQ2M6ICJzZWNk aXJAaWV0Zi5vcmciIDxzZWNkaXJAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NlY2Rpcl0gV3Jp dGluZyBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQpIaSwgVmluY2VudC4NCg0KVGhhbmtzLCBi dXQgSSBkb27igJl0IGtub3cgd2hhdCBraW5kIG9mIGxlc3NvbiB0aGVyZSBpcyBpbiB0aGlzIGZv ciB0aGUgZ2VuZXJhbCBSRkMtd3JpdGluZyBhdWRpZW5jZS4NCg0KQWx3YXlzIGNhbGwgb3V0IHdo ZW4geW91IGhhdmUgaW50ZXJuYWwgbGVuZ3RoIGZpZWxkcyBiZWNhdXNlIHRoYXQgY2FuIGJlIGRv bmUgZGFuZ2Vyb3VzbHkgaW4gQz8NCg0KSSB0aGluayBtaXMtaGFuZGxpbmcgbGVuZ3RoIGZpZWxk cyBoYXMgYmVlbiBhbiBpc3N1ZSB3aXRoIHByb3RvY29scyBhcyBsb25nIGFzIHByb3RvY29scyBo YXZlIGJlZW4gaW1wbGVtZW50ZWQuDQoNCllvYXYNCg0KDQpPbiAyNiBKdW4gMjAxOSwgYXQgOTo1 NywgVmluY2VudCBSb2NhIDx2aW5jZW50LnJvY2FAaW5yaWEuZnI8bWFpbHRvOnZpbmNlbnQucm9j YUBpbnJpYS5mcj4+IHdyb3RlOg0KDQpIZWxsbyBZb2F2IGFuZCBMaW5kYSwNCg0KR29vZCBpbml0 aWF0aXZlLg0KDQpTaW5jZSB5b3XigJlyZSBsb29raW5nIGZvciBzdG9yaWVzLCBoZXJlIGlzIGEg cHJvcG9zYWwsIHJvb3RlZCBpbiByZWFsIGxpZmUuDQpSRkM2NTIwIChodHRwczovL3Rvb2xzLmll dGYub3JnL2h0bWwvcmZjNjUyMDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX3Rvb2xzLmlldGYub3JnX2h0bWxfcmZjNjUyMCZkPUR3TUZhUSZjPTk2 WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj00TE0wR2JSMGg5RnZ4ODZGdHNLSS13Jm09MzJINUthZXJl Y0ZGZkhMX1JiSzZfUzNMNWJ3VUU5Szg4X2w2OVJZcnZJUSZzPUZiRHpxRVRGWDA4MHM4bm5WWEhV Uno2NG81Y2JySEFHZEtrbnh4TVZzQkEmZT0+KSBvbiBUTFMgaGVhcnRiZWF0IGV4dGVuc2lvbiBo YXMgYSBwcmV0dHkgc2ltcGxlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb246IGl0IHNh eXMNCml0IGRvZXMgbm90IGludHJvZHVjZSBhbnkgbmV3IHNlY3VyaXR5IGNvbnNpZGVyYXRpb24g YW5kIGl0IHJlZmVycyB0byB0d28gZXhpc3RpbmcgUkZDcy4NCg0KV2UgYWxsIGtub3cgdGhpcyBU TFMgaGVhcnRiZWF0IGV4dGVuc2lvbiBoYXMgYmVlbiB0aGUgY2F1c2Ugb2YgdGhlIGZhbW91cyBo ZWFydGJsZWVkIE9wZW5TU0wgdnVsbmVyYWJpbGl0eSBhbmQgYXNzb2NpYXRlZCBhdHRhY2suDQpP ZiBjb3Vyc2UgdGhlIG1ham9yIHByb2JsZW0gY29tZXMgZnJvbSBhbiBlcnJvbmVvdXMgaW1wbGVt ZW50YXRpb24gb2YgdGhlIG1lY2hhbmlzbSBpbiBPcGVuU1NMOg0KaHR0cHM6Ly9naXQub3BlbnNz bC5vcmcvZ2l0d2ViLz9wPW9wZW5zc2wuZ2l0O2E9Y29tbWl0ZGlmZjtoPTk2ZGI5MDIzYjg4MWQ3 Y2Q5ZjM3OWIwYzE1NDY1MGQ2YzEwOGU5YTM8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tL3YyL3VybD91PWh0dHBzLTNBX19naXQub3BlbnNzbC5vcmdfZ2l0d2ViXy0zRnAtM0RvcGVu c3NsLmdpdC0zQmEtM0Rjb21taXRkaWZmLTNCaC0zRDk2ZGI5MDIzYjg4MWQ3Y2Q5ZjM3OWIwYzE1 NDY1MGQ2YzEwOGU5YTMmZD1Ed01GYVEmYz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJnI9NExNMEdi UjBoOUZ2eDg2RnRzS0ktdyZtPTMySDVLYWVyZWNGRmZITF9SYks2X1MzTDVid1VFOUs4OF9sNjlS WXJ2SVEmcz05RlpUd29PYXVINDdrX25nRk1qUXp1TVBSYjBqSVdjczk2WTBheGRNOWdZJmU9Pg0K DQpUaGUgZ29hbCBpcyBub3QgdG8gYmxhbWUgYW55Ym9keSBpbiBwZXJzb24sIGVzcGVjaWFsbHkg YXMgdGhlIFJGQyBkZXNjcmliZXMgd2hhdCBzaG91bGQgYmUgZG9uZSB0byBwcmV2ZW50IGFueSBw cm9ibGVtLg0KQnV0IEkgYWxzbyB0aGluayB0aGlzIGlzIGEgZG9jdW1lbnQgd2hlcmUgd2UgYWxs IChpLmUuLCBhdXRob3JzL3NlY2Rpci9JRVNHKSBzaG91bGQgaGF2ZSBoaWdobGlnaHRlZCB0aGUg YXNzb2NpYXRlZCByaXNrIG9mIGJhZGx5DQppbXBsZW1lbnRpbmcgdGhlIHJlc3BvbnNlIG1lc3Nh Z2UgaW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24uIEFzIGFsd2F5cyBpbiBz dWNoIGEgc2l0dWF0aW9uLCBpdOKAmXMgZWFzaWVyIHRvIHNheSBhZnRlcndhcmRzIQ0KDQpJIHRo aW5rIHRoZXJlIGlzIGEgd2F5IHRvIHNheSB0aGF0IGluIGEgcG9zaXRpdmUgd2F5IChsZXNzb25z IGxlYXJuZWQpIGFuZCB0ZWxsIGFuIGludGVyZXN0aW5nIHN0b3J5IG1hbnkgcGVvcGxlIGhlYXJk IGFib3V0IHdpdGhvdXQga25vd2luZw0KdGhlIGRldGFpbHMuDQoNCkNoZWVycywNCg0KICBWaW5j ZW50DQoNCg0KTGUgMjUganVpbiAyMDE5IMOgIDIwOjU3LCBZb2F2IE5pciA8eW5pci5pZXRmQGdt YWlsLmNvbTxtYWlsdG86eW5pci5pZXRmQGdtYWlsLmNvbT4+IGEgw6ljcml0IDoNCg0KSGksIGFs bA0KDQpJZiB5b3XigJl2ZSBoYWQgYSBsb29rIGF0IHRoZSBkcmFmdCBhZ2VuZGEgKGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDUvYWdlbmRhLmh0bWw8aHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRm Lm9yZ19tZWV0aW5nXzEwNV9hZ2VuZGEuaHRtbCZkPUR3TUZhUSZjPTk2WmJaWmNhTUY0dzBGNGpw TjZMWmcmcj00TE0wR2JSMGg5RnZ4ODZGdHNLSS13Jm09MzJINUthZXJlY0ZGZkhMX1JiSzZfUzNM NWJ3VUU5Szg4X2w2OVJZcnZJUSZzPTNVSTdXUW13Znl6N2gxYnVpVlpPWThnN0Q2SzhBUkxTSFhB cm5fUFlVQmMmZT0+KSwgd2UgaGF2ZSBhIFdyaXRpbmcgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMg dHV0b3JpYWwgb24gU3VuZGF5LCB3aGljaCBMaW5kYSBEdW5iYXIgYW5kIEkgd2lsbCBiZSBkb2lu Zy4NCg0KVGhlIGlkZWEgaXMgdG8gZ2V0IHBlb3BsZSB3cml0aW5nIGRyYWZ0cyB0byBrbm93IHdo YXQgdGhleSBzaG91bGQgZG8gZm9yIGEgc21vb3RoIGludGVyYWN0aW9uIHdpdGggdXMgU2VjRGly IHBlb3BsZS4NCg0KVGhlIHNsaWRlcyBkbyBub3QgZXhpc3QgeWV0LCBidXQgd2UgaGF2ZSBhIHJv dWdoIG91dGxpbmUgb24gZ2l0aHViOiBodHRwczovL2dpdGh1Yi5jb20vSUVURi1TQUFHL1NlY3Vy aXR5Q29uc2lkZXJhdGlvbnNUdXRvcmlhbDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX2dpdGh1Yi5jb21fSUVURi0yRFNBQUdfU2VjdXJpdHlDb25z aWRlcmF0aW9uc1R1dG9yaWFsJmQ9RHdNRmFRJmM9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZyPTRM TTBHYlIwaDlGdng4NkZ0c0tJLXcmbT0zMkg1S2FlcmVjRkZmSExfUmJLNl9TM0w1YndVRTlLODhf bDY5UllydklRJnM9a01ZeXE5VHo1Ulp5cXBhQmpFUHdTV1lMdzdQNmpHOWVxaWdmRGVXMWxOayZl PT4NCg0KU28gaWYgdGhlcmXigJlzIG1pc3Npbmcgb3Igd3Jvbmcgc3R1ZmYsIHdl4oCZZCBsaWtl IHRvIGhlYXIgYWJvdXQgaXQsIHByZWZlcmFibHkgaW4gdGhlIGZvcm0gb2YgUFJzLg0KDQpCdXQg bW9zdCBvZiBhbGwsIHdl4oCZcmUgbG9va2luZyBmb3IgbW9yZSBleGFtcGxlcyBpbiB0aGUgZXhh bXBsZXMgcGFnZTogaHR0cHM6Ly9naXRodWIuY29tL0lFVEYtU0FBRy9TZWN1cml0eUNvbnNpZGVy YXRpb25zVHV0b3JpYWwvYmxvYi9tYXN0ZXIvZXhhbXBsZXMubWQ8aHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19naXRodWIuY29tX0lFVEYtMkRTQUFH X1NlY3VyaXR5Q29uc2lkZXJhdGlvbnNUdXRvcmlhbF9ibG9iX21hc3Rlcl9leGFtcGxlcy5tZCZk PUR3TUZhUSZjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj00TE0wR2JSMGg5RnZ4ODZGdHNLSS13 Jm09MzJINUthZXJlY0ZGZkhMX1JiSzZfUzNMNWJ3VUU5Szg4X2w2OVJZcnZJUSZzPWYxSDZiclUt MTNsWXUxX3JUbXBYdjVmR1U1ZGMyNThsMVVYdWFJck9YM1kmZT0+DQoNClNvIGFueSBob3Jyb3Ig c3RvcnksIHdhciBzdG9yeSwgc3R1ZmYgdGhhdOKAmXMgdGVycmlibHkgd3JvbmcsIG9yIGV2ZW4g c29tZXRoaW5nIHRoYXTigJlzIHN1cnByaXNpbmdseSByaWdodCB3aWxsIGJlIHdlbGNvbWUuDQoN ClRoYW5rcyBpbiBhZHZhbmNlDQoNCkxpbmRhICYgWW9hdg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2VjZGlyIG1haWxpbmcgbGlzdA0Kc2VjZGly QGlldGYub3JnPG1haWx0bzpzZWNkaXJAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NlY2RpcjxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20v djIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3NlY2RpciZk PUR3TUZhUSZjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj00TE0wR2JSMGg5RnZ4ODZGdHNLSS13 Jm09MzJINUthZXJlY0ZGZkhMX1JiSzZfUzNMNWJ3VUU5Szg4X2w2OVJZcnZJUSZzPTZiNlNSUGYt dmtrUHZqLUZyWC1xOHJ3UkhFMVJDRjU0cE9IVkZRQWtrUlEmZT0+DQp3aWtpOiBodHRwOi8vdG9v bHMuaWV0Zi5vcmcvYXJlYS9zZWMvdHJhYy93aWtpL1NlY0RpclJldmlldw0KDQoNCg== --_000_7D1A00B23A6F4B54AE8F9BB7771E6189akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <9AE02D15AC84D846A236CAA2DD58883B@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPldlbGwgdGhlcmXigJlzIGFsc28gdGhlIGZhY3QgdGhhdCBpdCB3YXMgaW1wbGVt ZW50ZWQgaW4gVExTIGJ1dCBvbmx5IGludGVuZGVkIGZvciBEVExTLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5CdXQgeWVhaCwgSeKAmW0gc3RpbGwgbm90IHN1cmUgd2hhdCB0aGUgbGVzc29uIGxl YXJuZWQgaXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Zb2F2 IE5pciAmbHQ7eW5pci5pZXRmQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+VGh1cnNk YXksIEp1bmUgMjcsIDIwMTkgYXQgMTI6MzMgQU08YnI+DQo8Yj5UbzogPC9iPlZpbmNlbnQgUm9j YSAmbHQ7dmluY2VudC5yb2NhQGlucmlhLmZyJmd0Ozxicj4NCjxiPkNjOiA8L2I+JnF1b3Q7c2Vj ZGlyQGlldGYub3JnJnF1b3Q7ICZsdDtzZWNkaXJAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVj dDogPC9iPlJlOiBbc2VjZGlyXSBXcml0aW5nIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLCBWaW5j ZW50LiA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5r cywgYnV0IEkgZG9u4oCZdCBrbm93IHdoYXQga2luZCBvZiBsZXNzb24gdGhlcmUgaXMgaW4gdGhp cyBmb3IgdGhlIGdlbmVyYWwgUkZDLXdyaXRpbmcgYXVkaWVuY2UuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsd2F5cyBjYWxsIG91dCB3aGVu IHlvdSBoYXZlIGludGVybmFsIGxlbmd0aCBmaWVsZHMgYmVjYXVzZSB0aGF0IGNhbiBiZSBkb25l IGRhbmdlcm91c2x5IGluIEM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgbWlzLWhhbmRsaW5nIGxlbmd0aCBmaWVsZHMgaGFzIGJl ZW4gYW4gaXNzdWUgd2l0aCBwcm90b2NvbHMgYXMgbG9uZyBhcyBwcm90b2NvbHMgaGF2ZSBiZWVu IGltcGxlbWVudGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5Zb2F2PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2lu LXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiAyNiBKdW4gMjAxOSwgYXQgOTo1NywgVmluY2VudCBSb2NhICZsdDs8YSBocmVmPSJt YWlsdG86dmluY2VudC5yb2NhQGlucmlhLmZyIj52aW5jZW50LnJvY2FAaW5yaWEuZnI8L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhl bGxvIFlvYXYgYW5kIExpbmRhLCA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkdvb2QgaW5pdGlhdGl2ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2luY2UgeW914oCZcmUgbG9va2luZyBmb3Igc3Rvcmll cywgaGVyZSBpcyBhIHByb3Bvc2FsLCByb290ZWQgaW4gcmVhbCBsaWZlLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UkZDNjUyMCAoPGEgaHJlZj0i aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29s cy5pZXRmLm9yZ19odG1sX3JmYzY1MjAmYW1wO2Q9RHdNRmFRJmFtcDtjPTk2WmJaWmNhTUY0dzBG NGpwTjZMWmcmYW1wO3I9NExNMEdiUjBoOUZ2eDg2RnRzS0ktdyZhbXA7bT0zMkg1S2FlcmVjRkZm SExfUmJLNl9TM0w1YndVRTlLODhfbDY5UllydklRJmFtcDtzPUZiRHpxRVRGWDA4MHM4bm5WWEhV Uno2NG81Y2JySEFHZEtrbnh4TVZzQkEmYW1wO2U9Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNjUyMDwvYT4pDQogb24gVExTIGhlYXJ0YmVhdCBleHRlbnNpb24gaGFzIGEgcHJldHR5 IHNpbXBsZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uOiBpdCBzYXlzJm5ic3A7PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pdCBkb2Vz IG5vdCBpbnRyb2R1Y2UgYW55IG5ldyBzZWN1cml0eSBjb25zaWRlcmF0aW9uIGFuZCBpdCByZWZl cnMgdG8gdHdvIGV4aXN0aW5nIFJGQ3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPldlIGFsbCBrbm93IHRoaXMgVExTIGhlYXJ0YmVhdCBleHRl bnNpb24gaGFzIGJlZW4gdGhlIGNhdXNlIG9mIHRoZSBmYW1vdXMgaGVhcnRibGVlZCBPcGVuU1NM IHZ1bG5lcmFiaWxpdHkgYW5kIGFzc29jaWF0ZWQgYXR0YWNrLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T2YgY291cnNlIHRoZSBtYWpvciBwcm9i bGVtIGNvbWVzIGZyb20gYW4gZXJyb25lb3VzIGltcGxlbWVudGF0aW9uIG9mIHRoZSBtZWNoYW5p c20gaW4gT3BlblNTTDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91 cmw/dT1odHRwcy0zQV9fZ2l0Lm9wZW5zc2wub3JnX2dpdHdlYl8tM0ZwLTNEb3BlbnNzbC5naXQt M0JhLTNEY29tbWl0ZGlmZi0zQmgtM0Q5NmRiOTAyM2I4ODFkN2NkOWYzNzliMGMxNTQ2NTBkNmMx MDhlOWEzJmFtcDtkPUR3TUZhUSZhbXA7Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJmFtcDtyPTRM TTBHYlIwaDlGdng4NkZ0c0tJLXcmYW1wO209MzJINUthZXJlY0ZGZkhMX1JiSzZfUzNMNWJ3VUU5 Szg4X2w2OVJZcnZJUSZhbXA7cz05RlpUd29PYXVINDdrX25nRk1qUXp1TVBSYjBqSVdjczk2WTBh eGRNOWdZJmFtcDtlPSI+aHR0cHM6Ly9naXQub3BlbnNzbC5vcmcvZ2l0d2ViLz9wPW9wZW5zc2wu Z2l0O2E9Y29tbWl0ZGlmZjtoPTk2ZGI5MDIzYjg4MWQ3Y2Q5ZjM3OWIwYzE1NDY1MGQ2YzEwOGU5 YTM8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoZSBnb2FsIGlzIG5vdCB0byBibGFtZSBhbnlib2R5IGluIHBlcnNvbiwgZXNwZWNpYWxs eSBhcyB0aGUgUkZDIGRlc2NyaWJlcyB3aGF0IHNob3VsZCBiZSBkb25lIHRvIHByZXZlbnQgYW55 IHByb2JsZW0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+QnV0IEkgYWxzbyB0aGluayB0aGlzIGlzIGEgZG9jdW1lbnQgd2hlcmUgd2Ug YWxsIChpLmUuLCBhdXRob3JzL3NlY2Rpci9JRVNHKSBzaG91bGQgaGF2ZSBoaWdobGlnaHRlZCB0 aGUgYXNzb2NpYXRlZCByaXNrIG9mIGJhZGx5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pbXBsZW1lbnRpbmcgdGhlIHJlc3BvbnNlIG1lc3NhZ2Ug aW4gdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24uIEFzIGFsd2F5cyBpbiBzdWNo IGEgc2l0dWF0aW9uLCBpdOKAmXMgZWFzaWVyIHRvIHNheSBhZnRlcndhcmRzITxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoZXJl IGlzIGEgd2F5IHRvIHNheSB0aGF0IGluIGEgcG9zaXRpdmUgd2F5IChsZXNzb25zIGxlYXJuZWQp IGFuZCB0ZWxsIGFuIGludGVyZXN0aW5nIHN0b3J5IG1hbnkgcGVvcGxlIGhlYXJkIGFib3V0IHdp dGhvdXQga25vd2luZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+dGhlIGRldGFpbHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgVmluY2VudDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxl IDI1IGp1aW4gMjAxOSDDoCAyMDo1NywgWW9hdiBOaXIgJmx0OzxhIGhyZWY9Im1haWx0bzp5bmly LmlldGZAZ21haWwuY29tIj55bmlyLmlldGZAZ21haWwuY29tPC9hPiZndDsgYSDDqWNyaXQgOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksIGFsbCA8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHlvdeKAmXZlIGhh ZCBhIGxvb2sgYXQgdGhlIGRyYWZ0IGFnZW5kYSAoPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNl LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRmLm9yZ19t ZWV0aW5nXzEwNV9hZ2VuZGEuaHRtbCZhbXA7ZD1Ed01GYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0 anBONkxaZyZhbXA7cj00TE0wR2JSMGg5RnZ4ODZGdHNLSS13JmFtcDttPTMySDVLYWVyZWNGRmZI TF9SYks2X1MzTDVid1VFOUs4OF9sNjlSWXJ2SVEmYW1wO3M9M1VJN1dRbXdmeXo3aDFidWlWWk9Z OGc3RDZLOEFSTFNIWEFybl9QWVVCYyZhbXA7ZT0iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvbWVldGluZy8xMDUvYWdlbmRhLmh0bWw8L2E+KSwNCiB3ZSBoYXZlIGEgV3JpdGluZyBTZWN1 cml0eSBDb25zaWRlcmF0aW9ucyB0dXRvcmlhbCBvbiBTdW5kYXksIHdoaWNoIExpbmRhIER1bmJh ciBhbmQgSSB3aWxsIGJlIGRvaW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgaWRlYSBpcyB0byBnZXQgcGVvcGxlIHdyaXRpbmcgZHJh ZnRzIHRvIGtub3cgd2hhdCB0aGV5IHNob3VsZCBkbyBmb3IgYSBzbW9vdGggaW50ZXJhY3Rpb24g d2l0aCB1cyBTZWNEaXIgcGVvcGxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgc2xpZGVzIGRvIG5vdCBleGlzdCB5ZXQsIGJ1dCB3ZSBo YXZlIGEgcm91Z2ggb3V0bGluZSBvbiBnaXRodWI6Jm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19naXRodWIuY29tX0lFVEYt MkRTQUFHX1NlY3VyaXR5Q29uc2lkZXJhdGlvbnNUdXRvcmlhbCZhbXA7ZD1Ed01GYVEmYW1wO2M9 OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj00TE0wR2JSMGg5RnZ4ODZGdHNLSS13JmFtcDtt PTMySDVLYWVyZWNGRmZITF9SYks2X1MzTDVid1VFOUs4OF9sNjlSWXJ2SVEmYW1wO3M9a01ZeXE5 VHo1Ulp5cXBhQmpFUHdTV1lMdzdQNmpHOWVxaWdmRGVXMWxOayZhbXA7ZT0iPmh0dHBzOi8vZ2l0 aHViLmNvbS9JRVRGLVNBQUcvU2VjdXJpdHlDb25zaWRlcmF0aW9uc1R1dG9yaWFsPC9hPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBpZiB0 aGVyZeKAmXMgbWlzc2luZyBvciB3cm9uZyBzdHVmZiwgd2XigJlkIGxpa2UgdG8gaGVhciBhYm91 dCBpdCwgcHJlZmVyYWJseSBpbiB0aGUgZm9ybSBvZiBQUnMuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCBtb3N0IG9mIGFsbCwgd2XigJly ZSBsb29raW5nIGZvciBtb3JlIGV4YW1wbGVzIGluIHRoZSBleGFtcGxlcyBwYWdlOiZuYnNwOzxh IGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fZ2l0aHViLmNvbV9JRVRGLTJEU0FBR19TZWN1cml0eUNvbnNpZGVyYXRpb25zVHV0b3JpYWxf YmxvYl9tYXN0ZXJfZXhhbXBsZXMubWQmYW1wO2Q9RHdNRmFRJmFtcDtjPTk2WmJaWmNhTUY0dzBG NGpwTjZMWmcmYW1wO3I9NExNMEdiUjBoOUZ2eDg2RnRzS0ktdyZhbXA7bT0zMkg1S2FlcmVjRkZm SExfUmJLNl9TM0w1YndVRTlLODhfbDY5UllydklRJmFtcDtzPWYxSDZiclUtMTNsWXUxX3JUbXBY djVmR1U1ZGMyNThsMVVYdWFJck9YM1kmYW1wO2U9Ij5odHRwczovL2dpdGh1Yi5jb20vSUVURi1T QUFHL1NlY3VyaXR5Q29uc2lkZXJhdGlvbnNUdXRvcmlhbC9ibG9iL21hc3Rlci9leGFtcGxlcy5t ZDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+U28gYW55IGhvcnJvciBzdG9yeSwgd2FyIHN0b3J5LCBzdHVmZiB0aGF04oCZcyB0ZXJyaWJs eSB3cm9uZywgb3IgZXZlbiBzb21ldGhpbmcgdGhhdOKAmXMgc3VycHJpc2luZ2x5IHJpZ2h0IHdp bGwgYmUgd2VsY29tZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhhbmtzIGluIGFkdmFuY2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGluZGEgJmFtcDsgWW9hdjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzZWNkaXIgbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNlY2RpckBpZXRmLm9yZyI+c2VjZGlyQGlldGYub3JnPC9h Pjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/ dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fc2VjZGlyJmFtcDtkPUR3 TUZhUSZhbXA7Yz05NlpiWlpjYU1GNHcwRjRqcE42TFpnJmFtcDtyPTRMTTBHYlIwaDlGdng4NkZ0 c0tJLXcmYW1wO209MzJINUthZXJlY0ZGZkhMX1JiSzZfUzNMNWJ3VUU5Szg4X2w2OVJZcnZJUSZh bXA7cz02YjZTUlBmLXZra1B2ai1GclgtcThyd1JIRTFSQ0Y1NHBPSFZGUUFra1JRJmFtcDtlPSI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXI8L2E+PGJyPg0Kd2lr aTogaHR0cDovL3Rvb2xzLmlldGYub3JnL2FyZWEvc2VjL3RyYWMvd2lraS9TZWNEaXJSZXZpZXc8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7D1A00B23A6F4B54AE8F9BB7771E6189akamaicom_-- From nobody Thu Jun 27 05:50:39 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A22B3120441 for ; Thu, 27 Jun 2019 05:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.798 X-Spam-Level: X-Spam-Status: No, score=-6.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 DPZ-vQg_r0dp for ; Thu, 27 Jun 2019 05:50:34 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (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 8ABF11203BB for ; Thu, 27 Jun 2019 05:50:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.63,423,1557180000"; d="scan'208,217";a="389371595" Received: from moucherotte.inrialpes.fr ([194.199.28.14]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Jun 2019 14:50:04 +0200 From: Vincent Roca Message-Id: <5C18F02D-BACE-4251-99D9-AA8D0AEA7F37@inria.fr> Content-Type: multipart/alternative; boundary="Apple-Mail=_F32A0BE0-3C8B-4B23-B058-12F77345E1A0" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 27 Jun 2019 14:50:03 +0200 In-Reply-To: <7D1A00B2-3A6F-4B54-AE8F-9BB7771E6189@akamai.com> Cc: Vincent Roca , secdir To: "Salz, Rich" , Yoav Nir References: <421EA63E-CD5F-4BCC-AA24-3BDBD7182B24@inria.fr> <558A448D-E5EE-4E3C-9B0A-F5B5490E793C@gmail.com> <7D1A00B2-3A6F-4B54-AE8F-9BB7771E6189@akamai.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [secdir] Writing Security Considerations X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 12:50:38 -0000 --Apple-Mail=_F32A0BE0-3C8B-4B23-B058-12F77345E1A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, The two messages I would suggest: - You, authors, think everything is fine, that your proposal = does not introduce any new threat. Think it twice (or more),=20 there=E2=80=99s probably something that=E2=80=99s worth being = said; - And the Security Considerations section is also meant to help = developers: in this specific case, it would have=20 been nice to add a warning about this carbon copy in the reply = packet, as we all discovered later. I think it=E2=80=99s a good example of cool protocol feature that can = turn into a security nightmare if wrongly implemented. It=E2=80=99s worth explaining IMHO. But that=E2=80=99s just an idea, feel free to ignore my suggestion. Cheers, Vincent > Le 27 juin 2019 =C3=A0 14:15, Salz, Rich a =C3=A9crit= : >=20 > Well there=E2=80=99s also the fact that it was implemented in TLS but = only intended for DTLS. > =20 > But yeah, I=E2=80=99m still not sure what the lesson learned is. > =20 > From: Yoav Nir > Date: Thursday, June 27, 2019 at 12:33 AM > To: Vincent Roca > Cc: "secdir@ietf.org" > Subject: Re: [secdir] Writing Security Considerations > =20 > Hi, Vincent.=20 > =20 > Thanks, but I don=E2=80=99t know what kind of lesson there is in this = for the general RFC-writing audience. > =20 > Always call out when you have internal length fields because that can = be done dangerously in C? > =20 > I think mis-handling length fields has been an issue with protocols as = long as protocols have been implemented. > =20 > Yoav >=20 >=20 >> On 26 Jun 2019, at 9:57, Vincent Roca > wrote: >> =20 >> Hello Yoav and Linda,=20 >> =20 >> Good initiative. >> =20 >> Since you=E2=80=99re looking for stories, here is a proposal, rooted = in real life. >> RFC6520 (https://tools.ietf.org/html/rfc6520 = ) on TLS heartbeat extension has a pretty = simple security considerations section: it says=20 >> it does not introduce any new security consideration and it refers to = two existing RFCs. >> =20 >> We all know this TLS heartbeat extension has been the cause of the = famous heartbleed OpenSSL vulnerability and associated attack. >> Of course the major problem comes from an erroneous implementation of = the mechanism in OpenSSL: >> = https://git.openssl.org/gitweb/?p=3Dopenssl.git;a=3Dcommitdiff;h=3D96db902= 3b881d7cd9f379b0c154650d6c108e9a3 = >> =20 >> The goal is not to blame anybody in person, especially as the RFC = describes what should be done to prevent any problem. >> But I also think this is a document where we all (i.e., = authors/secdir/IESG) should have highlighted the associated risk of = badly >> implementing the response message in the Security Considerations = section. As always in such a situation, it=E2=80=99s easier to say = afterwards! >> =20 >> I think there is a way to say that in a positive way (lessons = learned) and tell an interesting story many people heard about without = knowing >> the details. >> =20 >> Cheers, >> =20 >> Vincent >> =20 >> =20 >>> Le 25 juin 2019 =C3=A0 20:57, Yoav Nir > a =C3=A9crit : >>> =20 >>> Hi, all=20 >>> =20 >>> If you=E2=80=99ve had a look at the draft agenda = (https://datatracker.ietf.org/meeting/105/agenda.html = ), we have a Writing = Security Considerations tutorial on Sunday, which Linda Dunbar and I = will be doing. >>> =20 >>> The idea is to get people writing drafts to know what they should do = for a smooth interaction with us SecDir people. >>> =20 >>> The slides do not exist yet, but we have a rough outline on github: = https://github.com/IETF-SAAG/SecurityConsiderationsTutorial = >>> =20 >>> So if there=E2=80=99s missing or wrong stuff, we=E2=80=99d like to = hear about it, preferably in the form of PRs. >>> =20 >>> But most of all, we=E2=80=99re looking for more examples in the = examples page: = https://github.com/IETF-SAAG/SecurityConsiderationsTutorial/blob/master/ex= amples.md = >>> =20 >>> So any horror story, war story, stuff that=E2=80=99s terribly wrong, = or even something that=E2=80=99s surprisingly right will be welcome. >>> =20 >>> Thanks in advance >>> =20 >>> Linda & Yoav >>> =20 >>> _______________________________________________ >>> secdir mailing list >>> secdir@ietf.org >>> https://www.ietf.org/mailman/listinfo/secdir = >>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview --Apple-Mail=_F32A0BE0-3C8B-4B23-B058-12F77345E1A0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello,

The = two messages I would suggest:
- You, = authors, think everything is fine, that your proposal does not introduce = any new threat. Think it twice (or more), 
  =  there=E2=80=99s probably something that=E2=80=99s worth being = said;
- And the Security Considerations = section is also meant to help developers: in this specific case, it = would have 
  been nice to add a = warning about this carbon copy in the reply packet, as we all discovered = later.

I think = it=E2=80=99s a good example of cool protocol feature that can turn into = a security nightmare if wrongly implemented.
It=E2=80= =99s worth explaining IMHO.

But that=E2=80=99s just an idea, feel free to ignore my = suggestion.
Cheers,

  Vincent


Le = 27 juin 2019 =C3=A0 14:15, Salz, Rich <rsalz@akamai.com> a = =C3=A9crit :

Well there=E2=80=99s also the fact that = it was implemented in TLS but only intended for DTLS.
 
But yeah, = I=E2=80=99m still not sure what the lesson learned is.
 
From: Yoav Nir <ynir.ietf@gmail.com>
Date: Thursday, June 27, 2019 = at 12:33 AM
To: Vincent Roca <vincent.roca@inria.fr>
Cc: "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Writing = Security Considerations
 
Hi, Vincent. 
 
Thanks, but I don=E2=80=99t know what = kind of lesson there is in this for the general RFC-writing = audience.
 
Always call out when you have internal length fields because = that can be done dangerously in C?
 
I think mis-handling length fields has been an issue with = protocols as long as protocols have been implemented.
 
Yoav


On 26 Jun 2019, at 9:57, Vincent Roca = <vincent.roca@inria.fr> = wrote:
 
Hello Yoav and Linda, 
 
Good initiative.
 
Since you=E2=80=99re looking for = stories, here is a proposal, rooted in real life.
RFC6520 (https://tools.ietf.org/html/rfc6520) on TLS heartbeat = extension has a pretty simple security considerations section: it = says 
it does not introduce any new security = consideration and it refers to two existing RFCs.
 
We all know this TLS heartbeat = extension has been the cause of the famous heartbleed OpenSSL = vulnerability and associated attack.
Of course the major = problem comes from an erroneous implementation of the mechanism in = OpenSSL:
 
The goal is not to blame anybody in = person, especially as the RFC describes what should be done to prevent = any problem.
But I also think this is a = document where we all (i.e., authors/secdir/IESG) should have = highlighted the associated risk of badly
implementing the response message in the Security = Considerations section. As always in such a situation, it=E2=80=99s = easier to say afterwards!
 
I think there is a way to say that in a positive way (lessons = learned) and tell an interesting story many people heard about without = knowing
the details.
 
Cheers,
 
  Vincent
 
 
Le 25 = juin 2019 =C3=A0 20:57, Yoav Nir <ynir.ietf@gmail.com> a = =C3=A9crit :
 
Hi, all 
 
If you=E2=80=99ve had a look at the = draft agenda (https://datatracker.ietf.org/meeting/105/agenda.html), we = have a Writing Security Considerations tutorial on Sunday, which Linda = Dunbar and I will be doing.
 
The idea is to get people writing drafts to know what they = should do for a smooth interaction with us SecDir people.
 
The slides do not exist yet, but we = have a rough outline on github: https://github.com/IETF-SAAG/SecurityConsiderationsTutorial=
 
So if there=E2=80=99s missing or wrong = stuff, we=E2=80=99d like to hear about it, preferably in the form of = PRs.
 
But most of all, we=E2=80=99re looking for more examples in = the examples page: https://github.com/IETF-SAAG/SecurityConsiderationsTutorial/blo= b/master/examples.md
 
So any horror story, war story, stuff that=E2=80=99s terribly = wrong, or even something that=E2=80=99s surprisingly right will be = welcome.
 
Thanks in advance
 
Linda & Yoav
 
=
=
= --Apple-Mail=_F32A0BE0-3C8B-4B23-B058-12F77345E1A0-- From nobody Thu Jun 27 09:47:27 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A818120118 for ; Thu, 27 Jun 2019 09:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=futurewei.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 7eR-uM3uEsnY for ; Thu, 27 Jun 2019 09:47:23 -0700 (PDT) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-eopbgr810094.outbound.protection.outlook.com [40.107.81.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B40E7120112 for ; Thu, 27 Jun 2019 09:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Futurewei.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xZhZWGbEw1zylxEqZSbNPUSq8Aoap+e4jH7ehqYj8wA=; b=pTqgFT6Wa+5b0b6KXfFAS/3PxskCTn0rD2pfm6wR4ywTD51m7dF4uKfngqJzraUn0D0k13VWYYwMyPzpZPRKEbjhfO1vX91IeB3IoNQREM3EN+QbexW0Zy3IdBCzLoajBodHj/HJFc+fbev/0FbZhvHeusoYVyUyqDfVwdM2Lr8= Received: from MN2PR13MB3582.namprd13.prod.outlook.com (10.255.238.139) by MN2PR13MB2656.namprd13.prod.outlook.com (20.178.251.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2032.12; Thu, 27 Jun 2019 16:47:20 +0000 Received: from MN2PR13MB3582.namprd13.prod.outlook.com ([fe80::a8cd:e9ef:5219:67ea]) by MN2PR13MB3582.namprd13.prod.outlook.com ([fe80::a8cd:e9ef:5219:67ea%6]) with mapi id 15.20.2032.012; Thu, 27 Jun 2019 16:47:20 +0000 From: Linda Dunbar To: Vincent Roca , "Salz, Rich" , Yoav Nir CC: secdir Thread-Topic: [secdir] Writing Security Considerations Thread-Index: AQHVK4fepAORvcYl7Eyn4Hgy5k6N9KatgdgAgAFp7YCAAIEYgIAACcCAgAA/+lA= Date: Thu, 27 Jun 2019 16:47:20 +0000 Message-ID: References: <421EA63E-CD5F-4BCC-AA24-3BDBD7182B24@inria.fr> <558A448D-E5EE-4E3C-9B0A-F5B5490E793C@gmail.com> <7D1A00B2-3A6F-4B54-AE8F-9BB7771E6189@akamai.com> <5C18F02D-BACE-4251-99D9-AA8D0AEA7F37@inria.fr> In-Reply-To: <5C18F02D-BACE-4251-99D9-AA8D0AEA7F37@inria.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=linda.dunbar@futurewei.com; x-originating-ip: [12.111.81.80] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c73afe09-142e-49b2-e448-08d6fb1f1f6a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR13MB2656; x-ms-traffictypediagnostic: MN2PR13MB2656: x-ms-exchange-purlcount: 9 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 008184426E x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400004)(366004)(346002)(136003)(396003)(376002)(199004)(189003)(51874003)(14454004)(66574012)(3846002)(5660300002)(186003)(26005)(6436002)(71200400001)(6246003)(6116002)(14444005)(2906002)(256004)(15650500001)(2420400007)(790700001)(52536014)(6306002)(55016002)(76116006)(478600001)(86362001)(71190400001)(316002)(73956011)(64756008)(9686003)(54896002)(236005)(4326008)(606006)(66946007)(53936002)(81166006)(66446008)(561944003)(44832011)(66556008)(8936002)(74316002)(966005)(476003)(8676002)(25786009)(11346002)(7110500001)(7736002)(102836004)(446003)(53546011)(7696005)(6506007)(76176011)(486006)(99286004)(66066001)(68736007)(110136005)(33656002)(66476007)(81156014)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR13MB2656; H:MN2PR13MB3582.namprd13.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: futurewei.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 3E/F9SSGrAqy2NnIAo8WwphmSPvWivDBA/ZA6Q9IePEew6y9IQlvSfV94sQaefymP07jwKizB46xfhLBerRcRzccjFTAwgJQyGl2X7WHe08q4x8dBgsJ3uP3jW7aMfu9s2+WGczz6tTcWi4W3AUO8FAcgUIRZB6ggWCHqMkxdOhVRU071+OHuylYfclfSM8qNxJaX0cnPp7iXieHpXuH52fq9gsZBcrz3GwdX8FlcH9Z29FjeDEAvRxcPS4IdtMm1/ms+cmX6KTDSkASV526cHuB67wMtG5x02rLjvF4i70C6kAIJc9NoEz6CvYGqECyifeUZ5twT6/wkKxhdbvQp3z5VSofjQCGhboM5Cbl/e29cYK/hmmmhXK9IlSxkKQ+Ww82l+cpo0ZdzXlQIR/idXEK+NdjD35nk4X3CHcROK0= Content-Type: multipart/alternative; boundary="_000_MN2PR13MB35824C91911136E2E1DD1D4B85FD0MN2PR13MB3582namp_" MIME-Version: 1.0 X-OriginatorOrg: Futurewei.com X-MS-Exchange-CrossTenant-Network-Message-Id: c73afe09-142e-49b2-e448-08d6fb1f1f6a X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2019 16:47:20.7291 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 0fee8ff2-a3b2-4018-9c75-3a1d5591fedc X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ldunbar@futurewei.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR13MB2656 Archived-At: Subject: Re: [secdir] Writing Security Considerations X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 16:47:26 -0000 --_000_MN2PR13MB35824C91911136E2E1DD1D4B85FD0MN2PR13MB3582namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzZWUgbWFueSBkcmFmdHMgZnJvbSBSb3V0aW5nIEFyZWEgYW5kIE9wcyBBcmVhcyBoYXZlIHRo ZSBzaW1pbGFyIHdyaXRpbmcgb24gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgYXMgUkZDNjUyMC4N CkZvciBtYW55IHBlb3BsZSBpbiBSb3V0aW5nIGFuZCBPcHMsIFNlY3VyaXR5IGlzIG5vdCBvbiB0 aGVpciBtaW5kLCBldmVuIHdpdGggVGhpbmtpbmcgTXVsdGlwbGUgdGltZXMuDQoNCkl0IHdpbGwg YmUgbW9yZSBoZWxwZnVsIHRvIGNvbXBvc2UgYSBsaXN0IG9mIFNlY3VyaXR5IENoZWNrIExpc3Qu IERyYWZ0IGF1dGhvcnMgY2FuIGdvIHRocm91Z2ggdGhlIGxpc3QgdG8gYmUgcmVtaW5kZWQgb2Yg cG90ZW50aWFsIHNlY3VyaXR5IHJpc2tzIGludHJvZHVjZWQgYnkgdGhlIGRyYWZ0IHByb3Bvc2Vk IG1lY2hhbmlzbXMuDQoNCkxpbmRhDQoNCkZyb206IHNlY2RpciA8c2VjZGlyLWJvdW5jZXNAaWV0 Zi5vcmc+IE9uIEJlaGFsZiBPZiBWaW5jZW50IFJvY2ENClNlbnQ6IFRodXJzZGF5LCBKdW5lIDI3 LCAyMDE5IDc6NTAgQU0NClRvOiBTYWx6LCBSaWNoIDxyc2FsekBha2FtYWkuY29tPjsgWW9hdiBO aXIgPHluaXIuaWV0ZkBnbWFpbC5jb20+DQpDYzogc2VjZGlyIDxzZWNkaXJAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogW3NlY2Rpcl0gV3JpdGluZyBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KDQpI ZWxsbywNCg0KVGhlIHR3byBtZXNzYWdlcyBJIHdvdWxkIHN1Z2dlc3Q6DQogICAgICAgICAgICAg ICAtIFlvdSwgYXV0aG9ycywgdGhpbmsgZXZlcnl0aGluZyBpcyBmaW5lLCB0aGF0IHlvdXIgcHJv cG9zYWwgZG9lcyBub3QgaW50cm9kdWNlIGFueSBuZXcgdGhyZWF0LiBUaGluayBpdCB0d2ljZSAo b3IgbW9yZSksDQogICAgICAgICAgICAgICAgICB0aGVyZeKAmXMgcHJvYmFibHkgc29tZXRoaW5n IHRoYXTigJlzIHdvcnRoIGJlaW5nIHNhaWQ7DQogICAgICAgICAgICAgICAtIEFuZCB0aGUgU2Vj dXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBpcyBhbHNvIG1lYW50IHRvIGhlbHAgZGV2ZWxv cGVyczogaW4gdGhpcyBzcGVjaWZpYyBjYXNlLCBpdCB3b3VsZCBoYXZlDQogICAgICAgICAgICAg ICAgIGJlZW4gbmljZSB0byBhZGQgYSB3YXJuaW5nIGFib3V0IHRoaXMgY2FyYm9uIGNvcHkgaW4g dGhlIHJlcGx5IHBhY2tldCwgYXMgd2UgYWxsIGRpc2NvdmVyZWQgbGF0ZXIuDQoNCkkgdGhpbmsg aXTigJlzIGEgZ29vZCBleGFtcGxlIG9mIGNvb2wgcHJvdG9jb2wgZmVhdHVyZSB0aGF0IGNhbiB0 dXJuIGludG8gYSBzZWN1cml0eSBuaWdodG1hcmUgaWYgd3JvbmdseSBpbXBsZW1lbnRlZC4NCkl0 4oCZcyB3b3J0aCBleHBsYWluaW5nIElNSE8uDQoNCkJ1dCB0aGF04oCZcyBqdXN0IGFuIGlkZWEs IGZlZWwgZnJlZSB0byBpZ25vcmUgbXkgc3VnZ2VzdGlvbi4NCkNoZWVycywNCg0KICBWaW5jZW50 DQoNCg0KTGUgMjcganVpbiAyMDE5IMOgIDE0OjE1LCBTYWx6LCBSaWNoIDxyc2FsekBha2FtYWku Y29tPG1haWx0bzpyc2FsekBha2FtYWkuY29tPj4gYSDDqWNyaXQgOg0KDQpXZWxsIHRoZXJl4oCZ cyBhbHNvIHRoZSBmYWN0IHRoYXQgaXQgd2FzIGltcGxlbWVudGVkIGluIFRMUyBidXQgb25seSBp bnRlbmRlZCBmb3IgRFRMUy4NCg0KQnV0IHllYWgsIEnigJltIHN0aWxsIG5vdCBzdXJlIHdoYXQg dGhlIGxlc3NvbiBsZWFybmVkIGlzLg0KDQpGcm9tOiBZb2F2IE5pciA8eW5pci5pZXRmQGdtYWls LmNvbTxtYWlsdG86eW5pci5pZXRmQGdtYWlsLmNvbT4+DQpEYXRlOiBUaHVyc2RheSwgSnVuZSAy NywgMjAxOSBhdCAxMjozMyBBTQ0KVG86IFZpbmNlbnQgUm9jYSA8dmluY2VudC5yb2NhQGlucmlh LmZyPG1haWx0bzp2aW5jZW50LnJvY2FAaW5yaWEuZnI+Pg0KQ2M6ICJzZWNkaXJAaWV0Zi5vcmc8 bWFpbHRvOnNlY2RpckBpZXRmLm9yZz4iIDxzZWNkaXJAaWV0Zi5vcmc8bWFpbHRvOnNlY2RpckBp ZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTogW3NlY2Rpcl0gV3JpdGluZyBTZWN1cml0eSBDb25zaWRl cmF0aW9ucw0KDQpIaSwgVmluY2VudC4NCg0KVGhhbmtzLCBidXQgSSBkb27igJl0IGtub3cgd2hh dCBraW5kIG9mIGxlc3NvbiB0aGVyZSBpcyBpbiB0aGlzIGZvciB0aGUgZ2VuZXJhbCBSRkMtd3Jp dGluZyBhdWRpZW5jZS4NCg0KQWx3YXlzIGNhbGwgb3V0IHdoZW4geW91IGhhdmUgaW50ZXJuYWwg bGVuZ3RoIGZpZWxkcyBiZWNhdXNlIHRoYXQgY2FuIGJlIGRvbmUgZGFuZ2Vyb3VzbHkgaW4gQz8N Cg0KSSB0aGluayBtaXMtaGFuZGxpbmcgbGVuZ3RoIGZpZWxkcyBoYXMgYmVlbiBhbiBpc3N1ZSB3 aXRoIHByb3RvY29scyBhcyBsb25nIGFzIHByb3RvY29scyBoYXZlIGJlZW4gaW1wbGVtZW50ZWQu DQoNCllvYXYNCg0KDQoNCk9uIDI2IEp1biAyMDE5LCBhdCA5OjU3LCBWaW5jZW50IFJvY2EgPHZp bmNlbnQucm9jYUBpbnJpYS5mcjxtYWlsdG86dmluY2VudC5yb2NhQGlucmlhLmZyPj4gd3JvdGU6 DQoNCkhlbGxvIFlvYXYgYW5kIExpbmRhLA0KDQpHb29kIGluaXRpYXRpdmUuDQoNClNpbmNlIHlv deKAmXJlIGxvb2tpbmcgZm9yIHN0b3JpZXMsIGhlcmUgaXMgYSBwcm9wb3NhbCwgcm9vdGVkIGlu IHJlYWwgbGlmZS4NClJGQzY1MjAgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM2NTIw PGh0dHBzOi8vbmFtMDMuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRw cyUzQSUyRiUyRnVybGRlZmVuc2UucHJvb2Zwb2ludC5jb20lMkZ2MiUyRnVybCUzRnUlM0RodHRw cy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM2NTIwJTI2ZCUzRER3TUZhUSUyNmMlM0Q5Nlpi WlpjYU1GNHcwRjRqcE42TFpnJTI2ciUzRDRMTTBHYlIwaDlGdng4NkZ0c0tJLXclMjZtJTNEMzJI NUthZXJlY0ZGZkhMX1JiSzZfUzNMNWJ3VUU5Szg4X2w2OVJZcnZJUSUyNnMlM0RGYkR6cUVURlgw ODBzOG5uVlhIVVJ6NjRvNWNickhBR2RLa254eE1Wc0JBJTI2ZSUzRCZkYXRhPTAyJTdDMDElN0Ns aW5kYS5kdW5iYXIlNDBmdXR1cmV3ZWkuY29tJTdDYmUxNjA3ZTM4ODdkNDQxMThkOTcwOGQ2ZmFm ZTEwODIlN0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNhMWQ1NTkxZmVkYyU3QzElN0MwJTdDNjM2OTcy MzY2NDYxMjcwNzQ2JnNkYXRhPSUyQmU4ZFFBaWlNaFg4YXEySkJuJTJCUExDQUsxcGklMkZmZVNu eUlCQURUMEtNbkklM0QmcmVzZXJ2ZWQ9MD4pIG9uIFRMUyBoZWFydGJlYXQgZXh0ZW5zaW9uIGhh cyBhIHByZXR0eSBzaW1wbGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbjogaXQgc2F5 cw0KaXQgZG9lcyBub3QgaW50cm9kdWNlIGFueSBuZXcgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBh bmQgaXQgcmVmZXJzIHRvIHR3byBleGlzdGluZyBSRkNzLg0KDQpXZSBhbGwga25vdyB0aGlzIFRM UyBoZWFydGJlYXQgZXh0ZW5zaW9uIGhhcyBiZWVuIHRoZSBjYXVzZSBvZiB0aGUgZmFtb3VzIGhl YXJ0YmxlZWQgT3BlblNTTCB2dWxuZXJhYmlsaXR5IGFuZCBhc3NvY2lhdGVkIGF0dGFjay4NCk9m IGNvdXJzZSB0aGUgbWFqb3IgcHJvYmxlbSBjb21lcyBmcm9tIGFuIGVycm9uZW91cyBpbXBsZW1l bnRhdGlvbiBvZiB0aGUgbWVjaGFuaXNtIGluIE9wZW5TU0w6DQpodHRwczovL2dpdC5vcGVuc3Ns Lm9yZy9naXR3ZWIvP3A9b3BlbnNzbC5naXQ7YT1jb21taXRkaWZmO2g9OTZkYjkwMjNiODgxZDdj ZDlmMzc5YjBjMTU0NjUwZDZjMTA4ZTlhMzxodHRwczovL25hbTAzLnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLnByb29mcG9pbnQu Y29tJTJGdjIlMkZ1cmwlM0Z1JTNEaHR0cHMtM0FfX2dpdC5vcGVuc3NsLi5vcmdfZ2l0d2ViXy0z RnAtM0RvcGVuc3NsLmdpdC0zQmEtM0Rjb21taXRkaWZmLTNCaC0zRDk2ZGI5MDIzYjg4MWQ3Y2Q5 ZjM3OWIwYzE1NDY1MGQ2YzEwOGU5YTMlMjZkJTNERHdNRmFRJTI2YyUzRDk2WmJaWmNhTUY0dzBG NGpwTjZMWmclMjZyJTNENExNMEdiUjBoOUZ2eDg2RnRzS0ktdyUyNm0lM0QzMkg1S2FlcmVjRkZm SExfUmJLNl9TM0w1YndVRTlLODhfbDY5UllydklRJTI2cyUzRDlGWlR3b09hdUg0N2tfbmdGTWpR enVNUFJiMGpJV2NzOTZZMGF4ZE05Z1klMjZlJTNEJmRhdGE9MDIlN0MwMSU3Q2xpbmRhLmR1bmJh ciU0MGZ1dHVyZXdlaS5jb20lN0NiZTE2MDdlMzg4N2Q0NDExOGQ5NzA4ZDZmYWZlMTA4MiU3QzBm ZWU4ZmYyYTNiMjQwMTg5Yzc1M2ExZDU1OTFmZWRjJTdDMSU3QzAlN0M2MzY5NzIzNjY0NjEyODA3 NDAmc2RhdGE9enlzd1lwRkRUa3RwS1dmN0Y2bWs4Z1NRam9PVHBHclExTlVxMjBvakElMkZVJTNE JnJlc2VydmVkPTA+DQoNClRoZSBnb2FsIGlzIG5vdCB0byBibGFtZSBhbnlib2R5IGluIHBlcnNv biwgZXNwZWNpYWxseSBhcyB0aGUgUkZDIGRlc2NyaWJlcyB3aGF0IHNob3VsZCBiZSBkb25lIHRv IHByZXZlbnQgYW55IHByb2JsZW0uDQpCdXQgSSBhbHNvIHRoaW5rIHRoaXMgaXMgYSBkb2N1bWVu dCB3aGVyZSB3ZSBhbGwgKGkuZS4sIGF1dGhvcnMvc2VjZGlyL0lFU0cpIHNob3VsZCBoYXZlIGhp Z2hsaWdodGVkIHRoZSBhc3NvY2lhdGVkIHJpc2sgb2YgYmFkbHkNCmltcGxlbWVudGluZyB0aGUg cmVzcG9uc2UgbWVzc2FnZSBpbiB0aGUgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbi4g QXMgYWx3YXlzIGluIHN1Y2ggYSBzaXR1YXRpb24sIGl04oCZcyBlYXNpZXIgdG8gc2F5IGFmdGVy d2FyZHMhDQoNCkkgdGhpbmsgdGhlcmUgaXMgYSB3YXkgdG8gc2F5IHRoYXQgaW4gYSBwb3NpdGl2 ZSB3YXkgKGxlc3NvbnMgbGVhcm5lZCkgYW5kIHRlbGwgYW4gaW50ZXJlc3Rpbmcgc3RvcnkgbWFu eSBwZW9wbGUgaGVhcmQgYWJvdXQgd2l0aG91dCBrbm93aW5nDQp0aGUgZGV0YWlscy4NCg0KQ2hl ZXJzLA0KDQogIFZpbmNlbnQNCg0KDQpMZSAyNSBqdWluIDIwMTkgw6AgMjA6NTcsIFlvYXYgTmly IDx5bmlyLmlldGZAZ21haWwuY29tPG1haWx0bzp5bmlyLmlldGZAZ21haWwuY29tPj4gYSDDqWNy aXQgOg0KDQpIaSwgYWxsDQoNCklmIHlvdeKAmXZlIGhhZCBhIGxvb2sgYXQgdGhlIGRyYWZ0IGFn ZW5kYSAoaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwNS9hZ2VuZGEuaHRt bDxodHRwczovL25hbTAzLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0 cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLnByb29mcG9pbnQuY29tJTJGdjIlMkZ1cmwlM0Z1JTNEaHR0 cHMtM0FfX2RhdGF0cmFja2VyLi5pZXRmLm9yZ19tZWV0aW5nXzEwNV9hZ2VuZGEuaHRtbCUyNmQl M0REd01GYVElMjZjJTNEOTZaYlpaY2FNRjR3MEY0anBONkxaZyUyNnIlM0Q0TE0wR2JSMGg5RnZ4 ODZGdHNLSS13JTI2bSUzRDMySDVLYWVyZWNGRmZITF9SYks2X1MzTDVid1VFOUs4OF9sNjlSWXJ2 SVElMjZzJTNEM1VJN1dRbXdmeXo3aDFidWlWWk9ZOGc3RDZLOEFSTFNIWEFybl9QWVVCYyUyNmUl M0QmZGF0YT0wMiU3QzAxJTdDbGluZGEuZHVuYmFyJTQwZnV0dXJld2VpLmNvbSU3Q2JlMTYwN2Uz ODg3ZDQ0MTE4ZDk3MDhkNmZhZmUxMDgyJTdDMGZlZThmZjJhM2IyNDAxODljNzUzYTFkNTU5MWZl ZGMlN0MxJTdDMCU3QzYzNjk3MjM2NjQ2MTI5MDczNSZzZGF0YT1SRHdjTUludDdZeCUyRkh5TnVn OGF5WVBCa1liNyUyRk1YUHkzaGNHWE9yODhpbyUzRCZyZXNlcnZlZD0wPiksIHdlIGhhdmUgYSBX cml0aW5nIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHR1dG9yaWFsIG9uIFN1bmRheSwgd2hpY2gg TGluZGEgRHVuYmFyIGFuZCBJIHdpbGwgYmUgZG9pbmcuDQoNClRoZSBpZGVhIGlzIHRvIGdldCBw ZW9wbGUgd3JpdGluZyBkcmFmdHMgdG8ga25vdyB3aGF0IHRoZXkgc2hvdWxkIGRvIGZvciBhIHNt b290aCBpbnRlcmFjdGlvbiB3aXRoIHVzIFNlY0RpciBwZW9wbGUuDQoNClRoZSBzbGlkZXMgZG8g bm90IGV4aXN0IHlldCwgYnV0IHdlIGhhdmUgYSByb3VnaCBvdXRsaW5lIG9uIGdpdGh1YjogaHR0 cHM6Ly9naXRodWIuY29tL0lFVEYtU0FBRy9TZWN1cml0eUNvbnNpZGVyYXRpb25zVHV0b3JpYWw8 aHR0cHM6Ly9uYW0wMy5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBz JTNBJTJGJTJGdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbSUyRnYyJTJGdXJsJTNGdSUzRGh0dHBz LTNBX19naXRodWIuY29tX0lFVEYtMkRTQUFHX1NlY3VyaXR5Q29uc2lkZXJhdGlvbnNUdXRvcmlh bCUyNmQlM0REd01GYVElMjZjJTNEOTZaYlpaY2FNRjR3MEY0anBONkxaZyUyNnIlM0Q0TE0wR2JS MGg5RnZ4ODZGdHNLSS13JTI2bSUzRDMySDVLYWVyZWNGRmZITF9SYks2X1MzTDVid1VFOUs4OF9s NjlSWXJ2SVElMjZzJTNEa01ZeXE5VHo1Ulp5cXBhQmpFUHdTV1lMdzdQNmpHOWVxaWdmRGVXMWxO ayUyNmUlM0QmZGF0YT0wMiU3QzAxJTdDbGluZGEuZHVuYmFyJTQwZnV0dXJld2VpLmNvbSU3Q2Jl MTYwN2UzODg3ZDQ0MTE4ZDk3MDhkNmZhZmUxMDgyJTdDMGZlZThmZjJhM2IyNDAxODljNzUzYTFk NTU5MWZlZGMlN0MxJTdDMCU3QzYzNjk3MjM2NjQ2MTI5MDczNSZzZGF0YT1BN0E0OG1JUEdSUTl5 MkViamZVdyUyQm4lMkJ2QTB4bDhvd3lUQThDZk1jbDBwcyUzRCZyZXNlcnZlZD0wPg0KDQpTbyBp ZiB0aGVyZeKAmXMgbWlzc2luZyBvciB3cm9uZyBzdHVmZiwgd2XigJlkIGxpa2UgdG8gaGVhciBh Ym91dCBpdCwgcHJlZmVyYWJseSBpbiB0aGUgZm9ybSBvZiBQUnMuDQoNCkJ1dCBtb3N0IG9mIGFs bCwgd2XigJlyZSBsb29raW5nIGZvciBtb3JlIGV4YW1wbGVzIGluIHRoZSBleGFtcGxlcyBwYWdl OiBodHRwczovL2dpdGh1Yi5jb20vSUVURi1TQUFHL1NlY3VyaXR5Q29uc2lkZXJhdGlvbnNUdXRv cmlhbC9ibG9iL21hc3Rlci9leGFtcGxlcy5tZDxodHRwczovL25hbTAzLnNhZmVsaW5rcy5wcm90 ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLnByb29mcG9p bnQuY29tJTJGdjIlMkZ1cmwlM0Z1JTNEaHR0cHMtM0FfX2dpdGh1Yi5jb21fSUVURi0yRFNBQUdf U2VjdXJpdHlDb25zaWRlcmF0aW9uc1R1dG9yaWFsX2Jsb2JfbWFzdGVyX2V4YW1wbGVzLm1kJTI2 ZCUzRER3TUZhUSUyNmMlM0Q5NlpiWlpjYU1GNHcwRjRqcE42TFpnJTI2ciUzRDRMTTBHYlIwaDlG dng4NkZ0c0tJLXclMjZtJTNEMzJINUthZXJlY0ZGZkhMX1JiSzZfUzNMNWJ3VUU5Szg4X2w2OVJZ cnZJUSUyNnMlM0RmMUg2YnJVLTEzbFl1MV9yVG1wWHY1ZkdVNWRjMjU4bDFVWHVhSXJPWDNZJTI2 ZSUzRCZkYXRhPTAyJTdDMDElN0NsaW5kYS5kdW5iYXIlNDBmdXR1cmV3ZWkuY29tJTdDYmUxNjA3 ZTM4ODdkNDQxMThkOTcwOGQ2ZmFmZTEwODIlN0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNhMWQ1NTkx ZmVkYyU3QzElN0MwJTdDNjM2OTcyMzY2NDYxMzAwNzI3JnNkYXRhPWhUNTElMkJnZHR6bjVCSDBj OWdiQkRieGVrZDJ1QkJ5YWU4WURYZnMzcWVoNCUzRCZyZXNlcnZlZD0wPg0KDQpTbyBhbnkgaG9y cm9yIHN0b3J5LCB3YXIgc3RvcnksIHN0dWZmIHRoYXTigJlzIHRlcnJpYmx5IHdyb25nLCBvciBl dmVuIHNvbWV0aGluZyB0aGF04oCZcyBzdXJwcmlzaW5nbHkgcmlnaHQgd2lsbCBiZSB3ZWxjb21l Lg0KDQpUaGFua3MgaW4gYWR2YW5jZQ0KDQpMaW5kYSAmIFlvYXYNCg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNlY2RpciBtYWlsaW5nIGxpc3QNCnNl Y2RpckBpZXRmLm9yZzxtYWlsdG86c2VjZGlyQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zZWNkaXI8aHR0cHM6Ly9uYW0wMy5zYWZlbGlua3MucHJvdGVj dGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbSUyRnYyJTJGdXJsJTNGdSUzRGh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0 aW5mb19zZWNkaXIlMjZkJTNERHdNRmFRJTI2YyUzRDk2WmJaWmNhTUY0dzBGNGpwTjZMWmclMjZy JTNENExNMEdiUjBoOUZ2eDg2RnRzS0ktdyUyNm0lM0QzMkg1S2FlcmVjRkZmSExfUmJLNl9TM0w1 YndVRTlLODhfbDY5UllydklRJTI2cyUzRDZiNlNSUGYtdmtrUHZqLUZyWC1xOHJ3UkhFMVJDRjU0 cE9IVkZRQWtrUlElMjZlJTNEJmRhdGE9MDIlN0MwMSU3Q2xpbmRhLmR1bmJhciU0MGZ1dHVyZXdl aS5jb20lN0NiZTE2MDdlMzg4N2Q0NDExOGQ5NzA4ZDZmYWZlMTA4MiU3QzBmZWU4ZmYyYTNiMjQw MTg5Yzc1M2ExZDU1OTFmZWRjJTdDMSU3QzAlN0M2MzY5NzIzNjY0NjEzMDA3Mjcmc2RhdGE9RVlV cjVTQmdORGxRT1VGOUFJN3QyTHdTSmxjWEZzemxvZzJpQ3RDS05GdyUzRCZyZXNlcnZlZD0wPg0K d2lraTogaHR0cDovL3Rvb2xzLmlldGYub3JnL2FyZWEvc2VjL3RyYWMvd2lraS9TZWNEaXJSZXZp ZXc8aHR0cHM6Ly9uYW0wMy5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0 dHAlM0ElMkYlMkZ0b29scy5pZXRmLm9yZyUyRmFyZWElMkZzZWMlMkZ0cmFjJTJGd2lraSUyRlNl Y0RpclJldmlldyZkYXRhPTAyJTdDMDElN0NsaW5kYS5kdW5iYXIlNDBmdXR1cmV3ZWkuY29tJTdD YmUxNjA3ZTM4ODdkNDQxMThkOTcwOGQ2ZmFmZTEwODIlN0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNh MWQ1NTkxZmVkYyU3QzElN0MwJTdDNjM2OTcyMzY2NDYxMzEwNzIzJnNkYXRhPXAwV2VMZllpMjNi U0Q2c3NsTkZvQVl5aXplYlkwcnVld1AxJTJCZENGeUlwYyUzRCZyZXNlcnZlZD0wPg0KDQo= --_000_MN2PR13MB35824C91911136E2E1DD1D4B85FD0MN2PR13MB3582namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJcQFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBE ZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0K CXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29I eXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1k ZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93 ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25v cm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDph dXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5hcHBsZS10YWItc3Bhbg0KCXttc28tc3R5bGUtbmFtZTph cHBsZS10YWItc3Bhbjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUt bmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBzZWUgbWFueSBkcmFmdHMgZnJv bSBSb3V0aW5nIEFyZWEgYW5kIE9wcyBBcmVhcyBoYXZlIHRoZSBzaW1pbGFyIHdyaXRpbmcgb24g U2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgYXMgUkZDNjUyMC4NCjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Rm9yIG1hbnkgcGVvcGxlIGluIFJvdXRpbmcgYW5kIE9wcywgU2Vj dXJpdHkgaXMgbm90IG9uIHRoZWlyIG1pbmQsIGV2ZW4gd2l0aCBUaGlua2luZyBNdWx0aXBsZSB0 aW1lcy4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCB3aWxsIGJlIG1vcmUgaGVscGZ1bCB0 byBjb21wb3NlIGEgbGlzdCBvZiBTZWN1cml0eSBDaGVjayBMaXN0LiBEcmFmdCBhdXRob3JzIGNh biBnbyB0aHJvdWdoIHRoZSBsaXN0IHRvIGJlIHJlbWluZGVkIG9mIHBvdGVudGlhbCBzZWN1cml0 eSByaXNrcyBpbnRyb2R1Y2VkIGJ5IHRoZSBkcmFmdCBwcm9wb3NlZCBtZWNoYW5pc21zLg0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxpbmRhIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IHNlY2RpciAmbHQ7c2Vj ZGlyLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxiPk9uIEJlaGFsZiBPZg0KPC9iPlZpbmNlbnQgUm9j YTxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVuZSAyNywgMjAxOSA3OjUwIEFNPGJyPg0K PGI+VG86PC9iPiBTYWx6LCBSaWNoICZsdDtyc2FsekBha2FtYWkuY29tJmd0OzsgWW9hdiBOaXIg Jmx0O3luaXIuaWV0ZkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBzZWNkaXIgJmx0O3Nl Y2RpckBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzZWNkaXJdIFdyaXRp bmcgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkhlbGxvLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhlIHR3byBtZXNzYWdlcyBJIHdvdWxkIHN1Z2dlc3Q6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFi LXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+LSBZb3UsIGF1dGhvcnMs IHRoaW5rIGV2ZXJ5dGhpbmcgaXMgZmluZSwgdGhhdCB5b3VyIHByb3Bvc2FsIGRvZXMgbm90IGlu dHJvZHVjZSBhbnkgbmV3IHRocmVhdC4gVGhpbmsgaXQgdHdpY2UgKG9yIG1vcmUpLCZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g Y2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFu PiZuYnNwOyAmbmJzcDt0aGVyZeKAmXMgcHJvYmFibHkgc29tZXRoaW5nIHRoYXTigJlzIHdvcnRo IGJlaW5nIHNhaWQ7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA8L3NwYW4+LSBBbmQgdGhlIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24g aXMgYWxzbyBtZWFudCB0byBoZWxwIGRldmVsb3BlcnM6IGluIHRoaXMgc3BlY2lmaWMgY2FzZSwg aXQgd291bGQgaGF2ZSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgPC9zcGFuPiZuYnNwOyZuYnNwO2JlZW4gbmljZSB0byBhZGQgYSB3YXJu aW5nIGFib3V0IHRoaXMgY2FyYm9uIGNvcHkgaW4gdGhlIHJlcGx5IHBhY2tldCwgYXMgd2UgYWxs IGRpc2NvdmVyZWQgbGF0ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgaXTigJlzIGEgZ29vZCBleGFtcGxlIG9mIGNvb2wgcHJv dG9jb2wgZmVhdHVyZSB0aGF0IGNhbiB0dXJuIGludG8gYSBzZWN1cml0eSBuaWdodG1hcmUgaWYg d3JvbmdseSBpbXBsZW1lbnRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkl04oCZcyB3b3J0aCBleHBsYWluaW5nIElNSE8uPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCB0aGF04oCZcyBq dXN0IGFuIGlkZWEsIGZlZWwgZnJlZSB0byBpZ25vcmUgbXkgc3VnZ2VzdGlvbi48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IFZp bmNlbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxlIDI3IGp1aW4gMjAxOSDDoCAxNDoxNSwgU2Fs eiwgUmljaCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJzYWx6QGFrYW1haS5jb20iPnJzYWx6QGFrYW1h aS5jb208L2E+Jmd0OyBhIMOpY3JpdCA6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5XZWxsIHRoZXJl4oCZcyBhbHNvIHRoZSBmYWN0IHRoYXQgaXQgd2FzIGlt cGxlbWVudGVkIGluIFRMUyBidXQgb25seSBpbnRlbmRlZCBmb3IgRFRMUy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IHllYWgsIEnigJlt IHN0aWxsIG5vdCBzdXJlIHdoYXQgdGhlIGxlc3NvbiBsZWFybmVkIGlzLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1 QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+RnJvbTo8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+WW9hdiBOaXIgJmx0OzxhIGhyZWY9Im1haWx0bzp5 bmlyLmlldGZAZ21haWwuY29tIj55bmlyLmlldGZAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8Yj5E YXRlOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+ VGh1cnNkYXksIEp1bmUgMjcsIDIwMTkgYXQgMTI6MzMgQU08YnI+DQo8Yj5Ubzo8c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPlZpbmNlbnQgUm9jYSAm bHQ7PGEgaHJlZj0ibWFpbHRvOnZpbmNlbnQucm9jYUBpbnJpYS5mciI+dmluY2VudC5yb2NhQGlu cmlhLmZyPC9hPiZndDs8YnI+DQo8Yj5DYzo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PC9iPiZxdW90OzxhIGhyZWY9Im1haWx0bzpzZWNkaXJAaWV0Zi5v cmciPnNlY2RpckBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzZWNkaXJA aWV0Zi5vcmciPnNlY2RpckBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9iPlJlOiBbc2VjZGly XSBXcml0aW5nIFNlY3VyaXR5IENvbnNpZGVyYXRpb25zPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkhpLCBWaW5jZW50LjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcywgYnV0IEkgZG9u4oCZdCBrbm93IHdo YXQga2luZCBvZiBsZXNzb24gdGhlcmUgaXMgaW4gdGhpcyBmb3IgdGhlIGdlbmVyYWwgUkZDLXdy aXRpbmcgYXVkaWVuY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsd2F5cyBjYWxsIG91 dCB3aGVuIHlvdSBoYXZlIGludGVybmFsIGxlbmd0aCBmaWVsZHMgYmVjYXVzZSB0aGF0IGNhbiBi ZSBkb25lIGRhbmdlcm91c2x5IGluIEM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhp bmsgbWlzLWhhbmRsaW5nIGxlbmd0aCBmaWVsZHMgaGFzIGJlZW4gYW4gaXNzdWUgd2l0aCBwcm90 b2NvbHMgYXMgbG9uZyBhcyBwcm90b2NvbHMgaGF2ZSBiZWVuIGltcGxlbWVudGVkLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb2F2PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyNiBK dW4gMjAxOSwgYXQgOTo1NywgVmluY2VudCBSb2NhICZsdDs8YSBocmVmPSJtYWlsdG86dmluY2Vu dC5yb2NhQGlucmlhLmZyIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj52aW5jZW50LnJvY2FA aW5yaWEuZnI8L3NwYW4+PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyBZ b2F2IGFuZCBMaW5kYSw8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Hb29kIGluaXRpYXRpdmUuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlNpbmNlIHlvdeKAmXJlIGxvb2tpbmcgZm9yIHN0b3JpZXMsIGhlcmUgaXMg YSBwcm9wb3NhbCwgcm9vdGVkIGluIHJlYWwgbGlmZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJGQzY1MjAgKDxhIGhy ZWY9Imh0dHBzOi8vbmFtMDMuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1o dHRwcyUzQSUyRiUyRnVybGRlZmVuc2UucHJvb2Zwb2ludC5jb20lMkZ2MiUyRnVybCUzRnUlM0Ro dHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9yZmM2NTIwJTI2ZCUzRER3TUZhUSUyNmMlM0Q5 NlpiWlpjYU1GNHcwRjRqcE42TFpnJTI2ciUzRDRMTTBHYlIwaDlGdng4NkZ0c0tJLXclMjZtJTNE MzJINUthZXJlY0ZGZkhMX1JiSzZfUzNMNWJ3VUU5Szg4X2w2OVJZcnZJUSUyNnMlM0RGYkR6cUVU RlgwODBzOG5uVlhIVVJ6NjRvNWNickhBR2RLa254eE1Wc0JBJTI2ZSUzRCZhbXA7ZGF0YT0wMiU3 QzAxJTdDbGluZGEuZHVuYmFyJTQwZnV0dXJld2VpLmNvbSU3Q2JlMTYwN2UzODg3ZDQ0MTE4ZDk3 MDhkNmZhZmUxMDgyJTdDMGZlZThmZjJhM2IyNDAxODljNzUzYTFkNTU5MWZlZGMlN0MxJTdDMCU3 QzYzNjk3MjM2NjQ2MTI3MDc0NiZhbXA7c2RhdGE9JTJCZThkUUFpaU1oWDhhcTJKQm4lMkJQTENB SzFwaSUyRmZlU255SUJBRFQwS01uSSUzRCZhbXA7cmVzZXJ2ZWQ9MCI+PHNwYW4gc3R5bGU9ImNv bG9yOnB1cnBsZSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY1MjA8L3NwYW4+PC9h PikNCiBvbiBUTFMgaGVhcnRiZWF0IGV4dGVuc2lvbiBoYXMgYSBwcmV0dHkgc2ltcGxlIHNlY3Vy aXR5IGNvbnNpZGVyYXRpb25zIHNlY3Rpb246IGl0IHNheXMmbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPml0IGRv ZXMgbm90IGludHJvZHVjZSBhbnkgbmV3IHNlY3VyaXR5IGNvbnNpZGVyYXRpb24gYW5kIGl0IHJl ZmVycyB0byB0d28gZXhpc3RpbmcgUkZDcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2Ug YWxsIGtub3cgdGhpcyBUTFMgaGVhcnRiZWF0IGV4dGVuc2lvbiBoYXMgYmVlbiB0aGUgY2F1c2Ug b2YgdGhlIGZhbW91cyBoZWFydGJsZWVkIE9wZW5TU0wgdnVsbmVyYWJpbGl0eSBhbmQgYXNzb2Np YXRlZCBhdHRhY2suPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PZiBjb3Vyc2UgdGhlIG1ham9yIHByb2JsZW0gY29tZXMg ZnJvbSBhbiBlcnJvbmVvdXMgaW1wbGVtZW50YXRpb24gb2YgdGhlIG1lY2hhbmlzbSBpbiBPcGVu U1NMOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0cHM6Ly9uYW0wMy5zYWZlbGlua3MucHJvdGVjdGlv bi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv bSUyRnYyJTJGdXJsJTNGdSUzRGh0dHBzLTNBX19naXQub3BlbnNzbC4ub3JnX2dpdHdlYl8tM0Zw LTNEb3BlbnNzbC5naXQtM0JhLTNEY29tbWl0ZGlmZi0zQmgtM0Q5NmRiOTAyM2I4ODFkN2NkOWYz NzliMGMxNTQ2NTBkNmMxMDhlOWEzJTI2ZCUzRER3TUZhUSUyNmMlM0Q5NlpiWlpjYU1GNHcwRjRq cE42TFpnJTI2ciUzRDRMTTBHYlIwaDlGdng4NkZ0c0tJLXclMjZtJTNEMzJINUthZXJlY0ZGZkhM X1JiSzZfUzNMNWJ3VUU5Szg4X2w2OVJZcnZJUSUyNnMlM0Q5RlpUd29PYXVINDdrX25nRk1qUXp1 TVBSYjBqSVdjczk2WTBheGRNOWdZJTI2ZSUzRCZhbXA7ZGF0YT0wMiU3QzAxJTdDbGluZGEuZHVu YmFyJTQwZnV0dXJld2VpLmNvbSU3Q2JlMTYwN2UzODg3ZDQ0MTE4ZDk3MDhkNmZhZmUxMDgyJTdD MGZlZThmZjJhM2IyNDAxODljNzUzYTFkNTU5MWZlZGMlN0MxJTdDMCU3QzYzNjk3MjM2NjQ2MTI4 MDc0MCZhbXA7c2RhdGE9enlzd1lwRkRUa3RwS1dmN0Y2bWs4Z1NRam9PVHBHclExTlVxMjBvakEl MkZVJTNEJmFtcDtyZXNlcnZlZD0wIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5odHRwczov L2dpdC5vcGVuc3NsLm9yZy9naXR3ZWIvP3A9b3BlbnNzbC5naXQ7YT1jb21taXRkaWZmO2g9OTZk YjkwMjNiODgxZDdjZDlmMzc5YjBjMTU0NjUwZDZjMTA4ZTlhMzwvc3Bhbj48L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBnb2FsIGlzIG5vdCB0byBibGFtZSBhbnlib2R5IGluIHBl cnNvbiwgZXNwZWNpYWxseSBhcyB0aGUgUkZDIGRlc2NyaWJlcyB3aGF0IHNob3VsZCBiZSBkb25l IHRvIHByZXZlbnQgYW55IHByb2JsZW0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0IEkgYWxzbyB0aGlu ayB0aGlzIGlzIGEgZG9jdW1lbnQgd2hlcmUgd2UgYWxsIChpLmUuLCBhdXRob3JzL3NlY2Rpci9J RVNHKSBzaG91bGQgaGF2ZSBoaWdobGlnaHRlZCB0aGUgYXNzb2NpYXRlZCByaXNrIG9mIGJhZGx5 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5pbXBsZW1lbnRpbmcgdGhlIHJlc3BvbnNlIG1lc3NhZ2UgaW4gdGhlIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zIHNlY3Rpb24uIEFzIGFsd2F5cyBpbiBzdWNoIGEgc2l0dWF0aW9u LCBpdOKAmXMgZWFzaWVyIHRvIHNheSBhZnRlcndhcmRzITxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIHRoaW5rIHRoZXJlIGlzIGEgd2F5IHRvIHNheSB0aGF0IGluIGEgcG9zaXRpdmUgd2F5 IChsZXNzb25zIGxlYXJuZWQpIGFuZCB0ZWxsIGFuIGludGVyZXN0aW5nIHN0b3J5IG1hbnkgcGVv cGxlIGhlYXJkIGFib3V0IHdpdGhvdXQga25vd2luZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhlIGRldGFpbHMuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsgVmluY2VudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxlIDI1IGp1aW4gMjAxOSDDoCAyMDo1NywgWW9hdiBOaXIg Jmx0OzxhIGhyZWY9Im1haWx0bzp5bmlyLmlldGZAZ21haWwuY29tIj48c3BhbiBzdHlsZT0iY29s b3I6cHVycGxlIj55bmlyLmlldGZAZ21haWwuY29tPC9zcGFuPjwvYT4mZ3Q7IGEgw6ljcml0IDo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkhpLCBhbGw8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB5b3XigJl2ZSBoYWQgYSBs b29rIGF0IHRoZSBkcmFmdCBhZ2VuZGEgKDxhIGhyZWY9Imh0dHBzOi8vbmFtMDMuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UucHJv b2Zwb2ludC5jb20lMkZ2MiUyRnVybCUzRnUlM0RodHRwcy0zQV9fZGF0YXRyYWNrZXIuLmlldGYu b3JnX21lZXRpbmdfMTA1X2FnZW5kYS5odG1sJTI2ZCUzRER3TUZhUSUyNmMlM0Q5NlpiWlpjYU1G NHcwRjRqcE42TFpnJTI2ciUzRDRMTTBHYlIwaDlGdng4NkZ0c0tJLXclMjZtJTNEMzJINUthZXJl Y0ZGZkhMX1JiSzZfUzNMNWJ3VUU5Szg4X2w2OVJZcnZJUSUyNnMlM0QzVUk3V1Ftd2Z5ejdoMWJ1 aVZaT1k4ZzdENks4QVJMU0hYQXJuX1BZVUJjJTI2ZSUzRCZhbXA7ZGF0YT0wMiU3QzAxJTdDbGlu ZGEuZHVuYmFyJTQwZnV0dXJld2VpLmNvbSU3Q2JlMTYwN2UzODg3ZDQ0MTE4ZDk3MDhkNmZhZmUx MDgyJTdDMGZlZThmZjJhM2IyNDAxODljNzUzYTFkNTU5MWZlZGMlN0MxJTdDMCU3QzYzNjk3MjM2 NjQ2MTI5MDczNSZhbXA7c2RhdGE9UkR3Y01JbnQ3WXglMkZIeU51ZzhheVlQQmtZYjclMkZNWFB5 M2hjR1hPcjg4aW8lM0QmYW1wO3Jlc2VydmVkPTAiPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUi Pmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy8xMDUvYWdlbmRhLmh0bWw8L3Nw YW4+PC9hPiksDQogd2UgaGF2ZSBhIFdyaXRpbmcgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMgdHV0 b3JpYWwgb24gU3VuZGF5LCB3aGljaCBMaW5kYSBEdW5iYXIgYW5kIEkgd2lsbCBiZSBkb2luZy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGlkZWEgaXMgdG8gZ2V0IHBlb3BsZSB3cml0 aW5nIGRyYWZ0cyB0byBrbm93IHdoYXQgdGhleSBzaG91bGQgZG8gZm9yIGEgc21vb3RoIGludGVy YWN0aW9uIHdpdGggdXMgU2VjRGlyIHBlb3BsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ VGhlIHNsaWRlcyBkbyBub3QgZXhpc3QgeWV0LCBidXQgd2UgaGF2ZSBhIHJvdWdoIG91dGxpbmUg b24gZ2l0aHViOiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vbmFtMDMuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UucHJvb2Zwb2ludC5j b20lMkZ2MiUyRnVybCUzRnUlM0RodHRwcy0zQV9fZ2l0aHViLmNvbV9JRVRGLTJEU0FBR19TZWN1 cml0eUNvbnNpZGVyYXRpb25zVHV0b3JpYWwlMjZkJTNERHdNRmFRJTI2YyUzRDk2WmJaWmNhTUY0 dzBGNGpwTjZMWmclMjZyJTNENExNMEdiUjBoOUZ2eDg2RnRzS0ktdyUyNm0lM0QzMkg1S2FlcmVj RkZmSExfUmJLNl9TM0w1YndVRTlLODhfbDY5UllydklRJTI2cyUzRGtNWXlxOVR6NVJaeXFwYUJq RVB3U1dZTHc3UDZqRzllcWlnZkRlVzFsTmslMjZlJTNEJmFtcDtkYXRhPTAyJTdDMDElN0NsaW5k YS5kdW5iYXIlNDBmdXR1cmV3ZWkuY29tJTdDYmUxNjA3ZTM4ODdkNDQxMThkOTcwOGQ2ZmFmZTEw ODIlN0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNhMWQ1NTkxZmVkYyU3QzElN0MwJTdDNjM2OTcyMzY2 NDYxMjkwNzM1JmFtcDtzZGF0YT1BN0E0OG1JUEdSUTl5MkViamZVdyUyQm4lMkJ2QTB4bDhvd3lU QThDZk1jbDBwcyUzRCZhbXA7cmVzZXJ2ZWQ9MCI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+ aHR0cHM6Ly9naXRodWIuY29tL0lFVEYtU0FBRy9TZWN1cml0eUNvbnNpZGVyYXRpb25zVHV0b3Jp YWw8L3NwYW4+PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBpZiB0aGVyZeKAmXMg bWlzc2luZyBvciB3cm9uZyBzdHVmZiwgd2XigJlkIGxpa2UgdG8gaGVhciBhYm91dCBpdCwgcHJl ZmVyYWJseSBpbiB0aGUgZm9ybSBvZiBQUnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1 dCBtb3N0IG9mIGFsbCwgd2XigJlyZSBsb29raW5nIGZvciBtb3JlIGV4YW1wbGVzIGluIHRoZSBl eGFtcGxlcyBwYWdlOiZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vbmFtMDMuc2FmZWxpbmtzLnByb3Rl Y3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20lMkZ2MiUyRnVybCUzRnUlM0RodHRwcy0zQV9fZ2l0aHViLmNvbV9JRVRGLTJEU0FBR19T ZWN1cml0eUNvbnNpZGVyYXRpb25zVHV0b3JpYWxfYmxvYl9tYXN0ZXJfZXhhbXBsZXMubWQlMjZk JTNERHdNRmFRJTI2YyUzRDk2WmJaWmNhTUY0dzBGNGpwTjZMWmclMjZyJTNENExNMEdiUjBoOUZ2 eDg2RnRzS0ktdyUyNm0lM0QzMkg1S2FlcmVjRkZmSExfUmJLNl9TM0w1YndVRTlLODhfbDY5Ully dklRJTI2cyUzRGYxSDZiclUtMTNsWXUxX3JUbXBYdjVmR1U1ZGMyNThsMVVYdWFJck9YM1klMjZl JTNEJmFtcDtkYXRhPTAyJTdDMDElN0NsaW5kYS5kdW5iYXIlNDBmdXR1cmV3ZWkuY29tJTdDYmUx NjA3ZTM4ODdkNDQxMThkOTcwOGQ2ZmFmZTEwODIlN0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNhMWQ1 NTkxZmVkYyU3QzElN0MwJTdDNjM2OTcyMzY2NDYxMzAwNzI3JmFtcDtzZGF0YT1oVDUxJTJCZ2R0 em41QkgwYzlnYkJEYnhla2QydUJCeWFlOFlEWGZzM3FlaDQlM0QmYW1wO3Jlc2VydmVkPTAiPjxz cGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPmh0dHBzOi8vZ2l0aHViLmNvbS9JRVRGLVNBQUcvU2Vj dXJpdHlDb25zaWRlcmF0aW9uc1R1dG9yaWFsL2Jsb2IvbWFzdGVyL2V4YW1wbGVzLm1kPC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28gYW55IGhvcnJvciBzdG9yeSwgd2Fy IHN0b3J5LCBzdHVmZiB0aGF04oCZcyB0ZXJyaWJseSB3cm9uZywgb3IgZXZlbiBzb21ldGhpbmcg dGhhdOKAmXMgc3VycHJpc2luZ2x5IHJpZ2h0IHdpbGwgYmUgd2VsY29tZS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhhbmtzIGluIGFkdmFuY2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+TGluZGEgJmFtcDsgWW9hdjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzZWNkaXIgbWFpbGlu ZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNlY2RpckBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9 ImNvbG9yOnB1cnBsZSI+c2VjZGlyQGlldGYub3JnPC9zcGFuPjwvYT48YnI+DQo8YSBocmVmPSJo dHRwczovL25hbTAzLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZ1cmxkZWZlbnNlLnByb29mcG9pbnQuY29tJTJGdjIlMkZ1cmwlM0Z1JTNEaHR0cHMt M0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3NlY2RpciUyNmQlM0REd01GYVElMjZj JTNEOTZaYlpaY2FNRjR3MEY0anBONkxaZyUyNnIlM0Q0TE0wR2JSMGg5RnZ4ODZGdHNLSS13JTI2 bSUzRDMySDVLYWVyZWNGRmZITF9SYks2X1MzTDVid1VFOUs4OF9sNjlSWXJ2SVElMjZzJTNENmI2 U1JQZi12a2tQdmotRnJYLXE4cndSSEUxUkNGNTRwT0hWRlFBa2tSUSUyNmUlM0QmYW1wO2RhdGE9 MDIlN0MwMSU3Q2xpbmRhLmR1bmJhciU0MGZ1dHVyZXdlaS5jb20lN0NiZTE2MDdlMzg4N2Q0NDEx OGQ5NzA4ZDZmYWZlMTA4MiU3QzBmZWU4ZmYyYTNiMjQwMTg5Yzc1M2ExZDU1OTFmZWRjJTdDMSU3 QzAlN0M2MzY5NzIzNjY0NjEzMDA3MjcmYW1wO3NkYXRhPUVZVXI1U0JnTkRsUU9VRjlBSTd0Mkx3 U0psY1hGc3psb2cyaUN0Q0tORnclM0QmYW1wO3Jlc2VydmVkPTAiPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2VjZGlyPC9z cGFuPjwvYT48YnI+DQp3aWtpOiA8YSBocmVmPSJodHRwczovL25hbTAzLnNhZmVsaW5rcy5wcm90 ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cCUzQSUyRiUyRnRvb2xzLmlldGYub3JnJTJGYXJl YSUyRnNlYyUyRnRyYWMlMkZ3aWtpJTJGU2VjRGlyUmV2aWV3JmFtcDtkYXRhPTAyJTdDMDElN0Ns aW5kYS5kdW5iYXIlNDBmdXR1cmV3ZWkuY29tJTdDYmUxNjA3ZTM4ODdkNDQxMThkOTcwOGQ2ZmFm ZTEwODIlN0MwZmVlOGZmMmEzYjI0MDE4OWM3NTNhMWQ1NTkxZmVkYyU3QzElN0MwJTdDNjM2OTcy MzY2NDYxMzEwNzIzJmFtcDtzZGF0YT1wMFdlTGZZaTIzYlNENnNzbE5Gb0FZeWl6ZWJZMHJ1ZXdQ MSUyQmRDRnlJcGMlM0QmYW1wO3Jlc2VydmVkPTAiPg0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2Fy ZWEvc2VjL3RyYWMvd2lraS9TZWNEaXJSZXZpZXc8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_MN2PR13MB35824C91911136E2E1DD1D4B85FD0MN2PR13MB3582namp_-- From nobody Thu Jun 27 09:48:50 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761EB120118 for ; Thu, 27 Jun 2019 09:48:49 -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, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 3_6OaV0erXXI for ; Thu, 27 Jun 2019 09:48:46 -0700 (PDT) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C41CC120112 for ; Thu, 27 Jun 2019 09:48:45 -0700 (PDT) Received: by mail-wm1-x331.google.com with SMTP id u8so6346257wmm.1 for ; Thu, 27 Jun 2019 09:48:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=xJdy54Y1zgYJu3OReBycJTk4q9w0OlP21aN65nY/6PQ=; b=EEu3xCbpj6YzfM3uWDsrUvwMEP8N8Qeto5LMVIutQRDRzZTqyvi04Owls7awH/Ga9l k6+RsaEXCXju5CfYtX4Vo85n18gungWdmEwaQpHGbZyDB6vhX5DqcbdLbTlet4TurA2M SsM2utRZvBOR4sighT75kmV15hO3qGwpL3gId0Yt1NGt8Nj1e8faw4oiAcjYEiZX5Qn7 qDXRWu618c9mDH1mdLaKg07Tua5kxvCgqSQCQp7KQa5mxijD1y3foVwVVcy/b8zpM9fE 86awHDWM1I7yRG+3ZHoJeycPfawyyjJ68F80fxRG9sXyA3AWdKVAevJ5VJi1UN+bVxPO 9RUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=xJdy54Y1zgYJu3OReBycJTk4q9w0OlP21aN65nY/6PQ=; b=OEjp31gL3jvQUhYchdtqMrf6OB7yHK1WbMPXM8qIjm0Vrp80EUIn1CGYYPyII2PcMC XrFHTSKfN8ZkkUixfOd8YDgTEOPp59jbU4acs1WhSjKHJUck2kIk3GZIukhgS0bpaoqy Vyxlo5ZtuEgiLrJeZ+RWqZCGvsJaL2wBqP35QGvJyteg0p5wtifCHfIbqP9/HkaVIYVQ pkZ/o41fgA9GRGApB/lWvFGgyG7QB+KYKq4JyAZ/ueZ9RjnO2bIfVVQNRgYcRm+ZGRVw zGWLaARNNoeDTkstLeZsALn/mrzVgbskJrXOXqCzSgYunT3XCuZNPeXz4GS7dz/AvVFt orbw== X-Gm-Message-State: APjAAAVgMDp4oXVopqLzcreDQF/+BPnfabSaksB+wifY7DcIpvQL1ush 2tRY+uBubmfoQdXvhH9bPUI= X-Google-Smtp-Source: APXvYqyCmf46exFVsVvog1Ipn23O7cl4erJD2tGymSExe7x24KIyzisuSAXOkanT2B2fxVGRJBYaHQ== X-Received: by 2002:a1c:1fc2:: with SMTP id f185mr4041728wmf.154.1561654124228; Thu, 27 Jun 2019 09:48:44 -0700 (PDT) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id z5sm3917188wrh.16.2019.06.27.09.48.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Jun 2019 09:48:43 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_A3F9E08E-EA65-4A74-9581-348F74FA1835" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Thu, 27 Jun 2019 19:48:41 +0300 In-Reply-To: <5C18F02D-BACE-4251-99D9-AA8D0AEA7F37@inria.fr> Cc: Rich Salz , secdir To: Vincent Roca References: <421EA63E-CD5F-4BCC-AA24-3BDBD7182B24@inria.fr> <558A448D-E5EE-4E3C-9B0A-F5B5490E793C@gmail.com> <7D1A00B2-3A6F-4B54-AE8F-9BB7771E6189@akamai.com> <5C18F02D-BACE-4251-99D9-AA8D0AEA7F37@inria.fr> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [secdir] Writing Security Considerations X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2019 16:48:50 -0000 --Apple-Mail=_A3F9E08E-EA65-4A74-9581-348F74FA1835 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 27 Jun 2019, at 15:50, Vincent Roca wrote: >=20 > Hello, >=20 > The two messages I would suggest: > - You, authors, think everything is fine, that your proposal = does not introduce any new threat. Think it twice (or more),=20 > there=E2=80=99s probably something that=E2=80=99s worth being = said; That just reads like =E2=80=9CBe afraid. Be very afraid=E2=80=9D. Yeah, = we=E2=80=99re going to tell them to consider all security implications = and implementation pitfalls. But without a concrete list of things to = check, that=E2=80=99s just like Hill Street Blues=E2=80=99 =E2=80=9CLet=E2= =80=99s be careful out there" > - And the Security Considerations section is also meant to help = developers: in this specific case, it would have=20 > been nice to add a warning about this carbon copy in the reply = packet, as we all discovered later. Perhaps the broader lesson is to consider and call out whenever you are = using a non-standard format. If a protocol is using JSON, CBOR, XML, = YANG, or even ASN.1 you are going to be using some (hopefully) = well-tested library that protects you from buffer overruns. When you = roll your own format, like we do in things like TLS and IKE, the = implementer is going to be writing a parser, and writing a parser is = something that requires a level of care that should be called out. >=20 > I think it=E2=80=99s a good example of cool protocol feature that can = turn into a security nightmare if wrongly implemented. > It=E2=80=99s worth explaining IMHO. >=20 > But that=E2=80=99s just an idea, feel free to ignore my suggestion. If you can suggest text for the slide/s, we=E2=80=99ll consider it. > Cheers, >=20 > Vincent >=20 >=20 >> Le 27 juin 2019 =C3=A0 14:15, Salz, Rich > a =C3=A9crit : >>=20 >> Well there=E2=80=99s also the fact that it was implemented in TLS but = only intended for DTLS. >> =20 >> But yeah, I=E2=80=99m still not sure what the lesson learned is. >> =20 >> From: Yoav Nir > >> Date: Thursday, June 27, 2019 at 12:33 AM >> To: Vincent Roca > >> Cc: "secdir@ietf.org " > >> Subject: Re: [secdir] Writing Security Considerations >> =20 >> Hi, Vincent.=20 >> =20 >> Thanks, but I don=E2=80=99t know what kind of lesson there is in this = for the general RFC-writing audience. >> =20 >> Always call out when you have internal length fields because that can = be done dangerously in C? >> =20 >> I think mis-handling length fields has been an issue with protocols = as long as protocols have been implemented. >> =20 >> Yoav >>=20 >>=20 >>> On 26 Jun 2019, at 9:57, Vincent Roca > wrote: >>> =20 >>> Hello Yoav and Linda,=20 >>> =20 >>> Good initiative. >>> =20 >>> Since you=E2=80=99re looking for stories, here is a proposal, rooted = in real life. >>> RFC6520 (https://tools.ietf.org/html/rfc6520 = ) on TLS heartbeat extension has a pretty = simple security considerations section: it says=20 >>> it does not introduce any new security consideration and it refers = to two existing RFCs. >>> =20 >>> We all know this TLS heartbeat extension has been the cause of the = famous heartbleed OpenSSL vulnerability and associated attack. >>> Of course the major problem comes from an erroneous implementation = of the mechanism in OpenSSL: >>> = https://git.openssl.org/gitweb/?p=3Dopenssl.git;a=3Dcommitdiff;h=3D96db902= 3b881d7cd9f379b0c154650d6c108e9a3 = >>> =20 >>> The goal is not to blame anybody in person, especially as the RFC = describes what should be done to prevent any problem. >>> But I also think this is a document where we all (i.e., = authors/secdir/IESG) should have highlighted the associated risk of = badly >>> implementing the response message in the Security Considerations = section. As always in such a situation, it=E2=80=99s easier to say = afterwards! >>> =20 >>> I think there is a way to say that in a positive way (lessons = learned) and tell an interesting story many people heard about without = knowing >>> the details. >>> =20 >>> Cheers, >>> =20 >>> Vincent >>> =20 >>> =20 >>>> Le 25 juin 2019 =C3=A0 20:57, Yoav Nir > a =C3=A9crit : >>>> =20 >>>> Hi, all=20 >>>> =20 >>>> If you=E2=80=99ve had a look at the draft agenda = (https://datatracker.ietf.org/meeting/105/agenda.html = ), we have a Writing = Security Considerations tutorial on Sunday, which Linda Dunbar and I = will be doing. >>>> =20 >>>> The idea is to get people writing drafts to know what they should = do for a smooth interaction with us SecDir people. >>>> =20 >>>> The slides do not exist yet, but we have a rough outline on github: = https://github.com/IETF-SAAG/SecurityConsiderationsTutorial = >>>> =20 >>>> So if there=E2=80=99s missing or wrong stuff, we=E2=80=99d like to = hear about it, preferably in the form of PRs. >>>> =20 >>>> But most of all, we=E2=80=99re looking for more examples in the = examples page: = https://github.com/IETF-SAAG/SecurityConsiderationsTutorial/blob/master/ex= amples.md = >>>> =20 >>>> So any horror story, war story, stuff that=E2=80=99s terribly = wrong, or even something that=E2=80=99s surprisingly right will be = welcome. >>>> =20 >>>> Thanks in advance >>>> =20 >>>> Linda & Yoav >>>> =20 >>>> _______________________________________________ >>>> secdir mailing list >>>> secdir@ietf.org >>>> https://www.ietf.org/mailman/listinfo/secdir = >>>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview = --Apple-Mail=_A3F9E08E-EA65-4A74-9581-348F74FA1835 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 27 Jun 2019, at 15:50, Vincent Roca <vincent.roca@inria.fr> wrote:

Hello,

The two messages I would = suggest:
- You, authors, think everything = is fine, that your proposal does not introduce any new threat. Think it = twice (or more), 
   there=E2=80=99s = probably something that=E2=80=99s worth being = said;

That = just reads like =E2=80=9CBe afraid. Be very afraid=E2=80=9D. Yeah, = we=E2=80=99re going to tell them to consider all security implications = and implementation pitfalls. But without a concrete list of things to = check, that=E2=80=99s just like Hill Street Blues=E2=80=99 =E2=80=9CLet=E2= =80=99s be careful out there"

- And the Security Considerations = section is also meant to help developers: in this specific case, it = would have 
  been nice to add a = warning about this carbon copy in the reply packet, as we all discovered = later.

Perhaps the broader lesson is to consider and call = out whenever you are using a non-standard format. If a protocol is using = JSON, CBOR, XML, YANG, or even ASN.1 you are going to be using some = (hopefully) well-tested library that protects you from buffer overruns. = When you roll your own format, like we do in things like TLS and IKE, = the implementer is going to be writing a parser, and writing a parser is = something that requires a level of care that should be called = out.


I think it=E2=80=99s a good example of = cool protocol feature that can turn into a security nightmare if wrongly = implemented.
It=E2=80=99s worth explaining = IMHO.

But = that=E2=80=99s just an idea, feel free to ignore my = suggestion.

If you can suggest text for the slide/s, we=E2=80=99= ll consider it.

Cheers,

  Vincent


Le 27 = juin 2019 =C3=A0 14:15, Salz, Rich <rsalz@akamai.com> a =C3=A9crit :

Well = there=E2=80=99s also the fact that it was implemented in TLS but only = intended for DTLS.
 
But yeah, I=E2=80=99m still not sure what the lesson learned = is.
 
From: Yoav Nir <ynir.ietf@gmail.com>
Date: Thursday, June 27, 2019 = at 12:33 AM
To: Vincent Roca <vincent.roca@inria.fr>
Cc: "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] Writing = Security Considerations
 
Hi, Vincent. 
 
Thanks, but I don=E2=80=99t know what = kind of lesson there is in this for the general RFC-writing = audience.
 
Always call out when you have internal length fields because = that can be done dangerously in C?
 
I think mis-handling length fields has been an issue with = protocols as long as protocols have been implemented.
 
Yoav


On 26 Jun 2019, at 9:57, Vincent Roca = <vincent.roca@inria.fr> = wrote:
 
Hello Yoav and Linda, 
 
Good initiative.
 
Since you=E2=80=99re looking for = stories, here is a proposal, rooted in real life.
RFC6520 (https://tools.ietf.org/html/rfc6520) on TLS heartbeat = extension has a pretty simple security considerations section: it = says 
it does not introduce any new security = consideration and it refers to two existing RFCs.
 
We all know this TLS heartbeat = extension has been the cause of the famous heartbleed OpenSSL = vulnerability and associated attack.
Of course the major = problem comes from an erroneous implementation of the mechanism in = OpenSSL:
 
The goal is not to blame anybody in = person, especially as the RFC describes what should be done to prevent = any problem.
But I also think this is a = document where we all (i.e., authors/secdir/IESG) should have = highlighted the associated risk of badly
implementing the response message in the Security = Considerations section. As always in such a situation, it=E2=80=99s = easier to say afterwards!
 
I think there is a way to say that in a positive way (lessons = learned) and tell an interesting story many people heard about without = knowing
the details.
 
Cheers,
 
  Vincent
 
 
Le 25 = juin 2019 =C3=A0 20:57, Yoav Nir <ynir.ietf@gmail.com> a = =C3=A9crit :
 
Hi, all 
 
If you=E2=80=99ve had a look at the = draft agenda (https://datatracker.ietf.org/meeting/105/agenda.html), we = have a Writing Security Considerations tutorial on Sunday, which Linda = Dunbar and I will be doing.
 
The idea is to get people writing drafts to know what they = should do for a smooth interaction with us SecDir people.
 
The slides do not exist yet, but we = have a rough outline on github: https://github.com/IETF-SAAG/SecurityConsiderationsTutorial=
 
So if there=E2=80=99s missing or wrong = stuff, we=E2=80=99d like to hear about it, preferably in the form of = PRs.
 
But most of all, we=E2=80=99re looking for more examples in = the examples page: https://github.com/IETF-SAAG/SecurityConsiderationsTutorial/blo= b/master/examples.md
 
So any horror story, war story, stuff that=E2=80=99s terribly = wrong, or even something that=E2=80=99s surprisingly right will be = welcome.
 
Thanks in advance
 
Linda & Yoav
 
=
=


= --Apple-Mail=_A3F9E08E-EA65-4A74-9581-348F74FA1835-- From nobody Thu Jun 27 17:26:58 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372C6120169 for ; Thu, 27 Jun 2019 17:26:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 I603pr8LKU3v for ; Thu, 27 Jun 2019 17:26:55 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 7E0CA120122 for ; Thu, 27 Jun 2019 17:26:55 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x5S0Qjxv024683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 27 Jun 2019 20:26:48 -0400 Date: Thu, 27 Jun 2019 19:26:45 -0500 From: Benjamin Kaduk To: Linda Dunbar Cc: Vincent Roca , "Salz, Rich" , Yoav Nir , secdir Message-ID: <20190628002644.GR18345@kduck.mit.edu> References: <421EA63E-CD5F-4BCC-AA24-3BDBD7182B24@inria.fr> <558A448D-E5EE-4E3C-9B0A-F5B5490E793C@gmail.com> <7D1A00B2-3A6F-4B54-AE8F-9BB7771E6189@akamai.com> <5C18F02D-BACE-4251-99D9-AA8D0AEA7F37@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [secdir] Writing Security Considerations X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 00:26:57 -0000 On Thu, Jun 27, 2019 at 04:47:20PM +0000, Linda Dunbar wrote: > I see many drafts from Routing Area and Ops Areas have the similar writing on Security Considerations as RFC6520. > For many people in Routing and Ops, Security is not on their mind, even with Thinking Multiple times. > > It will be more helpful to compose a list of Security Check List. Draft authors can go through the list to be reminded of potential security risks introduced by the draft proposed mechanisms. This thread is rather apropos, as one of the items the IESG is working on is assembling some "hot topic" items from each area that regularly recur as issues arising at IESG evaluation or IETF LC. The idea would be that ADs, and perhaps WG chairs as well, would have some better visibility into what other Areas' review will look for, and avoid "late surprises" for document authors that were not thinking about any given topic. Roman and I just earlier today assembled a first cut at such "hot topics" for the security area: https://trac.ietf.org/trac/sec/wiki/TypicalSECAreaIssues . It's not exactly a checklist, but could probably be turned into one without too much work. Please take a look and make/suggest improvements -- it's a wiki, after all! -Ben From nobody Fri Jun 28 04:00:10 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54981120179; Fri, 28 Jun 2019 04:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 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_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Y2utBbP4; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=HIlSzWTs 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 ARtH4ymYFc_r; Fri, 28 Jun 2019 04:00:05 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8776312014A; Fri, 28 Jun 2019 04:00:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2822; q=dns/txt; s=iport; t=1561719604; x=1562929204; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=KoJCIeqsJ7Qg6eWPC2eamSxsIRX26LOJlr4E64NFwS4=; b=Y2utBbP48W4lr1pxlaoPB6vrOh5/lHikjqSlNxxmjKl078+CrHUVyhSZ YpIYqOAMNtNSbcUgRBCi4vDY0h3ooum0qGDTOS/AWn/kuvLzumc2GoHVO Bwn+5hmDh09maOWbpPphs0xGId8uB4wqXzuEq6MXYSVrXWrzmcvjYtzxM E=; IronPort-PHdr: =?us-ascii?q?9a23=3ARhGWcBQU5LQFLuPWCwOwHt5XYNpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjQmHNlIWUV513q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AnAADj8hVd/4oNJK1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBVgIBAQEBCwGBQ1ADgT8gBAsoh2MDjlyCW5dEglIDVAkBAQE?= =?us-ascii?q?MAQEtAgEBgUuCdQKDACM3Bg4BAwEBBAEBAgEFbYo3DIVKAQEBBBIuAQE3AQs?= =?us-ascii?q?EAgEIEQEDAQEBLjIXBggCBA4FCBEFBIRrAx0BApwdAoE4iGCCI4J5AQEFhQ8?= =?us-ascii?q?YghEJgTQBhHGGbReBQD+BV4FOfj6ERoM6giaOMJt9CQKCFpQTgiuHGI4ejSm?= =?us-ascii?q?XIwIEAgQFAg4BAQWBZiKBWHAVgyeCQQkDF4NOilNygSmMNiuCJQEB?= X-IronPort-AV: E=Sophos;i="5.63,427,1557187200"; d="scan'208";a="572248186" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Jun 2019 10:59:33 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x5SAxXb9006752 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 28 Jun 2019 10:59:33 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 28 Jun 2019 05:59:33 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 28 Jun 2019 06:59:32 -0400 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 28 Jun 2019 05:59:32 -0500 ARC-Seal: i=1; a=rsa-sha256; s=testarcselector01; d=microsoft.com; cv=none; b=Rl7PQV+hHCtEQgWLwiXeVNhJWJ4p2K4Z+g+5BajUiD1JAXxnfA2LwYDWLN8AfwuAy90a2uPIIrG6+dDNdhn4q6Wh/TSlRJGpWhOyKrKw9y6mf79RAqjOxVsqzUkdPVM/xloYRVw6GRB67MZ3H1VR6BBWFskiuNneotTRvI3OWrs= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=testarcselector01; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1MCQzkEZ95o5ptn+RcFQCTSb+eZ1yw8yEBlUcyq80Xg=; b=UKEcWRq6VJf4dNK0vlLVp4uGpt3R9cBr55sCnDY6DU+hY12x7qkTa1Y3c0djiQS2/7NxlxBdGNlUmDmcs9d4hclhsp7FDgmnCYTtH2NMct4yGMoSgr22de58Htvs0LvIdI7qGJUceVWE+VAAvPSp3gXoDH/owNmyxNlLg0bazBU= ARC-Authentication-Results: i=1; test.office365.com 1;spf=none;dmarc=none;dkim=none;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=1MCQzkEZ95o5ptn+RcFQCTSb+eZ1yw8yEBlUcyq80Xg=; b=HIlSzWTsr1aAhn9Y658njaqfBcSidtOzfn03fNCo8z6JjbFD8T0tRQc+hekVTJ7OIJT5796ma9tepYypbeXswzLz9Q2u9/BkjqV1gUPnOBQThdGba42SuuXk34o+RVEiYgbIqpeb8Nr2InK5RWSBAoMxR3xq7OHqutTt5eUD330= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3933.namprd11.prod.outlook.com (10.255.180.211) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.16; Fri, 28 Jun 2019 10:59:31 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2008.018; Fri, 28 Jun 2019 10:59:31 +0000 From: "Pascal Thubert (pthubert)" To: David Mandelberg CC: Tero Kivinen , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-6tisch-architecture.all@ietf.org" , Thomas Watteyne , =?iso-8859-2?Q?Mali=B9a_Vu=E8ini=E6?= , Michael Richardson Thread-Topic: [secdir] secdir review of draft-ietf-6tisch-architecture-21 Thread-Index: AQHVKitVZAMqDsUZHEuS/CYS/vDUhKaqVH6wgAEk6YCAAHyKMIAAjgwAgAFa8pCAADuNAIAC0WVQ Date: Fri, 28 Jun 2019 10:59:08 +0000 Deferred-Delivery: Fri, 28 Jun 2019 10:58:55 +0000 Message-ID: References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> <23825.24715.882644.180316@fireball.acr.fi> <28910.1561477164@localhost> <17322.1561564458@localhost> In-Reply-To: <17322.1561564458@localhost> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:c0c0:1005::2c6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 46c80c97-71a5-4034-f083-08d6fbb7b270 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3933; x-ms-traffictypediagnostic: MN2PR11MB3933: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 00826B6158 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(346002)(136003)(396003)(376002)(39860400002)(51444003)(13464003)(199004)(189003)(102836004)(71200400001)(6436002)(52536014)(8936002)(74316002)(256004)(186003)(446003)(305945005)(486006)(8676002)(229853002)(7736002)(14444005)(81166006)(476003)(53546011)(81156014)(53936002)(4326008)(9686003)(25786009)(6666004)(46003)(99286004)(6506007)(5660300002)(55016002)(11346002)(86362001)(76176011)(6246003)(2906002)(54906003)(7696005)(316002)(66476007)(33656002)(6116002)(71190400001)(73956011)(6916009)(66946007)(478600001)(64756008)(66446008)(66556008)(14454004)(76116006)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3933; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 5Ju9DTWK7/6uXk34dhASpIdlb+dx6aSMGP0/PMBaP4PSAXHaHgDQL3J33NtEmHTn9p34ankI97pGq5UTvDJpOr8S9arlYx8fDjmjTsJ6D1cc3yfVZxVbYxsXgQu1Bcf+b+hW792X/Ixxp6z5l0J0otag3t0ijezxbT1ZD3NK7ezCwPfghdCi+P0HwuN8atnI/VzaEp4w1a8r4uv+PLX2YZ1b4w6MOk8t+bAstaEd7u9vOlmqF+R6julXLhNUpv1aaDp5GreN3StBMCZQOB0a/gYVBctHmBXl/wYmqjBHx9MfpEUu62mGj2DIkIlgP9ekIrLXisYyB1b0VAfEcHK85Vq5x2dl4xvf8zpW0kRUWrsGzldFrYJ9rQazTjFTBL2RHQtu5RriPdlhCPVT+f98nLze95NlTEoVtjIxbU1ZNvw= Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 46c80c97-71a5-4034-f083-08d6fbb7b270 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2019 10:59:30.8897 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3933 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 11:00:08 -0000 Hello David Many thanks again. Your comments steered great discussions that led to impr= ovements in both this draft and minimal security. I posted -23 in the hope that it satisfies all your comments. Please let us= know is there is any additional issue we need to look at. =20 All the best, =20 Pascal > -----Original Message----- > From: Michael Richardson > Sent: mercredi 26 juin 2019 17:54 > To: Pascal Thubert (pthubert) > Cc: Tero Kivinen ; David Mandelberg > ; secdir@ietf.org; iesg@ietf.org; draft-ietf-6tisch= - > architecture.all@ietf.org; Thomas Watteyne ; > =3D?iso-8859-2?Q?Mali=3DB9a_Vu=3DE8ini=3DE6?=3D > Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21 >=20 >=20 > Pascal Thubert (pthubert) wrote: > >> Tero: > >> >> Note, that attacker might be able to replay valid ACKs for the = frame > >> >> sent by the JN, provided that the JRC (or whoever JN sent the m= essage > >> >> to) happened to ack message using the same ASN attacker faked f= or > JN. > >> > >> Pascal Thubert (pthubert) wrote: > >> > Your mean that the faked ASN is only slightly in the future, so = the > >> > attacker can repeat messages from the pledge after that delay? > >> > >> The faked ASN is always in the past. >=20 > > Do you mean the replayed ones? When the pledge does not have the ke= ys, > > the attacker can forge the beacon with any ASN, and place random by= tes > > in the MIC, can't it? >=20 > Yes, the replayed one has a "fake" ASN that is in the past. >=20 > > If the attacker fakes an ASN that is tomorrow and intercepts a join > > request, it could make the pledge seem to appear now on the network > > tomorrow even if the real pledge is long gone. >=20 > But that one won't validate. >=20 > >> So the L2-ACKs can be faked, was the point. >=20 > > I can see that an ACK can be replayed. But the ACK that was stored = in > > advance can only work if the attacked node speaks on the very ASN f= or > > which the attacker intercepted an ACK in the past. The attacker is = not > > in control of that and that makes its life harder. >=20 > When I said faked, I should have said replayed. >=20 > I think that we don't need to do this: just wait for a beacon. If the at= tacker can > block and replay them all, then they absolutely win, and the network can = not > form. Such an attacker probably can also put faraday cages around all th= e > nodes. >=20 > -- > Michael Richardson , Sandelman Software Works - > =3D IPv6 IoT consulting =3D- From nobody Fri Jun 28 11:54:37 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C16251201DB; Fri, 28 Jun 2019 11:54:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Robert Sparks via Datatracker To: Cc: draft-ietf-babel-hmac.all@ietf.org, ietf@ietf.org, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Robert Sparks Message-ID: <156174806170.21879.2999727589481093933@ietfa.amsl.com> Date: Fri, 28 Jun 2019 11:54:21 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-babel-hmac-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 18:54:22 -0000 Reviewer: Robert Sparks Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document is ready for publication as a Proposed Standard RFC, but has a nit that should be considered before publication. Nit: (This was part of my early review of -00) The claim in 1.1 about not requiring persistent storage is contradicted by the definition of the protocol. At the very least, there is the need to persist the most recent (index,PC) seen. From nobody Fri Jun 28 13:31:30 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A2CA212027B for ; Fri, 28 Jun 2019 13:31:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <156175388866.21789.15624776460718472313.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2019 13:31:28 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 20:31:29 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-07-11 Reviewer LC end Draft Christian Huitema R2019-06-17 draft-ietf-mpls-egress-protection-framework-06 Catherine Meadows 2019-06-25 draft-ietf-grow-bmp-adj-rib-out-06 Russ Mundy 2019-06-21 draft-ietf-iasa2-rfc7437bis-08 Christopher Wood 2019-05-28 draft-ietf-tram-turnbis-27 Last calls: Reviewer LC end Draft Nancy Cam-Winget 2019-06-04 draft-ietf-sipcore-rejected-08 Shaun Cooley 2019-03-13 draft-ietf-dots-data-channel-29 Roman Danyliw 2019-06-04 draft-ietf-rtgwg-enterprise-pa-multihoming-08 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Daniel Gillmor 2018-03-19 draft-gutmann-scep-14 Leif Johansson 2019-07-08 draft-ietf-manet-dlep-latency-extension-04 Scott Kelly 2019-07-04 draft-ietf-babel-applicability-06 Aanchal Malhotra 2019-06-26 draft-ietf-ipwave-ipv6-over-80211ocb-47 Catherine Meadows 2019-04-12 draft-ietf-mmusic-rfc4566bis-36 Daniel Migault 2019-07-03 draft-ietf-lamps-cms-shakes-11 Matthew Miller 2019-07-04 draft-ietf-intarea-frag-fragile-13 Matthew Miller 2019-04-08 draft-ietf-core-multipart-ct-03 Kathleen Moriarty 2019-07-11 draft-ietf-ospf-xaf-te-06 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Sandra Murphy 2019-07-08 draft-ietf-i2nsf-applicability-13 Yoav Nir 2019-07-08 draft-ietf-regext-epp-fees-16 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-08 Sean Turner R2019-07-04 draft-ietf-babel-dtls-05 David Waltermire 2019-02-15 draft-ietf-rtcweb-ip-handling-11 Klaas Wierenga 2019-02-26 draft-ietf-mpls-sr-over-ip-07 Taylor Yu 2019-02-15 draft-ietf-rtcweb-security-arch-18 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-12 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Kathleen Moriarty 2019-04-08 draft-ietf-bmwg-ngfw-performance-00 Next in the reviewer rotation: Magnus Nystrom Hilarie Orman Radia Perlman Derrell Piper Tim Polk Vincent Roca Kyle Rose Joseph Salowey Rich Salz Stefan Santesson From nobody Fri Jun 28 16:44:59 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FE9A120709; Fri, 28 Jun 2019 16:44:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Bmnvqk0ftS1p; Fri, 28 Jun 2019 16:44:40 -0700 (PDT) Received: from korolev.univ-paris7.fr (korolev.univ-paris7.fr [IPv6:2001:660:3301:8000::1:2]) (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 9D287120705; Fri, 28 Jun 2019 16:44:36 -0700 (PDT) Received: from mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [81.194.30.253]) by korolev.univ-paris7.fr (8.14.4/8.14.4/relay1/82085) with ESMTP id x5SNiWAO009110; Sat, 29 Jun 2019 01:44:32 +0200 Received: from mailhub.math.univ-paris-diderot.fr (localhost [127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTP id A1D5D4A4E3; Sat, 29 Jun 2019 01:44:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at math.univ-paris-diderot.fr Received: from mailhub.math.univ-paris-diderot.fr ([127.0.0.1]) by mailhub.math.univ-paris-diderot.fr (mailhub.math.univ-paris-diderot.fr [127.0.0.1]) (amavisd-new, port 10023) with ESMTP id O1ir-0GRb5SA; Sat, 29 Jun 2019 01:44:33 +0200 (CEST) Received: from pirx.irif.fr (unknown [78.194.40.74]) (Authenticated sender: jch) by mailhub.math.univ-paris-diderot.fr (Postfix) with ESMTPSA id 709134A4E0; Sat, 29 Jun 2019 01:44:33 +0200 (CEST) Date: Sat, 29 Jun 2019 01:44:33 +0200 Message-ID: <878stlz34u.wl-jch@irif.fr> From: Juliusz Chroboczek To: Robert Sparks Cc: , draft-ietf-babel-hmac.all@ietf.org, ietf@ietf.org, babel@ietf.org In-Reply-To: <156174806170.21879.2999727589481093933@ietfa.amsl.com> References: <156174806170.21879.2999727589481093933@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.7 (korolev.univ-paris7.fr [194.254.61.138]); Sat, 29 Jun 2019 01:44:32 +0200 (CEST) X-Miltered: at korolev with ID 5D16A660.000 by Joe's j-chkmail (http : // j-chkmail dot ensmp dot fr)! X-j-chkmail-Enveloppe: 5D16A660.000 from mailhub.math.univ-paris-diderot.fr/mailhub.math.univ-paris-diderot.fr/null/mailhub.math.univ-paris-diderot.fr/ X-j-chkmail-Score: MSGID : 5D16A660.000 on korolev.univ-paris7.fr : j-chkmail score : . : R=. U=. O=. B=0.000 -> S=0.000 X-j-chkmail-Status: Ham Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-babel-hmac-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 23:44:43 -0000 Dear Robert, > Nit: (This was part of my early review of -00) > The claim in 1.1 about not requiring persistent storage is contradicted by the > definition of the protocol. At the very least, there is the need to persist the > most recent (index,PC) seen. I most respectfully disagree. The whole point of the challenge/response mechanism is to avoid the need for persistent storage. If a node loses the information about a neighbour (e.g. because it has rebooted and lost the index/PC of the neighbour), it can simply send a new challenge to recover the state. Here is what is written in Section 2 (Conceptual overview): By itself, the PC mechanism is not sufficient to protect against replay. Consider a peer A that has no information about a peer B (e.g., because it has recently rebooted). Suppose that A receives a packet ostensibly from B carrying a given PC; since A has no information about B, it has no way to determine whether the packet is freshly generated or a replay of a previously sent packet. In this situation, A discards the packet and challenges B to prove that it knows the HMAC key. It sends a "challenge request", a TLV containing a unique nonce, a value that has never been used before and will never be used again. B replies to the challenge request with a "challenge reply", a TLV containing a copy of the nonce chosen by A, in a packet protected by HMAC and containing the new value of B's PC. Since the nonce has never been used before, B's reply proves B's knowledge of the HMAC key and the freshness of the PC. Should you disagree with the fact that this mechanism allows a node to recover the state that it has discarded, I request that you provide an example scenario in which this mechanism fails. -- Juliusz From nobody Sat Jun 29 08:26:10 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B99281200B6; Sat, 29 Jun 2019 08:26:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoav Nir via Datatracker To: Cc: ietf@ietf.org, draft-ietf-regext-epp-fees.all@ietf.org, regext@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Yoav Nir Message-ID: <156182196167.12901.11966487185176024571@ietfa.amsl.com> Date: Sat, 29 Jun 2019 08:26:01 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-regext-epp-fees-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2019 15:26:02 -0000 Reviewer: Yoav Nir Review result: Has Nits Hi I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The entire text of the Security Considerations section is as follows: The mapping extensions described in this document do not provide any security services beyond those described by EPP [RFC5730], the EPP domain name mapping [RFC5731], and protocol layers used by EPP. The security considerations described in these other specifications apply to this specification as well. This is what we like to call "security considerations by reference". I don't know what "security services" are in this context, but they are not the only thing that needs to be described in a Security Considerations section. In this case, the draft adds information about fees, customer credit and pay schedule. This falls under the category of financial information, which should be protected in transit by security mechanisms that protect confidentiality and integrity. It is also true that any transport mechanism that complies with RFC 5730 provides those functions. So what I'm missing here is a sentence that calls this out specifically. Something along the lines of "This extension adds financial information to the EPP protocol, so confidentiality and integrity protection must be provided by the transport mechanism. All transports compliant with RFC5730 provide that" From nobody Sat Jun 29 10:02:58 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80D0F1200A3; Sat, 29 Jun 2019 10:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 Q298DK3o93ct; Sat, 29 Jun 2019 10:02:41 -0700 (PDT) Received: from mail-io1-f42.google.com (mail-io1-f42.google.com [209.85.166.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC6001200C5; Sat, 29 Jun 2019 10:02:40 -0700 (PDT) Received: by mail-io1-f42.google.com with SMTP id e5so19330291iok.4; Sat, 29 Jun 2019 10:02:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jkvypC//U8i3ReQPy7QsLEega9HuWyfq/yutLuNvhoE=; b=od4Eb+LCg/tj9XiZfcr0OnTOPWZWQCkO88AmPnbN/S3M2bqga4JAAxtYNZOqfEPXND 5yNLN1RDgsMuDXa5FPoC2uDEwtsyR6m2RK5A4ijtSe+BLbGFi1FYH4K78g1Hdx8QicTH I1zBA2H2+gB6fedzXVDPIPLRbzeaUrMjdMw4RjuMkPaUssqrJsTBoSQrbwRypG+xbZZW C5w37hEAIayRKiZ6sPU6SJUXAXpZdpjsGRxiB+ruRgFN05PfvqhrSXgvK9h/KkKb6VAo 6CClfJUgs14RBTw5VeLmY8mCXVrKIQlyHtx6u+jMLc2jj3ajJO1KCi27M/DUBDhvLH6r OW7g== X-Gm-Message-State: APjAAAVaTcv/kLy6jjZL0WDRG4O6YslRNtOaC+sQTvXbuF2lTTfODSJh mq8l/DUe0RqvxMa668289YSJSm9bdWMyTxRiqYM= X-Google-Smtp-Source: APXvYqwISwZPIenA28C6DErWp/a/+THjlJreo1V0EvZWMkPRX/jCq5xL5OU+13BBxiCyNBPNO2ncH3nD4wu7WeVIK0k= X-Received: by 2002:a5d:9613:: with SMTP id w19mr9905646iol.140.1561827759852; Sat, 29 Jun 2019 10:02:39 -0700 (PDT) MIME-Version: 1.0 References: <156182196167.12901.11966487185176024571@ietfa.amsl.com> In-Reply-To: <156182196167.12901.11966487185176024571@ietfa.amsl.com> From: Barry Leiba Date: Sat, 29 Jun 2019 13:02:29 -0400 Message-ID: To: Yoav Nir Cc: draft-ietf-regext-epp-fees.all@ietf.org, ietf@ietf.org, regext@ietf.org, secdir@ietf.org Content-Type: multipart/alternative; boundary="000000000000d390cb058c795cc9" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-regext-epp-fees-16 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2019 17:02:43 -0000 --000000000000d390cb058c795cc9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, Yoav. I had warned the working group of that very issue, and I=E2= =80=99m sure they plan to address it as part of the last call comments. Thanks for raising the issue here as well. Barry On Sat, Jun 29, 2019 at 11:26 AM Yoav Nir via Datatracker wrote: > Reviewer: Yoav Nir > Review result: Has Nits > > Hi > > I have reviewed this document as part of the security directorate's ongoi= ng > effort to review all IETF documents being processed by the IESG. These > comments were written primarily for the benefit of the security area > directors. > Document editors and WG chairs should treat these comments just like any > other > last call comments. > > The entire text of the Security Considerations section is as follows: > > The mapping extensions described in this document do not provide any > security services beyond those described by EPP [RFC5730], the EPP > domain name mapping [RFC5731], and protocol layers used by EPP. The > security considerations described in these other specifications apply > to this specification as well. > > This is what we like to call "security considerations by reference". I > don't > know what "security services" are in this context, but they are not the > only > thing that needs to be described in a Security Considerations section. > > In this case, the draft adds information about fees, customer credit and > pay > schedule. This falls under the category of financial information, which > should > be protected in transit by security mechanisms that protect > confidentiality and > integrity. It is also true that any transport mechanism that complies wit= h > RFC > 5730 provides those functions. So what I'm missing here is a sentence tha= t > calls this out specifically. Something along the lines of "This extension > adds > financial information to the EPP protocol, so confidentiality and integri= ty > protection must be provided by the transport mechanism. All transports > compliant with RFC5730 provide that" > > --000000000000d390cb058c795cc9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks, Yoav.=C2=A0 I had warned the working group o= f that very issue, and I=E2=80=99m sure they plan to address it as part of = the last call comments.=C2=A0 Thanks for raising the issue here as well.

Barry

=
On Sat, Ju= n 29, 2019 at 11:26 AM Yoav Nir via Datatracker <noreply@ietf.org> wrote:
Reviewer: Yoav Nir
Review result: Has Nits

Hi

I have reviewed this document as part of the security directorate's ong= oing
effort to review all IETF documents being processed by the IESG.=C2=A0 Thes= e
comments were written primarily for the benefit of the security area direct= ors.
Document editors and WG chairs should treat these comments just like any ot= her
last call comments.

The entire text of the Security Considerations section is as follows:

=C2=A0 =C2=A0The mapping extensions described in this document do not provi= de any
=C2=A0 =C2=A0security services beyond those described by EPP [RFC5730], the= EPP
=C2=A0 =C2=A0domain name mapping [RFC5731], and protocol layers used by EPP= .=C2=A0 The
=C2=A0 =C2=A0security considerations described in these other specification= s apply
=C2=A0 =C2=A0to this specification as well.

This is what we like to call "security considerations by reference&quo= t;. I don't
know what "security services" are in this context, but they are n= ot the only
thing that needs to be described in a Security Considerations section.

In this case, the draft adds information about fees, customer credit and pa= y
schedule. This falls under the category of financial information, which sho= uld
be protected in transit by security mechanisms that protect confidentiality= and
integrity. It is also true that any transport mechanism that complies with = RFC
5730 provides those functions. So what I'm missing here is a sentence t= hat
calls this out specifically. Something along the lines of "This extens= ion adds
financial information to the EPP protocol, so confidentiality and integrity=
protection must be provided by the transport mechanism.=C2=A0 All transport= s
compliant with RFC5730 provide that"

--000000000000d390cb058c795cc9-- From nobody Sun Jun 30 10:45:06 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 515041200F7 for ; Sun, 30 Jun 2019 10:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mandelberg.org 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 jsnrvWWXiYb6 for ; Sun, 30 Jun 2019 10:44:56 -0700 (PDT) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (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 41E1212010D for ; Sun, 30 Jun 2019 10:44:53 -0700 (PDT) X_CMAE_Category: , , X-CNFS-Analysis: v=2.2 cv=buYOPwSi c=1 sm=1 tr=0 a=OXtaa+9CFT7WVSERtyqzJw==:117 a=OXtaa+9CFT7WVSERtyqzJw==:17 a=jpOVt7BSZ2e4Z31A5e1TngXxSK0=:19 a=KGjhK52YXX0A:10 a=-CRmgG0JhlAA:10 a=NTnny0joGdQA:10 a=dq6fvYVFJ5YA:10 a=bmmO2AaSJ7QA:10 a=l70xHGcnAAAA:8 a=AUd_NHdVAAAA:8 a=BTUBnpS-AAAA:8 a=48vgC7mUAAAA:8 a=XEC7Y1hFCdGuypyff68A:9 a=jiObf9B0YAUA:10 a=JtN_ecm89k2WOvw5-HMO:22 a=pblkFgjdBCuYZ9-HdJ6i:22 a=w1C3t2QeGrPiZgrLijVG:22 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: ZHNlb21uQHJjbi5jb20= Authentication-Results: smtp01.rcn.cmh.synacor.com header.DKIM-Signature=@mandelberg.org; dkim=pass Authentication-Results: smtp01.rcn.cmh.synacor.com header.from=david@mandelberg.org; sender-id=softfail Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.mail=david@mandelberg.org; spf=softfail; sender-id=softfail Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.user=dseomn@rcn.com; auth=pass (LOGIN) Received: from [209.6.43.168] ([209.6.43.168:59698] helo=uriel.mandelberg.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=DHE-RSA-AES256-GCM-SHA384) id 05/C4-36753-215F81D5; Sun, 30 Jun 2019 13:44:51 -0400 Received: from [192.168.1.152] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id DFA881C6033; Sun, 30 Jun 2019 13:44:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mandelberg.org; s=201903; t=1561916689; bh=YTWr46pZP38Qg+jENv8lK6KoFtwkrJ0K1QejFOUcGzM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=o3nOmHvHgg3iQ5dD8TCK9oQ2uNvcwEtE+2cFvZ8TaNzCvigiqbZRtbtS6DF8pp0oO L6CXgYw+PoZ+7ej8ASkOCuhBvIFkSZhvbVR9eeYduIRcRtln1efJjE3lRvQC8AL2Xc cqY4mHFQL1pPd00wbJk3rwpvswQ8tlfyWENxkEMkfdzjFkP6OCAlcfoftPdxW6tlw2 3ax8sCv8TwGXCitesD7yQciwf0d97vYMiAfvXTok1SyXNTNFHiy0BT6JSyLTXpO/2r DAbm6766MbjZ1u/NYqU4ufxeBoBYTWBL1+PU0CupJ4MpZlW/z0ANUYCpn+b4hDmnYQ Yuj3qpWi+DrFg== To: "Pascal Thubert (pthubert)" Cc: Tero Kivinen , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-6tisch-architecture.all@ietf.org" , Thomas Watteyne , =?UTF-8?B?TWFsacWhYSBWdcSNaW5p?= =?UTF-8?B?xIc=?= , Michael Richardson References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> <23825.24715.882644.180316@fireball.acr.fi> <28910.1561477164@localhost> <17322.1561564458@localhost> From: David Mandelberg Message-ID: <66e00d2b-448a-7845-451f-6a0a14a3fb11@mandelberg.org> Date: Sun, 30 Jun 2019 13:44:47 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=iso-8859-2; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 30 Jun 2019 17:44:58 -0000 -23 looks good. Thank you all for doing the work to secure the protocols! On 6/28/19 6:59 AM, Pascal Thubert (pthubert) wrote: > Hello David > > Many thanks again. Your comments steered great discussions that led to improvements in both this draft and minimal security. > I posted -23 in the hope that it satisfies all your comments. Please let us know is there is any additional issue we need to look at. > > All the best, > > Pascal > >> -----Original Message----- >> From: Michael Richardson >> Sent: mercredi 26 juin 2019 17:54 >> To: Pascal Thubert (pthubert) >> Cc: Tero Kivinen ; David Mandelberg >> ; secdir@ietf.org; iesg@ietf.org; draft-ietf-6tisch- >> architecture.all@ietf.org; Thomas Watteyne ; >> =?iso-8859-2?Q?Mali=B9a_Vu=E8ini=E6?= >> Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21 >> >> >> Pascal Thubert (pthubert) wrote: >> >> Tero: >> >> >> Note, that attacker might be able to replay valid ACKs for the frame >> >> >> sent by the JN, provided that the JRC (or whoever JN sent the message >> >> >> to) happened to ack message using the same ASN attacker faked for >> JN. >> >> >> >> Pascal Thubert (pthubert) wrote: >> >> > Your mean that the faked ASN is only slightly in the future, so the >> >> > attacker can repeat messages from the pledge after that delay? >> >> >> >> The faked ASN is always in the past. >> >> > Do you mean the replayed ones? When the pledge does not have the keys, >> > the attacker can forge the beacon with any ASN, and place random bytes >> > in the MIC, can't it? >> >> Yes, the replayed one has a "fake" ASN that is in the past. >> >> > If the attacker fakes an ASN that is tomorrow and intercepts a join >> > request, it could make the pledge seem to appear now on the network >> > tomorrow even if the real pledge is long gone. >> >> But that one won't validate. >> >> >> So the L2-ACKs can be faked, was the point. >> >> > I can see that an ACK can be replayed. But the ACK that was stored in >> > advance can only work if the attacked node speaks on the very ASN for >> > which the attacker intercepted an ACK in the past. The attacker is not >> > in control of that and that makes its life harder. >> >> When I said faked, I should have said replayed. >> >> I think that we don't need to do this: just wait for a beacon. If the attacker can >> block and replay them all, then they absolutely win, and the network can not >> form. Such an attacker probably can also put faraday cages around all the >> nodes. >> >> -- >> Michael Richardson , Sandelman Software Works - >> = IPv6 IoT consulting =- > From nobody Sun Jun 30 20:21:38 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99C611201F8; Sun, 30 Jun 2019 20:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=nohats.ca 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 4GYzUXVEUQr5; Sun, 30 Jun 2019 20:21:34 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 511601201F0; Sun, 30 Jun 2019 20:21:28 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 45cXhk0v2Dz370; Mon, 1 Jul 2019 05:21:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1561951286; bh=E9rPIKo9r7VoEvULG1Ci4eml+MeMBf4mR1hZ3Hfyaj8=; h=Date:From:To:Subject; b=rRX9ItnH7cApmQ3Itu21KgMudyvMRJurlrwaAYT8F56/6PCsewxhHntRytJ7LIiAM 7Cx6XUzToIZB0Eoopvg7nHAPJs4/uJTqh4HCk8fr9pkCVdR81ijwPPmgE1T3sixWuO 9N9uVQO1EL/joKMJFCbkUJ24hWzq82nONBt3c0PA= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id czHsr-Qwd9pb; Mon, 1 Jul 2019 05:21:22 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 1 Jul 2019 05:21:21 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id B429543924E; Sun, 30 Jun 2019 23:21:20 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca B429543924E Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A8C81410A4DB; Sun, 30 Jun 2019 23:21:20 -0400 (EDT) Date: Sun, 30 Jun 2019 23:21:20 -0400 (EDT) From: Paul Wouters To: draft-vixie-dnsop-dns-rpz@ietf.org, ise-chairs@ietf.org, secdir Message-ID: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Archived-At: Subject: [secdir] Review of draft-vixie-dns-rpz-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 03:21:38 -0000 I have reviewed this document at the request of the Independent Stream Editor. Note that as the document itself states, if something was designed from scratch, different design decisions would be made, and several improvements could be implemented. But the goal of this document is to describes a defacto industry standard that has been implemented by multiple vendors. As such, I believe it is best that this document is published to ensure interoperability. It will also allow the IETF community to start on a bis document to improve on the shortcomings of this implementation which thankfully are already described in the document. This document facilities nationstate wide censorship. Since code is already out there, we cannot prevent this anymore, and the best way forward is to write a bis document without these flaws (for which I've already offered idea and a willingness to contribute to the bis document). As such, I think this document should be published either as-is, or with just minor clarifications, required for the existing code base to interop on the short term. Long term, the goal would be for the bis implementation to spread further. In general, I found some of the text very difficult to read, despite having extensive DNS experience and having written DNS RFCs. But I don't think at this time we should attempt to change that for this document. If an RR found in an RPZ is meaningless or unusable for response policy purposes, then the containing RRset SHOULD be ignored, Is there a difference in failing between no QNAME present in the RPZ, and this "ignore" ? It is not clear what ignore means if there is no other RRset covering the QNAME. Return NXDOMAIN or NODATA (or ServFail?) Version and format is mentioned before it is explained? Where is this version? A single resource record (RR) consisting of a CNAME whose target is the root domain (.) will cause a response of NXDOMAIN to be returned. What should happen when there are two RRs with either same or different RDATA? I am little concerned with overloading CNAME's to "." and "*.", as those queries do have real answers in the root zone (NSEC proof of non-existence) and would have prefered to see this land into a specifically reserved zone instead. But that will need to be done for the bis version. Precedence is mentioned before it is explained where or how it is encoded. (similar to version) rpz-drop. / rpz-passthru. is uses yet _another_ zone. It would have been nicer if all these CNAME targets lived within one zone, as that makes handling special zones easier in general. It seems also likely that if any of this is hand edited, the trailing dot might be forgotten, leading to weird things? The document explains this design weakness as well. What is the chance of bogus RPZ lookalike code causing interferece? For example, what happens if I add this to my nohats.ca. zone: nohats.ca IN CNAME rpz-passthrough. That is, can someone spoof a domain onto an RPZ list they do not control? In theory, this would not be possible. But in practise, a lot of DNS code is re-used between RPZ code and regular DNS code. The special RPZ encodings which are not to be taken as Local Data are CNAMEs with targets that are: + "." (NXDOMAIN action), + "*." (NODATA action), + a top level domain starting with "rpz-", + a child of a top level domain starting with "rpz-". Is there any other usage known of CNAME's pointing to "." or "*." ? Claiming a CNAME target cannot start with "rpz-" or a 2nd level domain cannot start with "rpz-" is surely a very dangerous hack, and infringes upon other parties that might not be aware of these restrictions possibly causing deployments issues. What it someone has the domain "rpz-exmaple.com." ? Or what if ICANN delegates "rpz-example.". While these should not be affected as LHS (versus RDATA), it seems this is a disaster waiting to happen. This is really a bad use of squatting on the root zone name space. It would have been much better if a clear longer string that wouldn't match an expected real use domain or prefix was picked, eg "response-zone-data." and "*.response-zone-data." At least for now, no TLD's start with "rpz-". A quick test shows an unfortunate namespace clash with things like the Religions Padagigisches Zentrum and others: rpz-aurich.de rpz-bayern.de rpz-bilder.de rpz-bochum.de rpz-bonn.de rpz-bremen.de rpz-dresden.de rpz-ekhn.de rpz-heavyequipmentsales.de rpz-heilsbronn.de rpz-igb.de rpz-immobilien.de rpz-kassel.de rpz-kirchheimbolanden.de rpz-kusel.de rpz-manualdoproprietario.com.br rpz-nord.de rpz-solutions.co.uk rpz-speyer.de rpz-sued.de rpz-test.co.uk rpz-tester.co.uk rpz-testers.co.uk rpz-testing.co.uk rpz-tests.co.uk rpz-unterfranken.de rpz-valve.co.uk rpz-valve.uk rpz-valvesolutions.co.uk rpz-valvetest.co.uk rpz-valvetest.uk rpz-valvetesters.co.uk rpz-valvetesting.co.uk rpz-web.de rpz-zlin.cz rpz-zwickau.de If anything, this shows it is important to get this document out so that we can work on the bis document that will have its own restricted sub-zone dedicated for this where it is not possible that QNAME/RDATA targets would get mixed up and accidentally fail on RPZ. Wildcards are not valid as CNAME targets in ordinary DNS zones. How does using this "illegal" construct work in various DNS software that underlies the RPZ implementation? Is there a danger in DNS libraries used by RPZ software to be implemented incorrectly if the underlying DNS library is very strict? I think not, as this wildcard use is pretty fundamental to RPZ, so I assume the whole thing just won't work if this is the case. But a side-effect could be that the DNS library is modified to allow wildcards in CNAME RDATA, causing real DNS to mistakenly be allowed to do this. Would that cause operational issues with regular DNS? But again, this is more something to be thought about for the next version of RPZ. The 5 listed trigger types are: - Client IP Address - QNAME - Response IP Address - NSDNAME - NSIP I find it confusing that this is a mix of "C style defines" and "multiple english words". I would have probably used CLIENT_IP and RESPONSE_IP (and NS_NAME and NS_IP), and not NSDNAME (as that is confusingly looking like NS and DNAME, two existing RRTYPES) The explanation of 4.1 saying it can be used to quarantine a compromised client is probably a feature that should be added to the Introduction text, which otherwise focuses mostly on access prevention of legitimate clients. IP address encoding should probably gets its own subsction in Section 4 before describing the first trigger type. I find NSDNAME confusing, because it appears to be something with NS and DNAME, but it really is just "Nameserver trigger". Maybe NS_NAME would have been more clear, but I don't know how much this term is now embedded into existing reference implementations. Is there a reason nameserver names cannot be blocked using QNAME triggers? Why is this a specific different type of trigger? Wouldn't blocking ns.nohats.ca as an IP work equally well? I guess similarly with the NSIP trigger? I'm sure there is a good reason for this, but I can't tell that from any of the present text. I would help to add some text that states line order of an RPZ zonefile is not at all considered as a precedence order when processing RPZ rules. The "order" of the rules is in the implementation, not based on the order of the lines in an rpz zone file. I'm a little concerned about NSDNAME triggers, since those can cover part of an RRset (where an RRset is normally covered by one RRSIG in DNSSEC). Does this type of trigger remove/modify the individual RRs only, or does one hit within an RRSet match the entire RRset ? eg if ns1.nohats.ca is listed in the NSDNAME set to be blocked, does it affect ns0.nohats.ca if for nohats.ca those two are the NS records? Or in English, if a domain being published by multiple NS records has one NS records that is matched in an RPZ block, will it just block the one nameserver or block the entire domain? This is probably the only issue that I would insist on clarifying in the document, as I can see different implementations doing this differently, making RPZ zones inconsistent across implementations. There is a lot of text on what to do when there are conflicting RPZ directives, by specifying a complex ordering mechanism (eg Section 5). Another approach could be to not allow such conflicts to happen. eg refuse to add a RPZ rule that would be the equivalent of "unreachable code". My guess is that this is complicated and possibly too resource intensive to enforce in code? But perhaps that can/should be spelled out more clearly? An implementation SHOULD include a configuration option such as "recursive-only no" to relax this restriction. I assume this means "An RPZ implementation"? Please clarify that. I'm confused why this option is sometimes needed. Can you explain the use of this option better. Ideally, it would explain why the SHOULD is not a MUST as well? And what is the expected interaction with forwarder statements? Also by default, RPZ policies are applied only while responding to DNS requests that do not request DNSSEC metadata (DO=0) or for which no DNSSEC metadata exists. An implementation MAY include a configuration option such as "break-dnssec yes" to relax this restriction. This comes as a big surprise to me so far into the document. Definitely, a few sentences about DNSSEC interaction should go into the the Introduction. Also, wouldn't this be an attack vector? If you are doing Client IP address RPZ blocks, wouldn't a malicious client just set DO=1 to avoid having its malicious DNS resolve requests blocked? This seems like a big shortcoming (and I'm saying that while being relieved this is there because it means it won't break my own DNS, since I always use DNSSEC). Something a bis document should fix up properly. If a policy rule matches and results in a modified answer, then that modified answer will include in its additional section the SOA RR of the policy zone whose rule was used to generate the modified answer. This is also something that comes out of nowhere and pretty late, and probably deservers a mention in the introduction. I also do not see any of this in the examples, so it would be good to add an example DNS answer that shows such an additional section SOA RR. DISABLED SHOULD be implemented and causes any rule of the zone, when selected as a "best match", to have no effect, except to log what would otherwise have happened, provided sufficient logging is enabled. I prefer the name PERMISSIVE, in the same way that SElinux has enabled, permissive and disabled. It is not intuitive that "disabled" still causes all RPZ queries and processing to happen. I assume it is too late now to change this as there are some implementations out there now, but again something to think of for the bis document. The master also SHOULD be configured as necessary to send NOTIFY messages to each slave. Because minimal data latency is critical both to the prevention of crime and abuse and to the withdrawal of erroneous or outdated policy, a DNS RPZ producer SHOULD also make every effort to minimize data latency, including ensuring that NOTIFY messages are sent in a timely manner after each change of the DNS RPZ on the master server. I think this paragraph is arguing for MUST's while stating SHOULDs ? Right now it seems to contradict the importance level. For example, a DNS RPZ might include a QNAME policy rule for "BAD.EXAMPLE.COM" as well as a Response IP Address policy rule for 192.0.2.1. Clarify that these are special domains and IP addresses that cannot occur in the wild? Possibly mention the example/documentation RFC 5737. What we want to avoid is someone copying this as example for a new RPZ zone and changing 192.0.2.1 into some other actual valid public IP that's in use on the internet. Implementations which include this optimization SHOULD provide a configuration switch (for example, "qname-wait-recurse") to turn it on and off. Why is this? The text clearly demonstrates that in some cases this path is never needed to be traversed (eg on hitting Client IP Address trigger). Why SHOULD implementations have an override for this? (I found out why near the end in Section 12, see my comments there) The default value of the switch MAY be on or off. This MAY is curious, as a switch MUST be on or off? Probably language without the word MAY makes more sense in this context. Section 9.3 seems dangerous. Especially, as some TLDs are known to accidentally make orphaned glue authoritative data in their TLD zone. Malicious parties could specifically seek these out knowing it will bypass RPZ. If I could manage to get an A record for nohats.ca. into the ca. TLD zone, would any RPZ restrictions based on NS nohats.ca. automatically be skipped by RPZ restrictions? I find the start of 9.4 confusing. It would seem those implementations are completely vulnerable to DNS spoofing and lack any support of DNSSEC. Those resolvers should be considered completely broken and this document should not facilitate those servers at all. Seperate from that, I understand there are children and parent sticky resolver policies and that part does fit into this section properly. Perhaps a slightly more accurate rewrite of this first paragraph would fix this. I feel Section 9.5 could be better implemented with a new keyword (another CNAME target) that would mean both uses are disallowed. But as this document is describing existing implementations, that can be taken forward to the bis document. Section 10 is a very useful section for work on a bis document. While I normally would be tempted to not put this into and RFC (similar to the Implementation Considerations that is remove prior to publication), in this case I agree it should be left in here to help the DNSOPS WG to write a bis document. Section 12.2 is obviously the one that concerns me most. A successor version of RPZ must support DNSSEC in such a way that updated clients can use RPZ yet their answers cannot be withheld - this prevents nationstate censorship using mandatory RPZ.A Section 12.4 is a little odd. It claims that for counter-intellegence purpose, the early abort of recursion leaks information to the attacker and therefor there should be an option to enable/disable that. It seems either the code should never abort early, or one just has to live with the information leak in favour of performance. The individual administrator is probably not able to set this option in favourable way for the internet at large anyway, and if such an administrator makes a personal choice, it is most likely they will always prefer optimising their cpu usage of RPZ. I see no mention of the TTL of RPZ data. Should there be some advise about what TTLs to use for RPZ data? Is there any (bad) interaction with query minimalization and rpz ? The document could do with a Human Rights consideration section, as the document specifies a method to implement censorship. But I think the goal is to publish and immediately improve on this in such a way that it cannot be abused for nation state censorship, so I am okay with not doing it for this version, which is mostly documentation of existing process. NITS: "An RPZ need not support query access since query access is never required." This is a bit confusing, since an RPZ is a zone, and what else is a zone used for? (does this mean you can only take the entire RPZ, and not query it "live" ?) Paul From nobody Sun Jun 30 21:31:34 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A15A01201F1; Sun, 30 Jun 2019 21:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 LN323LZRmvRw; Sun, 30 Jun 2019 21:31:30 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 852E11201F0; Sun, 30 Jun 2019 21:31:30 -0700 (PDT) Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id E166F892C6; Mon, 1 Jul 2019 04:31:28 +0000 (UTC) From: Paul Vixie To: Paul Wouters Cc: draft-vixie-dnsop-dns-rpz@ietf.org, ise-chairs@ietf.org, secdir Date: Mon, 01 Jul 2019 04:31:27 +0000 Message-ID: <4764650.hNbmM6NLfM@linux-9daj> Organization: none In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Archived-At: Subject: Re: [secdir] Review of draft-vixie-dns-rpz-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2019 04:31:32 -0000 thank you pwouters, i will see what i can do to address your comments in the next draft. meanwhile, some of our colleagues at cnnic have indicated a willingness to work on the -bis concept of including both the truth and the lie, with a dnssec proof of the truth, and a tsig or sig(0) of the lie, so that the client can be aware of both, and make its own choices. i'd be happy to be a part of that conversation, and, i wish that vernon or i had thought of this originally. dns firewalls are valuable as a feature, but should be usable on a permission model. note that in a private network like my home or business, i would not offer that choice. but for isp and other access networks, that choice should be available to every user. thanks again for your review. vixie