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=A0Ready 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=A0Ready 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):

https://github.com/pusateri/draft-ietf-dnssd-push

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: