From nobody Mon Jul 1 09:43:50 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 B5F9D120904; Fri, 28 Jun 2019 14:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1561757857; bh=iesuhuQfseg5R2nydnhzMu7JYrRQL+FPBLO0wG0qYa4=; h=From:Date:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=YwYqjha5RWUorsBPHnY3/XCcRrJQOtPkaxd3W+ynWLMA7RMDDUPPLxomNQtdB18Iz VT6zmNkxWciOypp3ww6J/SMSxj8uWLWsZtlPdNuepmLcN9gmrQBrcJMsdSdg322JY+ rpFU06JoVriFiXKc93yzz3m3Zk6pbUORMrgoR/Aw= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Jun 28 14:37:37 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 55F401202BD; Fri, 28 Jun 2019 14:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1561757857; bh=iesuhuQfseg5R2nydnhzMu7JYrRQL+FPBLO0wG0qYa4=; h=From:Date:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=YwYqjha5RWUorsBPHnY3/XCcRrJQOtPkaxd3W+ynWLMA7RMDDUPPLxomNQtdB18Iz VT6zmNkxWciOypp3ww6J/SMSxj8uWLWsZtlPdNuepmLcN9gmrQBrcJMsdSdg322JY+ rpFU06JoVriFiXKc93yzz3m3Zk6pbUORMrgoR/Aw= 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 3488512028B for ; Fri, 28 Jun 2019 14:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7GFJ_V1m7c6 for ; Fri, 28 Jun 2019 14:37:33 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (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 9B545120110 for ; Fri, 28 Jun 2019 14:37:33 -0700 (PDT) Received: from [93.30.120.228] (helo=[192.168.1.20]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hgyYm-0006lx-59; Fri, 28 Jun 2019 21:37:32 +0000 From: Coralie Mercier Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Fri, 28 Jun 2019 23:37:30 +0200 Message-Id: To: new-work@ietf.org X-Mailer: Apple Mail (2.3445.104.11) Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Mon, 01 Jul 2019 09:43:49 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Privacy Interest Group (PING) (until 2019-08-04) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 21:37:39 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to review a draft charter for the Privacy Interest Group (PING): https://w3cping.github.io/administrivia/charter-draft.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2019-08-04 on the proposed charter. Please send comments to public-new-work@w3.org, which has a public archive: http://lists.w3.org/Archives/Public/public-new-work/ Other than comments sent in formal responses by W3C Advisory Committee Representatives, W3C cannot guarantee a response to comments. If you work for a W3C Member [1], please coordinate your comments with your Advisory Committee Representative. For example, you may wish to make public comments via this list and have your Advisory Committee Representative refer to it from his or her formal review comments. If you should have any questions or need further information, please contact Samuel Weileer, Team Contact . Thank you, Coralie Mercier, Head of W3C Marketing & Communications [1] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Marketing & Communications - https://www.w3.org mailto:coralie@w3.org +337 810 795 22 https://www.w3.org/People/Coralie/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Mon Jul 1 17:26:20 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 438F112018A; Mon, 1 Jul 2019 17:26:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Daniel Migault via Datatracker To: Cc: spasm@ietf.org, draft-ietf-lamps-cms-shakes.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Daniel Migault Message-ID: <156202717120.5730.12825083272193517507@ietfa.amsl.com> Date: Mon, 01 Jul 2019 17:26:11 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-lamps-cms-shakes-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jul 2019 00:26:12 -0000 Reviewer: Daniel Migault Review result: Has Nits Hi I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I believe the document is ready with nits. Yours, Daniel LAMPS WG P. Kampanakis Internet-Draft Cisco Systems Updates: 3370 (if approved) Q. Dang Intended status: Standards Track NIST Expires: December 19, 2019 June 17, 2019 Use of the SHAKE One-way Hash Functions in the Cryptographic Message Syntax (CMS) draft-ietf-lamps-cms-shakes-11 2. Introduction In the SHA-3 family, two extendable-output functions (SHAKEs), SHAKE128 and SHAKE256, are defined. Four other hash function instances, SHA3-224, SHA3-256, SHA3-384, and SHA3-512 are also defined but are out of scope for this document. A SHAKE is a variable length hash function defined as SHAKE(M, d) where the output is a d-bits long digest of message M. The corresponding collision and second preimage resistance strengths for SHAKE128 are min(d/2,128) and min(d,128) bits respectively (Appendix A.1 [SHA3]). And, the corresponding collision and second preimage resistance strengths for SHAKE256 are min(d/2,256) and min(d,256) bits respectively. since we are introducing d in this section and the specification fixes d later, we may fix d here and list the associated security for the fixed value. I would also suggest that additional resistance considerations be mentioned in the security consideration with a reference to it in the introduction. Additional consideration would also provide preimage resistance and extends the considerations regarding 128/256 bit security and post quantum resistance. A SHAKE can be used in CMS as the message digest function (to hash the message to be signed) in RSASSA-PSS and ECDSA, message authentication code and as the mask generation function (MGF) in RSASSA-PSS. This specification describes the identifiers for SHAKEs to be used in CMS and their meaning. 3. Identifiers This section defines four new object identifiers (OIDs) for using SHAKE128 and SHAKE256 in CMS. It is unclear to me if this section defines OIDs. Instead, it seems to me that the section lists OIDs for convenience but these are defined in other documents. Two object identifiers for SHAKE128 and SHAKE256 hash functions are defined in [shake-nist-oids] and we include them here for convenience. id-shake128 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 11 } id-shake256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithm(4) 2 12 } In this specification, when using the id-shake128 or id-shake256 algorithm identifiers, the parameters MUST be absent. That is, the identifier SHALL be a SEQUENCE of one component, the OID. It might be clearer if the AlgoritmIdentifier structure is added for convenience or referenced maybe by RFC5280 in the document. On the other hand, I am also inclined to think that this section may be replaced with a reference to lamps-pkix-shake.and the list of id-*. This could be one sentence in the introduction 4. Use in CMS 4.1. Message Digests The id-shake128 and id-shake256 OIDs (Section 3) can be used as the digest algorithm identifiers located in the SignedData, SignerInfo, DigestedData, and the AuthenticatedData digestAlgorithm fields in CMS x [RFC5652]. The encoding MUST omit the parameters field and the I might be missing one level of encapsulation, but my understanding is that digest algorithm identifiers and algorithm identifiers have the same structure. If that is correct, it seems that the requirement to omit the parameters is redundant with the definition of the algorithm identifiers as well as with lamps-pkix-shake. I am reading the sentence as it provides some requirements on the message format (no parameters are provided) as well as the setting of an output size. I interpret the output size as a parameter for the message-digesting algorithm as opposed as a parameter that is provided in the message. If that is the case, that might be specified explicitly and maybe in two different sentences as to avoid coupling requirements of different nature. output size, d, for the SHAKE128 or SHAKE256 message digest MUST be 256 or 512 bits respectively. The digest values are located in the DigestedData field and the Message Digest authenticated attribute included in the signedAttributes of the SignedData signerInfo. In addition, digest values are input to signature algorithms. The digest algorithm MUST be the same as the message hash algorithms used in signatures. 4.2. Signatures In CMS, signature algorithm identifiers are located in the SignerInfo signatureAlgorithm field of SignedData content type and countersignature attribute. Signature values are located in the SignerInfo signature field of SignedData content type and countersignature attribute. Conforming implementations that process RSASSA-PSS and ECDSA with SHAKE signatures when processing CMS data MUST recognize the corresponding OIDs specified in Section 3. When using RSASSA-PSS or ECDSA with SHAKEs, the RSA modulus and ECDSA curve order SHOULD be chosen in line with the SHAKE output length. In the context of this document SHAKE128 OIDs are RECOMMENDED for 2048 or 3072-bit RSA modulus or curves with group order of 256-bits. SHAKE256 OIDs are RECOMMENDED for 4096-bit RSA modulus and higher or curves with group order of 384-bits and higher. I believe a reference to the security consideration should be provided with further discussions on the meaning of "in line". The security consideration should maybe provide a reference that correlates symmetric - as CMS can be used with AES -, factoring modulus Elliptic curves and hash. Though the current security consideration reference SP800-78-4 and SP800-107, maybe the following ones could be used in the security consideration. They look more recent but I have not deeply looked at those. * Algorithms, Key Size and Protocols Report (2018), H2020-ICT-2014 – Project 645421, D5.4, ECRYPT-CSA, 02/2018. * Recommendation for Key Management, Special Publication 800-57 Part 1 Rev. 4, NIST, 01/2016. 4.2.1. RSASSA-PSS Signatures The RSASSA-PSS algorithm is defined in [RFC8017]. When id-RSASSA- PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256 specified in Section 3 is used, the encoding MUST omit the parameters field. That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one component, id-RSASSA- PSS-SHAKE128 or id-RSASSA-PSS-SHAKE256. [RFC4055] defines RSASSA- PSS-params that are used to define the algorithms and inputs to the algorithm. This specification does not use parameters because the hash, mask generation algorithm, trailer and salt are embedded in the OID definition. This is a similar comment as the one provided earlier. It does not seem to me that this document "specifies" (in section 3) algorithms. It seems to me these algorithms are provided for convenience but are specified in pkix-shake. Similarly, the absence of parameter does not seems to me necessary here - unless I am missing something. It seems that MUST and SHALL are aiming at preventing the NULL parameter, I am wondering if there are any reasons for having different terms. The explanation may be moved to section 3. The hash algorithm to hash a message being signed and the hash algorithm as the mask generation function used in RSASSA-PSS MUST be the same, SHAKE128 or SHAKE256 respectively. The output-length of the hash algorithm which hashes the message SHALL be 32 or 64 bytes respectively. I suggest we use bytes or bits in the document. 4.2.2. ECDSA Signatures The Elliptic Curve Digital Signature Algorithm (ECDSA) is defined in [X9.62]. When the id-ecdsa-with-shake128 or id-ecdsa-with-shake256 (specified in Section 3) algorithm identifier appears, the respective SHAKE function is used as the hash. The encoding MUST omit the parameters field. That is, the AlgorithmIdentifier SHALL be a SEQUENCE of one component, the OID id-ecdsa-with-shake128 or id- ecdsa-with-shake256. same comment regarding the parameter field 4.3. Public Keys The identifier parameters, as explained in Section 3, MUST be absent. Same comment as above. 4.4. Message Authentication Codes 6. Security Considerations This document updates [RFC3370]. The security considerations section of that document applies to this specification as well. NIST has defined appropriate use of the hash functions in terms of the algorithm strengths and expected time frames for secure use in Special Publications (SPs) [SP800-78-4] and [SP800-107]. These documents can be used as guides to choose appropriate key sizes for various security scenarios. When more than two parties share the same message-authentication key, data origin authentication is not provided. Any party that knows the message-authentication key can compute a valid MAC, therefore the content could originate from any one of the parties. I would suggest to add some considerations on resistance with post quantum computers. From nobody Tue Jul 2 09:15: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 B6D92120412; Tue, 2 Jul 2019 09:15:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Nancy Cam-Winget via Datatracker To: Cc: sipcore@ietf.org, draft-ietf-sipcore-rejected.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Nancy Cam-Winget Message-ID: <156208413663.23908.7643344599862494056@ietfa.amsl.com> Date: Tue, 02 Jul 2019 09:15:36 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-sipcore-rejected-08 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, 02 Jul 2019 16:15:37 -0000 Reviewer: Nancy Cam-Winget Review result: Has Nits SECDIR review of draft-ietf-sipcore-rejected-08 Reviewer: Nancy Cam-Winget Review result: Ready with Nits I have reviewed this document as part of the security directorate'sÊ ongoing effort to review all IETF documents being processed by theÊ IESG.ÊÊThese comments were written primarily for the benefit of theÊ security area directors.ÊÊDocument editors and WG chairs should treatÊ these comments just like any other last call comments. This document defines the use of value 608 as the "rejected" SIP response code. More specifically, the intent is to define a code such that an intermediary (e.g. an analytics engine versus the target user server) can signal that it is rejecting the call. The following are general comments and suggestions (and editorial nits at the end): 3.1 "Proxies need to be mindful that a downstream intermediary may reject....", this seems too imply that there are other nodes in the path that can generate the 608 reject. What is the underlying key used to sign the JWT and how can this be validated as being a proper and identifiably authorized intermediary to issue such a 608 signal? What happens if multiple intermediaries want to reject the call? Perhaps adding a sentence here would be helpful. 6. "Yet another risk is a malicious intermediary.....strongly recommend the recipient validates to whom they are communicating"; it seems like perhaps this should be a MUST in that the recipient should validate that both the message is valid but also the sender can be trusted. Signing the jCard is actually a MUST. This paragraph is a bit long and hard to discern, it could benefit from breaking it into the different considerations: the need to at minimum sign the jCard, the need to also trust (verify the authorization or validity of the source). - there should also be considerations or how to handle multiple intermediaries sending the sip.608 signals Editorial nits: - I presume the [RFCXXXX] refers to this draft once it is RFC'ed.... 3.4 "The simple rule is a network element ....", this should be a stronger MUST that is the network element that is sip.608 "MUST convey at a minimum..." From nobody Fri Jul 5 11:12:11 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 7E96D1200F5; Fri, 5 Jul 2019 11:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=KBpL/oMt; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=INckBotm 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 BdPRHVk7LfIW; Fri, 5 Jul 2019 11:12:06 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 852491200F4; Fri, 5 Jul 2019 11:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15240; q=dns/txt; s=iport; t=1562350325; x=1563559925; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=xu1T6Bs3NiXssIQMzXGlt0JbmE+XkcxIkevuSrPtzeI=; b=KBpL/oMtFAhyqC2nrURC5rmavvWA8CbEcfoQBXpn7uoSJlXtTIb8ynd3 BOWCPLHizn90RZ1lHKJNb0aArU8Oc1JhNG/Y8jwLuwGg1oFMatEmSrSm0 h+hmupB8gHQSxwYuHwyE8fCjZfHtao+1A3CsSW2CkwFNB7HKhjG6AAQVC I=; IronPort-PHdr: =?us-ascii?q?9a23=3ArIdcFRzBOf/MLmHXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZudCkT+NPfsZgQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BtAACxkR9d/4oNJK1mGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBVgMBAQELAYFDUANqVSAECygKhBKDRwOOSoJbl0aCUgNUCQEBAQw?= =?us-ascii?q?BARgNCAIBAYRAAheCFyM3Bg4BAwEBBAEBAgEFbYo3DIVKAQEBBAEBEBERDAE?= =?us-ascii?q?BLAsBCwQCAQgRBAEBAwImAgICJQsVCAgCBAENBQgagwGBagMdAQIMmmwCgTi?= =?us-ascii?q?IYHGBMoE5gUABAQWFFhiCEgMGgQwoAYteF4FAP4ERRoJMPoJhAQECgWGDCDK?= =?us-ascii?q?CJot1gnWbXwkCgheGVoRriF2XeI0whz+MMFqCcgIEAgQFAg4BAQWBZiIqgS5?= =?us-ascii?q?wFTuCbBOCLgkCAReDToUUhT9ygSmMTQGBIAEB?= X-IronPort-AV: E=Sophos;i="5.63,455,1557187200"; d="scan'208";a="587636697" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 05 Jul 2019 18:12:03 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x65IC3E4023485 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 5 Jul 2019 18:12:03 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 5 Jul 2019 13:12:02 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 5 Jul 2019 14:12:00 -0400 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 5 Jul 2019 13:12:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xu1T6Bs3NiXssIQMzXGlt0JbmE+XkcxIkevuSrPtzeI=; b=INckBotmlvpX946LOKTCRiYEfkJaStMWm2x3YKTkSjyMywd6IHjnM8ejw+2c13jHUQb5ETXysYnoWHPdzEEgwiG18PT8xyagun2RCufF27N+aSJ8ec8fS7/XhMcMcpev2Bbl3TSoCKm1tdTNoQmPB5E4g7g61pdm8UVn6g5OP64= Received: from BN7PR11MB2547.namprd11.prod.outlook.com (52.135.244.29) by BN7PR11MB2563.namprd11.prod.outlook.com (52.135.244.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.18; Fri, 5 Jul 2019 17:56:04 +0000 Received: from BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::b1dc:fd0d:e540:67aa]) by BN7PR11MB2547.namprd11.prod.outlook.com ([fe80::b1dc:fd0d:e540:67aa%7]) with mapi id 15.20.2032.019; Fri, 5 Jul 2019 17:56:04 +0000 From: "Panos Kampanakis (pkampana)" To: Daniel Migault , "secdir@ietf.org" CC: "spasm@ietf.org" Thread-Topic: [lamps] Secdir last call review of draft-ietf-lamps-cms-shakes-11 Thread-Index: AQHVMGz8Y3AT7G/6YEuDZe4hzJWqDaa8Oexg Date: Fri, 5 Jul 2019 17:56:04 +0000 Message-ID: References: <156202717120.5730.12825083272193517507@ietfa.amsl.com> In-Reply-To: <156202717120.5730.12825083272193517507@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [173.38.117.93] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cae62517-0ecc-48eb-7281-08d701720cbd x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:BN7PR11MB2563; x-ms-traffictypediagnostic: BN7PR11MB2563: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 008960E8EC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(366004)(396003)(39860400002)(346002)(136003)(199004)(189003)(13464003)(76116006)(186003)(66476007)(478600001)(26005)(73956011)(66556008)(76176011)(53546011)(66446008)(110136005)(102836004)(6506007)(64756008)(316002)(68736007)(486006)(2906002)(81166006)(8936002)(11346002)(966005)(446003)(74316002)(8676002)(52536014)(30864003)(33656002)(71200400001)(5660300002)(81156014)(229853002)(7736002)(99286004)(305945005)(7696005)(476003)(71190400001)(66946007)(55016002)(66066001)(66574012)(14444005)(25786009)(256004)(6306002)(53936002)(9686003)(6436002)(86362001)(3846002)(4326008)(6116002)(14454004)(6246003)(2501003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN7PR11MB2563; H:BN7PR11MB2547.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: aDEzSTCbU4UWL8TCzBR25eUFB2QfwGulQTRPX3nEmAwllkQJs+GOaX44bJCg16YdzQHk7tiOIG2vkfrIT3nyb3WJhMhFKyFaLHI1fNHfNsMBfHF22ab7Ju9XL0DHEj9Yk+2V+5y3aJ3RWhdDQO0D68wf3NL2eCOdCHsj++v/SdsBxeZqFIFYcvsxgd8v7v1tLTcryffnl3oZcd4jNjro9Unm+mSqRv03zuY9WkSWg/+f/zsmPxMQVpV+hmhs1pU+n84FgMIznCPW2d4urU1Nt5QBA/TdsOlU2apApd+42OqtRmBzVdwmj6Y9QpGAW3hsh/Xr/NBPKPx/q9YUcETkFQxLmJ968VE0nwPGRSrnbboT3cNB1QF0W+roAR+xX2JRyOFOWQg9tsv3qNUcHzy+TCsnmt3tQ/jLdvtk/sqZ3W0= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: cae62517-0ecc-48eb-7281-08d701720cbd X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jul 2019 17:56:04.6896 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pkampana@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN7PR11MB2563 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [secdir] [lamps] Secdir last call review of draft-ietf-lamps-cms-shakes-11 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, 05 Jul 2019 18:12:10 -0000 SGkgRGFuLA0KDQpUaGFuayB5b3UgZm9yIHRoZSB0aG9yb3VnaCByZXZpZXcuIA0KDQpJIGFkZHJl c3NlZCB5b3VyIGNvbW1lbnRzIGluIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgZHJhZnQgaW4g Z2l0IGh0dHBzOi8vZ2l0aHViLmNvbS9jc29zdG8tcGsvYWRkaW5nLXNoYWtlLXRvLXBraXgvYmxv Yi9tYXN0ZXIvZHJhZnQtaWV0Zi1sYW1wcy1jbXMtc2hha2VzLWN1cnJlbnQudHh0IEZvciB0aGUg c3BlY2lmaWMgYW5zd2VycyBhbmQgZml4ZXMgdG8geW91ciBjb21tZW50cyBjaGVjayBvdXQgdGhl IGdpdCBpc3N1ZSBodHRwczovL2dpdGh1Yi5jb20vY3Nvc3RvLXBrL2FkZGluZy1zaGFrZS10by1w a2l4L2lzc3Vlcy80OSNpc3N1ZWNvbW1lbnQtNTA4MzEyNzI5IExldCBtZSBrbm93IGlmIHNvbWV0 aGluZyBkb2Vzbid0IG1ha2Ugc2Vuc2UuIA0KDQpJIHdpbGwgdXBsb2FkIHRoaXMgaXRlcmF0aW9u IGluIGEgd2VlayBvciBzby4gDQoNClJncywNClBhbm9zDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IFNwYXNtIDxzcGFzbS1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYg T2YgRGFuaWVsIE1pZ2F1bHQgdmlhIERhdGF0cmFja2VyDQpTZW50OiBNb25kYXksIEp1bHkgMDEs IDIwMTkgODoyNiBQTQ0KVG86IHNlY2RpckBpZXRmLm9yZw0KQ2M6IHNwYXNtQGlldGYub3JnOyBk cmFmdC1pZXRmLWxhbXBzLWNtcy1zaGFrZXMuYWxsQGlldGYub3JnOyBpZXRmQGlldGYub3JnDQpT dWJqZWN0OiBbbGFtcHNdIFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtbGFt cHMtY21zLXNoYWtlcy0xMQ0KDQpSZXZpZXdlcjogRGFuaWVsIE1pZ2F1bHQNClJldmlldyByZXN1 bHQ6IEhhcyBOaXRzDQoNCkhpDQoNCkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBh cnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3 IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuICBUaGVzZSBj b21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2Vj dXJpdHkgYXJlYSBkaXJlY3RvcnMuICBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hv dWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNv bW1lbnRzLg0KDQpJIGJlbGlldmUgdGhlIGRvY3VtZW50IGlzIHJlYWR5IHdpdGggbml0cy4NCg0K WW91cnMsDQpEYW5pZWwNCg0KTEFNUFMgV0cgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBQLiBLYW1wYW5ha2lzDQpJbnRlcm5ldC1EcmFmdCAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIENpc2NvIFN5c3RlbXMNClVwZGF0 ZXM6IDMzNzAgKGlmIGFwcHJvdmVkKSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgUS4gRGFuZw0KSW50ZW5kZWQgc3RhdHVzOiBTdGFuZGFyZHMgVHJhY2sgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBOSVNUDQpFeHBpcmVzOiBEZWNlbWJlciAxOSwgMjAxOSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEp1bmUgMTcsIDIwMTkNCg0KICBVc2Ugb2Yg dGhlIFNIQUtFIE9uZS13YXkgSGFzaCBGdW5jdGlvbnMgaW4gdGhlIENyeXB0b2dyYXBoaWMgTWVz c2FnZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgU3ludGF4IChDTVMpDQogICAgICAg ICAgICAgICAgICAgICBkcmFmdC1pZXRmLWxhbXBzLWNtcy1zaGFrZXMtMTENCg0KMi4gIEludHJv ZHVjdGlvbg0KDQogICBJbiB0aGUgU0hBLTMgZmFtaWx5LCB0d28gZXh0ZW5kYWJsZS1vdXRwdXQg ZnVuY3Rpb25zIChTSEFLRXMpLA0KICAgU0hBS0UxMjggYW5kIFNIQUtFMjU2LCBhcmUgZGVmaW5l ZC4gIEZvdXIgb3RoZXIgaGFzaCBmdW5jdGlvbg0KICAgaW5zdGFuY2VzLCBTSEEzLTIyNCwgU0hB My0yNTYsIFNIQTMtMzg0LCBhbmQgU0hBMy01MTIgYXJlIGFsc28NCiAgIGRlZmluZWQgYnV0IGFy ZSBvdXQgb2Ygc2NvcGUgZm9yIHRoaXMgZG9jdW1lbnQuICBBIFNIQUtFIGlzIGENCiAgIHZhcmlh YmxlIGxlbmd0aCBoYXNoIGZ1bmN0aW9uIGRlZmluZWQgYXMgU0hBS0UoTSwgZCkgd2hlcmUgdGhl IG91dHB1dA0KICAgaXMgYSBkLWJpdHMgbG9uZyBkaWdlc3Qgb2YgbWVzc2FnZSBNLiAgVGhlIGNv cnJlc3BvbmRpbmcgY29sbGlzaW9uDQogICBhbmQgc2Vjb25kIHByZWltYWdlIHJlc2lzdGFuY2Ug c3RyZW5ndGhzIGZvciBTSEFLRTEyOCBhcmUNCiAgIG1pbihkLzIsMTI4KSBhbmQgbWluKGQsMTI4 KSBiaXRzIHJlc3BlY3RpdmVseSAoQXBwZW5kaXggQS4xIFtTSEEzXSkuDQogICBBbmQsIHRoZSBj b3JyZXNwb25kaW5nIGNvbGxpc2lvbiBhbmQgc2Vjb25kIHByZWltYWdlIHJlc2lzdGFuY2UNCiAg IHN0cmVuZ3RocyBmb3IgU0hBS0UyNTYgYXJlIG1pbihkLzIsMjU2KSBhbmQgbWluKGQsMjU2KSBi aXRzDQogICByZXNwZWN0aXZlbHkuDQoNCjxtZ2x0Pg0Kc2luY2Ugd2UgYXJlIGludHJvZHVjaW5n IGQgaW4gdGhpcyBzZWN0aW9uIGFuZCB0aGUgc3BlY2lmaWNhdGlvbiBmaXhlcyBkIGxhdGVyLCB3 ZSBtYXkgZml4IGQgaGVyZSBhbmQgbGlzdCB0aGUgYXNzb2NpYXRlZCBzZWN1cml0eSBmb3IgdGhl IGZpeGVkIHZhbHVlLg0KDQpJIHdvdWxkIGFsc28gc3VnZ2VzdCB0aGF0IGFkZGl0aW9uYWwgcmVz aXN0YW5jZSBjb25zaWRlcmF0aW9ucyBiZSBtZW50aW9uZWQgaW4gdGhlIHNlY3VyaXR5IGNvbnNp ZGVyYXRpb24gd2l0aCBhIHJlZmVyZW5jZSB0byBpdCBpbiB0aGUgaW50cm9kdWN0aW9uLiBBZGRp dGlvbmFsIGNvbnNpZGVyYXRpb24gd291bGQgYWxzbyBwcm92aWRlIHByZWltYWdlIHJlc2lzdGFu Y2UgYW5kIGV4dGVuZHMgdGhlIGNvbnNpZGVyYXRpb25zIHJlZ2FyZGluZyAxMjgvMjU2IGJpdCBz ZWN1cml0eSBhbmQgcG9zdCBxdWFudHVtIHJlc2lzdGFuY2UuDQoNCjwvbWdsdD4NCg0KICAgQSBT SEFLRSBjYW4gYmUgdXNlZCBpbiBDTVMgYXMgdGhlIG1lc3NhZ2UgZGlnZXN0IGZ1bmN0aW9uICh0 byBoYXNoDQogICB0aGUgbWVzc2FnZSB0byBiZSBzaWduZWQpIGluIFJTQVNTQS1QU1MgYW5kIEVD RFNBLCBtZXNzYWdlDQogICBhdXRoZW50aWNhdGlvbiBjb2RlIGFuZCBhcyB0aGUgbWFzayBnZW5l cmF0aW9uIGZ1bmN0aW9uIChNR0YpIGluDQogICBSU0FTU0EtUFNTLiAgVGhpcyBzcGVjaWZpY2F0 aW9uIGRlc2NyaWJlcyB0aGUgaWRlbnRpZmllcnMgZm9yIFNIQUtFcw0KICAgdG8gYmUgdXNlZCBp biBDTVMgYW5kIHRoZWlyIG1lYW5pbmcuDQoNCjMuICBJZGVudGlmaWVycw0KDQogICBUaGlzIHNl Y3Rpb24gZGVmaW5lcyBmb3VyIG5ldyBvYmplY3QgaWRlbnRpZmllcnMgKE9JRHMpIGZvciB1c2lu Zw0KICAgU0hBS0UxMjggYW5kIFNIQUtFMjU2IGluIENNUy4NCg0KPG1nbHQ+DQpJdCBpcyB1bmNs ZWFyIHRvIG1lIGlmIHRoaXMgc2VjdGlvbiBkZWZpbmVzIE9JRHMuIEluc3RlYWQsIGl0IHNlZW1z IHRvIG1lIHRoYXQgdGhlIHNlY3Rpb24gbGlzdHMgT0lEcyBmb3IgY29udmVuaWVuY2UgYnV0IHRo ZXNlIGFyZSBkZWZpbmVkIGluIG90aGVyIGRvY3VtZW50cy4NCjwvbWdsdD4NCg0KICAgVHdvIG9i amVjdCBpZGVudGlmaWVycyBmb3IgU0hBS0UxMjggYW5kIFNIQUtFMjU2IGhhc2ggZnVuY3Rpb25z IGFyZQ0KICAgZGVmaW5lZCBpbiBbc2hha2UtbmlzdC1vaWRzXSBhbmQgd2UgaW5jbHVkZSB0aGVt IGhlcmUgZm9yDQogICBjb252ZW5pZW5jZS4NCg0KICAgICBpZC1zaGFrZTEyOCBPQkpFQ1QgSURF TlRJRklFUiA6Oj0geyBqb2ludC1pc28taXR1LXQoMikNCiAgICAgICAgICBjb3VudHJ5KDE2KSB1 cyg4NDApIG9yZ2FuaXphdGlvbigxKSBnb3YoMTAxKSBjc29yKDMpDQogICAgICAgICAgbmlzdEFs Z29yaXRobSg0KSAyIDExIH0NCg0KICAgICBpZC1zaGFrZTI1NiBPQkpFQ1QgSURFTlRJRklFUiA6 Oj0geyBqb2ludC1pc28taXR1LXQoMikNCiAgICAgICAgICBjb3VudHJ5KDE2KSB1cyg4NDApIG9y Z2FuaXphdGlvbigxKSBnb3YoMTAxKSBjc29yKDMpDQogICAgICAgICAgbmlzdEFsZ29yaXRobSg0 KSAyIDEyIH0NCg0KICAgSW4gdGhpcyBzcGVjaWZpY2F0aW9uLCB3aGVuIHVzaW5nIHRoZSBpZC1z aGFrZTEyOCBvciBpZC1zaGFrZTI1Ng0KICAgYWxnb3JpdGhtIGlkZW50aWZpZXJzLCB0aGUgcGFy YW1ldGVycyBNVVNUIGJlIGFic2VudC4gIFRoYXQgaXMsIHRoZQ0KICAgaWRlbnRpZmllciBTSEFM TCBiZSBhIFNFUVVFTkNFIG9mIG9uZSBjb21wb25lbnQsIHRoZSBPSUQuDQoNCjxtZ2x0Pg0KSXQg bWlnaHQgYmUgY2xlYXJlciBpZiB0aGUgQWxnb3JpdG1JZGVudGlmaWVyIHN0cnVjdHVyZSBpcyBh ZGRlZCBmb3IgY29udmVuaWVuY2Ugb3IgcmVmZXJlbmNlZCBtYXliZSBieSBSRkM1MjgwIGluIHRo ZSBkb2N1bWVudC4NCg0KT24gdGhlIG90aGVyIGhhbmQsIEkgYW0gYWxzbyBpbmNsaW5lZCB0byB0 aGluayB0aGF0IHRoaXMgc2VjdGlvbiBtYXkgYmUgcmVwbGFjZWQgd2l0aCBhIHJlZmVyZW5jZSB0 byBsYW1wcy1wa2l4LXNoYWtlLmFuZCB0aGUgbGlzdCBvZiBpZC0qLg0KVGhpcyBjb3VsZCBiZSBv bmUgc2VudGVuY2UgaW4gdGhlIGludHJvZHVjdGlvbiA8L21nbHQ+DQoNCjQuICBVc2UgaW4gQ01T DQoNCjQuMS4gIE1lc3NhZ2UgRGlnZXN0cw0KDQogICBUaGUgaWQtc2hha2UxMjggYW5kIGlkLXNo YWtlMjU2IE9JRHMgKFNlY3Rpb24gMykgY2FuIGJlIHVzZWQgYXMgdGhlDQogICBkaWdlc3QgYWxn b3JpdGhtIGlkZW50aWZpZXJzIGxvY2F0ZWQgaW4gdGhlIFNpZ25lZERhdGEsIFNpZ25lckluZm8s DQogICBEaWdlc3RlZERhdGEsIGFuZCB0aGUgQXV0aGVudGljYXRlZERhdGEgZGlnZXN0QWxnb3Jp dGhtIGZpZWxkcyBpbiBDTVMgIHggIFtSRkM1NjUyXS4gIFRoZSBlbmNvZGluZyBNVVNUIG9taXQg dGhlIHBhcmFtZXRlcnMgZmllbGQgYW5kIHRoZQ0KDQo8bWdsdD4NCkkgbWlnaHQgYmUgbWlzc2lu ZyBvbmUgbGV2ZWwgb2YgZW5jYXBzdWxhdGlvbiwgYnV0IG15IHVuZGVyc3RhbmRpbmcgaXMgdGhh dCBkaWdlc3QgYWxnb3JpdGhtIGlkZW50aWZpZXJzIGFuZCBhbGdvcml0aG0gaWRlbnRpZmllcnMg aGF2ZSB0aGUgc2FtZSBzdHJ1Y3R1cmUuIElmIHRoYXQgaXMgY29ycmVjdCwgaXQgc2VlbXMgdGhh dCB0aGUgcmVxdWlyZW1lbnQgdG8gb21pdCB0aGUgcGFyYW1ldGVycyBpcyByZWR1bmRhbnQgd2l0 aCB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgYWxnb3JpdGhtIGlkZW50aWZpZXJzIGFzIHdlbGwgYXMg d2l0aCBsYW1wcy1wa2l4LXNoYWtlLg0KDQpJIGFtIHJlYWRpbmcgdGhlIHNlbnRlbmNlIGFzIGl0 IHByb3ZpZGVzIHNvbWUgcmVxdWlyZW1lbnRzIG9uIHRoZSBtZXNzYWdlIGZvcm1hdCAobm8gcGFy YW1ldGVycyBhcmUgcHJvdmlkZWQpIGFzIHdlbGwgYXMgdGhlIHNldHRpbmcgb2YgYW4gb3V0cHV0 IHNpemUuIEkgaW50ZXJwcmV0IHRoZSBvdXRwdXQgc2l6ZSBhcyBhIHBhcmFtZXRlciBmb3IgdGhl IG1lc3NhZ2UtZGlnZXN0aW5nIGFsZ29yaXRobSBhcyBvcHBvc2VkIGFzIGEgcGFyYW1ldGVyIHRo YXQgaXMgcHJvdmlkZWQgaW4gdGhlIG1lc3NhZ2UuIElmIHRoYXQgaXMgdGhlIGNhc2UsIHRoYXQg bWlnaHQgYmUgc3BlY2lmaWVkIGV4cGxpY2l0bHkgYW5kIG1heWJlIGluIHR3byBkaWZmZXJlbnQg c2VudGVuY2VzIGFzIHRvIGF2b2lkIGNvdXBsaW5nIHJlcXVpcmVtZW50cyBvZiBkaWZmZXJlbnQg bmF0dXJlLg0KPC9tZ2x0Pg0KDQogICBvdXRwdXQgc2l6ZSwgZCwgZm9yIHRoZSBTSEFLRTEyOCBv ciBTSEFLRTI1NiBtZXNzYWdlIGRpZ2VzdCBNVVNUIGJlDQogICAyNTYgb3IgNTEyIGJpdHMgcmVz cGVjdGl2ZWx5Lg0KDQogICBUaGUgZGlnZXN0IHZhbHVlcyBhcmUgbG9jYXRlZCBpbiB0aGUgRGln ZXN0ZWREYXRhIGZpZWxkIGFuZCB0aGUNCiAgIE1lc3NhZ2UgRGlnZXN0IGF1dGhlbnRpY2F0ZWQg YXR0cmlidXRlIGluY2x1ZGVkIGluIHRoZQ0KICAgc2lnbmVkQXR0cmlidXRlcyBvZiB0aGUgU2ln bmVkRGF0YSBzaWduZXJJbmZvLiAgSW4gYWRkaXRpb24sIGRpZ2VzdA0KICAgdmFsdWVzIGFyZSBp bnB1dCB0byBzaWduYXR1cmUgYWxnb3JpdGhtcy4gIFRoZSBkaWdlc3QgYWxnb3JpdGhtIE1VU1QN CiAgIGJlIHRoZSBzYW1lIGFzIHRoZSBtZXNzYWdlIGhhc2ggYWxnb3JpdGhtcyB1c2VkIGluIHNp Z25hdHVyZXMuDQoNCjQuMi4gIFNpZ25hdHVyZXMNCg0KICAgSW4gQ01TLCBzaWduYXR1cmUgYWxn b3JpdGhtIGlkZW50aWZpZXJzIGFyZSBsb2NhdGVkIGluIHRoZSBTaWduZXJJbmZvDQogICBzaWdu YXR1cmVBbGdvcml0aG0gZmllbGQgb2YgU2lnbmVkRGF0YSBjb250ZW50IHR5cGUgYW5kDQogICBj b3VudGVyc2lnbmF0dXJlIGF0dHJpYnV0ZS4gIFNpZ25hdHVyZSB2YWx1ZXMgYXJlIGxvY2F0ZWQg aW4gdGhlDQogICBTaWduZXJJbmZvIHNpZ25hdHVyZSBmaWVsZCBvZiBTaWduZWREYXRhIGNvbnRl bnQgdHlwZSBhbmQNCiAgIGNvdW50ZXJzaWduYXR1cmUgYXR0cmlidXRlLg0KDQogICBDb25mb3Jt aW5nIGltcGxlbWVudGF0aW9ucyB0aGF0IHByb2Nlc3MgUlNBU1NBLVBTUyBhbmQgRUNEU0Egd2l0 aA0KICAgU0hBS0Ugc2lnbmF0dXJlcyB3aGVuIHByb2Nlc3NpbmcgQ01TIGRhdGEgTVVTVCByZWNv Z25pemUgdGhlDQogICBjb3JyZXNwb25kaW5nIE9JRHMgc3BlY2lmaWVkIGluIFNlY3Rpb24gMy4N Cg0KICAgV2hlbiB1c2luZyBSU0FTU0EtUFNTIG9yIEVDRFNBIHdpdGggU0hBS0VzLCB0aGUgUlNB IG1vZHVsdXMgYW5kIEVDRFNBDQogICBjdXJ2ZSBvcmRlciBTSE9VTEQgYmUgY2hvc2VuIGluIGxp bmUgd2l0aCB0aGUgU0hBS0Ugb3V0cHV0IGxlbmd0aC4NCiAgIEluIHRoZSBjb250ZXh0IG9mIHRo aXMgZG9jdW1lbnQgU0hBS0UxMjggT0lEcyBhcmUgUkVDT01NRU5ERUQgZm9yDQogICAyMDQ4IG9y IDMwNzItYml0IFJTQSBtb2R1bHVzIG9yIGN1cnZlcyB3aXRoIGdyb3VwIG9yZGVyIG9mIDI1Ni1i aXRzLg0KICAgU0hBS0UyNTYgT0lEcyBhcmUgUkVDT01NRU5ERUQgZm9yIDQwOTYtYml0IFJTQSBt b2R1bHVzIGFuZCBoaWdoZXIgb3INCiAgIGN1cnZlcyB3aXRoIGdyb3VwIG9yZGVyIG9mIDM4NC1i aXRzIGFuZCBoaWdoZXIuDQoNCjxtZ2x0Pg0KSSBiZWxpZXZlIGEgcmVmZXJlbmNlIHRvIHRoZSBz ZWN1cml0eSBjb25zaWRlcmF0aW9uICBzaG91bGQgYmUgcHJvdmlkZWQgd2l0aCBmdXJ0aGVyIGRp c2N1c3Npb25zIG9uIHRoZSBtZWFuaW5nIG9mICAiaW4gbGluZSIuICBUaGUgc2VjdXJpdHkgY29u c2lkZXJhdGlvbiBzaG91bGQgbWF5YmUgcHJvdmlkZSBhIHJlZmVyZW5jZSB0aGF0IGNvcnJlbGF0 ZXMgc3ltbWV0cmljDQotIGFzIENNUyBjYW4gYmUgdXNlZCB3aXRoIEFFUyAtLCBmYWN0b3Jpbmcg bW9kdWx1cyBFbGxpcHRpYyBjdXJ2ZXMgYW5kIGhhc2guIFRob3VnaCB0aGUgY3VycmVudCBzZWN1 cml0eSBjb25zaWRlcmF0aW9uIHJlZmVyZW5jZSBTUDgwMC03OC00IGFuZCBTUDgwMC0xMDcsIG1h eWJlIHRoZSBmb2xsb3dpbmcgb25lcyBjb3VsZCBiZSB1c2VkIGluIHRoZSBzZWN1cml0eSBjb25z aWRlcmF0aW9uLiBUaGV5IGxvb2sgbW9yZSByZWNlbnQgYnV0IEkgaGF2ZSBub3QgZGVlcGx5IGxv b2tlZCBhdCB0aG9zZS4NCg0KKiBBbGdvcml0aG1zLCBLZXkgU2l6ZSBhbmQgUHJvdG9jb2xzIFJl cG9ydCAoMjAxOCksIEgyMDIwLUlDVC0yMDE0IOKAkyBQcm9qZWN0IDY0NTQyMSwgRDUuNCwgRUNS WVBULUNTQSwgMDIvMjAxOC4gKiBSZWNvbW1lbmRhdGlvbiBmb3IgS2V5IE1hbmFnZW1lbnQsIFNw ZWNpYWwgUHVibGljYXRpb24gODAwLTU3IFBhcnQgMSBSZXYuIDQsIE5JU1QsIDAxLzIwMTYuDQoN CjwvbWdsdD4NCg0KNC4yLjEuICBSU0FTU0EtUFNTIFNpZ25hdHVyZXMNCg0KICAgVGhlIFJTQVNT QS1QU1MgYWxnb3JpdGhtIGlzIGRlZmluZWQgaW4gW1JGQzgwMTddLiAgV2hlbiBpZC1SU0FTU0Et DQogICBQU1MtU0hBS0UxMjggb3IgaWQtUlNBU1NBLVBTUy1TSEFLRTI1NiBzcGVjaWZpZWQgaW4g U2VjdGlvbiAzIGlzDQogICB1c2VkLCB0aGUgZW5jb2RpbmcgTVVTVCBvbWl0IHRoZSBwYXJhbWV0 ZXJzIGZpZWxkLiAgVGhhdCBpcywgdGhlDQogICBBbGdvcml0aG1JZGVudGlmaWVyIFNIQUxMIGJl IGEgU0VRVUVOQ0Ugb2Ygb25lIGNvbXBvbmVudCwgaWQtUlNBU1NBLQ0KICAgUFNTLVNIQUtFMTI4 IG9yIGlkLVJTQVNTQS1QU1MtU0hBS0UyNTYuICBbUkZDNDA1NV0gZGVmaW5lcyBSU0FTU0EtDQog ICBQU1MtcGFyYW1zIHRoYXQgYXJlIHVzZWQgdG8gZGVmaW5lIHRoZSBhbGdvcml0aG1zIGFuZCBp bnB1dHMgdG8gdGhlDQogICBhbGdvcml0aG0uICBUaGlzIHNwZWNpZmljYXRpb24gZG9lcyBub3Qg dXNlIHBhcmFtZXRlcnMgYmVjYXVzZSB0aGUNCiAgIGhhc2gsIG1hc2sgZ2VuZXJhdGlvbiBhbGdv cml0aG0sIHRyYWlsZXIgYW5kIHNhbHQgYXJlIGVtYmVkZGVkIGluIHRoZQ0KICAgT0lEIGRlZmlu aXRpb24uDQoNCjxtZ2x0Pg0KVGhpcyBpcyBhIHNpbWlsYXIgY29tbWVudCBhcyB0aGUgb25lIHBy b3ZpZGVkIGVhcmxpZXIuIEl0IGRvZXMgbm90IHNlZW0gdG8gbWUgdGhhdCB0aGlzIGRvY3VtZW50 ICJzcGVjaWZpZXMiIChpbiBzZWN0aW9uIDMpIGFsZ29yaXRobXMuIEl0IHNlZW1zIHRvIG1lIHRo ZXNlIGFsZ29yaXRobXMgYXJlIHByb3ZpZGVkIGZvciBjb252ZW5pZW5jZSBidXQgYXJlIHNwZWNp ZmllZCBpbiBwa2l4LXNoYWtlLg0KDQpTaW1pbGFybHksIHRoZSBhYnNlbmNlIG9mIHBhcmFtZXRl ciBkb2VzIG5vdCBzZWVtcyB0byBtZSBuZWNlc3NhcnkgaGVyZQ0KLSB1bmxlc3MgSSBhbSBtaXNz aW5nIHNvbWV0aGluZy4gSXQgc2VlbXMgdGhhdCBNVVNUIGFuZCBTSEFMTCBhcmUgYWltaW5nIGF0 IHByZXZlbnRpbmcgdGhlIE5VTEwgcGFyYW1ldGVyLCBJIGFtIHdvbmRlcmluZyBpZiB0aGVyZSBh cmUgYW55IHJlYXNvbnMgZm9yIGhhdmluZyBkaWZmZXJlbnQgdGVybXMuDQoNClRoZSBleHBsYW5h dGlvbiBtYXkgYmUgbW92ZWQgdG8gc2VjdGlvbiAzLg0KDQo8L21nbHQ+DQoNCiAgIFRoZSBoYXNo IGFsZ29yaXRobSB0byBoYXNoIGEgbWVzc2FnZSBiZWluZyBzaWduZWQgYW5kIHRoZSBoYXNoDQog ICBhbGdvcml0aG0gYXMgdGhlIG1hc2sgZ2VuZXJhdGlvbiBmdW5jdGlvbiB1c2VkIGluIFJTQVNT QS1QU1MgTVVTVCBiZQ0KICAgdGhlIHNhbWUsIFNIQUtFMTI4IG9yIFNIQUtFMjU2IHJlc3BlY3Rp dmVseS4gIFRoZSBvdXRwdXQtbGVuZ3RoIG9mDQogICB0aGUgaGFzaCBhbGdvcml0aG0gd2hpY2gg aGFzaGVzIHRoZSBtZXNzYWdlIFNIQUxMIGJlIDMyIG9yIDY0IGJ5dGVzDQogICByZXNwZWN0aXZl bHkuDQoNCjxtZ2x0Pg0KSSBzdWdnZXN0IHdlIHVzZSBieXRlcyBvciBiaXRzIGluIHRoZSBkb2N1 bWVudC4NCjwvbWdsdD4NCg0KNC4yLjIuICBFQ0RTQSBTaWduYXR1cmVzDQoNCiAgIFRoZSBFbGxp cHRpYyBDdXJ2ZSBEaWdpdGFsIFNpZ25hdHVyZSBBbGdvcml0aG0gKEVDRFNBKSBpcyBkZWZpbmVk IGluDQogICBbWDkuNjJdLiAgV2hlbiB0aGUgaWQtZWNkc2Etd2l0aC1zaGFrZTEyOCBvciBpZC1l Y2RzYS13aXRoLXNoYWtlMjU2DQogICAoc3BlY2lmaWVkIGluIFNlY3Rpb24gMykgYWxnb3JpdGht IGlkZW50aWZpZXIgYXBwZWFycywgdGhlIHJlc3BlY3RpdmUNCiAgIFNIQUtFIGZ1bmN0aW9uIGlz IHVzZWQgYXMgdGhlIGhhc2guICBUaGUgZW5jb2RpbmcgTVVTVCBvbWl0IHRoZQ0KICAgcGFyYW1l dGVycyBmaWVsZC4gIFRoYXQgaXMsIHRoZSBBbGdvcml0aG1JZGVudGlmaWVyIFNIQUxMIGJlIGEN CiAgIFNFUVVFTkNFIG9mIG9uZSBjb21wb25lbnQsIHRoZSBPSUQgaWQtZWNkc2Etd2l0aC1zaGFr ZTEyOCBvciBpZC0NCiAgIGVjZHNhLXdpdGgtc2hha2UyNTYuDQoNCjxtZ2x0Pg0Kc2FtZSBjb21t ZW50IHJlZ2FyZGluZyB0aGUgcGFyYW1ldGVyIGZpZWxkIDwvbWdsdD4NCg0KNC4zLiAgUHVibGlj IEtleXMNCg0KICAgVGhlIGlkZW50aWZpZXIgcGFyYW1ldGVycywgYXMgZXhwbGFpbmVkIGluIFNl Y3Rpb24gMywgTVVTVCBiZSBhYnNlbnQuDQo8bWdsdD4NClNhbWUgY29tbWVudCBhcyBhYm92ZS4N CjwvbWdsdD4NCjQuNC4gIE1lc3NhZ2UgQXV0aGVudGljYXRpb24gQ29kZXMNCg0KNi4gIFNlY3Vy aXR5IENvbnNpZGVyYXRpb25zDQoNCiAgIFRoaXMgZG9jdW1lbnQgdXBkYXRlcyBbUkZDMzM3MF0u ICBUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2VjdGlvbg0KICAgb2YgdGhhdCBkb2N1bWVu dCBhcHBsaWVzIHRvIHRoaXMgc3BlY2lmaWNhdGlvbiBhcyB3ZWxsLg0KDQogICBOSVNUIGhhcyBk ZWZpbmVkIGFwcHJvcHJpYXRlIHVzZSBvZiB0aGUgaGFzaCBmdW5jdGlvbnMgaW4gdGVybXMgb2YN CiAgIHRoZSBhbGdvcml0aG0gc3RyZW5ndGhzIGFuZCBleHBlY3RlZCB0aW1lIGZyYW1lcyBmb3Ig c2VjdXJlIHVzZSBpbg0KICAgU3BlY2lhbCBQdWJsaWNhdGlvbnMgKFNQcykgW1NQODAwLTc4LTRd IGFuZCBbU1A4MDAtMTA3XS4gIFRoZXNlDQogICBkb2N1bWVudHMgY2FuIGJlIHVzZWQgYXMgZ3Vp ZGVzIHRvIGNob29zZSBhcHByb3ByaWF0ZSBrZXkgc2l6ZXMgZm9yDQogICB2YXJpb3VzIHNlY3Vy aXR5IHNjZW5hcmlvcy4NCg0KICAgV2hlbiBtb3JlIHRoYW4gdHdvIHBhcnRpZXMgc2hhcmUgdGhl IHNhbWUgbWVzc2FnZS1hdXRoZW50aWNhdGlvbiBrZXksDQogICBkYXRhIG9yaWdpbiBhdXRoZW50 aWNhdGlvbiBpcyBub3QgcHJvdmlkZWQuICBBbnkgcGFydHkgdGhhdCBrbm93cyB0aGUNCiAgIG1l c3NhZ2UtYXV0aGVudGljYXRpb24ga2V5IGNhbiBjb21wdXRlIGEgdmFsaWQgTUFDLCB0aGVyZWZv cmUgdGhlDQogICBjb250ZW50IGNvdWxkIG9yaWdpbmF0ZSBmcm9tIGFueSBvbmUgb2YgdGhlIHBh cnRpZXMuDQoNCjxtZ2x0Pg0KSSB3b3VsZCBzdWdnZXN0IHRvIGFkZCBzb21lIGNvbnNpZGVyYXRp b25zIG9uIHJlc2lzdGFuY2Ugd2l0aCBwb3N0IHF1YW50dW0gY29tcHV0ZXJzLg0KPC9tZ2x0Pg0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpTcGFz bSBtYWlsaW5nIGxpc3QNClNwYXNtQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NwYXNtDQo= From nobody Sun Jul 7 13:29:08 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 34452120094; Sun, 7 Jul 2019 13:28:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Christopher Wood via Datatracker To: Cc: draft-ietf-tram-turnbis.all@ietf.org, ietf@ietf.org, tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Christopher Wood Message-ID: <156253133809.549.13521510978566357744@ietfa.amsl.com> Date: Sun, 07 Jul 2019 13:28:58 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-tram-turnbis-27 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: Sun, 07 Jul 2019 20:28:59 -0000 Reviewer: Christopher Wood 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. The summary of the review is: Ready with nits Summary: In general, the document is well written and clearly founded in operational experience. The security considerations are thorough, providing examples where necessary to highlight important problem areas. It draws a clear line between issues best addressed by applications outside of TURN, and provides sufficient detail for those issues in scope. My comments and questions are, hopefully, mostly nits. General comments: - TURN server authentication in the case of (D)TLS is underspecified. Are servers assumed to have WebPKI certificates, OOB-trusted raw public keys, or something else? Is there a preferred form of authentication? Relatedly, in Section 3.2, how do clients authenticate the server? - Section 3.7: Could TURN servers not chunk data from stream-oriented transports (TCP or TLS) to a preferred MTU size before relaying to peers? Specifically, there are likely some cases wherein the server could deal with the client data messages larger than the recommended 500B limit. On that point, should servers even accept data larger than this recommended size? - Section 3.9: There may be cases where the TLS connection post TCP connection establishment fails. It would therefore seems prudent to not declare victory for one connection over the other until TLS connects, too. - Section 3 could benefit from a subsection on replays and the nonce role. In particular, as later discussed in the security considerations, some of these attacks are not new to TURN and should therefore be dealt with by the application protocol (SRTP). This section might also describe nonce rotation policies with more specificity, as this is underspecified in the document. - Section 3 could also benefit from discussion about cleartext versus encryption transports between clients and servers. Encrypting the nonce, username, realm, etc., among other things, has obvious benefits. - Why are SOFTWARE and FINGERPRINT attributes recommended? It seems like clients should be discouraged from sending these if anything, especially if not used to make allocation decisions on the server. - Section 5: When servers receive data that exceeds an allocation’s bandwidth quota, servers silently discard this data. This means there’s no allocation-based flow control mechanism between client and server beyond what’s provided by the transport protocol, right? This seems fine, though perhaps some discussion of why this design decision was made would be helpful. For example, I could imagine explicit signals from servers to clients that indicate server state would reveal information about other allocations on the server, which might be problematic. - Section 7.2 suggests that servers can redirect client allocation requests to other servers. Can this create a loop, wherein two TURN servers redirect to one another? Moreover, is it acceptable for one TURN server to redirect to an unrelated TURN server? (It should be made clear here that these responses are authenticated, as otherwise it would be possible for an on-path adversary to redirect allocation requests to a server it owns.) - Section 21.1.2: Use of (D)TLS doesn’t help against dictionary attacks much, since presumably there’s low entropy in usernames and passwords alike. Thus, I question whether this is a “stronger” mitigation. - Section 12.1.6: “username” and “realm” are not considered sensitive? They seem sensitive to me. - As an extension, it seems possible to improve on what’s in STUN. For example, it may be worthwhile, here or elsewhere, to update STUN’s long term credential key derivation process (MD5(username + realm + password)) to something a bit more modern. This is quite likely out of scope, though in the context of client authentication it seems worth mentioning that TURN is limited to the mechanisms provided by STUN. Nits and other comments: - Section 2: “message-digest” is undefined in the Nonce definition. - Section 3: It’s probably worth citing RFC8446 as the recommended version of TLS. - Section 3.4: It might be worth mentioning that use of (D)TLS for the client-to-server transport mitigates the need for Send and Data authentication. - Section 3.4: What does “proper security” mean? - Figure 4: Adding another message exchange wherein a channel message is sent without a prior ChannelBind request would be useful to highlight this dependency and expected behavior from clients and servers. - Section 3.6: Another benefit of this user space design decision is use of (D)TLS links. - Section 5: Where did the 40 second request buffer timeout come from? Adding some details might help. - Section 6: “secure hash” is undefined, though presumably what is meant is a cryptographic hash with collision resistance. It would be good to clarify this requirement. - Section 7.4: What is the retry behavior if allocation requests timeout? - Section 12.5: The STUN requirement for 4-byte alignment should be cited when discussing the TCP and TLS padding requirement. - Section 15: Typo “DON’T FRAGMENT”. From nobody Mon Jul 8 07:19:04 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD0A1201EC; Mon, 8 Jul 2019 07:18:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 (1024-bit key) header.d=mcafee.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 483ZFm5wqlbF; Mon, 8 Jul 2019 07:18:46 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (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 2CAE41201CD; Mon, 8 Jul 2019 07:18:45 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1562594892; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=GETm54WgCBWcPpWyWH+NxVojeB5cjpXhTG2ith 8H9+g=; b=OQwX5+D+kEIXRMn7K2Nq4GmtzrypnzY0yuJV3OEL iuXPc3NAEbjLriA7ClHAGlhG+R9FdUqlKFEJOOyihopGfYtQ4c YubIcqFrU/kxOgf0g+Mzeg8udOJ8zCVLsQZODHdATf1SXayq1Q y5Un2+cp2IWnh728JaVEyB4ALd5tdGc= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 607d_9297_f2b6f823_38b6_40ce_a733_aeaf1269efd4; Mon, 08 Jul 2019 08:08:11 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 8 Jul 2019 08:18:28 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Mon, 8 Jul 2019 08:18:28 -0600 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (10.44.176.242) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 8 Jul 2019 08:18:26 -0600 Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB1403.namprd16.prod.outlook.com (10.173.215.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.18; Mon, 8 Jul 2019 14:18:26 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2052.019; Mon, 8 Jul 2019 14:18:26 +0000 From: "Konda, Tirumaleswar Reddy" To: Christopher Wood , "secdir@ietf.org" CC: "draft-ietf-tram-turnbis.all@ietf.org" , "ietf@ietf.org" , "tram@ietf.org" Thread-Topic: [tram] Secdir last call review of draft-ietf-tram-turnbis-27 Thread-Index: AQHVNQMAJeymFhPVnEO1ky4wx5pqrabAcMBw Date: Mon, 8 Jul 2019 14:18:26 +0000 Message-ID: References: <156253133809.549.13521510978566357744@ietfa.amsl.com> In-Reply-To: <156253133809.549.13521510978566357744@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.8 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 933ce875-82a7-4a58-e040-08d703af2494 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB1403; x-ms-traffictypediagnostic: DM5PR16MB1403: x-ms-exchange-purlcount: 11 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00922518D8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(136003)(39860400002)(346002)(376002)(32952001)(51914003)(13464003)(199004)(189003)(5660300002)(76116006)(4326008)(73956011)(52536014)(66446008)(81166006)(14454004)(72206003)(186003)(66946007)(478600001)(476003)(81156014)(26005)(64756008)(6246003)(86362001)(966005)(8676002)(66476007)(66556008)(76176011)(53546011)(71200400001)(2906002)(8936002)(25786009)(7696005)(55016002)(486006)(71190400001)(66066001)(9686003)(6506007)(6306002)(3846002)(99286004)(68736007)(6116002)(229853002)(33656002)(2501003)(316002)(54906003)(305945005)(446003)(102836004)(80792005)(256004)(5024004)(74316002)(110136005)(14444005)(7736002)(6436002)(53936002)(11346002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1403; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: GVZ/nyGTSnm/7dXWzIcqvhwsBj70cblOI7OGBk81+wmbWi6LfXECiY6gJEIMXLiqVp/irlsPFdZd1eMc9qd+1yjWBl+SG3P1JbkJc0t39Tue295/DTW+NS7cSVDrRWh3HmT+YqxnGULvA47vROlZLR3y+JtlWPkxCFXmBJjDuEmSv1D8UWs14oVPZEjdtCRHhiVV3tMJwl3cBoLyj89xKHd8k9Ms5nDDd37Mw16OL3KPIGkdOSh3SHj6RdOoc00TCbMu23O9bwqt900g92wAEs3HAqjEQV3ixTfPR+l7cdK9pZgkOYhblmqTFlif0Vgw0XmN+l4EvttQ13/tw6QyiYGKvfNTPwTkHoOOFh6XVARgWZa8MuvB4ngypW6D6uH5C4kVv+SzVOragZjlcDUZVRdxKKzQtdfd4XtUqwLwEME= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 933ce875-82a7-4a58-e040-08d703af2494 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Jul 2019 14:18:26.1669 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1403 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6585> : inlines <7115> : streams <1826746> : uri <2865133> Archived-At: Subject: Re: [secdir] [tram] Secdir last call review of draft-ietf-tram-turnbis-27 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, 08 Jul 2019 14:18:51 -0000 SGkgQ2hyaXN0b3BoZXIsDQoNClRoYW5rcyBmb3IgdGhlIGRldGFpbGVkIHJldmlldy4gUGxlYXNl IHNlZSBpbmxpbmUNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiB0cmFt IDx0cmFtLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBDaHJpc3RvcGhlciBXb29kIHZp YQ0KPiBEYXRhdHJhY2tlcg0KPiBTZW50OiBNb25kYXksIEp1bHkgOCwgMjAxOSAxOjU5IEFNDQo+ IFRvOiBzZWNkaXJAaWV0Zi5vcmcNCj4gQ2M6IGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLmFsbEBp ZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsgdHJhbUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBbdHJhbV0g U2VjZGlyIGxhc3QgY2FsbCByZXZpZXcgb2YgZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMjcNCj4g DQo+IFRoaXMgZW1haWwgb3JpZ2luYXRlZCBmcm9tIG91dHNpZGUgb2YgdGhlIG9yZ2FuaXphdGlv bi4gRG8gbm90IGNsaWNrIGxpbmtzIG9yDQo+IG9wZW4gYXR0YWNobWVudHMgdW5sZXNzIHlvdSBy ZWNvZ25pemUgdGhlIHNlbmRlciBhbmQga25vdyB0aGUgY29udGVudCBpcw0KPiBzYWZlLg0KPiAN Cj4gUmV2aWV3ZXI6IENocmlzdG9waGVyIFdvb2QNCj4gUmV2aWV3IHJlc3VsdDogSGFzIE5pdHMN Cj4gDQo+IEkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3Vy aXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZw0KPiBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRv Y3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuIFRoZXNlDQo+IGNvbW1lbnRzIHdl cmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVh DQo+IGRpcmVjdG9ycy4NCj4gRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0 cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55DQo+IG90aGVyIGxhc3QgY2FsbCBjb21t ZW50cy4NCj4gDQo+IFRoZSBzdW1tYXJ5IG9mIHRoZSByZXZpZXcgaXM6IFJlYWR5IHdpdGggbml0 cw0KPiANCj4gU3VtbWFyeToNCj4gDQo+IEluIGdlbmVyYWwsIHRoZSBkb2N1bWVudCBpcyB3ZWxs IHdyaXR0ZW4gYW5kIGNsZWFybHkgZm91bmRlZCBpbiBvcGVyYXRpb25hbA0KPiBleHBlcmllbmNl LiBUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgYXJlIHRob3JvdWdoLCBwcm92aWRpbmcgZXhh bXBsZXMNCj4gd2hlcmUgbmVjZXNzYXJ5IHRvIGhpZ2hsaWdodCBpbXBvcnRhbnQgcHJvYmxlbSBh cmVhcy4gSXQgZHJhd3MgYSBjbGVhciBsaW5lDQo+IGJldHdlZW4gaXNzdWVzIGJlc3QgYWRkcmVz c2VkIGJ5IGFwcGxpY2F0aW9ucyBvdXRzaWRlIG9mIFRVUk4sIGFuZA0KPiBwcm92aWRlcyBzdWZm aWNpZW50IGRldGFpbCBmb3IgdGhvc2UgaXNzdWVzIGluIHNjb3BlLiBNeSBjb21tZW50cyBhbmQN Cj4gcXVlc3Rpb25zIGFyZSwgaG9wZWZ1bGx5LCBtb3N0bHkgbml0cy4NCj4gDQo+IEdlbmVyYWwg Y29tbWVudHM6DQo+IA0KPiAtIFRVUk4gc2VydmVyIGF1dGhlbnRpY2F0aW9uIGluIHRoZSBjYXNl IG9mIChEKVRMUyBpcyB1bmRlcnNwZWNpZmllZC4gQXJlDQo+IHNlcnZlcnMgYXNzdW1lZCB0byBo YXZlIFdlYlBLSSBjZXJ0aWZpY2F0ZXMsIE9PQi10cnVzdGVkIHJhdyBwdWJsaWMga2V5cywNCj4g b3Igc29tZXRoaW5nIGVsc2U/IElzIHRoZXJlIGEgcHJlZmVycmVkIGZvcm0gb2YgYXV0aGVudGlj YXRpb24/IA0KPiBSZWxhdGVkbHksIGluDQo+IFNlY3Rpb24gMy4yLCBob3cgZG8gY2xpZW50cyBh dXRoZW50aWNhdGUgdGhlIHNlcnZlcj8gDQoNClNlcnZlciBjZXJ0aWZpY2F0ZSB2YWxpZGF0aW9u IGlzIGRpc2N1c3NlZCBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10 cmFtLXN0dW5iaXMtMjEjc2VjdGlvbi02LjIuMy4gIEkgaGF2ZSBtb2RpZmllZCB0aGUgdGV4dCBh cyBmb2xsb3dzOg0KDQpJZiAoRClUTFMgdHJhbnNwb3J0IGlzIHVzZWQgYmV0d2VlbiB0aGUgVFVS TiBjbGllbnQgYW5kIHRoZSBUVVJOIHNlcnZlciwgdGhlIGNpcGhlciBzdWl0ZXMsDQpzZXJ2ZXIg Y2VydGlmaWNhdGUgdmFsaWRhdGlvbiBhbmQgYXV0aGVudGljYXRpb24gb2YgVFVSTiBzZXJ2ZXIg YXJlDQpkaXNjdXNzZWQgaW4gU2VjdGlvbiA2LjIuMyBvZiBbSS1ELmlldGYtdHJhbS1zdHVuYmlz XQ0KDQo+LSBTZWN0aW9uIDMuNzogQ291bGQNCj4gVFVSTiBzZXJ2ZXJzIG5vdCBjaHVuayBkYXRh IGZyb20gc3RyZWFtLW9yaWVudGVkIHRyYW5zcG9ydHMgKFRDUCBvciBUTFMpDQo+IHRvIGEgcHJl ZmVycmVkIE1UVSBzaXplIGJlZm9yZSByZWxheWluZyB0byBwZWVycz8gDQo+IFNwZWNpZmljYWxs eSwgdGhlcmUgYXJlIGxpa2VseQ0KPiBzb21lIGNhc2VzIHdoZXJlaW4gdGhlIHNlcnZlciBjb3Vs ZCBkZWFsIHdpdGggdGhlIGNsaWVudCBkYXRhIG1lc3NhZ2VzDQo+IGxhcmdlciB0aGFuIHRoZSBy ZWNvbW1lbmRlZCA1MDBCIGxpbWl0LiBPbiB0aGF0IHBvaW50LCBzaG91bGQgc2VydmVycyBldmVu DQo+IGFjY2VwdCBkYXRhIGxhcmdlciB0aGFuIHRoaXMgcmVjb21tZW5kZWQgc2l6ZSA/IC0gDQoN ClBsZWFzZSBzZWUgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJhbS10 dXJuYmlzLTI3I3NlY3Rpb24tMTUgZm9yIFRDUC10by1VRFAgcmVsYXkuIElmIHRoZSBQTVRVIGlz IG5vdCBrbm93biwgYW5kIG9uIGxlZ2FjeSBvciBvdGhlcndpc2UgdW51c3VhbCBuZXR3b3Jrcywg DQo1MDAgYnl0ZSBsaW1pdCBmb3IgYXBwbGljYXRpb24gZGF0YSBpcyByZWNvbW1lbmRlZC4NCg0K PiBTZWN0aW9uIDMuOTogVGhlcmUgbWF5IGJlDQo+IGNhc2VzIHdoZXJlIHRoZSBUTFMgY29ubmVj dGlvbiBwb3N0IFRDUCBjb25uZWN0aW9uIGVzdGFibGlzaG1lbnQgZmFpbHMuIEl0DQo+IHdvdWxk IHRoZXJlZm9yZSBzZWVtcyBwcnVkZW50IHRvIG5vdCBkZWNsYXJlIHZpY3RvcnkgZm9yIG9uZSBj b25uZWN0aW9uDQo+IG92ZXIgdGhlIG90aGVyIHVudGlsIFRMUyBjb25uZWN0cywgdG9vLiAtDQoN CkFncmVlZCwgRXJpYyAoYXMgcGFydCBvZiBJU0VHIHJldmlldykgc3VnZ2VzdGVkIHRvIHNpbXBs aWZ5IHRoZSB0ZXh0LiBJIGhhdmUgdXBkYXRlZCB0aGUgdGV4dCBhcyBmb2xsb3dzOg0KDQogICBv ICBGb3IgVENQIG9yIFRMUy1vdmVyLVRDUCwgdGhlIHJlc3VsdHMgb2YgdGhlIEhhcHB5IEV5ZWJh bGxzDQogICAgICBwcm9jZWR1cmUgW1JGQzgzMDVdIGFyZSB1c2VkIGJ5IHRoZSBUVVJOIGNsaWVu dCBmb3Igc2VuZGluZyBpdHMNCiAgICAgIFRVUk4gbWVzc2FnZXMgdG8gdGhlIHNlcnZlci4NCg0K PiBTZWN0aW9uIDMgY291bGQgYmVuZWZpdCBmcm9tIGENCj4gc3Vic2VjdGlvbiBvbiByZXBsYXlz IGFuZCB0aGUgbm9uY2Ugcm9sZS4gSW4gcGFydGljdWxhciwgYXMgbGF0ZXIgZGlzY3Vzc2VkIGlu DQo+IHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucywgc29tZSBvZiB0aGVzZSBhdHRhY2tzIGFy ZSBub3QgbmV3IHRvIFRVUk4gYW5kDQo+IHNob3VsZCB0aGVyZWZvcmUgYmUgZGVhbHQgd2l0aCBi eSB0aGUgYXBwbGljYXRpb24gcHJvdG9jb2wgKFNSVFApLiBUaGlzDQo+IHNlY3Rpb24gbWlnaHQg YWxzbyBkZXNjcmliZSBub25jZSByb3RhdGlvbiBwb2xpY2llcyB3aXRoIG1vcmUgc3BlY2lmaWNp dHksIGFzDQo+IHRoaXMgaXMgdW5kZXJzcGVjaWZpZWQgaW4gdGhlIGRvY3VtZW50LiANCg0KSXQg aXMgZGlzY3Vzc2VkIGluIFNlY3Rpb24gNSBpbiB0aGUgc3BlY2lmaWNhdGlvbiwgdGhlIHNlcnZl ciBzaG91bGQgZXhwaXJlIHRoZSBub25jZSBhdCBsZWFzdCBvbmNlIGV2ZXJ5IGhvdXIgZHVyaW5n IHRoZSBsaWZldGltZSBvZiB0aGUgYWxsb2NhdGlvbi4NCg0KPi0gU2VjdGlvbiAzIGNvdWxkIGFs c28gYmVuZWZpdCBmcm9tDQo+IGRpc2N1c3Npb24gYWJvdXQgY2xlYXJ0ZXh0IHZlcnN1cyBlbmNy eXB0aW9uIHRyYW5zcG9ydHMgYmV0d2VlbiBjbGllbnRzIGFuZA0KPiBzZXJ2ZXJzLg0KDQpJdCBp cyBkaXNjdXNzZWQgaW4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJh bS10dXJuYmlzLTI3I3NlY3Rpb24tMjEuMS42LiANCg0KPiBFbmNyeXB0aW5nIHRoZSBub25jZSwg dXNlcm5hbWUsIHJlYWxtLCBldGMuLCBhbW9uZyBvdGhlciB0aGluZ3MsIGhhcw0KPiBvYnZpb3Vz IGJlbmVmaXRzLiAtIFdoeSBhcmUgU09GVFdBUkUgYW5kIEZJTkdFUlBSSU5UIGF0dHJpYnV0ZXMN Cj4gcmVjb21tZW5kZWQ/ICBJdCBzZWVtcyBsaWtlIGNsaWVudHMgc2hvdWxkIGJlIGRpc2NvdXJh Z2VkIGZyb20gc2VuZGluZw0KPiB0aGVzZSBpZiBhbnl0aGluZywgZXNwZWNpYWxseSBpZiBub3Qg dXNlZCB0byBtYWtlIGFsbG9jYXRpb24gZGVjaXNpb25zIG9uIHRoZQ0KPiBzZXJ2ZXIuIA0KDQpV c2VybmFtZSBtYXkgbm90IGJlIHRoZSB1c2VyIGlkZW50aXR5LCBQbGVhc2Ugc2VlIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM3NjM1KSwgSXQgY291bGQgYmUgYW4gZXBoZW1lcmFsIGFu ZCB1bmlxdWUga2V5IGlkZW50aWZpZXIuIEZ1cnRoZXIsIHVzZXJuYW1lIGNhbiBiZSBhbm9ueW1p emVkIChwbGVhc2Ugc2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRy YW0tc3R1bmJpcy0yMSNzZWN0aW9uLTE0LjQpLiAgIA0KU09GVFdBUkUgYW5kIEZJTkdFUlBSSU5U IGF0dHJpYnV0ZXMgYXJlIGRlZmluZWQgaW4gdGhlIFNUVU4gc3BlY2lmaWNhdGlvbiwgc2VlIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0tc3R1bmJpcy0yMS4gDQoN Ci0gU2VjdGlvbiA1OiBXaGVuIHNlcnZlcnMgcmVjZWl2ZSBkYXRhIHRoYXQgZXhjZWVkcyBhbiBh bGxvY2F0aW9u4oCZcw0KPiBiYW5kd2lkdGggcXVvdGEsIHNlcnZlcnMgc2lsZW50bHkgZGlzY2Fy ZCB0aGlzIGRhdGEuIFRoaXMgbWVhbnMgdGhlcmXigJlzIG5vDQo+IGFsbG9jYXRpb24tYmFzZWQg ZmxvdyBjb250cm9sIG1lY2hhbmlzbSBiZXR3ZWVuIGNsaWVudCBhbmQgc2VydmVyIGJleW9uZA0K PiB3aGF04oCZcyBwcm92aWRlZCBieSB0aGUgdHJhbnNwb3J0IHByb3RvY29sLCByaWdodD8gDQoN ClllcywgVURQIGRvZXMgbm90IGluY2x1ZGUgYSBjb25nZXN0aW9uIGNvbnRyb2wgbWVjaGFuaXNt LiAgDQoNCj4gVGhpcyBzZWVtcyBmaW5lLCB0aG91Z2gNCj4gcGVyaGFwcyBzb21lIGRpc2N1c3Np b24gb2Ygd2h5IHRoaXMgZGVzaWduIGRlY2lzaW9uIHdhcyBtYWRlIHdvdWxkIGJlDQo+IGhlbHBm dWwuIEZvciBleGFtcGxlLCBJIGNvdWxkIGltYWdpbmUgZXhwbGljaXQgc2lnbmFscyBmcm9tIHNl cnZlcnMgdG8gY2xpZW50cw0KPiB0aGF0IGluZGljYXRlIHNlcnZlciBzdGF0ZSB3b3VsZCByZXZl YWwgaW5mb3JtYXRpb24gYWJvdXQgb3RoZXIgYWxsb2NhdGlvbnMNCj4gb24gdGhlIHNlcnZlciwg d2hpY2ggbWlnaHQgYmUgcHJvYmxlbWF0aWMuIC0NCg0KVGhlIGVycm9ycyA0ODYgKEFsbG9jYXRp b24gUXVvdGEgRXhjZWVkZWQpIG9yIDUwOCAoSW5zdWZmaWNpZW50IENhcGFjaXR5KSAgZG8gbm90 IHJldmVhbCBpbmZvcm1hdGlvbiBvZiB3aGljaCBvdGhlciB1c2VycyBhcmUgdXNpbmcgdGhlIFRV Uk4gc2VydmVyLiANCg0KPiBTZWN0aW9uIDcuMiBzdWdnZXN0cyB0aGF0DQo+IHNlcnZlcnMgY2Fu IHJlZGlyZWN0IGNsaWVudCBhbGxvY2F0aW9uIHJlcXVlc3RzIHRvIG90aGVyIHNlcnZlcnMuIENh biB0aGlzDQo+IGNyZWF0ZSBhIGxvb3AsIHdoZXJlaW4gdHdvIFRVUk4gc2VydmVycyByZWRpcmVj dCB0byBvbmUgYW5vdGhlcj8gDQoNClRoZSBjbGllbnQgZGV0ZWN0IGFuZCBzdG9wIHRoZSBsb29w LCBpdCBpcyBzaW1pbGFyIHRvIEhUVFAgcmVkaXJlY3Rpb24uDQoNCj4gTW9yZW92ZXIsDQo+IGlz IGl0IGFjY2VwdGFibGUgZm9yIG9uZSBUVVJOIHNlcnZlciB0byByZWRpcmVjdCB0byBhbiB1bnJl bGF0ZWQgVFVSTiBzZXJ2ZXI/DQo+IChJdCBzaG91bGQgYmUgbWFkZSBjbGVhciBoZXJlIHRoYXQg dGhlc2UgcmVzcG9uc2VzIGFyZSBhdXRoZW50aWNhdGVkLCBhcw0KPiBvdGhlcndpc2UgaXQgd291 bGQgYmUgcG9zc2libGUgZm9yIGFuIG9uLXBhdGggYWR2ZXJzYXJ5IHRvIHJlZGlyZWN0IGFsbG9j YXRpb24NCj4gcmVxdWVzdHMgdG8gYSBzZXJ2ZXIgaXQgb3ducy4pIA0KDQpJdCBpcyBhbHJlYWR5 IGRpc2N1c3NlZCBpbiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFt LXN0dW5iaXMtMjEjc2VjdGlvbi0xMCANCg0KPiAtIFNlY3Rpb24NCj4gMjEuMS4yOiBVc2Ugb2Yg KEQpVExTIGRvZXNu4oCZdCBoZWxwIGFnYWluc3QgZGljdGlvbmFyeSBhdHRhY2tzIG11Y2gsIHNp bmNlDQo+IHByZXN1bWFibHkgdGhlcmXigJlzIGxvdyBlbnRyb3B5IGluIHVzZXJuYW1lcyBhbmQg cGFzc3dvcmRzIGFsaWtlLiBUaHVzLCBJDQo+IHF1ZXN0aW9uIHdoZXRoZXIgdGhpcyBpcyBhIOKA nHN0cm9uZ2Vy4oCdIG1pdGlnYXRpb24uIA0KDQpUaGUgc2VjdGlvbiBvbmx5IGRpc2N1c3NlcyAi b2ZmbGluZSIgZGljdGlvbmFyeSBhdHRhY2ssIEhvdyBpcyBvZmZsaW5lIGRpY3Rpb25hcnkgYXR0 YWNrIHBvc3NpYmxlIHdpdGggKEQpVExTID8NCg0KPi0gU2VjdGlvbiAxMi4xLjY6IOKAnHVzZXJu YW1l4oCdDQo+IGFuZCDigJxyZWFsbeKAnSBhcmUgbm90IGNvbnNpZGVyZWQgc2Vuc2l0aXZlPyBU aGV5IHNlZW0gc2Vuc2l0aXZlIHRvIG1lLiAtIEFzIGFuDQo+IGV4dGVuc2lvbiwgaXQgc2VlbXMg cG9zc2libGUgdG8gaW1wcm92ZSBvbiB3aGF04oCZcyBpbiBTVFVOLiBGb3IgZXhhbXBsZSwgaXQN Cj4gbWF5IGJlIHdvcnRod2hpbGUsIGhlcmUgb3IgZWxzZXdoZXJlLCB0byB1cGRhdGUgU1RVTuKA mXMgbG9uZyB0ZXJtDQo+IGNyZWRlbnRpYWwga2V5IGRlcml2YXRpb24gcHJvY2VzcyAoTUQ1KHVz ZXJuYW1lICsgcmVhbG0gKyBwYXNzd29yZCkpIHRvDQo+IHNvbWV0aGluZyBhIGJpdCBtb3JlIG1v ZGVybi4gVGhpcyBpcyBxdWl0ZSBsaWtlbHkgb3V0IG9mIHNjb3BlLCB0aG91Z2ggaW4gdGhlDQo+ IGNvbnRleHQgb2YgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGl0IHNlZW1zIHdvcnRoIG1lbnRpb25p bmcgdGhhdCBUVVJOIGlzDQo+IGxpbWl0ZWQgdG8gdGhlIG1lY2hhbmlzbXMgcHJvdmlkZWQgYnkg U1RVTi4NCg0KQXMgbWVudGlvbmVkIHByZXZpb3VzbHksIHVzZXJuYW1lIG1heSBub3QgYmUgdGhl IGVuZC11c2VyIHJlYWwgaWRlbnRpdHkgYW5kIHVzZXJuYW1lIGNhbiBiZSBhbm9ueW1pemVkLiAg IA0KDQo+IA0KPiBOaXRzIGFuZCBvdGhlciBjb21tZW50czoNCj4gDQo+IC0gU2VjdGlvbiAyOiDi gJxtZXNzYWdlLWRpZ2VzdOKAnSBpcyB1bmRlZmluZWQgaW4gdGhlIE5vbmNlIGRlZmluaXRpb24u DQoNClRoYW5rcywgcmVwbGFjZWQgIm1lc3NhZ2UtZGlnZXN0IiB3aXRoICJzZXJ2ZXIgcmVzcG9u c2UiDQoNCj4gLSBTZWN0aW9uIDM6IEl04oCZcyBwcm9iYWJseSB3b3J0aCBjaXRpbmcgUkZDODQ0 NiBhcyB0aGUgcmVjb21tZW5kZWQgdmVyc2lvbg0KPiBvZiBUTFMuIA0KDQpUaGUgZHJhZnQgc2F5 cyBndWlkYW5jZSBnaXZlbiBpbiBbUkZDNzUyNV0gTVVTVCBiZSBmb2xsb3dlZCB0byBhdm9pZCBh dHRhY2tzIG9uIChEKVRMUy4gUkZDNzUyNSBzYXlzIFRMUyAxLjMgcmVzb2x2ZXMgdGhlIHZ1bG5l cmFiaWxpdGllcyBmb3VuZCBpbiBwcmV2aW91cyBUTFMgdmVyc2lvbnMuDQoNCj4tIFNlY3Rpb24g My40OiBJdCBtaWdodCBiZSB3b3J0aCBtZW50aW9uaW5nIHRoYXQgdXNlIG9mIChEKVRMUyBmb3Ig dGhlDQo+IGNsaWVudC10by1zZXJ2ZXIgdHJhbnNwb3J0IG1pdGlnYXRlcyB0aGUgbmVlZCBmb3Ig U2VuZCBhbmQgRGF0YQ0KPiBhdXRoZW50aWNhdGlvbi4NCg0KaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTI3I3NlY3Rpb24tMjEuMS40IGRpc2N1c3Nl cyB0aGlzIGlzc3VlIGluIGRldGFpbC4gDQoNCj4gLSBTZWN0aW9uIDMuNDogV2hhdCBkb2VzIOKA nHByb3BlciBzZWN1cml0eeKAnSBtZWFuPyANCg0KVGhhbmtzLCByZXBsYWNlZCAicHJvcGVyIHNl Y3VyaXR5IiB3aXRoICJlbmQtdG8tZW5kIHNlY3VyaXR5Ii4NCg0KPi0gRmlndXJlIDQ6IEFkZGlu ZyBhbm90aGVyDQo+IG1lc3NhZ2UgZXhjaGFuZ2Ugd2hlcmVpbiBhIGNoYW5uZWwgbWVzc2FnZSBp cyBzZW50IHdpdGhvdXQgYSBwcmlvcg0KPiBDaGFubmVsQmluZCByZXF1ZXN0IHdvdWxkIGJlIHVz ZWZ1bCB0byBoaWdobGlnaHQgdGhpcyBkZXBlbmRlbmN5IGFuZA0KPiBleHBlY3RlZCBiZWhhdmlv ciBmcm9tIGNsaWVudHMgYW5kIHNlcnZlcnMuIA0KDQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtMjcjc2VjdGlvbi0xMi42IGV4cGxhaW5zIHRoYXQg SWYgdGhlIENoYW5uZWxEYXRhIG1lc3NhZ2UgaXMgcmVjZWl2ZWQgb24gYSBjaGFubmVsIHRoYXQg aXMgbm90IGJvdW5kIHRvIGFueSBwZWVyLCB0aGVuIHRoZSBtZXNzYWdlIGlzIHNpbGVudGx5IGRp c2NhcmRlZC4NCg0KPiAtIFNlY3Rpb24gMy42OiBBbm90aGVyIGJlbmVmaXQgb2YNCj4gdGhpcyB1 c2VyIHNwYWNlIGRlc2lnbiBkZWNpc2lvbiBpcyB1c2Ugb2YgKEQpVExTIGxpbmtzLiAtDQoNCkdv b2QgcG9pbnQsIHVwZGF0ZWQgbGluZSB0byBzYXk6DQpmb3IgZXhhbXBsZSwgdG8gYWxsb3cgYSBU VVJOIHNlcnZlciB0byBiZSBpbnRlZ3JhdGVkIGludG8gYSBwZWVyLXRvLXBlZXIgYXBwbGljYXRp b24gc28gdGhhdCBvbmUgcGVlciBjYW4gb2ZmZXIgTkFUIHRyYXZlcnNhbCBzZXJ2aWNlcyB0byBh bm90aGVyIHBlZXIgYW5kIHRvIHVzZSAoRClUTFMgdG8gc2VjdXJlIHRoZSBUVVJOIGNvbm5lY3Rp b24uDQoNCiBTZWN0aW9uIDU6IFdoZXJlIGRpZA0KPiB0aGUgNDAgc2Vjb25kIHJlcXVlc3QgYnVm ZmVyIHRpbWVvdXQgY29tZSBmcm9tPyANCg0KSXQgaXMgY29taW5nIGZyb20gdGhlIFNUVU4gc3Bl Y2lmaWNhdGlvbiAoc2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRy YW0tc3R1bmJpcy0yMSNzZWN0aW9uLTYuMy4xKSANCg0KPiBBZGRpbmcgc29tZSBkZXRhaWxzDQo+ IG1pZ2h0IGhlbHAuIC0gU2VjdGlvbiA2OiDigJxzZWN1cmUgaGFzaOKAnSBpcyB1bmRlZmluZWQs IHRob3VnaCBwcmVzdW1hYmx5IHdoYXQNCj4gaXMgbWVhbnQgaXMgYSBjcnlwdG9ncmFwaGljIGhh c2ggd2l0aCBjb2xsaXNpb24gcmVzaXN0YW5jZS4gSXQgd291bGQgYmUgZ29vZCB0bw0KPiBjbGFy aWZ5IHRoaXMgcmVxdWlyZW1lbnQuIA0KDQpZZXMsIHJlcGxhY2VkIHdpdGggIiBjcnlwdG9ncmFw aGljIGhhc2giLiANCg0KPiAtIFNlY3Rpb24gNy40OiBXaGF0IGlzIHRoZSByZXRyeSBiZWhhdmlv ciBpZiBhbGxvY2F0aW9uDQo+IHJlcXVlc3RzIHRpbWVvdXQ/IA0KDQpUaGUgcmV0cnkgYmVoYXZp b3IgaXMgZGlzY3Vzc2VkIGFzIGZvbGxvd3M6DQoNCiAgIG8gIChSZXF1ZXN0IHRpbWVkIG91dCk6 IFRoZXJlIGlzIGVpdGhlciBhIHByb2JsZW0gd2l0aCB0aGUgc2VydmVyLCBvcg0KICAgICAgYSBw cm9ibGVtIHJlYWNoaW5nIHRoZSBzZXJ2ZXIgd2l0aCB0aGUgY2hvc2VuIHRyYW5zcG9ydC4gIFRo ZQ0KICAgICAgY2xpZW50IGNvbnNpZGVycyB0aGUgY3VycmVudCB0cmFuc2FjdGlvbiBhcyBoYXZp bmcgZmFpbGVkIGJ1dCBNQVkNCiAgICAgIGNob29zZSB0byByZXRyeSB0aGUgQWxsb2NhdGUgcmVx dWVzdCB1c2luZyBhIGRpZmZlcmVudCB0cmFuc3BvcnQNCiAgICAgIChlLmcuLCBUQ1AgaW5zdGVh ZCBvZiBVRFApLg0KDQoNCj4tIFNlY3Rpb24gMTIuNTogVGhlIFNUVU4gcmVxdWlyZW1lbnQgZm9y IDQtYnl0ZQ0KPiBhbGlnbm1lbnQgc2hvdWxkIGJlIGNpdGVkIHdoZW4gZGlzY3Vzc2luZyB0aGUg VENQIGFuZCBUTFMgcGFkZGluZw0KPiByZXF1aXJlbWVudC4gDQoNCkRvbmUuDQoNCj4gLSBTZWN0 aW9uIDE1OiBUeXBvIOKAnERPTuKAmVQgRlJBR01FTlTigJ0uDQoNCkZpeGVkLg0KDQpDaGVlcnMs DQotVGlydQ0KDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gdHJhbSBtYWlsaW5nIGxpc3QNCj4gdHJhbUBpZXRmLm9yZw0KPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RyYW0NCg== From nobody Mon Jul 8 13:38:22 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 77599120041; Mon, 8 Jul 2019 13:38:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kathleen Moriarty via Datatracker To: Cc: draft-ietf-bmwg-ngfw-performance.all@ietf.org, ietf@ietf.org, bmwg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Kathleen Moriarty Message-ID: <156261828836.820.7530581707536369773@ietfa.amsl.com> Date: Mon, 08 Jul 2019 13:38:08 -0700 Archived-At: Subject: [secdir] Secdir early review of draft-ietf-bmwg-ngfw-performance-00 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2019 20:38:09 -0000 Reviewer: Kathleen Moriarty Review result: Has Nits Thank you for your work on draft-ietf-bmwg-ngfw-performance. This is a straightforward review establishing metrics for comparison of SUT/DUT for firewalls establishing measurement requirements as well as acceptance criteria. When crypto is recommended for use in testing, it's current, although it should be noted that this is just for test environments. In terms of security, I think this document is ready with nits. Please add a security considerations section. Feel free to include something like what's above. Section 4.1: Nit Spell out Device under test/system under test on first use. I don't think it comes up that often in the IESG review cycle. I had to look it up and my memory was jogged. Sorry for my late 'early' review! From nobody Mon Jul 8 13:40: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 5F32C120086 for ; Mon, 8 Jul 2019 13:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.604 X-Spam-Level: X-Spam-Status: No, score=-0.604 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, PDS_NO_HELO_DNS=1.295, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=netsecopen-org.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 v6bkpIXST-D7 for ; Mon, 8 Jul 2019 13:40:28 -0700 (PDT) Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (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 B81DF1202CD for ; Mon, 8 Jul 2019 13:40:26 -0700 (PDT) Received: by mail-qt1-x833.google.com with SMTP id y26so6843112qto.4 for ; Mon, 08 Jul 2019 13:40:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netsecopen-org.20150623.gappssmtp.com; s=20150623; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=yYx/H+KQXBN094jLAtWooUjYvNms58BW9Wn4ycNu/6E=; b=tVOS6Hu46SIyEQOCYmtwS41MhjoYcmZvlxgQxR6VXevGVmIbrAhpcbqQpDMYNoBihJ +lsifjsmfAQlhCphXSsrGh9E57cKp8x9/wqVHHnzLN32BjFEt2IAPrtNYmQ3855ciHQw 1MxvSFuaqtefCFzYEWtGEnPW2FSYtVaBEZczsVXAxqXlQYxjDi7Eab9gOLY4CqHC/4Fm ZVCXbJ9H3AA+Akz764tYYnXr1C4TFR1ha7789Cr2HoKz8nvn8Ojif+c1VAMAO5mGanlz gxvByywWptpZ50dQvXNcWyDNo28Imvicul9wuUb4VjjWqeH7AId71lX5UjGd0vsjFBBd JCnw== 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:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=yYx/H+KQXBN094jLAtWooUjYvNms58BW9Wn4ycNu/6E=; b=R7u+GdnOmhkIxWTzOBz8ksNuicEgGqTsp2mGM9duguZmeUpnDcspcINruWzshcCzYK vvL4pyKH1N/Dbjj3+AU3hqT1YVc7EOVTg/U5sht2Jyvwhiw1f5hvf7tpdw1G9IVbTF/U 0xLU9r7KfG3BBqHqi0Nz/++i//s30Xbt2hqwqH70aHRMAr0nn0ZVLqoMmNqsoSLg6E2Y HLrvksKd2s4v0NN3GMWql906XVV5ghf1d24JPL2ioRGj+AK3earF5Dyyxa1AHSjoYXgk SKGctI3SucF1a2BvbLE16jg36xmuz3sVvwdeJ8ZihAL7yC7JpKITEN89PWRelhdYs2ct p12A== X-Gm-Message-State: APjAAAVRTXRQyWYJQti2UB7LM6zBYxwsczym9NomXBW51qrCwtT3KRFB uMGZiOdIz8ieiR8rkvjKenSosA== X-Google-Smtp-Source: APXvYqw5uCLhW8/tTMLp0bwUIAuGihDzQT9P0WQhSPdSz0Y8WdFBWyUqm4REYd/g8JX2A4/I93AUOQ== X-Received: by 2002:ac8:444c:: with SMTP id m12mr15734751qtn.306.1562618425687; Mon, 08 Jul 2019 13:40:25 -0700 (PDT) Received: from BrianPC (c-98-235-201-224.hsd1.pa.comcast.net. [98.235.201.224]) by smtp.gmail.com with ESMTPSA id p23sm4215810qke.44.2019.07.08.13.40.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Jul 2019 13:40:25 -0700 (PDT) From: "Brian Monkman" To: "'Kathleen Moriarty'" , Cc: , , References: <156261828836.820.7530581707536369773@ietfa.amsl.com> In-Reply-To: <156261828836.820.7530581707536369773@ietfa.amsl.com> Date: Mon, 8 Jul 2019 16:40:22 -0400 Message-ID: <00b701d535cd$5dd9a490$198cedb0$@netsecopen.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQKALfXAuYNHgZeMPKkOA0rWpRO3s6VrPnQQ Content-Language: en-ca Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-bmwg-ngfw-performance-00 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, 08 Jul 2019 20:40:36 -0000 Thanks for your feedback Kathleen. I will review it with the team and = may get back to you with questions. Brian Monkman -----Original Message----- From: Kathleen Moriarty via Datatracker =20 Sent: July 8, 2019 4:38 PM To: secdir@ietf.org Cc: draft-ietf-bmwg-ngfw-performance.all@ietf.org; ietf@ietf.org; = bmwg@ietf.org Subject: Secdir early review of draft-ietf-bmwg-ngfw-performance-00 Reviewer: Kathleen Moriarty Review result: Has Nits Thank you for your work on draft-ietf-bmwg-ngfw-performance. This is a = straightforward review establishing metrics for comparison of SUT/DUT = for firewalls establishing measurement requirements as well as = acceptance criteria. When crypto is recommended for use in testing, it's current, although = it should be noted that this is just for test environments. In terms of = security, I think this document is ready with nits. Please add a security considerations section. Feel free to include = something like what's above. Section 4.1: Nit Spell out Device under test/system under test on first use. I don't = think it comes up that often in the IESG review cycle. I had to look it = up and my memory was jogged. Sorry for my late 'early' review! From nobody Tue Jul 9 00:07: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 113CC1202F8; Tue, 9 Jul 2019 00:07:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nnIIdapDPjb0; Tue, 9 Jul 2019 00:07:26 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 F1A141200F7; Tue, 9 Jul 2019 00:07:25 -0700 (PDT) Received: from pps.filterd (m0049458.ppops.net [127.0.0.1]) by m0049458.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x6975HXq016747; Tue, 9 Jul 2019 03:07:22 -0400 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049458.ppops.net-00191d01. with ESMTP id 2tmhqswg3q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 09 Jul 2019 03:07:22 -0400 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id x6977LtQ001959; Tue, 9 Jul 2019 02:07:21 -0500 Received: from zlp30495.vci.att.com (zlp30495.vci.att.com [135.46.181.158]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id x6977JVi001918 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 9 Jul 2019 02:07:19 -0500 Received: from zlp30495.vci.att.com (zlp30495.vci.att.com [127.0.0.1]) by zlp30495.vci.att.com (Service) with ESMTP id B4836400A0A3; Tue, 9 Jul 2019 07:07:19 +0000 (GMT) Received: from clpi183.sldc.sbc.com (unknown [135.41.1.46]) by zlp30495.vci.att.com (Service) with ESMTP id 974FB400A0A2; Tue, 9 Jul 2019 07:07:19 +0000 (GMT) Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id x6977Jc3009187; Tue, 9 Jul 2019 02:07:19 -0500 Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.255.15]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id x69774l2008165; Tue, 9 Jul 2019 02:07:04 -0500 Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-green.research.att.com (Postfix) with ESMTP id 9042DE1098; Tue, 9 Jul 2019 03:05:37 -0400 (EDT) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njbdcas1.research.att.com ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0439.000; Tue, 9 Jul 2019 03:06:17 -0400 From: "MORTON, ALFRED C (AL)" To: Brian Monkman , "'Kathleen Moriarty'" , "secdir@ietf.org" CC: "draft-ietf-bmwg-ngfw-performance.all@ietf.org" , "ietf@ietf.org" , "bmwg@ietf.org" Thread-Topic: Secdir early review of draft-ietf-bmwg-ngfw-performance-00 Thread-Index: AQHVNc0IhaR19GS8XU2P9JMA53XEoKbBci0AgABqNaA= Date: Tue, 9 Jul 2019 07:06:16 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CFA0AA95B9@njmtexg5.research.att.com> References: <156261828836.820.7530581707536369773@ietfa.amsl.com> <00b701d535cd$5dd9a490$198cedb0$@netsecopen.org> In-Reply-To: <00b701d535cd$5dd9a490$198cedb0$@netsecopen.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.134.50.125] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-09_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907090085 Archived-At: Subject: Re: [secdir] Secdir early review of draft-ietf-bmwg-ngfw-performance-00 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, 09 Jul 2019 07:07:28 -0000 TGV0IG1lIGFkZCBteSB0aGFua3MgZm9yIHlvdXIgcmV2aWV3IEthdGhsZWVuIQ0KDQpAQnJpYW4g YW5kIHRlYW0sIHRoZXJlIGlzIGEgInN0YW5kYXJkIiBzZWN1cml0eSBzZWN0aW9uDQppbiB3ZyBj aGFpcidzIHNsaWRlcyBhbmQgb3RoZXIgZHJhZnRzLiBQbGVhc2UgZmVlbCANCmZyZWUgdG8gaW1w cm92ZSBhbmQgY3VzdG9taXplIHRoZSB0ZXh0IGZvciB0aGlzIA0KY2FzZSBvZiBuZXh0LWdlbiBm aXJld2FsbCBiZW5jaG1hcmtpbmcgDQooaW4gaXNvbGF0ZWQgdGVzdCBlbnZpcm9ubWVudHMsIGNv bnNpc3RlbnQgd2l0aCBvdXIgY2hhcnRlcikuDQoNCnJlZ2FyZHMsDQpBbA0KYm13ZyBjby1jaGFp cg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJyaWFuIE1vbmttYW4g W21haWx0bzpibW9ua21hbkBuZXRzZWNvcGVuLm9yZ10NCj4gU2VudDogTW9uZGF5LCBKdWx5IDgs IDIwMTkgNDo0MCBQTQ0KPiBUbzogJ0thdGhsZWVuIE1vcmlhcnR5JyA8S2F0aGxlZW4uTW9yaWFy dHkuaWV0ZkBnbWFpbC5jb20+Ow0KPiBzZWNkaXJAaWV0Zi5vcmcNCj4gQ2M6IGRyYWZ0LWlldGYt Ym13Zy1uZ2Z3LXBlcmZvcm1hbmNlLmFsbEBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsNCj4gYm13 Z0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogU2VjZGlyIGVhcmx5IHJldmlldyBvZiBkcmFmdC1p ZXRmLWJtd2ctbmdmdy1wZXJmb3JtYW5jZS0wMA0KPiANCj4gVGhhbmtzIGZvciB5b3VyIGZlZWRi YWNrIEthdGhsZWVuLiBJIHdpbGwgcmV2aWV3IGl0IHdpdGggdGhlIHRlYW0gYW5kIG1heQ0KPiBn ZXQgYmFjayB0byB5b3Ugd2l0aCBxdWVzdGlvbnMuDQo+IA0KPiBCcmlhbiBNb25rbWFuDQo+IA0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBLYXRobGVlbiBNb3JpYXJ0eSB2 aWEgRGF0YXRyYWNrZXIgPG5vcmVwbHlAaWV0Zi5vcmc+DQo+IFNlbnQ6IEp1bHkgOCwgMjAxOSA0 OjM4IFBNDQo+IFRvOiBzZWNkaXJAaWV0Zi5vcmcNCj4gQ2M6IGRyYWZ0LWlldGYtYm13Zy1uZ2Z3 LXBlcmZvcm1hbmNlLmFsbEBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsNCj4gYm13Z0BpZXRmLm9y Zw0KPiBTdWJqZWN0OiBTZWNkaXIgZWFybHkgcmV2aWV3IG9mIGRyYWZ0LWlldGYtYm13Zy1uZ2Z3 LXBlcmZvcm1hbmNlLTAwDQo+IA0KPiBSZXZpZXdlcjogS2F0aGxlZW4gTW9yaWFydHkNCj4gUmV2 aWV3IHJlc3VsdDogSGFzIE5pdHMNCj4gDQo+IFRoYW5rIHlvdSBmb3IgeW91ciB3b3JrIG9uIGRy YWZ0LWlldGYtYm13Zy1uZ2Z3LXBlcmZvcm1hbmNlLiAgVGhpcyBpcyBhDQo+IHN0cmFpZ2h0Zm9y d2FyZCByZXZpZXcgZXN0YWJsaXNoaW5nIG1ldHJpY3MgZm9yIGNvbXBhcmlzb24gb2YgU1VUL0RV VCBmb3INCj4gZmlyZXdhbGxzIGVzdGFibGlzaGluZyBtZWFzdXJlbWVudCByZXF1aXJlbWVudHMg YXMgd2VsbCBhcyBhY2NlcHRhbmNlDQo+IGNyaXRlcmlhLg0KPiAgV2hlbiBjcnlwdG8gaXMgcmVj b21tZW5kZWQgZm9yIHVzZSBpbiB0ZXN0aW5nLCBpdCdzIGN1cnJlbnQsIGFsdGhvdWdoIGl0DQo+ IHNob3VsZCBiZSBub3RlZCB0aGF0IHRoaXMgaXMganVzdCBmb3IgdGVzdCBlbnZpcm9ubWVudHMu ICBJbiB0ZXJtcyBvZg0KPiBzZWN1cml0eSwgSSB0aGluayB0aGlzIGRvY3VtZW50IGlzIHJlYWR5 IHdpdGggbml0cy4NCj4gDQo+IFBsZWFzZSBhZGQgYSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBz ZWN0aW9uLiAgRmVlbCBmcmVlIHRvIGluY2x1ZGUNCj4gc29tZXRoaW5nIGxpa2Ugd2hhdCdzIGFi b3ZlLg0KPiANCj4gU2VjdGlvbiA0LjE6IE5pdA0KPiANCj4gU3BlbGwgb3V0IERldmljZSB1bmRl ciB0ZXN0L3N5c3RlbSB1bmRlciB0ZXN0IG9uIGZpcnN0IHVzZS4gIEkgZG9uJ3QgdGhpbmsNCj4g aXQgY29tZXMgdXAgdGhhdCBvZnRlbiBpbiB0aGUgSUVTRyByZXZpZXcgY3ljbGUuICBJIGhhZCB0 byBsb29rIGl0IHVwIGFuZA0KPiBteSBtZW1vcnkgd2FzIGpvZ2dlZC4NCj4gDQo+IFNvcnJ5IGZv ciBteSBsYXRlICdlYXJseScgcmV2aWV3IQ0KPiANCj4gDQoNCg== From nobody Tue Jul 9 13:00:34 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 D814F12001A; Tue, 9 Jul 2019 13:00:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Mundy via Datatracker To: Cc: iasa20@ietf.org, ietf@ietf.org, draft-ietf-iasa2-rfc7437bis.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Russ Mundy Message-ID: <156270241775.15904.2426062824267979240@ietfa.amsl.com> Date: Tue, 09 Jul 2019 13:00:17 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-iasa2-rfc7437bis-08 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, 09 Jul 2019 20:00:18 -0000 Reviewer: Russ Mundy Review result: Ready This ID does an excellent job of defining the IETF nomcom process, is well written and understandable. It is ready for publication. From nobody Tue Jul 9 13: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 B324C12004F; Tue, 9 Jul 2019 13:30:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Nq6v59nuhvh; Tue, 9 Jul 2019 13:30:56 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AB8C120025; Tue, 9 Jul 2019 13:30:56 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x69KUj20017200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 9 Jul 2019 16:30:48 -0400 Date: Tue, 9 Jul 2019 15:30:45 -0500 From: Benjamin Kaduk To: "Konda, Tirumaleswar Reddy" Cc: Christopher Wood , "secdir@ietf.org" , "draft-ietf-tram-turnbis.all@ietf.org" , "ietf@ietf.org" , "tram@ietf.org" Message-ID: <20190709203044.GD24351@kduck.mit.edu> References: <156253133809.549.13521510978566357744@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [secdir] [tram] Secdir last call review of draft-ietf-tram-turnbis-27 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, 09 Jul 2019 20:31:00 -0000 Chris, thanks for the review. Some more questions/comments inline as I prepare to ballot on this document... On Mon, Jul 08, 2019 at 02:18:26PM +0000, Konda, Tirumaleswar Reddy wrote: > Hi Christopher, > > Thanks for the detailed review. Please see inline > > > -----Original Message----- > > From: tram On Behalf Of Christopher Wood via > > Datatracker > > Sent: Monday, July 8, 2019 1:59 AM > > To: secdir@ietf.org > > Cc: draft-ietf-tram-turnbis.all@ietf.org; ietf@ietf.org; tram@ietf.org > > Subject: [tram] Secdir last call review of draft-ietf-tram-turnbis-27 > > > > This email originated from outside of the organization. Do not click links or > > open attachments unless you recognize the sender and know the content is > > safe. > > > > Reviewer: Christopher Wood > > 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. > > > > The summary of the review is: Ready with nits > > > > Summary: > > > > In general, the document is well written and clearly founded in operational > > experience. The security considerations are thorough, providing examples > > where necessary to highlight important problem areas. It draws a clear line > > between issues best addressed by applications outside of TURN, and > > provides sufficient detail for those issues in scope. My comments and > > questions are, hopefully, mostly nits. > > > > General comments: > > > > - TURN server authentication in the case of (D)TLS is underspecified. Are > > servers assumed to have WebPKI certificates, OOB-trusted raw public keys, > > or something else? Is there a preferred form of authentication? > > Relatedly, in > > Section 3.2, how do clients authenticate the server? > > Server certificate validation is discussed in https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-6.2.3. I have modified the text as follows: > > If (D)TLS transport is used between the TURN client and the TURN server, the cipher suites, > server certificate validation and authentication of TURN server are > discussed in Section 6.2.3 of [I-D.ietf-tram-stunbis] That helps, but it would still be nice to give some indication of what certificate PKI(s) are expected to be used. Is anything other than the Web PKI under consideration? > >- Section 3.7: Could > > TURN servers not chunk data from stream-oriented transports (TCP or TLS) > > to a preferred MTU size before relaying to peers? > > Specifically, there are likely > > some cases wherein the server could deal with the client data messages > > larger than the recommended 500B limit. On that point, should servers even > > accept data larger than this recommended size ? - > > Please see https://tools.ietf.org/html/draft-ietf-tram-turnbis-27#section-15 for TCP-to-UDP relay. If the PMTU is not known, and on legacy or otherwise unusual networks, > 500 byte limit for application data is recommended. > > > Section 3.9: There may be > > cases where the TLS connection post TCP connection establishment fails. It > > would therefore seems prudent to not declare victory for one connection > > over the other until TLS connects, too. - > > Agreed, Eric (as part of ISEG review) suggested to simplify the text. I have updated the text as follows: > > o For TCP or TLS-over-TCP, the results of the Happy Eyeballs > procedure [RFC8305] are used by the TURN client for sending its > TURN messages to the server. Is the editor's copy available for viewing somewhere? It would be good to see this (and other changes) in context. > > Section 3 could benefit from a > > subsection on replays and the nonce role. In particular, as later discussed in > > the security considerations, some of these attacks are not new to TURN and > > should therefore be dealt with by the application protocol (SRTP). This > > section might also describe nonce rotation policies with more specificity, as > > this is underspecified in the document. > > It is discussed in Section 5 in the specification, the server should expire the nonce at least once every hour during the lifetime of the allocation. > > >- Section 3 could also benefit from > > discussion about cleartext versus encryption transports between clients and > > servers. > > It is discussed in https://tools.ietf.org/html/draft-ietf-tram-turnbis-27#section-21.1.6. There's not much discussion about potential information leakage via (e.g.) USERNAME/USERHASH, and really just a claim that the peer address is the "primary protocol content". > > Encrypting the nonce, username, realm, etc., among other things, has > > obvious benefits. - Why are SOFTWARE and FINGERPRINT attributes > > recommended? It seems like clients should be discouraged from sending > > these if anything, especially if not used to make allocation decisions on the > > server. > > Username may not be the user identity, Please see https://tools.ietf.org/html/rfc7635), It could be an ephemeral and unique key identifier. Further, username can be anonymized (please see https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-14.4). > SOFTWARE and FINGERPRINT attributes are defined in the STUN specification, see https://tools.ietf.org/html/draft-ietf-tram-stunbis-21. These mechanisms are partial mitigations but can still be susceptible to cross-connection correlation attacks. > - Section 5: When servers receive data that exceeds an allocation’s > > bandwidth quota, servers silently discard this data. This means there’s no > > allocation-based flow control mechanism between client and server beyond > > what’s provided by the transport protocol, right? > > Yes, UDP does not include a congestion control mechanism. > > > This seems fine, though > > perhaps some discussion of why this design decision was made would be > > helpful. For example, I could imagine explicit signals from servers to clients > > that indicate server state would reveal information about other allocations > > on the server, which might be problematic. - > > The errors 486 (Allocation Quota Exceeded) or 508 (Insufficient Capacity) do not reveal information of which other users are using the TURN server. At least the latter seems to give some indication that many other users are using the server at the time (so that it's overloaded), though not information about *which* users that is. > > Section 7.2 suggests that > > servers can redirect client allocation requests to other servers. Can this > > create a loop, wherein two TURN servers redirect to one another? > > The client detect and stop the loop, it is similar to HTTP redirection. Where is this specified? Thanks, Ben > > Moreover, > > is it acceptable for one TURN server to redirect to an unrelated TURN server? > > (It should be made clear here that these responses are authenticated, as > > otherwise it would be possible for an on-path adversary to redirect allocation > > requests to a server it owns.) > > It is already discussed in https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-10 > > > - Section > > 21.1.2: Use of (D)TLS doesn’t help against dictionary attacks much, since > > presumably there’s low entropy in usernames and passwords alike. Thus, I > > question whether this is a “stronger” mitigation. > > The section only discusses "offline" dictionary attack, How is offline dictionary attack possible with (D)TLS ? > > >- Section 12.1.6: “username” > > and “realm” are not considered sensitive? They seem sensitive to me. - As an > > extension, it seems possible to improve on what’s in STUN. For example, it > > may be worthwhile, here or elsewhere, to update STUN’s long term > > credential key derivation process (MD5(username + realm + password)) to > > something a bit more modern. This is quite likely out of scope, though in the > > context of client authentication it seems worth mentioning that TURN is > > limited to the mechanisms provided by STUN. > > As mentioned previously, username may not be the end-user real identity and username can be anonymized. > > > > > Nits and other comments: > > > > - Section 2: “message-digest” is undefined in the Nonce definition. > > Thanks, replaced "message-digest" with "server response" > > > - Section 3: It’s probably worth citing RFC8446 as the recommended version > > of TLS. > > The draft says guidance given in [RFC7525] MUST be followed to avoid attacks on (D)TLS. RFC7525 says TLS 1.3 resolves the vulnerabilities found in previous TLS versions. > > >- Section 3.4: It might be worth mentioning that use of (D)TLS for the > > client-to-server transport mitigates the need for Send and Data > > authentication. > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-27#section-21.1.4 discusses this issue in detail. > > > - Section 3.4: What does “proper security” mean? > > Thanks, replaced "proper security" with "end-to-end security". > > >- Figure 4: Adding another > > message exchange wherein a channel message is sent without a prior > > ChannelBind request would be useful to highlight this dependency and > > expected behavior from clients and servers. > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-27#section-12.6 explains that If the ChannelData message is received on a channel that is not bound to any peer, then the message is silently discarded. > > > - Section 3.6: Another benefit of > > this user space design decision is use of (D)TLS links. - > > Good point, updated line to say: > for example, to allow a TURN server to be integrated into a peer-to-peer application so that one peer can offer NAT traversal services to another peer and to use (D)TLS to secure the TURN connection. > > Section 5: Where did > > the 40 second request buffer timeout come from? > > It is coming from the STUN specification (see https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-6.3.1) > > > Adding some details > > might help. - Section 6: “secure hash” is undefined, though presumably what > > is meant is a cryptographic hash with collision resistance. It would be good to > > clarify this requirement. > > Yes, replaced with " cryptographic hash". > > > - Section 7.4: What is the retry behavior if allocation > > requests timeout? > > The retry behavior is discussed as follows: > > o (Request timed out): There is either a problem with the server, or > a problem reaching the server with the chosen transport. The > client considers the current transaction as having failed but MAY > choose to retry the Allocate request using a different transport > (e.g., TCP instead of UDP). > > > >- Section 12.5: The STUN requirement for 4-byte > > alignment should be cited when discussing the TCP and TLS padding > > requirement. > > Done. > > > - Section 15: Typo “DON’T FRAGMENT”. > > Fixed. > > Cheers, > -Tiru > > > > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram From nobody Tue Jul 9 13:39: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 6332312004F for ; Tue, 9 Jul 2019 13:39:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 zkkdeQUqDba2 for ; Tue, 9 Jul 2019 13:39:49 -0700 (PDT) Received: from smtp82.iad3a.emailsrvr.com (smtp82.iad3a.emailsrvr.com [173.203.187.82]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7E08120025 for ; Tue, 9 Jul 2019 13:39:48 -0700 (PDT) Received: from app65.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp11.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id CC6F75705; Tue, 9 Jul 2019 16:39:47 -0400 (EDT) X-Sender-Id: scott@hyperthought.com Received: from app65.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Tue, 09 Jul 2019 16:39:47 -0400 Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by app65.wa-webapps.iad3a (Postfix) with ESMTP id B79FAE0046; Tue, 9 Jul 2019 16:39:47 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Tue, 9 Jul 2019 13:39:47 -0700 (PDT) X-Auth-ID: scott@hyperthought.com Date: Tue, 9 Jul 2019 13:39:47 -0700 (PDT) From: "Scott G. Kelly" To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-babel-applicability.all@tools.ietf.org MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain Message-ID: <1562704787.749713969@apps.rackspace.com> X-Mailer: webmail/16.4.5-RC Archived-At: Subject: [secdir] secdir review of draft-ietf-babel-applicability-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, 09 Jul 2019 20:39:51 -0000 I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These com= ments 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.=0A=0AThe summary of the review is ready.=0A=0AThi= s informational document describes applicability of the Babel routing proto= col in terms of existing deployments. It recommends using one of two securi= ty mechanisms defined for Babel (HMAC vs. DTLS). I did not review the refer= enced docs for HMAC/DTLS, but assuming there are no issues with those docs,= I see no security issues with this document. From nobody Wed Jul 10 05:41:04 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE39120130 for ; Wed, 10 Jul 2019 05:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mcafee.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 jB7fYHK-RiIB for ; Wed, 10 Jul 2019 05:40:56 -0700 (PDT) Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [216.205.24.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9493212012C for ; Wed, 10 Jul 2019 05:40:54 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1562761813; h=ARC-Seal: ARC-Message-Signature:ARC-Authentication-Results: From:To:CC:Subject:Thread-Topic:Thread-Index: Date:Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=tYV0Mxd/EHV7xQvZjZoVWECZR4eGEOW6Yv37ey YSbQ8=; b=h3hqW0zDaQ6aS3OxKUMdsLwPgZZ//CTfaWt7/5+P NYaBtWegF5Z7JRsSbD5HK0OoiGgi6MmLTrAHk4A6l2vMn5rROt NCIDZ3B+txT5ZdU6rxQ9T/0XiIJpg4dxGdL04cTq88gM40igN0 KlkC/lhXuPbFASu5mKvqxu3QaBwWogY= Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-69-6T7oguXnO2GWuWGMOirQnA-1; Wed, 10 Jul 2019 08:40:43 -0400 Received: from DNVEXAPP1N05.corpzone.internalzone.com (DNVEXAPP1N05.corpzone.internalzone.com [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 6fce_6c22_8546be77_e434_43e5_8158_5cdcb3449957; Wed, 10 Jul 2019 06:30:11 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 10 Jul 2019 06:40:39 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Wed, 10 Jul 2019 06:40:39 -0600 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 10 Jul 2019 06:40:37 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d0PbQH7S5pEdBBJdLPBuCg/0G3dmP0KmLvLN0NRhPjoTnGzeIUQSOyRfDx+eMm2NZYUqlqeSfd19TUJ2TN9Rbq6nwlmepjb8cSPwg2qYzJCe+wP/l1SnHmUJYpohOpm48DWSOu2sEgT2mZlZMLJznsFO8Oa0ortJbpjMIMZ8TUvzVJnjJgUrECXR8dWX4qVJZxJomgnTfFXEcppfB2JWgFeM4N/8vn+gLKTXGpxWzATGShGpyKQtxjPGtO5E0jSrZZ26ThyqhnBuA9fo2KU+KOtr7ErjF/OdlGgpFf6Q3ZhqLvUXxLYPvkXuNWs2UfnaK7VyhY2crLRDk+Lzdlk3OQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tYV0Mxd/EHV7xQvZjZoVWECZR4eGEOW6Yv37eyYSbQ8=; b=nP3uRIsI/HW5j3WmXuQkxV509rFqTAuONPNZMsvoj5kl45OD6XFFjWq6tbKZGU3sUaDvf3DciQuHYVa6NXF8Z+q14skO6aCY1w4XkEqOv6EkwMfffTbakhUP4F1RHR+pxMry9sEYuEIJhrf7y2voMoxkmpuz4E9vC3eVJHy1oKIlkf1MMxI1YgEAaS9Qb3Q030pTQ/3wIiChJ8OiZbVi4xxkNwZ3EGwiJCt+u1STR4J2OslStv47viQFd1mb7oBPoe3aoQE/2e4/Y34tiKgWaq2C/+HjJyfBmyop3VpzaxTArbZB6BK66m7BvULPr8yHkB1d69wWwcuPsVFBDKcWLA== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mcafee.com;dmarc=pass action=none header.from=mcafee.com;dkim=pass header.d=mcafee.com;arc=none Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5SPR00MB242.namprd16.prod.outlook.com (10.168.120.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Wed, 10 Jul 2019 12:40:37 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2052.019; Wed, 10 Jul 2019 12:40:37 +0000 From: "Konda, Tirumaleswar Reddy" To: Benjamin Kaduk CC: Christopher Wood , "secdir@ietf.org" , "draft-ietf-tram-turnbis.all@ietf.org" , "ietf@ietf.org" , "tram@ietf.org" Thread-Topic: [tram] Secdir last call review of draft-ietf-tram-turnbis-27 Thread-Index: AQHVNQMAJeymFhPVnEO1ky4wx5pqrabAcMBwgAJPmICAAKIlAA== Date: Wed, 10 Jul 2019 12:40:37 +0000 Message-ID: References: <156253133809.549.13521510978566357744@ietfa.amsl.com> <20190709203044.GD24351@kduck.mit.edu> In-Reply-To: <20190709203044.GD24351@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.16 dlp-reaction: no-action x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fdf60297-a4c7-448a-b521-08d70533cf56 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5SPR00MB242; x-ms-traffictypediagnostic: DM5SPR00MB242: x-ms-exchange-purlcount: 14 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0094E3478A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(346002)(376002)(39860400002)(366004)(189003)(199004)(32952001)(51914003)(13464003)(99286004)(68736007)(53936002)(966005)(7736002)(71200400001)(71190400001)(6916009)(316002)(6306002)(76176011)(9686003)(2171002)(54906003)(305945005)(33656002)(30864003)(476003)(25786009)(478600001)(229853002)(7696005)(486006)(66066001)(6246003)(14454004)(2906002)(5660300002)(186003)(8676002)(102836004)(26005)(81156014)(81166006)(11346002)(52536014)(8936002)(66476007)(66946007)(80792005)(66556008)(64756008)(66446008)(6506007)(53546011)(55016002)(76116006)(6116002)(3846002)(86362001)(446003)(5024004)(74316002)(4326008)(6436002)(256004)(14444005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5SPR00MB242; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 2oOIAYrY6AykjsFJHqTeFjwsec7f9EEWYLGK50ohHYrsid7zgpX8n85jeEdudbnMpcHLvsCzvWm85RiP6cEsAZlwXvFvxUs+RC7CRk8rL/E0VLoJcbog701+/z+yXAYlNoGARXGsBPfUVrO2iXuJKZSQbZFT26eK1FKmtlx3DrqIivbbFD4uEV0MjbcomuiMOQbmqpdLeCO6ww0jNmymISIoxvsiWjBCB8tCCEKb8JccfFRthXgyytwn0/JTDLHrHIz6xkPBKjXrM6dZ1r7BzNLaXM+JywGtse1sWYRrgrq9v8K3m/E4LsDp1zvmsQT2I7ELFzpffrNDblJsAVBMX/WFln2dIxfbkkR+qYhUag6O+Qoxl2F7hytaJ5ui+IfVijQdhlsf5G82ver5MFP1IbDFTlwrqwtfGOjq2E5rZzk= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fdf60297-a4c7-448a-b521-08d70533cf56 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2019 12:40:37.5160 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5SPR00MB242 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6586> : inlines <7115> : streams <1826946> : uri <2865937> X-MC-Unique: 6T7oguXnO2GWuWGMOirQnA-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [secdir] [tram] Secdir last call review of draft-ietf-tram-turnbis-27 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, 10 Jul 2019 12:41:01 -0000 SGkgQmVuLA0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcuIFBsZWFzZSBzZWUgaW5saW5lLg0KDQo+ IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEJlbmphbWluIEthZHVrIDxrYWR1 a0BtaXQuZWR1Pg0KPiBTZW50OiBXZWRuZXNkYXksIEp1bHkgMTAsIDIwMTkgMjowMSBBTQ0KPiBU bzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSA8VGlydW1hbGVzd2FyUmVkZHlfS29uZGFATWNB ZmVlLmNvbT4NCj4gQ2M6IENocmlzdG9waGVyIFdvb2QgPGNhd0BoZWFwaW5nYml0cy5uZXQ+OyBz ZWNkaXJAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtDQo+IHRyYW0tdHVybmJpcy5hbGxAaWV0Zi5vcmc7 IGlldGZAaWV0Zi5vcmc7IHRyYW1AaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFt0cmFtXSBTZWNk aXIgbGFzdCBjYWxsIHJldmlldyBvZiBkcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0yNw0KPiANCj4g VGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5pemF0aW9uLiBE byBub3QgY2xpY2sgbGlua3Mgb3INCj4gb3BlbiBhdHRhY2htZW50cyB1bmxlc3MgeW91IHJlY29n bml6ZSB0aGUgc2VuZGVyIGFuZCBrbm93IHRoZSBjb250ZW50IGlzDQo+IHNhZmUuDQo+IA0KPiBD aHJpcywgdGhhbmtzIGZvciB0aGUgcmV2aWV3LiAgU29tZSBtb3JlIHF1ZXN0aW9ucy9jb21tZW50 cyBpbmxpbmUgYXMgSQ0KPiBwcmVwYXJlIHRvIGJhbGxvdCBvbiB0aGlzIGRvY3VtZW50Li4uDQo+ IA0KPiBPbiBNb24sIEp1bCAwOCwgMjAxOSBhdCAwMjoxODoyNlBNICswMDAwLCBLb25kYSwgVGly dW1hbGVzd2FyIFJlZGR5IHdyb3RlOg0KPiA+IEhpIENocmlzdG9waGVyLA0KPiA+DQo+ID4gVGhh bmtzIGZvciB0aGUgZGV0YWlsZWQgcmV2aWV3LiBQbGVhc2Ugc2VlIGlubGluZQ0KPiA+DQo+ID4g PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogdHJhbSA8dHJhbS1ib3Vu Y2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgQ2hyaXN0b3BoZXIgV29vZCB2aWENCj4gPiA+IERh dGF0cmFja2VyDQo+ID4gPiBTZW50OiBNb25kYXksIEp1bHkgOCwgMjAxOSAxOjU5IEFNDQo+ID4g PiBUbzogc2VjZGlyQGlldGYub3JnDQo+ID4gPiBDYzogZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMu YWxsQGlldGYub3JnOyBpZXRmQGlldGYub3JnOw0KPiA+ID4gdHJhbUBpZXRmLm9yZw0KPiA+ID4g U3ViamVjdDogW3RyYW1dIFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mDQo+ID4gPiBkcmFmdC1p ZXRmLXRyYW0tdHVybmJpcy0yNw0KPiA+ID4NCj4gPiA+IFRoaXMgZW1haWwgb3JpZ2luYXRlZCBm cm9tIG91dHNpZGUgb2YgdGhlIG9yZ2FuaXphdGlvbi4gRG8gbm90IGNsaWNrDQo+ID4gPiBsaW5r cyBvciBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5k IGtub3cNCj4gPiA+IHRoZSBjb250ZW50IGlzIHNhZmUuDQo+ID4gPg0KPiA+ID4gUmV2aWV3ZXI6 IENocmlzdG9waGVyIFdvb2QNCj4gPiA+IFJldmlldyByZXN1bHQ6IEhhcyBOaXRzDQo+ID4gPg0K PiA+ID4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJp dHkgZGlyZWN0b3JhdGUncw0KPiA+ID4gb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRG IGRvY3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlDQo+ID4gPiBJRVNHLiBUaGVzZSBjb21t ZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUNCj4gPiA+ IHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLg0KPiA+ID4gRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cg Y2hhaXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UNCj4gPiA+IGFueSBv dGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQo+ID4gPg0KPiA+ID4gVGhlIHN1bW1hcnkgb2YgdGhl IHJldmlldyBpczogUmVhZHkgd2l0aCBuaXRzDQo+ID4gPg0KPiA+ID4gU3VtbWFyeToNCj4gPiA+ DQo+ID4gPiBJbiBnZW5lcmFsLCB0aGUgZG9jdW1lbnQgaXMgd2VsbCB3cml0dGVuIGFuZCBjbGVh cmx5IGZvdW5kZWQgaW4NCj4gPiA+IG9wZXJhdGlvbmFsIGV4cGVyaWVuY2UuIFRoZSBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucyBhcmUgdGhvcm91Z2gsDQo+ID4gPiBwcm92aWRpbmcgZXhhbXBsZXMg d2hlcmUgbmVjZXNzYXJ5IHRvIGhpZ2hsaWdodCBpbXBvcnRhbnQgcHJvYmxlbQ0KPiA+ID4gYXJl YXMuIEl0IGRyYXdzIGEgY2xlYXIgbGluZSBiZXR3ZWVuIGlzc3VlcyBiZXN0IGFkZHJlc3NlZCBi eQ0KPiA+ID4gYXBwbGljYXRpb25zIG91dHNpZGUgb2YgVFVSTiwgYW5kIHByb3ZpZGVzIHN1ZmZp Y2llbnQgZGV0YWlsIGZvcg0KPiA+ID4gdGhvc2UgaXNzdWVzIGluIHNjb3BlLiBNeSBjb21tZW50 cyBhbmQgcXVlc3Rpb25zIGFyZSwgaG9wZWZ1bGx5LCBtb3N0bHkNCj4gbml0cy4NCj4gPiA+DQo+ ID4gPiBHZW5lcmFsIGNvbW1lbnRzOg0KPiA+ID4NCj4gPiA+IC0gVFVSTiBzZXJ2ZXIgYXV0aGVu dGljYXRpb24gaW4gdGhlIGNhc2Ugb2YgKEQpVExTIGlzDQo+ID4gPiB1bmRlcnNwZWNpZmllZC4g QXJlIHNlcnZlcnMgYXNzdW1lZCB0byBoYXZlIFdlYlBLSSBjZXJ0aWZpY2F0ZXMsDQo+ID4gPiBP T0ItdHJ1c3RlZCByYXcgcHVibGljIGtleXMsIG9yIHNvbWV0aGluZyBlbHNlPyBJcyB0aGVyZSBh IHByZWZlcnJlZA0KPiBmb3JtIG9mIGF1dGhlbnRpY2F0aW9uPw0KPiA+ID4gUmVsYXRlZGx5LCBp bg0KPiA+ID4gU2VjdGlvbiAzLjIsIGhvdyBkbyBjbGllbnRzIGF1dGhlbnRpY2F0ZSB0aGUgc2Vy dmVyPw0KPiA+DQo+ID4gU2VydmVyIGNlcnRpZmljYXRlIHZhbGlkYXRpb24gaXMgZGlzY3Vzc2Vk IGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC0NCj4gaWV0Zi10cmFtLXN0dW5i aXMtMjEjc2VjdGlvbi02LjIuMy4gIEkgaGF2ZSBtb2RpZmllZCB0aGUgdGV4dCBhcyBmb2xsb3dz Og0KPiA+DQo+ID4gSWYgKEQpVExTIHRyYW5zcG9ydCBpcyB1c2VkIGJldHdlZW4gdGhlIFRVUk4g Y2xpZW50IGFuZCB0aGUgVFVSTg0KPiA+IHNlcnZlciwgdGhlIGNpcGhlciBzdWl0ZXMsIHNlcnZl ciBjZXJ0aWZpY2F0ZSB2YWxpZGF0aW9uIGFuZA0KPiA+IGF1dGhlbnRpY2F0aW9uIG9mIFRVUk4g c2VydmVyIGFyZSBkaXNjdXNzZWQgaW4gU2VjdGlvbiA2LjIuMyBvZg0KPiA+IFtJLUQuaWV0Zi10 cmFtLXN0dW5iaXNdDQo+IA0KPiBUaGF0IGhlbHBzLCBidXQgaXQgd291bGQgc3RpbGwgYmUgbmlj ZSB0byBnaXZlIHNvbWUgaW5kaWNhdGlvbiBvZiB3aGF0IGNlcnRpZmljYXRlDQo+IFBLSShzKSBh cmUgZXhwZWN0ZWQgdG8gYmUgdXNlZC4gIElzIGFueXRoaW5nIG90aGVyIHRoYW4gdGhlIFdlYiBQ S0kgdW5kZXINCj4gY29uc2lkZXJhdGlvbiA/DQoNCk5vLiBQbGVhc2Ugc2VlIGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0tc3R1bmJpcy0yMSNzZWN0aW9uLTYuMi4z LCBJdCBkaXNjdXNzZXMgdG8gdmVyaWZ5IHRoZSBjZXJ0aWZpY2F0ZSBwYXRoIGFuZCBpZGVudGl0 eSBvZiB0aGUgc2VydmVyLg0KDQo+IA0KPiA+ID4tIFNlY3Rpb24gMy43OiBDb3VsZA0KPiA+ID4g VFVSTiBzZXJ2ZXJzIG5vdCBjaHVuayBkYXRhIGZyb20gc3RyZWFtLW9yaWVudGVkIHRyYW5zcG9y dHMgKFRDUCBvcg0KPiA+ID5UTFMpICB0byBhIHByZWZlcnJlZCBNVFUgc2l6ZSBiZWZvcmUgcmVs YXlpbmcgdG8gcGVlcnM/DQo+ID4gPiBTcGVjaWZpY2FsbHksIHRoZXJlIGFyZSBsaWtlbHkNCj4g PiA+IHNvbWUgY2FzZXMgd2hlcmVpbiB0aGUgc2VydmVyIGNvdWxkIGRlYWwgd2l0aCB0aGUgY2xp ZW50IGRhdGENCj4gPiA+bWVzc2FnZXMgIGxhcmdlciB0aGFuIHRoZSByZWNvbW1lbmRlZCA1MDBC IGxpbWl0LiBPbiB0aGF0IHBvaW50LA0KPiA+ID5zaG91bGQgc2VydmVycyBldmVuICBhY2NlcHQg ZGF0YSBsYXJnZXIgdGhhbiB0aGlzIHJlY29tbWVuZGVkIHNpemUgPw0KPiA+ID4tDQo+ID4NCj4g PiBQbGVhc2Ugc2VlDQo+ID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYt dHJhbS10dXJuYmlzLTI3I3NlY3Rpb24tMTUgZm9yDQo+ID4gVENQLXRvLVVEUCByZWxheS4gSWYg dGhlIFBNVFUgaXMgbm90IGtub3duLCBhbmQgb24gbGVnYWN5IG9yIG90aGVyd2lzZQ0KPiA+IHVu dXN1YWwgbmV0d29ya3MsDQo+ID4gNTAwIGJ5dGUgbGltaXQgZm9yIGFwcGxpY2F0aW9uIGRhdGEg aXMgcmVjb21tZW5kZWQuDQo+ID4NCj4gPiA+IFNlY3Rpb24gMy45OiBUaGVyZSBtYXkgYmUNCj4g PiA+IGNhc2VzIHdoZXJlIHRoZSBUTFMgY29ubmVjdGlvbiBwb3N0IFRDUCBjb25uZWN0aW9uIGVz dGFibGlzaG1lbnQNCj4gPiA+IGZhaWxzLiBJdCB3b3VsZCB0aGVyZWZvcmUgc2VlbXMgcHJ1ZGVu dCB0byBub3QgZGVjbGFyZSB2aWN0b3J5IGZvcg0KPiA+ID4gb25lIGNvbm5lY3Rpb24gb3ZlciB0 aGUgb3RoZXIgdW50aWwgVExTIGNvbm5lY3RzLCB0b28uIC0NCj4gPg0KPiA+IEFncmVlZCwgRXJp YyAoYXMgcGFydCBvZiBJU0VHIHJldmlldykgc3VnZ2VzdGVkIHRvIHNpbXBsaWZ5IHRoZSB0ZXh0 LiBJIGhhdmUNCj4gdXBkYXRlZCB0aGUgdGV4dCBhcyBmb2xsb3dzOg0KPiA+DQo+ID4gICAgbyAg Rm9yIFRDUCBvciBUTFMtb3Zlci1UQ1AsIHRoZSByZXN1bHRzIG9mIHRoZSBIYXBweSBFeWViYWxs cw0KPiA+ICAgICAgIHByb2NlZHVyZSBbUkZDODMwNV0gYXJlIHVzZWQgYnkgdGhlIFRVUk4gY2xp ZW50IGZvciBzZW5kaW5nIGl0cw0KPiA+ICAgICAgIFRVUk4gbWVzc2FnZXMgdG8gdGhlIHNlcnZl ci4NCj4gDQo+IElzIHRoZSBlZGl0b3IncyBjb3B5IGF2YWlsYWJsZSBmb3Igdmlld2luZyBzb21l d2hlcmU/ICBJdCB3b3VsZCBiZSBnb29kIHRvDQo+IHNlZSB0aGlzIChhbmQgb3RoZXIgY2hhbmdl cykgaW4gY29udGV4dC4NCg0KWWVzLCBQbGVhc2Ugc2VlIGh0dHBzOi8vZ2l0aHViLmNvbS90aXJl ZGR5Mi9UVVJOYmlzIA0KDQo+IA0KPiA+ID4gU2VjdGlvbiAzIGNvdWxkIGJlbmVmaXQgZnJvbSBh DQo+ID4gPiBzdWJzZWN0aW9uIG9uIHJlcGxheXMgYW5kIHRoZSBub25jZSByb2xlLiBJbiBwYXJ0 aWN1bGFyLCBhcyBsYXRlcg0KPiA+ID4gZGlzY3Vzc2VkIGluIHRoZSBzZWN1cml0eSBjb25zaWRl cmF0aW9ucywgc29tZSBvZiB0aGVzZSBhdHRhY2tzIGFyZQ0KPiA+ID4gbm90IG5ldyB0byBUVVJO IGFuZCBzaG91bGQgdGhlcmVmb3JlIGJlIGRlYWx0IHdpdGggYnkgdGhlDQo+ID4gPiBhcHBsaWNh dGlvbiBwcm90b2NvbCAoU1JUUCkuIFRoaXMgc2VjdGlvbiBtaWdodCBhbHNvIGRlc2NyaWJlIG5v bmNlDQo+ID4gPiByb3RhdGlvbiBwb2xpY2llcyB3aXRoIG1vcmUgc3BlY2lmaWNpdHksIGFzIHRo aXMgaXMgdW5kZXJzcGVjaWZpZWQgaW4gdGhlDQo+IGRvY3VtZW50Lg0KPiA+DQo+ID4gSXQgaXMg ZGlzY3Vzc2VkIGluIFNlY3Rpb24gNSBpbiB0aGUgc3BlY2lmaWNhdGlvbiwgdGhlIHNlcnZlciBz aG91bGQgZXhwaXJlIHRoZQ0KPiBub25jZSBhdCBsZWFzdCBvbmNlIGV2ZXJ5IGhvdXIgZHVyaW5n IHRoZSBsaWZldGltZSBvZiB0aGUgYWxsb2NhdGlvbi4NCj4gPg0KPiA+ID4tIFNlY3Rpb24gMyBj b3VsZCBhbHNvIGJlbmVmaXQgZnJvbQ0KPiA+ID4gZGlzY3Vzc2lvbiBhYm91dCBjbGVhcnRleHQg dmVyc3VzIGVuY3J5cHRpb24gdHJhbnNwb3J0cyBiZXR3ZWVuDQo+ID4gPmNsaWVudHMgYW5kICBz ZXJ2ZXJzLg0KPiA+DQo+ID4gSXQgaXMgZGlzY3Vzc2VkIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0NCj4gMjcjc2VjdGlvbi0yMS4xLjYuDQo+ IA0KPiBUaGVyZSdzIG5vdCBtdWNoIGRpc2N1c3Npb24gYWJvdXQgcG90ZW50aWFsIGluZm9ybWF0 aW9uICBsZWFrYWdlIHZpYSAoZS5nLikNCj4gVVNFUk5BTUUvVVNFUkhBU0gsIGFuZCByZWFsbHkg anVzdCBhIGNsYWltIHRoYXQgdGhlIHBlZXIgYWRkcmVzcyBpcyB0aGUNCj4gInByaW1hcnkgcHJv dG9jb2wgY29udGVudCIuDQoNCkFncmVlZCwgYWRkZWQgdGhlIGZvbGxvd2luZyBwYXJhZ3JhcGgg Og0KDQpJZiB0aGUgVFVSTiBjbGllbnQgYW5kIHNlcnZlciB1c2UgdGhlIFNUVU4gRXh0ZW5zaW9u IGZvciBUaGlyZC1QYXJ0eSBBdXRob3JpemF0aW9uIFtSRkM3NjM1XSwgdGhlIHVzZXJuYW1lIGRv ZXMgbm90IHJldmVhbCB0aGUNCnJlYWwgdXNlcidzIGlkZW50aXR5LCB0aGUgVVNFUk5BTUUgYXR0 cmlidXRlIGNhcnJpZXMgYW4gZXBoZW1lcmFsIGFuZCB1bmlxdWUga2V5IGlkZW50aWZpZXIsIGFu ZCB0aGUga2V5IGlkZW50aWZpZXIgY2FuIGNoYW5nZSBwZXIgY2FsbC4NCklmIHRoZSBUVVJOIGNs aWVudCBhbmQgc2VydmVyIHVzZSB0aGUgU1RVTiBsb25nLXRlcm0gY3JlZGVudGlhbCBtZWNoYW5p c20gYW5kIHRoZSB1c2VybmFtZSByZXZlYWxzIHRoZQ0KcmVhbCB1c2VyJ3MgaWRlbnRpdHksIHRo ZSBjbGllbnQgbmVlZCB0byBlaXRoZXIgdXNlIChEKVRMUyB0cmFuc3BvcnQgYmV0d2VlbiB0aGUg Y2xpZW50IGFuZCB0aGUgc2VydmVyIG9yIHVzZSANCnRoZSBVU0VSSEFTSCBhdHRyaWJ1dGUgaW5z dGVhZCBvZiB0aGUgVVNFUk5BTUUgYXR0cmlidXRlIHRvIGFub255bm1pemUgdGhlIHVzZXJuYW1l Lg0KDQo+IA0KPiA+ID4gRW5jcnlwdGluZyB0aGUgbm9uY2UsIHVzZXJuYW1lLCByZWFsbSwgZXRj LiwgYW1vbmcgb3RoZXIgdGhpbmdzLCBoYXMNCj4gPiA+IG9idmlvdXMgYmVuZWZpdHMuIC0gV2h5 IGFyZSBTT0ZUV0FSRSBhbmQgRklOR0VSUFJJTlQgYXR0cmlidXRlcw0KPiA+ID4gcmVjb21tZW5k ZWQ/ICBJdCBzZWVtcyBsaWtlIGNsaWVudHMgc2hvdWxkIGJlIGRpc2NvdXJhZ2VkIGZyb20NCj4g PiA+IHNlbmRpbmcgdGhlc2UgaWYgYW55dGhpbmcsIGVzcGVjaWFsbHkgaWYgbm90IHVzZWQgdG8g bWFrZSBhbGxvY2F0aW9uDQo+ID4gPiBkZWNpc2lvbnMgb24gdGhlIHNlcnZlci4NCj4gPg0KPiA+ IFVzZXJuYW1lIG1heSBub3QgYmUgdGhlIHVzZXIgaWRlbnRpdHksIFBsZWFzZSBzZWUNCj4gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc2MzUpLCBJdCBjb3VsZCBiZSBhbiBlcGhlbWVy YWwgYW5kIHVuaXF1ZQ0KPiBrZXkgaWRlbnRpZmllci4gRnVydGhlciwgdXNlcm5hbWUgY2FuIGJl IGFub255bWl6ZWQgKHBsZWFzZSBzZWUNCj4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWlldGYtdHJhbS1zdHVuYmlzLTIxI3NlY3Rpb24tMTQuNCkuDQo+ID4gU09GVFdBUkUgYW5k IEZJTkdFUlBSSU5UIGF0dHJpYnV0ZXMgYXJlIGRlZmluZWQgaW4gdGhlIFNUVU4NCj4gc3BlY2lm aWNhdGlvbiwgc2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0t c3R1bmJpcy0yMS4NCj4gDQo+IFRoZXNlIG1lY2hhbmlzbXMgIGFyZSBwYXJ0aWFsIG1pdGlnYXRp b25zIGJ1dCBjYW4gc3RpbGwgYmUgc3VzY2VwdGlibGUgdG8gY3Jvc3MtDQo+IGNvbm5lY3Rpb24g Y29ycmVsYXRpb24gYXR0YWNrcy4NCg0KVGhlIHVzZSBvZiBGSU5HRVJQUklOVCBpcyBub3QgbWFu ZGF0b3J5LCB0aGUgVFVSTiBjbGllbnQgYW5kIHNlcnZlciBtYXkgaW5jbHVkZSB0aGUgRklOR0VS UFJJTlQgYXR0cmlidXRlLiAgTm90ZSB0aGF0IElDRSAoaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzg0NDUpIG1hbmRhdGVzIHRoZSB1c2Ugb2YgRklOR0VSUFJJTlQgYXR0cmlidXRlLiBB ZGRlZCB0aGUgZm9sbG93aW5nIGxpbmUgZm9yIFNPRlRXQVJFIGF0dHJpYnV0ZSAoVFVSTmJpcyBp cyB1c2luZyB0aGUgc2FtZSBiZWhhdmlvciBkZWZpbmVkIGluIFJGQzU3NjYgdG8gdXNlIFNPRlRX QVJFIGF0dHJpYnV0ZSkgIDoNCg0KU09GV0FURSBhdHRyaWJ1dGUgY2FuIHJldmVhbCB0aGUgc3Bl Y2lmaWMgc29mdHdhcmUgdmVyc2lvbiBvZiB0aGUgVFVSTiBjbGllbnQgYW5kIHNlcnZlciB0byBl YXZlc2Ryb3BwZXIgYW5kIGl0IG1pZ2h0IHBvc3NpYmx5IGFsbG93IGF0dGFja3MgYWdhaW5zdCB2 dWxuZXJhYmxlIHNvZnR3YXJlIHRoYXQgaXMga25vd24gdG8gY29udGFpbiBzZWN1cml0eSBob2xl cy4gSWYgaXQgaXMgaW1wb3J0YW50IHRvIHByZXZlbnQgYW4gZWF2ZXNkcm9wcGVyIGZyb20gbGVh cm5pbmcgdGhlIHNvZnR3YXJlIHZlcnNpb24sIFRVUk4gY2FuIGJlIHJ1biBvdmVyIChEKVRMUy4N Cg0KDQo+IA0KPiA+IC0gU2VjdGlvbiA1OiBXaGVuIHNlcnZlcnMgcmVjZWl2ZSBkYXRhIHRoYXQg ZXhjZWVkcyBhbiBhbGxvY2F0aW9u4oCZcw0KPiA+ID4gYmFuZHdpZHRoIHF1b3RhLCBzZXJ2ZXJz IHNpbGVudGx5IGRpc2NhcmQgdGhpcyBkYXRhLiBUaGlzIG1lYW5zDQo+ID4gPiB0aGVyZeKAmXMg bm8gYWxsb2NhdGlvbi1iYXNlZCBmbG93IGNvbnRyb2wgbWVjaGFuaXNtIGJldHdlZW4gY2xpZW50 DQo+ID4gPiBhbmQgc2VydmVyIGJleW9uZCB3aGF04oCZcyBwcm92aWRlZCBieSB0aGUgdHJhbnNw b3J0IHByb3RvY29sLCByaWdodD8NCj4gPg0KPiA+IFllcywgVURQIGRvZXMgbm90IGluY2x1ZGUg YSBjb25nZXN0aW9uIGNvbnRyb2wgbWVjaGFuaXNtLg0KPiA+DQo+ID4gPiBUaGlzIHNlZW1zIGZp bmUsIHRob3VnaA0KPiA+ID4gcGVyaGFwcyBzb21lIGRpc2N1c3Npb24gb2Ygd2h5IHRoaXMgZGVz aWduIGRlY2lzaW9uIHdhcyBtYWRlIHdvdWxkDQo+ID4gPiBiZSBoZWxwZnVsLiBGb3IgZXhhbXBs ZSwgSSBjb3VsZCBpbWFnaW5lIGV4cGxpY2l0IHNpZ25hbHMgZnJvbQ0KPiA+ID4gc2VydmVycyB0 byBjbGllbnRzIHRoYXQgaW5kaWNhdGUgc2VydmVyIHN0YXRlIHdvdWxkIHJldmVhbA0KPiA+ID4g aW5mb3JtYXRpb24gYWJvdXQgb3RoZXIgYWxsb2NhdGlvbnMgb24gdGhlIHNlcnZlciwgd2hpY2gg bWlnaHQgYmUNCj4gPiA+IHByb2JsZW1hdGljLiAtDQo+ID4NCj4gPiBUaGUgZXJyb3JzIDQ4NiAo QWxsb2NhdGlvbiBRdW90YSBFeGNlZWRlZCkgb3IgNTA4IChJbnN1ZmZpY2llbnQgQ2FwYWNpdHkp DQo+IGRvIG5vdCByZXZlYWwgaW5mb3JtYXRpb24gb2Ygd2hpY2ggb3RoZXIgdXNlcnMgYXJlIHVz aW5nIHRoZSBUVVJOIHNlcnZlci4NCj4gDQo+IEF0IGxlYXN0IHRoZSBsYXR0ZXIgc2VlbXMgdG8g Z2l2ZSBzb21lIGluZGljYXRpb24gdGhhdCBtYW55IG90aGVyIHVzZXJzIGFyZQ0KPiB1c2luZyB0 aGUgc2VydmVyIGF0IHRoZSAgdGltZSAoc28gdGhhdCBpdCdzIG92ZXJsb2FkZWQpLCB0aG91Z2gg bm90IGluZm9ybWF0aW9uDQo+IGFib3V0ICp3aGljaCogdXNlcnMgdGhhdCBpcy4NCg0KWWVzLCBz aW1pbGFyIHRvIDUwMyBIVFRQIGVycm9yIHJlc3BvbnNlLg0KDQo+IA0KPiA+ID4gU2VjdGlvbiA3 LjIgc3VnZ2VzdHMgdGhhdA0KPiA+ID4gc2VydmVycyBjYW4gcmVkaXJlY3QgY2xpZW50IGFsbG9j YXRpb24gcmVxdWVzdHMgdG8gb3RoZXIgc2VydmVycy4NCj4gPiA+IENhbiB0aGlzIGNyZWF0ZSBh IGxvb3AsIHdoZXJlaW4gdHdvIFRVUk4gc2VydmVycyByZWRpcmVjdCB0byBvbmUgYW5vdGhlcj8N Cj4gPg0KPiA+IFRoZSBjbGllbnQgZGV0ZWN0IGFuZCBzdG9wIHRoZSBsb29wLCBpdCBpcyBzaW1p bGFyIHRvIEhUVFAgcmVkaXJlY3Rpb24uDQo+IA0KPiBXaGVyZSBpcyB0aGlzIHNwZWNpZmllZD8N Cg0KSXQgaXMgc3BlY2lmaWVkIGluIHRoZSBsYXN0IHBhcmFncmFwaCBvZiBodHRwczovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXN0dW5iaXMtMjEjc2VjdGlvbi0xMCANCg0K PHNuaXA+DQpJZiB0aGUgY2xpZW50IGhhcyBiZWVuIHJlZGlyZWN0ZWQgdG8gYQ0Kc2VydmVyIHRv IHdoaWNoIGl0IGhhcyBhbHJlYWR5IHNlbnQgdGhpcyByZXF1ZXN0IHdpdGhpbiB0aGUgbGFzdCBm aXZlDQptaW51dGVzLCBpdCBNVVNUIGlnbm9yZSB0aGUgcmVkaXJlY3Rpb24gYW5kIGNvbnNpZGVy IHRoZSB0cmFuc2FjdGlvbg0KdG8gaGF2ZSBmYWlsZWQuICBUaGlzIHByZXZlbnRzIGluZmluaXRl IHBpbmctcG9uZ2luZyBiZXR3ZWVuIHNlcnZlcnMNCmluIGNhc2Ugb2YgcmVkaXJlY3Rpb24gbG9v cHMuDQo8L3NuaXA+DQoNCkNoZWVycywNCi1UaXJ1DQoNCj4gDQo+IFRoYW5rcywNCj4gDQo+IEJl bg0KPiANCj4gPiA+IE1vcmVvdmVyLA0KPiA+ID4gaXMgaXQgYWNjZXB0YWJsZSBmb3Igb25lIFRV Uk4gc2VydmVyIHRvIHJlZGlyZWN0IHRvIGFuIHVucmVsYXRlZCBUVVJODQo+IHNlcnZlcj8NCj4g PiA+IChJdCBzaG91bGQgYmUgbWFkZSBjbGVhciBoZXJlIHRoYXQgdGhlc2UgcmVzcG9uc2VzIGFy ZQ0KPiA+ID4gYXV0aGVudGljYXRlZCwgYXMgb3RoZXJ3aXNlIGl0IHdvdWxkIGJlIHBvc3NpYmxl IGZvciBhbiBvbi1wYXRoDQo+ID4gPiBhZHZlcnNhcnkgdG8gcmVkaXJlY3QgYWxsb2NhdGlvbiBy ZXF1ZXN0cyB0byBhIHNlcnZlciBpdCBvd25zLikNCj4gPg0KPiA+IEl0IGlzIGFscmVhZHkgZGlz Y3Vzc2VkIGluDQo+ID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJh bS1zdHVuYmlzLTIxI3NlY3Rpb24tMTANCj4gPg0KPiA+ID4gLSBTZWN0aW9uDQo+ID4gPiAyMS4x LjI6IFVzZSBvZiAoRClUTFMgZG9lc27igJl0IGhlbHAgYWdhaW5zdCBkaWN0aW9uYXJ5IGF0dGFj a3MgbXVjaCwNCj4gPiA+IHNpbmNlIHByZXN1bWFibHkgdGhlcmXigJlzIGxvdyBlbnRyb3B5IGlu IHVzZXJuYW1lcyBhbmQgcGFzc3dvcmRzDQo+ID4gPiBhbGlrZS4gVGh1cywgSSBxdWVzdGlvbiB3 aGV0aGVyIHRoaXMgaXMgYSDigJxzdHJvbmdlcuKAnSBtaXRpZ2F0aW9uLg0KPiA+DQo+ID4gVGhl IHNlY3Rpb24gb25seSBkaXNjdXNzZXMgIm9mZmxpbmUiIGRpY3Rpb25hcnkgYXR0YWNrLCBIb3cg aXMgb2ZmbGluZQ0KPiBkaWN0aW9uYXJ5IGF0dGFjayBwb3NzaWJsZSB3aXRoIChEKVRMUyA/DQo+ ID4NCj4gPiA+LSBTZWN0aW9uIDEyLjEuNjog4oCcdXNlcm5hbWXigJ0NCj4gPiA+IGFuZCDigJxy ZWFsbeKAnSBhcmUgbm90IGNvbnNpZGVyZWQgc2Vuc2l0aXZlPyBUaGV5IHNlZW0gc2Vuc2l0aXZl IHRvIG1lLg0KPiA+ID4tIEFzIGFuICBleHRlbnNpb24sIGl0IHNlZW1zIHBvc3NpYmxlIHRvIGlt cHJvdmUgb24gd2hhdOKAmXMgaW4gU1RVTi4NCj4gPiA+Rm9yIGV4YW1wbGUsIGl0ICBtYXkgYmUg d29ydGh3aGlsZSwgaGVyZSBvciBlbHNld2hlcmUsIHRvIHVwZGF0ZQ0KPiA+ID5TVFVO4oCZcyBs b25nIHRlcm0gIGNyZWRlbnRpYWwga2V5IGRlcml2YXRpb24gcHJvY2VzcyAoTUQ1KHVzZXJuYW1l ICsNCj4gPiA+cmVhbG0gKyBwYXNzd29yZCkpIHRvICBzb21ldGhpbmcgYSBiaXQgbW9yZSBtb2Rl cm4uIFRoaXMgaXMgcXVpdGUNCj4gPiA+bGlrZWx5IG91dCBvZiBzY29wZSwgdGhvdWdoIGluIHRo ZSAgY29udGV4dCBvZiBjbGllbnQgYXV0aGVudGljYXRpb24NCj4gPiA+aXQgc2VlbXMgd29ydGgg bWVudGlvbmluZyB0aGF0IFRVUk4gaXMgIGxpbWl0ZWQgdG8gdGhlIG1lY2hhbmlzbXMNCj4gcHJv dmlkZWQgYnkgU1RVTi4NCj4gPg0KPiA+IEFzIG1lbnRpb25lZCBwcmV2aW91c2x5LCB1c2VybmFt ZSBtYXkgbm90IGJlIHRoZSBlbmQtdXNlciByZWFsIGlkZW50aXR5DQo+IGFuZCB1c2VybmFtZSBj YW4gYmUgYW5vbnltaXplZC4NCj4gPg0KPiA+ID4NCj4gPiA+IE5pdHMgYW5kIG90aGVyIGNvbW1l bnRzOg0KPiA+ID4NCj4gPiA+IC0gU2VjdGlvbiAyOiDigJxtZXNzYWdlLWRpZ2VzdOKAnSBpcyB1 bmRlZmluZWQgaW4gdGhlIE5vbmNlIGRlZmluaXRpb24uDQo+ID4NCj4gPiBUaGFua3MsIHJlcGxh Y2VkICJtZXNzYWdlLWRpZ2VzdCIgd2l0aCAic2VydmVyIHJlc3BvbnNlIg0KPiA+DQo+ID4gPiAt IFNlY3Rpb24gMzogSXTigJlzIHByb2JhYmx5IHdvcnRoIGNpdGluZyBSRkM4NDQ2IGFzIHRoZSBy ZWNvbW1lbmRlZA0KPiA+ID4gdmVyc2lvbiBvZiBUTFMuDQo+ID4NCj4gPiBUaGUgZHJhZnQgc2F5 cyBndWlkYW5jZSBnaXZlbiBpbiBbUkZDNzUyNV0gTVVTVCBiZSBmb2xsb3dlZCB0byBhdm9pZA0K PiBhdHRhY2tzIG9uIChEKVRMUy4gUkZDNzUyNSBzYXlzIFRMUyAxLjMgcmVzb2x2ZXMgdGhlIHZ1 bG5lcmFiaWxpdGllcyBmb3VuZCBpbg0KPiBwcmV2aW91cyBUTFMgdmVyc2lvbnMuDQo+ID4NCj4g PiA+LSBTZWN0aW9uIDMuNDogSXQgbWlnaHQgYmUgd29ydGggbWVudGlvbmluZyB0aGF0IHVzZSBv ZiAoRClUTFMgZm9yDQo+ID4gPnRoZSAgY2xpZW50LXRvLXNlcnZlciB0cmFuc3BvcnQgbWl0aWdh dGVzIHRoZSBuZWVkIGZvciBTZW5kIGFuZCBEYXRhDQo+ID4gPmF1dGhlbnRpY2F0aW9uLg0KPiA+ DQo+ID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtdHJhbS10dXJuYmlz LTI3I3NlY3Rpb24tMjEuMS40DQo+IGRpc2N1c3NlcyB0aGlzIGlzc3VlIGluIGRldGFpbC4NCj4g Pg0KPiA+ID4gLSBTZWN0aW9uIDMuNDogV2hhdCBkb2VzIOKAnHByb3BlciBzZWN1cml0eeKAnSBt ZWFuPw0KPiA+DQo+ID4gVGhhbmtzLCByZXBsYWNlZCAicHJvcGVyIHNlY3VyaXR5IiB3aXRoICJl bmQtdG8tZW5kIHNlY3VyaXR5Ii4NCj4gPg0KPiA+ID4tIEZpZ3VyZSA0OiBBZGRpbmcgYW5vdGhl cg0KPiA+ID4gbWVzc2FnZSBleGNoYW5nZSB3aGVyZWluIGEgY2hhbm5lbCBtZXNzYWdlIGlzIHNl bnQgd2l0aG91dCBhIHByaW9yDQo+ID4gPkNoYW5uZWxCaW5kIHJlcXVlc3Qgd291bGQgYmUgdXNl ZnVsIHRvIGhpZ2hsaWdodCB0aGlzIGRlcGVuZGVuY3kgYW5kDQo+ID4gPmV4cGVjdGVkIGJlaGF2 aW9yIGZyb20gY2xpZW50cyBhbmQgc2VydmVycy4NCj4gPg0KPiA+IGh0dHBzOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0yNyNzZWN0aW9uLTEyLjYgZXhwbGFp bnMNCj4gdGhhdCBJZiB0aGUgQ2hhbm5lbERhdGEgbWVzc2FnZSBpcyByZWNlaXZlZCBvbiBhIGNo YW5uZWwgdGhhdCBpcyBub3QgYm91bmQgdG8NCj4gYW55IHBlZXIsIHRoZW4gdGhlIG1lc3NhZ2Ug aXMgc2lsZW50bHkgZGlzY2FyZGVkLg0KPiA+DQo+ID4gPiAtIFNlY3Rpb24gMy42OiBBbm90aGVy IGJlbmVmaXQgb2YNCj4gPiA+IHRoaXMgdXNlciBzcGFjZSBkZXNpZ24gZGVjaXNpb24gaXMgdXNl IG9mIChEKVRMUyBsaW5rcy4gLQ0KPiA+DQo+ID4gR29vZCBwb2ludCwgdXBkYXRlZCBsaW5lIHRv IHNheToNCj4gPiBmb3IgZXhhbXBsZSwgdG8gYWxsb3cgYSBUVVJOIHNlcnZlciB0byBiZSBpbnRl Z3JhdGVkIGludG8gYSBwZWVyLXRvLXBlZXINCj4gYXBwbGljYXRpb24gc28gdGhhdCBvbmUgcGVl ciBjYW4gb2ZmZXIgTkFUIHRyYXZlcnNhbCBzZXJ2aWNlcyB0byBhbm90aGVyIHBlZXINCj4gYW5k IHRvIHVzZSAoRClUTFMgdG8gc2VjdXJlIHRoZSBUVVJOIGNvbm5lY3Rpb24uDQo+ID4NCj4gPiAg U2VjdGlvbiA1OiBXaGVyZSBkaWQNCj4gPiA+IHRoZSA0MCBzZWNvbmQgcmVxdWVzdCBidWZmZXIg dGltZW91dCBjb21lIGZyb20/DQo+ID4NCj4gPiBJdCBpcyBjb21pbmcgZnJvbSB0aGUgU1RVTiBz cGVjaWZpY2F0aW9uIChzZWUNCj4gPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi10cmFtLXN0dW5iaXMtMjEjc2VjdGlvbi02LjMuMSkNCj4gPg0KPiA+ID4gQWRkaW5nIHNv bWUgZGV0YWlscw0KPiA+ID4gbWlnaHQgaGVscC4gLSBTZWN0aW9uIDY6IOKAnHNlY3VyZSBoYXNo 4oCdIGlzIHVuZGVmaW5lZCwgdGhvdWdoDQo+ID4gPiBwcmVzdW1hYmx5IHdoYXQgaXMgbWVhbnQg aXMgYSBjcnlwdG9ncmFwaGljIGhhc2ggd2l0aCBjb2xsaXNpb24NCj4gPiA+IHJlc2lzdGFuY2Uu IEl0IHdvdWxkIGJlIGdvb2QgdG8gY2xhcmlmeSB0aGlzIHJlcXVpcmVtZW50Lg0KPiA+DQo+ID4g WWVzLCByZXBsYWNlZCB3aXRoICIgY3J5cHRvZ3JhcGhpYyBoYXNoIi4NCj4gPg0KPiA+ID4gLSBT ZWN0aW9uIDcuNDogV2hhdCBpcyB0aGUgcmV0cnkgYmVoYXZpb3IgaWYgYWxsb2NhdGlvbiByZXF1 ZXN0cw0KPiA+ID4gdGltZW91dD8NCj4gPg0KPiA+IFRoZSByZXRyeSBiZWhhdmlvciBpcyBkaXNj dXNzZWQgYXMgZm9sbG93czoNCj4gPg0KPiA+ICAgIG8gIChSZXF1ZXN0IHRpbWVkIG91dCk6IFRo ZXJlIGlzIGVpdGhlciBhIHByb2JsZW0gd2l0aCB0aGUgc2VydmVyLCBvcg0KPiA+ICAgICAgIGEg cHJvYmxlbSByZWFjaGluZyB0aGUgc2VydmVyIHdpdGggdGhlIGNob3NlbiB0cmFuc3BvcnQuICBU aGUNCj4gPiAgICAgICBjbGllbnQgY29uc2lkZXJzIHRoZSBjdXJyZW50IHRyYW5zYWN0aW9uIGFz IGhhdmluZyBmYWlsZWQgYnV0IE1BWQ0KPiA+ICAgICAgIGNob29zZSB0byByZXRyeSB0aGUgQWxs b2NhdGUgcmVxdWVzdCB1c2luZyBhIGRpZmZlcmVudCB0cmFuc3BvcnQNCj4gPiAgICAgICAoZS5n LiwgVENQIGluc3RlYWQgb2YgVURQKS4NCj4gPg0KPiA+DQo+ID4gPi0gU2VjdGlvbiAxMi41OiBU aGUgU1RVTiByZXF1aXJlbWVudCBmb3IgNC1ieXRlICBhbGlnbm1lbnQgc2hvdWxkIGJlDQo+ID4g PmNpdGVkIHdoZW4gZGlzY3Vzc2luZyB0aGUgVENQIGFuZCBUTFMgcGFkZGluZyAgcmVxdWlyZW1l bnQuDQo+ID4NCj4gPiBEb25lLg0KPiA+DQo+ID4gPiAtIFNlY3Rpb24gMTU6IFR5cG8g4oCcRE9O 4oCZVCBGUkFHTUVOVOKAnS4NCj4gPg0KPiA+IEZpeGVkLg0KPiA+DQo+ID4gQ2hlZXJzLA0KPiA+ IC1UaXJ1DQo+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IHRyYW0gbWFpbGluZyBsaXN0DQo+ID4gPiB0 cmFtQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3RyYW0NCg== From nobody Wed Jul 10 14:01:45 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F904120025; Wed, 10 Jul 2019 14:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1AE0f2Q3c2HZ; Wed, 10 Jul 2019 14:01:40 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01AC4120147; Wed, 10 Jul 2019 14:01:39 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x6AL1P0e027682 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Jul 2019 00:01:25 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x6AL1PuI028215; Thu, 11 Jul 2019 00:01:25 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23846.21029.236657.158497@fireball.acr.fi> Date: Thu, 11 Jul 2019 00:01:25 +0300 From: Tero Kivinen To: "Pascal Thubert \(pthubert\)" Cc: David Mandelberg , "secdir\@ietf.org" , "iesg\@ietf.org" , "draft-ietf-6tisch-architecture.all\@ietf.org" , Thomas Watteyne , Michael Richardson , =?utf-8?Q?Mali=B9a_Vu=E8ini=E6?= In-Reply-To: References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> <23825.24715.882644.180316@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 53 min X-Total-Time: 54 min Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 21:01:44 -0000 I am now back from my eclipse trip, so I will try to answer some of these emails appeared while I was on vacation. Pascal Thubert (pthubert) writes: > > Now, if JN is using extended address to generate nonce, the nonce will be > > different for all other nonces ever used, even the ASN is faked, and has been > > This is assuming that the attacker is not attacking the same device > twice, isn't it? True, and actually the easiest thing is to attack same JN again. This example assumes that slotframe is 100 and there is one shared slot in slotframe which is the first slot there, thus if asn % 100 then that is shared slot, used for beacons, and joining messages etc. JN attacker JRC -- ------- --- <-- beacon with ASN=1000, Src=JRC save beacon receive beacon wait for shared next slot, send joining request clear text joining request ASN=1100, Src=JN --> <-- Enh-Ack ASN=1100, Src=JRC receive ack, wait for reply <-- clear text joining reply ASN=1200, Src=JRC save joining reply receive reply, JN has joined network, receives L2 key K1, starts using it. sends Enh-Ack --> JN starts some upper layer protocol procedure having some secret information proteced by L2 security with K1, ASN=2200, Src=JN --> save message <-- Enh-Ack ASN=2200, Src=JRC save copy of Enh-ack, but destroy it so JN does not get ack, thus JN will retranmits JN waits for random amount of shared slots and then retransmits previous packet with new ASN, i.e., encrypts packet again with K1, ASN=2900, Src=Jn save another copy with another ASN. These are just to make attacker easier later, as attacker might want to have multiple copies with different ASNs just in case JN does not happen to use same ASN next time than it used last time. After enough copies of messages attacker can kill JN from network and cause it to reboot JN reboots, starts over JN listens beacons <-- replays beacon with ASN=1000, Src=JRC, on channel X <-- beacon with ASN=9000, Src=JRC, on channel Y, where X and Y are not same unless ASNs % channels happen to match, attacker can make them so that they do not match, which means JN will never hear any real packets as it is using wrong offset to hopping sequnce. clear text joining request this assumes this is exactly same request than last time, i.e., the persistent counter in joining request did not get incremented on the failed attempt to join, or at least same reply is acceptable to JN. ASN=1100, Src=JN --> <-- attacker replies with Enh-Ack ASN=1100, Src=JRC receive ack, wait for reply <-- attacker replays joining reply ASN=1200, Src=JRC receive reply, JN has joined network, receives L2 key K1, starts using it. sends Enh-Ack --> JN starts some upper layer protocol procedure having some secret information proteced by L2 security with K1, ASN=2200, Src=JN --> <-- attacker replays with stored Enc-Ack with ASN=2200, Src=JN. This is just to allow JN to go forward. JN sends next request protected by L2 security with K1, ASN=2900, Src=JN --> And now attacker got two different messages encrypted with same key K1, with same nonce (ASN=2900), so it can just xor them together and get xor of plain text packets, thus can perhaps find out secret data from one of the packets. If first ASN does happen to match, it will wait for next retransmission and at some point attacker might see ASN with packet which it stored earlier. If this does not happen, it will simply cause JN to start over again, and repeat the process. > > used before. On the other hand if JN also receives short address assignment > > from the JRC, JRC needs to make sure that short address has not been > > assigned to anybody else before, as if it was used by someone else, and frame > > sent by JN is encrypted, then attacker will now have two packets with same > > ASN, and short address, meaning same nonce, and it can now decrypt packets. > > That's unless new keys are given if the short address is reattributed, correct? Yes, but as I shown above the attack also works while using extended addresses, but then it works against the same node. > > Note, that attacker might be able to replay valid ACKs for the frame sent by > > the JN, provided that the JRC (or whoever JN sent the message > > to) happened to ack message using the same ASN attacker faked for JN. > > Your mean that the faked ASN is only slightly in the future, so the > attacker can repeat messages from the pledge after that delay? No, the attacker can collect copies of Enh-Acks from the previous packet exchanges between JRC and JN. Actually all the joining traffic happens happens without L2 security, so attacker can simply send normal non authenticated Enc-Acks back. Only place where the attacker wants to replay saved encrypted Enc-Acks are the first real protocol packet exachanges. With short addresses this is can be easier, than with extended addresses, but if short addresses are never reused with same key, then that should block short address issues. This attack against same node do require that JN will accept replayed reply from JRC, and I do not think it will, if I remember there was counter in the oscore or something, that got incremented for every request, and JN would check that it will not accept replayed replies. Or was it so that only JRC checks for replays? -- kivinen@iki.fi From nobody Wed Jul 10 14:14:35 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 3635912014E for ; Wed, 10 Jul 2019 14:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=unavailable 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 6cmR35HMit8u for ; Wed, 10 Jul 2019 14:14:32 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F424120025 for ; Wed, 10 Jul 2019 14:14:31 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x6ALE53w025419 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Jul 2019 00:14:05 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x6ALE5Tf013629; Thu, 11 Jul 2019 00:14:05 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23846.21789.391089.209823@fireball.acr.fi> Date: Thu, 11 Jul 2019 00:14:05 +0300 From: Tero Kivinen To: "Pascal Thubert \(pthubert\)" Cc: David Mandelberg , =?utf-8?Q?Mali=C5=A1a_Vu=C4=8Dini=C4=87?= , Michael Richardson , "secdir\@ietf.org" , "iesg\@ietf.org" , "draft-ietf-6tisch-architecture.all\@ietf.org" In-Reply-To: References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 13 min X-Total-Time: 12 min Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2019 21:14:34 -0000 Pascal Thubert (pthubert) writes: > With 6TiSCH, the pledge discovers a tentative ASN in beacons sent by > nodes that have already joined the network. As the pledge is not in > possession of Link-Layer keys for the visited network, it cannot > verify the message integrity code (MIC) authenticating the beacon. > Even if it did have the keys, it still could not verify the beacon as > it could be a replay by an attacker and thus could still announce an > ASN that represents a time in the past. That time would match a > valid timeslot it if is correct modulo the number of channels used for > hopping. Note, that attacker can pick time, and channel correctly so that it will always match. I.e., if he wants to reply beacon with ASN=1235 and that was sent on channel X, it simply needs to replay that same ASN=1235 on channel X, regardless what current ASN and channel would be for others in the network. It is actually beneficial for it to use some offset, so JN will not accidently see any real messages... Most likely JN will start listening beacons on channel X, then if does not hear anything for some time, it moves to X+1 etc. Most likely it will stay on channel X so long that it will hear beacon from there. So attacker stores that beacon on channel X and the ASN is so that it is assuming channel X for hopping. Now if attacker retransmits this out on channel X immediately when it assumes JN is listening, JN will pick it, and will then pick wrong offset for channel hopping. So, that sentence about Time and module to number of channels, is not useful. > After obtaining that tentative ASN, the pledge authenticates itself > to the network using some mechanism outside of IEEE Std 802.15.4. > With 6TiSCH, a Join Proxy (JP) helps the pledge for the join > procedure by relaying the link-scope Join Request over the IP network > to a Join Registrar/Coordinator (JRC) that can authenticate the > pledge and validate that it is attached to the appropriate network. > As a result of this exchange the pledge is in possession of a Link- > Layer material including a key and a short address, and assuming that > the ASN is correct, all traffic can be secured at the Link-Layer. > > This authentication steps must be such that they cannot be replayed > by an attacker, and it must not depend on th tentative ASN being > valid. Note that IEEE std. 802.15.4 TSCH does not provide replay > protection at all, and that for instance attacker can cause a > legitimate node to retransmit a previous message by destroying an > ack. It results and upper layer protocol must provide a way to detect > replayed messages and cope with them. > > During the authentication the keying material that the pledge obtains > from the JRC does NOT provide protection against spoofed ASN. Once > the pledge has obtained the keys to use in the network, it still > needs to verify the ASN. If the nonce used in the Layer-2 security > derives from the extended (MAC-64) address, then replaying the ASN > alone cannot enable a nonce-reuse attack unless the same node is > attacked twice and loses all state in-between. But if the nonce > derives from the short address (e.g., assigned by the JRC) then the > nonce-reuse attacks are possible, and the JRC must ensure that it > never assigns short addresses that were already given to this or > other nodes with the same keys. > > At that point, an additional step may be required to ensure that the > ASN is correct. For instance, the pledge could perform a first > exchange with a peer node that is trusted and has already joined, > e.g., its RPL time parent, and the message should not be encrypted > but only authenticated at the Link-Layer. The request from the > pledge should contain a nonce with a random part that is not ASN, and > the authenticated response should contain the current ASN and echo > the nonce. Sending ASNs in the mssage is almost impossible, as upper layer does not have any idea what ASN will be used to send message out. It does not know when the next slot to the JN will be, and it does not know whether that slot will be free etc. Because of this I think it is better to use some other method, i.e., if JN just generates random cookie and sends that to JP/JRC, and JP/JRC will then echo that same cookie back then JN will know that exchange is fresh, and if that was authenticated using L2 key K1, then ASN was implictly verified also, as JP/JRC who do know correct ASN, will drop the incoming frame as it will have wrong MIC because of wrong nonce. -- kivinen@iki.fi From nobody Wed Jul 10 16:33:32 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 2D34C120222; Wed, 10 Jul 2019 16:33:17 -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.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Christian Huitema Message-ID: <156280159709.15552.7625042656517587687@ietfa.amsl.com> Date: Wed, 10 Jul 2019 16:33:17 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-mpls-egress-protection-framework-06 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, 10 Jul 2019 23:33:17 -0000 Reviewer: Christian Huitema Review result: Ready The additional paragraph in the security section addresses the issue pointed out in the previous review. From nobody Thu Jul 11 04:31:58 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 426EE120099; Thu, 11 Jul 2019 04:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=hh/lt3To; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=CUgEKWih 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 TE3e-Vji2dzg; Thu, 11 Jul 2019 04:31:48 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 388F3120045; Thu, 11 Jul 2019 04:31:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5837; q=dns/txt; s=iport; t=1562844708; x=1564054308; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=rGRU8WBEVt8I7NRy2AkepQIBJaNjB0mihEfvSSMO1NA=; b=hh/lt3To0qCSm0mN4/vnE6i9vmT0YcCW0iEVNRjtYNtG26+Lz3+85UnU YEp92NLnoUILNZmGw6/AGeek/5YT8Zljv0VkduheSnZbsw3cNRZQ2c2I7 11NqpCPeY58gs7gk9fyd7Wy1rqWOD2hCjqYpNEuj3zIonZoyh/hywR2ic E=; IronPort-PHdr: =?us-ascii?q?9a23=3AIhQbHhSjIHpE2Hb6Zj4JkZuQ8tpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjQmHNlIWUV513q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BrBQCaHSdd/40NJK1lHAEBAQQBAQc?= =?us-ascii?q?EAQGBZ4FEKScDalUgBAsoh2MDjkZMgg+XSoJSA1QJAQEBDAEBIwoCAQGEQAK?= =?us-ascii?q?CUyM4EwEDAQEEAQECAQVthTwMhUoBAQEBAxIuAQE3AQsEAgEIEQEDAQEvMhc?= =?us-ascii?q?GCAIEDgUIGoMBgWoDHQECDKERAoE4iGCCI4J5AQEFhQMYghIDBoE0iRaCLB0?= =?us-ascii?q?XgUA/gRFGgU5+PoJhAQECAYFggzqCJowPnkwJAoIZhliNS4IshyKOM5R0kAA?= =?us-ascii?q?CBAIEBQIOAQEFgWchgVhwFYMngkEMF4EDAQKCSIUUhT9ygSmMGSuCJQEB?= X-IronPort-AV: E=Sophos;i="5.63,478,1557187200"; d="scan'208";a="373851864" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Jul 2019 11:31:46 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x6BBVkMP022919 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Jul 2019 11:31:46 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 11 Jul 2019 06:31:45 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 11 Jul 2019 06:31:45 -0500 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 11 Jul 2019 06:31:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NVWCRHaRJlhpQR1p2/jdyjFs8ewGghO+ya0w2FBmjbA=; b=CUgEKWih6AskKETLWgeKQwcglSViCV9Pc+hXCSF4of758qtHtM2TcOty80D1Mnv8AgeqpZ/hXTLrTqAOj9IocVwWhqEdom0ox/Sk9wTkyLggVL9O1NHQR4jlNZEvKznnmrw2YL0swnD+Edy8wRF08MWtKzz7iBfcb5ZPCzpozGI= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3901.namprd11.prod.outlook.com (10.255.180.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.19; Thu, 11 Jul 2019 11:31:44 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::1ce9:1582:146c:c50a%6]) with mapi id 15.20.2052.022; Thu, 11 Jul 2019 11:31:44 +0000 From: "Pascal Thubert (pthubert)" To: Tero Kivinen CC: David Mandelberg , =?iso-8859-2?Q?Mali=B9a_Vu=E8ini=E6?= , Michael Richardson , "secdir@ietf.org" , "iesg@ietf.org" , "draft-ietf-6tisch-architecture.all@ietf.org" Thread-Topic: secdir review of draft-ietf-6tisch-architecture-21 Thread-Index: AQHVKitVZAMqDsUZHEuS/CYS/vDUhKasV4DggBgc+ICAAO6ZoA== Date: Thu, 11 Jul 2019 11:31:34 +0000 Deferred-Delivery: Thu, 11 Jul 2019 11:30:59 +0000 Message-ID: References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> <23846.21789.391089.209823@fireball.acr.fi> In-Reply-To: <23846.21789.391089.209823@fireball.acr.fi> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com; x-originating-ip: [2001:420:c0c0:1002::1b3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0d299f7b-427e-48b8-ace9-08d705f359ed x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MN2PR11MB3901; x-ms-traffictypediagnostic: MN2PR11MB3901: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0095BCF226 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(396003)(39860400002)(136003)(366004)(189003)(199004)(13464003)(66446008)(64756008)(66556008)(66476007)(66946007)(55016002)(966005)(86362001)(478600001)(5660300002)(81166006)(316002)(76116006)(66574012)(46003)(11346002)(99286004)(6306002)(2906002)(476003)(8936002)(446003)(6246003)(9686003)(229853002)(6436002)(53936002)(186003)(4326008)(81156014)(6116002)(25786009)(102836004)(54906003)(6506007)(6666004)(33656002)(305945005)(74316002)(256004)(76176011)(5024004)(71190400001)(14444005)(53546011)(14454004)(52536014)(71200400001)(68736007)(6916009)(8676002)(7696005)(7736002)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3901; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: GCa/eVIIdG46t7zxGpQm/ugW5bvHQtPZ8PPiInSdCWIAtfaw2RVZMtmmDRlQslic2oEz4J7IJNxNSJVdZCgWAyt82PfmLEFcZL5yo3g75HMYqx5/JBp8NcQYwseFkR+B9H6SRDa/GsITcFNxs1MdFTlShkh1JrjAPp1dLX0bVn8oqU6PKUg2d/sRnW7JnB8Te91bKEt04GwpOgaT5sHGo2JrfAygEC5EL26JxKSVcyDaH3j1gOFmD2C5Gc8pGkxHoPDOlsk6n84AoeR71U61CtyRqG93+U/6dYENJzW88rqnDbBMYyxn1wRAMTKWewaKPbJhYVrA/8Z7PJL7fHqAarY3LVh8kZl9cL11XTUmuae6KJvFEGTlv+Bu+pgwvFJnhVzbQgZu3Sh20a9AbffxcHYAUksI0lfrcTp/nFLAVSM= Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0d299f7b-427e-48b8-ace9-08d705f359ed X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 11:31:43.8815 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pthubert@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3901 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 11:31:52 -0000 All good, Tero. I think we are in perfect line. If you can find the time please have a look= at https://tools.ietf.org/html/draft-ietf-6tisch-architecture-24#section-6= to make sure all is correct, I think it is. At this point it is up to Malisa to add more details in the security sectio= n of minimal security and I trust that this thread helps. All the best, Pascal > -----Original Message----- > From: Tero Kivinen > Sent: mercredi 10 juillet 2019 23:14 > To: Pascal Thubert (pthubert) > Cc: David Mandelberg ; Mali=B9a Vu=E8ini=E6 > ; Michael Richardson ; > secdir@ietf.org; iesg@ietf.org; draft-ietf-6tisch-architecture.all@ietf.o= rg > Subject: RE: secdir review of draft-ietf-6tisch-architecture-21 >=20 > Pascal Thubert (pthubert) writes: > > With 6TiSCH, the pledge discovers a tentative ASN in beacons sent by > > nodes that have already joined the network. As the pledge is not in > > possession of Link-Layer keys for the visited network, it cannot > > verify the message integrity code (MIC) authenticating the beacon. > > Even if it did have the keys, it still could not verify the beacon a= s > > it could be a replay by an attacker and thus could still announce an > > ASN that represents a time in the past. That time would match a > > valid timeslot it if is correct modulo the number of channels used f= or > > hopping. >=20 > Note, that attacker can pick time, and channel correctly so that it will = always > match. I.e., if he wants to reply beacon with ASN=3D1235 and that was sen= t on > channel X, it simply needs to replay that same > ASN=3D1235 on channel X, regardless what current ASN and channel would be > for others in the network. It is actually beneficial for it to use some o= ffset, so > JN will not accidently see any real messages... >=20 > Most likely JN will start listening beacons on channel X, then if does no= t hear > anything for some time, it moves to X+1 etc. Most likely it will stay on = channel > X so long that it will hear beacon from there. So attacker stores that be= acon > on channel X and the ASN is so that it is assuming channel X for hopping. >=20 > Now if attacker retransmits this out on channel X immediately when it > assumes JN is listening, JN will pick it, and will then pick wrong offset= for > channel hopping. >=20 > So, that sentence about Time and module to number of channels, is not > useful. >=20 > > After obtaining that tentative ASN, the pledge authenticates itself > > to the network using some mechanism outside of IEEE Std 802.15.4. > > With 6TiSCH, a Join Proxy (JP) helps the pledge for the join > > procedure by relaying the link-scope Join Request over the IP networ= k > > to a Join Registrar/Coordinator (JRC) that can authenticate the > > pledge and validate that it is attached to the appropriate network. > > As a result of this exchange the pledge is in possession of a Link- > > Layer material including a key and a short address, and assuming tha= t > > the ASN is correct, all traffic can be secured at the Link-Layer. > > > > This authentication steps must be such that they cannot be replayed > > by an attacker, and it must not depend on th tentative ASN being > > valid. Note that IEEE std. 802.15.4 TSCH does not provide replay > > protection at all, and that for instance attacker can cause a > > legitimate node to retransmit a previous message by destroying an > > ack. It results and upper layer protocol must provide a way to detec= t > > replayed messages and cope with them. > > > > During the authentication the keying material that the pledge obtain= s > > from the JRC does NOT provide protection against spoofed ASN. Once > > the pledge has obtained the keys to use in the network, it still > > needs to verify the ASN. If the nonce used in the Layer-2 security > > derives from the extended (MAC-64) address, then replaying the ASN > > alone cannot enable a nonce-reuse attack unless the same node is > > attacked twice and loses all state in-between. But if the nonce > > derives from the short address (e.g., assigned by the JRC) then the > > nonce-reuse attacks are possible, and the JRC must ensure that it > > never assigns short addresses that were already given to this or > > other nodes with the same keys. > > > > At that point, an additional step may be required to ensure that the > > ASN is correct. For instance, the pledge could perform a first > > exchange with a peer node that is trusted and has already joined, > > e.g., its RPL time parent, and the message should not be encrypted > > but only authenticated at the Link-Layer. The request from the > > pledge should contain a nonce with a random part that is not ASN, an= d > > the authenticated response should contain the current ASN and echo > > the nonce. >=20 > Sending ASNs in the mssage is almost impossible, as upper layer does not > have any idea what ASN will be used to send message out. It does not know > when the next slot to the JN will be, and it does not know whether that s= lot > will be free etc. >=20 > Because of this I think it is better to use some other method, i.e., if J= N just > generates random cookie and sends that to JP/JRC, and JP/JRC will then ec= ho > that same cookie back then JN will know that exchange is fresh, and if th= at > was authenticated using L2 key K1, then ASN was implictly verified also, = as > JP/JRC who do know correct ASN, will drop the incoming frame as it will h= ave > wrong MIC because of wrong nonce. > -- > kivinen@iki.fi From nobody Thu Jul 11 15:27:58 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 110901200DB; Thu, 11 Jul 2019 15:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_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=heapingbits.net header.b=KZYhR+SN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=zHX2Wvpk 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 J4nrfVwvj7AZ; Thu, 11 Jul 2019 15:27:52 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4EE11200B6; Thu, 11 Jul 2019 15:27:52 -0700 (PDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id D443A220BA; Thu, 11 Jul 2019 18:27:51 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute6.internal (MEProxy); Thu, 11 Jul 2019 18:27:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type:content-transfer-encoding; s=fm1; bh=6V NbfZFwSDaPF+hX8BUwuR4yZ86wlHBpSPfd9ywphSE=; b=KZYhR+SN4p7oJ1zSH2 R8dK0cDnqWxEvGSFwbzL1l5Bl1t4vSyCqB1LDnWu85WCO6ejbcC0Zgow/ts8ro3j Db5Majn3novJrsS/OPNZUwXptt9xMpsMwhZoOlI12nfz5bDhn/QcJNtlPYS+1cws W/2hAVMW1BcyJS0nwBcuEUc8M7R4zCW2UZBZ54SG3X0921HFf7ghCJ6/SnGjMGsj 4Gr3JEk1p73Tvfv0jFLZrF/Vx+yIOUQwGqs5y7wTti/OBOxVwaBKG0aDqQYpT7Cl oErgq+hKPUonxMC91g5saMfG+SFhOzJDdZGyHrd9LDYaDkBp5UcI/hGwH5/TmZj8 +Vcg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding: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=6VNbfZFwSDaPF+hX8BUwuR4yZ86wlHBpSPfd9ywph SE=; b=zHX2WvpkSaKXQdvHnd1PyN/Cx+/1D/GpXB7GAcjVrMCjtCyMA+N8+CE/F 75gOskGHwy8szW24SuwGVQ4waARxBte9U+it5NW8F3d6kaFSkS5E/gT49bSxF994 wlECWUiQqn8n5nYGE+MBpx2DM+o6XB1fZoU5hHI7vdsh7H2FJOLtl8yfLWGuGYrz ujjFZjnTPuRXaDjsdWb273lEElaN5txqHXj8JwGys61vSmW7kFH1zZMyANKv4pdV LljuR0tNhEV5G+yOu/oXg6ucwK2DNm4+VxHBYWr8tJIM0RfG5YeZOz9k5gqWifqy rUwCR5zxIA4d1/9WoGmrLve3BCPpw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrgeelgdduudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdevhhhr ihhsthhophhhvghrucghohhougdfuceotggrfieshhgvrghpihhnghgsihhtshdrnhgvth eqnecuffhomhgrihhnpehhthhtphehtdefrhgvshhpohhnshgvtghouggvrghnrghlohhg hiifohhulhgusggvhhgvlhhpfhhulhdrrghtpdhgihhthhhusgdrtghomhdpihgvthhfrd horhhgnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhgsghithhs rdhnvghtnecuvehluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4A5233C00A1; Thu, 11 Jul 2019 18:27:51 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.6-731-g19d3b16-fmstable-20190627v1 Mime-Version: 1.0 Message-Id: <8ba1f7d3-d286-46df-9c13-383340bbf7b5@www.fastmail.com> In-Reply-To: References: <156253133809.549.13521510978566357744@ietfa.amsl.com> <20190709203044.GD24351@kduck.mit.edu> Date: Thu, 11 Jul 2019 15:27:50 -0700 From: "Christopher Wood" To: "Konda, Tirumaleswar Reddy" , "Benjamin Kaduk" Cc: "secdir@ietf.org" , "draft-ietf-tram-turnbis.all@ietf.org" , "ietf@ietf.org" , "tram@ietf.org" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] [tram] Secdir last call review of draft-ietf-tram-turnbis-27 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, 11 Jul 2019 22:27:56 -0000 Hi Tiru, On Wed, Jul 10, 2019, at 5:41 AM, Konda, Tirumaleswar Reddy wrote: > Hi Ben, >=20 > Thanks for the review. Please see inline. >=20 > > -----Original Message----- > > From: Benjamin Kaduk > > Sent: Wednesday, July 10, 2019 2:01 AM > > To: Konda, Tirumaleswar Reddy > > Cc: Christopher Wood ; secdir@ietf.org; draft-i= etf- > > tram-turnbis.all@ietf.org; ietf@ietf.org; tram@ietf.org > > Subject: Re: [tram] Secdir last call review of draft-ietf-tram-turnb= is-27 > >=20 > > This email originated from outside of the organization. Do not click= links or > > open attachments unless you recognize the sender and know the conten= t is > > safe. > >=20 > > Chris, thanks for the review. Some more questions/comments inline a= s I > > prepare to ballot on this document... > >=20 > > On Mon, Jul 08, 2019 at 02:18:26PM +0000, Konda, Tirumaleswar Reddy = wrote: > > > Hi Christopher, > > > > > > Thanks for the detailed review. Please see inline > > > > > > > -----Original Message----- > > > > From: tram On Behalf Of Christopher Wood= via > > > > Datatracker > > > > Sent: Monday, July 8, 2019 1:59 AM > > > > To: secdir@ietf.org > > > > Cc: draft-ietf-tram-turnbis.all@ietf.org; ietf@ietf.org; > > > > tram@ietf.org > > > > Subject: [tram] Secdir last call review of > > > > draft-ietf-tram-turnbis-27 > > > > > > > > This email originated from outside of the organization. Do not c= lick > > > > links or open attachments unless you recognize the sender and kn= ow > > > > the content is safe. > > > > > > > > Reviewer: Christopher Wood > > > > Review result: Has Nits > > > > > > > > I have reviewed this document as part of the security directorat= e's > > > > ongoing effort to review all IETF documents being processed by t= he > > > > IESG. These comments were written primarily for the benefit of t= he > > > > security area directors. > > > > Document editors and WG chairs should treat these comments just = like > > > > any other last call comments. > > > > > > > > The summary of the review is: Ready with nits > > > > > > > > Summary: > > > > > > > > In general, the document is well written and clearly founded in > > > > operational experience. The security considerations are thorough= , > > > > providing examples where necessary to highlight important proble= m > > > > areas. It draws a clear line between issues best addressed by > > > > applications outside of TURN, and provides sufficient detail for= > > > > those issues in scope. My comments and questions are, hopefully,= mostly > > nits. > > > > > > > > General comments: > > > > > > > > - TURN server authentication in the case of (D)TLS is > > > > underspecified. Are servers assumed to have WebPKI certificates,= > > > > OOB-trusted raw public keys, or something else? Is there a prefe= rred > > form of authentication? > > > > Relatedly, in > > > > Section 3.2, how do clients authenticate the server? > > > > > > Server certificate validation is discussed in https://tools.ietf.o= rg/html/draft- > > ietf-tram-stunbis-21#section-6.2.3. I have modified the text as fol= lows: > > > > > > If (D)TLS transport is used between the TURN client and the TURN > > > server, the cipher suites, server certificate validation and > > > authentication of TURN server are discussed in Section 6.2.3 of > > > [I-D.ietf-tram-stunbis] > >=20 > > That helps, but it would still be nice to give some indication of wh= at certificate > > PKI(s) are expected to be used. Is anything other than the Web PKI = under > > consideration ? >=20 > No. Please see=20 > https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-6.2.3,=20= > It discusses to verify the certificate path and identity of the server= . Perhaps it would be good to explicitly say this in the document? >=20 > >=20 > > > >- Section 3.7: Could > > > > TURN servers not chunk data from stream-oriented transports (TCP= or > > > >TLS) to a preferred MTU size before relaying to peers? > > > > Specifically, there are likely > > > > some cases wherein the server could deal with the client data > > > >messages larger than the recommended 500B limit. On that point, > > > >should servers even accept data larger than this recommended siz= e ? > > > >- > > > > > > Please see > > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-27#section-15 = for > > > TCP-to-UDP relay. If the PMTU is not known, and on legacy or other= wise > > > unusual networks, > > > 500 byte limit for application data is recommended. > > > > > > > Section 3.9: There may be > > > > cases where the TLS connection post TCP connection establishment= > > > > fails. It would therefore seems prudent to not declare victory f= or > > > > one connection over the other until TLS connects, too. - > > > > > > Agreed, Eric (as part of ISEG review) suggested to simplify the te= xt. I have > > updated the text as follows: > > > > > > o For TCP or TLS-over-TCP, the results of the Happy Eyeballs > > > procedure [RFC8305] are used by the TURN client for sending = its > > > TURN messages to the server. > >=20 > > Is the editor's copy available for viewing somewhere? It would be g= ood to > > see this (and other changes) in context. >=20 > Yes, Please see https://github.com/tireddy2/TURNbis=20 Thanks! >=20 > >=20 > > > > Section 3 could benefit from a > > > > subsection on replays and the nonce role. In particular, as late= r > > > > discussed in the security considerations, some of these attacks = are > > > > not new to TURN and should therefore be dealt with by the > > > > application protocol (SRTP). This section might also describe no= nce > > > > rotation policies with more specificity, as this is underspecifi= ed in the > > document. > > > > > > It is discussed in Section 5 in the specification, the server shou= ld expire the > > nonce at least once every hour during the lifetime of the allocation= . > > > > > > >- Section 3 could also benefit from > > > > discussion about cleartext versus encryption transports between > > > >clients and servers. > > > > > > It is discussed in https://tools.ietf.org/html/draft-ietf-tram-tur= nbis- > > 27#section-21.1.6. > >=20 > > There's not much discussion about potential information leakage via= (e.g.) > > USERNAME/USERHASH, and really just a claim that the peer address is = the > > "primary protocol content". +1 to Ben's concern, which echoes my own. > Agreed, added the following paragraph : >=20 > If the TURN client and server use the STUN Extension for Third-Party=20= > Authorization [RFC7635], the username does not reveal the > real user's identity, the USERNAME attribute carries an ephemeral and=20= > unique key identifier, and the key identifier can change per call. > If the TURN client and server use the STUN long-term credential=20 > mechanism and the username reveals the > real user's identity, the client need to either use (D)TLS transport=20= > between the client and the server or use=20 > the USERHASH attribute instead of the USERNAME attribute to anonynmize= =20 > the username. This is an improvement -- thanks! Should use of (D)TLS be mandated ("MUS= T" instead of "need to") when long-term credentials are used? > > > > Encrypting the nonce, username, realm, etc., among other things,= has > > > > obvious benefits. - Why are SOFTWARE and FINGERPRINT attributes > > > > recommended? It seems like clients should be discouraged from > > > > sending these if anything, especially if not used to make alloca= tion > > > > decisions on the server. > > > > > > Username may not be the user identity, Please see > > https://tools.ietf.org/html/rfc7635), It could be an ephemeral and u= nique > > key identifier. Further, username can be anonymized (please see > > https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-14.4)= . > > > SOFTWARE and FINGERPRINT attributes are defined in the STUN > > specification, see https://tools.ietf.org/html/draft-ietf-tram-stunb= is-21. I realize they're defined elsewhere. My concern was that this draft seem= s to encourage sending them when perhaps that's not needed, i.e., as is = the case for the SOFTWARE attribute. > >=20 > > These mechanisms are partial mitigations but can still be susceptib= le to cross- > > connection correlation attacks. >=20 > The use of FINGERPRINT is not mandatory, the TURN client and server ma= y=20 > include the FINGERPRINT attribute. Note that ICE=20 > (https://tools.ietf.org/html/rfc8445) mandates the use of FINGERPRINT=20= > attribute. Added the following line for SOFTWARE attribute (TURNbis is= =20 > using the same behavior defined in RFC5766 to use SOFTWARE attribute) = : >=20 > SOFWATE attribute can reveal the specific software version of the TURN= =20 > client and server to eavesdropper and it might possibly allow attacks=20= > against vulnerable software that is known to contain security holes. I= f=20 > it is important to prevent an eavesdropper from learning the software=20= > version, TURN can be run over (D)TLS. I'd replace "holes" with "vulnerabilities," and rewrite=20 "If it is important to prevent an eavesdropper from learning the sof= tware version, TURN can be run over (D)TLS." as follows: "TURN SHOULD be run over (D)TLS to prevent leaking the SOFTWARE attribut= e in clear text." > > > - Section 5: When servers receive data that exceeds an allocation=E2= =80=99s > > > > bandwidth quota, servers silently discard this data. This means > > > > there=E2=80=99s no allocation-based flow control mechanism betwe= en client > > > > and server beyond what=E2=80=99s provided by the transport proto= col, right? > > > > > > Yes, UDP does not include a congestion control mechanism. Right -- it might be good to mention this explicitly. > > > > This seems fine, though > > > > perhaps some discussion of why this design decision was made wou= ld > > > > be helpful. For example, I could imagine explicit signals from > > > > servers to clients that indicate server state would reveal > > > > information about other allocations on the server, which might b= e > > > > problematic. - > > > > > > The errors 486 (Allocation Quota Exceeded) or 508 (Insufficient Ca= pacity) > > do not reveal information of which other users are using the TURN se= rver. Perhaps not which other *users* are using the TURN server, correct. It m= ay leak other information though, and drawing HTTP 503 response code ana= logy would be helpful. > > At least the latter seems to give some indication that many other us= ers are > > using the server at the time (so that it's overloaded), though not = information > > about *which* users that is. >=20 > Yes, similar to 503 HTTP error response. >=20 > >=20 > > > > Section 7.2 suggests that > > > > servers can redirect client allocation requests to other servers= . > > > > Can this create a loop, wherein two TURN servers redirect to one= another? > > > > > > The client detect and stop the loop, it is similar to HTTP redirec= tion. > >=20 > > Where is this specified? >=20 > It is specified in the last paragraph of=20 > https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-10=20 Aha -- I missed that. Thanks! Best, Chris From nobody Thu Jul 11 15:43:22 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 0544B12016B; Thu, 11 Jul 2019 15:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hRveSqs2U5iq; Thu, 11 Jul 2019 15:43:11 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E7BC120159; Thu, 11 Jul 2019 15:43:11 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x6BMh1rR001752 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 12 Jul 2019 01:43:01 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x6BMh1lw021352; Fri, 12 Jul 2019 01:43:01 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23847.47989.166847.374951@fireball.acr.fi> Date: Fri, 12 Jul 2019 01:43:01 +0300 From: Tero Kivinen To: "Pascal Thubert \(pthubert\)" , , "draft-ietf-6tisch-architecture.all\@ietf.org" , "secdir\@ietf.org" , Michael Richardson , "iesg\@ietf.org" , Thomas Watteyne , David Mandelberg In-Reply-To: <23846.21029.236657.158497@fireball.acr.fi> References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> <23825.24715.882644.180316@fireball.acr.fi> <23846.21029.236657.158497@fireball.acr.fi> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 19 min X-Total-Time: 18 min Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2019 22:43:13 -0000 Tero Kivinen writes: > I am now back from my eclipse trip, so I will try to answer some of > these emails appeared while I was on vacation. And, now when I was thinking this more, I think there is actually bigger issue, as the first step of joining is done in clear, without any protection, so attacker does can simply act as man in the middle and convert ASNs as it feels like on the second run. I.e., attacker first allows JN to join network normally and stores all packets JN sends and the associated ASN. When it finds packet with ASN z it wants to attack it forces JN to drop out of network (note, this packet it wants to attack can be much later, it does not have to be any of the first frames). Then it sends a beacon with ASN of x, where x is close to the ASN of packet it wants to attack. JN then packet out to JRC with ASN of x + n1, the attacker can ack it, and then take that packet and replay that to the JRC at ASN of y (where x != y, and y > x). When JRC sends reply packet at y + m, the attacker can reply it back to JN with ASN x + n2 and JN will accept it. Now JN has properly rejoined the network (both JN and JRC have authenticated themselves) and JN has keys K1, but thinks ASN is x instead of y. Next packet it sends will be encrypted with K1 and with ASN of x + n3. If x + n3 happens to be the ASN of z the attacker gets two frames encrypted with same key k1 and nonce generated from ASN z. If first try goes wrong it can allow JN to replay until x + n3 > z, and then it can start over again and adjust the starting value of x so it is better guess of how long JN will take when sending frames out... So I do not think we can do anything in the JN <-> JRC protocol to protect against this, the only real way to protect against this, is to send L2 authenticated (but not encrypted) frame after authentication phase from the JN to JRC containing random cookie, and require that JRC to echo it back to JN in similar authenticated but not encrypted frame. I.e., make sure the joining process is (I leave out acks in this picture): JN JRC -- --- security level 0 joining request -> <-- security level 0 joining reply take L2 key K1 in use security level 1-3 cookie request -> <-- security level 1-3 cookie reply with same cookie than in request. And after this the JN is ready to start sending encrypted frames. -- kivinen@iki.fi From nobody Fri Jul 12 02:04: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 5FC7E12049A; Fri, 12 Jul 2019 02:04:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EF70-0wOCNBJ; Fri, 12 Jul 2019 02:04:17 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50740120462; Fri, 12 Jul 2019 02:04:15 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.63,481,1557180000"; d="scan'208";a="391553283" Received: from wifi-eduroam-84-247.paris.inria.fr ([128.93.84.247]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jul 2019 11:04:13 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: =?utf-8?B?TWFsacWhYSBWdcSNaW5pxIc=?= In-Reply-To: <23847.47989.166847.374951@fireball.acr.fi> Date: Fri, 12 Jul 2019 11:04:13 +0200 Cc: "Pascal Thubert (pthubert)" , "draft-ietf-6tisch-architecture.all@ietf.org" , "secdir@ietf.org" , Michael Richardson , "iesg@ietf.org" , Thomas Watteyne , David Mandelberg Content-Transfer-Encoding: quoted-printable Message-Id: <42437526-EFD8-47F7-994C-A914049EB6A3@inria.fr> References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> <23825.24715.882644.180316@fireball.acr.fi> <23846.21029.236657.158497@fireball.acr.fi> <23847.47989.166847.374951@fireball.acr.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2019 09:04:22 -0000 Hello Tero, My understanding of this attack that you describe is that the attacker: (1) can force the joined node to drop out of the network (2) can force the pledge (ex. joined node) to select it as JP (1) can be relaxed by assuming that the joined node can for any reason = drop out of network. Another way to do this would be the selective = jamming attack as discussed in draft-tiloca-6tisch-robust-scheduling. So = this holds. For (2), my understanding is that we have consensus that the protection = is the existing mechanism specified in RFC8180 making the pledge wait = for MAX_EB_DELAY before selecting a JP in order to have at least = NUM_NEIGHBOURS_TO_WAIT distinct JP candidates, with legitimate ones = advertising a value of ASN that is higher than that replayed by the = attacker. What seems missing is a note in the minimal-security draft = that the pledge MUST remain listening on the initial channel after = receiving the first EB, in order not to enable the attacker to desync it = from the network. Did I get that wrong? Mali=C5=A1a > On 12 Jul 2019, at 00:43, Tero Kivinen wrote: >=20 > Tero Kivinen writes: >> I am now back from my eclipse trip, so I will try to answer some of >> these emails appeared while I was on vacation.=20 >=20 > And, now when I was thinking this more, I think there is actually > bigger issue, as the first step of joining is done in clear, without > any protection, so attacker does can simply act as man in the middle > and convert ASNs as it feels like on the second run. >=20 > I.e., attacker first allows JN to join network normally and stores all > packets JN sends and the associated ASN. When it finds packet with ASN > z it wants to attack it forces JN to drop out of network (note, this > packet it wants to attack can be much later, it does not have to be > any of the first frames). >=20 > Then it sends a beacon with ASN of x, where x is close to the ASN of > packet it wants to attack. JN then packet out to JRC with ASN of x + > n1, the attacker can ack it, and then take that packet and replay that > to the JRC at ASN of y (where x !=3D y, and y > x). When JRC sends = reply > packet at y + m, the attacker can reply it back to JN with ASN x + n2 > and JN will accept it. Now JN has properly rejoined the network (both > JN and JRC have authenticated themselves) and JN has keys K1, but > thinks ASN is x instead of y. Next packet it sends will be encrypted > with K1 and with ASN of x + n3. If x + n3 happens to be the ASN > of z the attacker gets two frames encrypted with same key k1 and nonce > generated from ASN z. If first try goes wrong it can allow JN to > replay until x + n3 > z, and then it can start over again and adjust > the starting value of x so it is better guess of how long JN will take > when sending frames out...=20 >=20 > So I do not think we can do anything in the JN <-> JRC protocol to > protect against this, the only real way to protect against this, is to > send L2 authenticated (but not encrypted) frame after authentication > phase from the JN to JRC containing random cookie, and require that > JRC to echo it back to JN in similar authenticated but not encrypted > frame. >=20 > I.e., make sure the joining process is (I leave out acks in this > picture): >=20 > JN JRC > -- --- > security level 0 > joining request -> >=20 > <-- security level 0 > joining reply >=20 > take L2 key K1 in use > security level 1-3 > cookie request -> >=20 > <-- security level 1-3 > cookie reply with same > cookie than in request. >=20 > And after this the JN is ready to start sending encrypted frames.=20 > --=20 > kivinen@iki.fi >=20 > --=20 > MailScanner believes this is threat-free - www.ucg.ac.me >=20 From nobody Fri Jul 12 06:02: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 0C98F1204AD for ; Fri, 12 Jul 2019 06:02:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mcafee.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 aGtolGlBj75B for ; Fri, 12 Jul 2019 06:02:40 -0700 (PDT) Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [63.128.21.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7388A120045 for ; Fri, 12 Jul 2019 06:02:40 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1562935841; h=ARC-Seal: ARC-Message-Signature:ARC-Authentication-Results: From:To:CC:Subject:Thread-Topic:Thread-Index: Date:Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=loBSUN30EadwAboQoVxqgjpMSNyPGG78/RC94I vKELo=; b=EBlhtQ1hZ1sUvxmd0vvaIODPlu32ES+hGdGOkM14 cZf48qGBR6vcD3Ax5M25ZTrII1lt1v0AjyjaGoCOSQ0Lj0OrMY JY7Fvbc1NcFqT/mk8ac7vafRpCpa+yWKDWfVxYO59HtOPQvwGz hozm+yvW1LkbGq2Q1yKt9JbQUUG2g6s= Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-70-VQsFFgDgPT2XiOObIEL_6w-1; Fri, 12 Jul 2019 09:01:18 -0400 Received: from DNVEXAPP1N05.corpzone.internalzone.com (unknown [10.44.48.89]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 2f15_6c24_326978ac_545f_48e8_ada6_573df227ceb2; Fri, 12 Jul 2019 06:50:40 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 12 Jul 2019 07:01:15 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Fri, 12 Jul 2019 07:01:15 -0600 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 12 Jul 2019 07:01:11 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K4v8yQDlb8VeVhGs+J7RQ/pu+2BGHPMHDhfP1ChdKYVLhMRlt3uJ5cpNLPxJULbmQP9Z3ZXEHufRouo0H2sa8EpZiMBtkRnjOZKLjBW5AgUFvZCDGoZZx52XNgw1VWi2nkDLvSeUiPXvpuPZYrizX+ov4q1Jn1r8aq5gRjQyesYAlRdN8lSe8EQhczXcmdvIWPUPAwiYay/b2rNeXrFWrTK+FJdg9SedvN1OwOVdstJUg4EuKIX+0fCcBHO7HeNZZcjxLL3pQ+zu+eHy9rAGL/lbtTP9IWEOnrI7bwK4teC4Yigm/Sa3PknZgZWIfaa0m62xtYnRQKgUZhAc4RnTmw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=loBSUN30EadwAboQoVxqgjpMSNyPGG78/RC94IvKELo=; b=oFW6x0x6FRtApaAPtcYJqhYqJ2RBe8FRyZgEBSEl/Nep5juBQFIpnWrvPMWMsIDv0Mm8PMprheQXawJ4YLLzX4yLBqFS7jyLpf8x98mes9ZmlKQukMdRj0xWCWFENUbndjWh7hoqzVx/kUgDKcWMCH05y4vGsE8yJVQ2WN6SEhjLnV99LzQfc5Zlt6zgAttXYocTA7a/jTyIvQX7J3TDO7OL7ql2+Qy8wZHZSTQ9oayHikWTNm2iF88NhS5Vp0e1WxHonYurmSBZlEEWtOhLUDrzQFDOhXmca50Jl5QSU4DeutNx9xVpX5XShr/uilGxXCSuVydqRdKtono7rg9IrA== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mcafee.com;dmarc=pass action=none header.from=mcafee.com;dkim=pass header.d=mcafee.com;arc=none Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB1801.namprd16.prod.outlook.com (10.174.176.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Fri, 12 Jul 2019 13:01:10 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2052.019; Fri, 12 Jul 2019 13:01:10 +0000 From: "Konda, Tirumaleswar Reddy" To: Christopher Wood , Benjamin Kaduk CC: "secdir@ietf.org" , "draft-ietf-tram-turnbis.all@ietf.org" , "ietf@ietf.org" , "tram@ietf.org" Thread-Topic: [tram] Secdir last call review of draft-ietf-tram-turnbis-27 Thread-Index: AQHVNQMAJeymFhPVnEO1ky4wx5pqrabAcMBwgAJPmICAAKIlAIACozsAgAC0umA= Date: Fri, 12 Jul 2019 13:01:09 +0000 Message-ID: References: <156253133809.549.13521510978566357744@ietfa.amsl.com> <20190709203044.GD24351@kduck.mit.edu> <8ba1f7d3-d286-46df-9c13-383340bbf7b5@www.fastmail.com> In-Reply-To: <8ba1f7d3-d286-46df-9c13-383340bbf7b5@www.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.16 dlp-reaction: no-action x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: db3655d5-e213-4cb1-3014-08d706c902cc x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB1801; x-ms-traffictypediagnostic: DM5PR16MB1801: x-ms-exchange-purlcount: 10 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00963989E5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(366004)(136003)(396003)(39860400002)(346002)(51914003)(13464003)(189003)(52014003)(199004)(32952001)(52536014)(102836004)(316002)(6246003)(6116002)(6506007)(66556008)(53546011)(186003)(64756008)(26005)(7696005)(99286004)(66946007)(66446008)(30864003)(76176011)(110136005)(3846002)(76116006)(66476007)(54906003)(86362001)(5660300002)(66066001)(2906002)(9686003)(11346002)(966005)(446003)(71190400001)(53936002)(81166006)(6436002)(80792005)(81156014)(6306002)(55016002)(476003)(305945005)(486006)(74316002)(229853002)(7736002)(71200400001)(8936002)(256004)(33656002)(14454004)(4326008)(68736007)(5024004)(14444005)(478600001)(8676002)(25786009)(2171002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1801; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: hZUhB3pSEX5RS8k7gGUvl9GYRSxwh3+hGaMNxkq6qlQkxeiuuPP2IOeYsZ8Usrte9QhFL89OWNEGKuOzj1KZ4facZdcd/tO+h9N5j67s5RyC1BziCy3yMn62+UKRltYny4kLSLnuo9INLilpQ8fQfwXh+n6OoUDrW/jij6oOp5KgyUCvK5dPwE013ZjRm4AUkLqgREkq1qR+sRhkrfMNObcWroDcn6PLUNsWCMJoSdzruUx06zxacxFqkCKQp2qXXHqHAtIaWpIPqzUsJ6cvz+igI1a7WFCt/rqhurc0AXIga7WGX+95uXc6APrXlPZQ87+aCaqRoDizvoRvRojfEjhvovDLcW1GFzEGjuJ8Y/g8SD9VoWdI7V5hVC3nSIdAWk0obd3tEZ83kxb+Lt2ZfCzo8+ZnFxXF+craWXjrlrk= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: db3655d5-e213-4cb1-3014-08d706c902cc X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jul 2019 13:01:10.0132 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1801 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6589> : inlines <7118> : streams <1827138> : uri <2866735> X-MC-Unique: VQsFFgDgPT2XiOObIEL_6w-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [secdir] [tram] Secdir last call review of draft-ietf-tram-turnbis-27 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, 12 Jul 2019 13:02:52 -0000 SGkgQ2hyaXMsDQoNClBsZWFzZSBzZWUgaW5saW5lIA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IENocmlzdG9waGVyIFdvb2QgPGNhd0BoZWFwaW5nYml0cy5uZXQ+DQo+ IFNlbnQ6IEZyaWRheSwgSnVseSAxMiwgMjAxOSAzOjU4IEFNDQo+IFRvOiBLb25kYSwgVGlydW1h bGVzd2FyIFJlZGR5DQo+IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPjsgQmVu amFtaW4gS2FkdWsNCj4gPGthZHVrQG1pdC5lZHU+DQo+IENjOiBzZWNkaXJAaWV0Zi5vcmc7IGRy YWZ0LWlldGYtdHJhbS10dXJuYmlzLmFsbEBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsNCj4gdHJh bUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3RyYW1dIFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3 IG9mIGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTI3DQo+IA0KPiBUaGlzIGVtYWlsIG9yaWdpbmF0 ZWQgZnJvbSBvdXRzaWRlIG9mIHRoZSBvcmdhbml6YXRpb24uIERvIG5vdCBjbGljayBsaW5rcyBv cg0KPiBvcGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5k IGtub3cgdGhlIGNvbnRlbnQgaXMNCj4gc2FmZS4NCj4gDQo+IEhpIFRpcnUsDQo+IA0KPiBPbiBX ZWQsIEp1bCAxMCwgMjAxOSwgYXQgNTo0MSBBTSwgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSB3 cm90ZToNCj4gPiBIaSBCZW4sDQo+ID4NCj4gPiBUaGFua3MgZm9yIHRoZSByZXZpZXcuIFBsZWFz ZSBzZWUgaW5saW5lLg0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ ID4gRnJvbTogQmVuamFtaW4gS2FkdWsgPGthZHVrQG1pdC5lZHU+DQo+ID4gPiBTZW50OiBXZWRu ZXNkYXksIEp1bHkgMTAsIDIwMTkgMjowMSBBTQ0KPiA+ID4gVG86IEtvbmRhLCBUaXJ1bWFsZXN3 YXIgUmVkZHkNCj4gPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+DQo+ID4gPiBD YzogQ2hyaXN0b3BoZXIgV29vZCA8Y2F3QGhlYXBpbmdiaXRzLm5ldD47IHNlY2RpckBpZXRmLm9y ZzsNCj4gPiA+IGRyYWZ0LWlldGYtIHRyYW0tdHVybmJpcy5hbGxAaWV0Zi5vcmc7IGlldGZAaWV0 Zi5vcmc7IHRyYW1AaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJlOiBbdHJhbV0gU2VjZGlyIGxh c3QgY2FsbCByZXZpZXcgb2YNCj4gPiA+IGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTI3DQo+ID4g Pg0KPiA+ID4gVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5p emF0aW9uLiBEbyBub3QgY2xpY2sNCj4gPiA+IGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5s ZXNzIHlvdSByZWNvZ25pemUgdGhlIHNlbmRlciBhbmQga25vdw0KPiA+ID4gdGhlIGNvbnRlbnQg aXMgc2FmZS4NCj4gPiA+DQo+ID4gPiBDaHJpcywgdGhhbmtzIGZvciB0aGUgcmV2aWV3LiAgU29t ZSBtb3JlIHF1ZXN0aW9ucy9jb21tZW50cyBpbmxpbmUNCj4gPiA+IGFzIEkgcHJlcGFyZSB0byBi YWxsb3Qgb24gdGhpcyBkb2N1bWVudC4uLg0KPiA+ID4NCj4gPiA+IE9uIE1vbiwgSnVsIDA4LCAy MDE5IGF0IDAyOjE4OjI2UE0gKzAwMDAsIEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkNCj4gd3Jv dGU6DQo+ID4gPiA+IEhpIENocmlzdG9waGVyLA0KPiA+ID4gPg0KPiA+ID4gPiBUaGFua3MgZm9y IHRoZSBkZXRhaWxlZCByZXZpZXcuIFBsZWFzZSBzZWUgaW5saW5lDQo+ID4gPiA+DQo+ID4gPiA+ ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiBGcm9tOiB0cmFtIDx0cmFt LWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBDaHJpc3RvcGhlcg0KPiBXb29kDQo+ID4g PiA+ID4gdmlhIERhdGF0cmFja2VyDQo+ID4gPiA+ID4gU2VudDogTW9uZGF5LCBKdWx5IDgsIDIw MTkgMTo1OSBBTQ0KPiA+ID4gPiA+IFRvOiBzZWNkaXJAaWV0Zi5vcmcNCj4gPiA+ID4gPiBDYzog ZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMuYWxsQGlldGYub3JnOyBpZXRmQGlldGYub3JnOw0KPiA+ ID4gPiA+IHRyYW1AaWV0Zi5vcmcNCj4gPiA+ID4gPiBTdWJqZWN0OiBbdHJhbV0gU2VjZGlyIGxh c3QgY2FsbCByZXZpZXcgb2YNCj4gPiA+ID4gPiBkcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0yNw0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBv ZiB0aGUgb3JnYW5pemF0aW9uLiBEbyBub3QNCj4gPiA+ID4gPiBjbGljayBsaW5rcyBvciBvcGVu IGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXINCj4gPiA+ID4gPiBh bmQga25vdyB0aGUgY29udGVudCBpcyBzYWZlLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gUmV2aWV3 ZXI6IENocmlzdG9waGVyIFdvb2QNCj4gPiA+ID4gPiBSZXZpZXcgcmVzdWx0OiBIYXMgTml0cw0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFy dCBvZiB0aGUgc2VjdXJpdHkNCj4gPiA+ID4gPiBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0 IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcNCj4gPiA+ID4gPiBwcm9jZXNzZWQg YnkgdGhlIElFU0cuIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yDQo+ ID4gPiA+ID4gdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLg0KPiA+ ID4gPiA+IERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2Ug Y29tbWVudHMganVzdA0KPiA+ID4gPiA+IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50 cy4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFRoZSBzdW1tYXJ5IG9mIHRoZSByZXZpZXcgaXM6IFJl YWR5IHdpdGggbml0cw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gU3VtbWFyeToNCj4gPiA+ID4gPg0K PiA+ID4gPiA+IEluIGdlbmVyYWwsIHRoZSBkb2N1bWVudCBpcyB3ZWxsIHdyaXR0ZW4gYW5kIGNs ZWFybHkgZm91bmRlZCBpbg0KPiA+ID4gPiA+IG9wZXJhdGlvbmFsIGV4cGVyaWVuY2UuIFRoZSBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucyBhcmUNCj4gPiA+ID4gPiB0aG9yb3VnaCwgcHJvdmlkaW5n IGV4YW1wbGVzIHdoZXJlIG5lY2Vzc2FyeSB0byBoaWdobGlnaHQNCj4gPiA+ID4gPiBpbXBvcnRh bnQgcHJvYmxlbSBhcmVhcy4gSXQgZHJhd3MgYSBjbGVhciBsaW5lIGJldHdlZW4gaXNzdWVzDQo+ ID4gPiA+ID4gYmVzdCBhZGRyZXNzZWQgYnkgYXBwbGljYXRpb25zIG91dHNpZGUgb2YgVFVSTiwg YW5kIHByb3ZpZGVzDQo+ID4gPiA+ID4gc3VmZmljaWVudCBkZXRhaWwgZm9yIHRob3NlIGlzc3Vl cyBpbiBzY29wZS4gTXkgY29tbWVudHMgYW5kDQo+ID4gPiA+ID4gcXVlc3Rpb25zIGFyZSwgaG9w ZWZ1bGx5LCBtb3N0bHkNCj4gPiA+IG5pdHMuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBHZW5lcmFs IGNvbW1lbnRzOg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gLSBUVVJOIHNlcnZlciBhdXRoZW50aWNh dGlvbiBpbiB0aGUgY2FzZSBvZiAoRClUTFMgaXMNCj4gPiA+ID4gPiB1bmRlcnNwZWNpZmllZC4g QXJlIHNlcnZlcnMgYXNzdW1lZCB0byBoYXZlIFdlYlBLSSBjZXJ0aWZpY2F0ZXMsDQo+ID4gPiA+ ID4gT09CLXRydXN0ZWQgcmF3IHB1YmxpYyBrZXlzLCBvciBzb21ldGhpbmcgZWxzZT8gSXMgdGhl cmUgYQ0KPiA+ID4gPiA+IHByZWZlcnJlZA0KPiA+ID4gZm9ybSBvZiBhdXRoZW50aWNhdGlvbj8N Cj4gPiA+ID4gPiBSZWxhdGVkbHksIGluDQo+ID4gPiA+ID4gU2VjdGlvbiAzLjIsIGhvdyBkbyBj bGllbnRzIGF1dGhlbnRpY2F0ZSB0aGUgc2VydmVyPw0KPiA+ID4gPg0KPiA+ID4gPiBTZXJ2ZXIg Y2VydGlmaWNhdGUgdmFsaWRhdGlvbiBpcyBkaXNjdXNzZWQgaW4NCj4gPiA+ID4gaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LQ0KPiA+ID4gaWV0Zi10cmFtLXN0dW5iaXMtMjEjc2Vj dGlvbi02LjIuMy4gIEkgaGF2ZSBtb2RpZmllZCB0aGUgdGV4dCBhcyBmb2xsb3dzOg0KPiA+ID4g Pg0KPiA+ID4gPiBJZiAoRClUTFMgdHJhbnNwb3J0IGlzIHVzZWQgYmV0d2VlbiB0aGUgVFVSTiBj bGllbnQgYW5kIHRoZSBUVVJODQo+ID4gPiA+IHNlcnZlciwgdGhlIGNpcGhlciBzdWl0ZXMsIHNl cnZlciBjZXJ0aWZpY2F0ZSB2YWxpZGF0aW9uIGFuZA0KPiA+ID4gPiBhdXRoZW50aWNhdGlvbiBv ZiBUVVJOIHNlcnZlciBhcmUgZGlzY3Vzc2VkIGluIFNlY3Rpb24gNi4yLjMgb2YNCj4gPiA+ID4g W0ktRC5pZXRmLXRyYW0tc3R1bmJpc10NCj4gPiA+DQo+ID4gPiBUaGF0IGhlbHBzLCBidXQgaXQg d291bGQgc3RpbGwgYmUgbmljZSB0byBnaXZlIHNvbWUgaW5kaWNhdGlvbiBvZg0KPiA+ID4gd2hh dCBjZXJ0aWZpY2F0ZQ0KPiA+ID4gUEtJKHMpIGFyZSBleHBlY3RlZCB0byBiZSB1c2VkLiAgSXMg YW55dGhpbmcgb3RoZXIgdGhhbiB0aGUgV2ViIFBLSQ0KPiA+ID4gdW5kZXIgY29uc2lkZXJhdGlv biA/DQo+ID4NCj4gPiBOby4gUGxlYXNlIHNlZQ0KPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLXRyYW0tc3R1bmJpcy0yMSNzZWN0aW9uLTYuMi4zLA0KPiA+IEl0IGRp c2N1c3NlcyB0byB2ZXJpZnkgdGhlIGNlcnRpZmljYXRlIHBhdGggYW5kIGlkZW50aXR5IG9mIHRo ZSBzZXJ2ZXIuDQo+IA0KPiBQZXJoYXBzIGl0IHdvdWxkIGJlIGdvb2QgdG8gZXhwbGljaXRseSBz YXkgdGhpcyBpbiB0aGUgZG9jdW1lbnQ/DQoNCkkgYWRkZWQgdGhlIGZvbGxvd2luZyBsaW5lOg0K DQpJZiAoRClUTFMgdHJhbnNwb3J0IGlzIHVzZWQgYmV0d2VlbiB0aGUgVFVSTiBjbGllbnQgYW5k IHRoZSBUVVJOIA0Kc2VydmVyLCB0aGUgY2lwaGVyIHN1aXRlcywgc2VydmVyIGNlcnRpZmljYXRl IHZhbGlkYXRpb24gYW5kIA0KYXV0aGVudGljYXRpb24gb2YgVFVSTiBzZXJ2ZXIgYXJlIGRpc2N1 c3NlZCBpbiBTZWN0aW9uIDYuMi4zIG9mIA0KW0ktRC5pZXRmLXRyYW0tc3R1bmJpc10uDQoNCj4g DQo+ID4NCj4gPiA+DQo+ID4gPiA+ID4tIFNlY3Rpb24gMy43OiBDb3VsZA0KPiA+ID4gPiA+IFRV Uk4gc2VydmVycyBub3QgY2h1bmsgZGF0YSBmcm9tIHN0cmVhbS1vcmllbnRlZCB0cmFuc3BvcnRz IChUQ1ANCj4gPiA+ID4gPm9yDQo+ID4gPiA+ID5UTFMpICB0byBhIHByZWZlcnJlZCBNVFUgc2l6 ZSBiZWZvcmUgcmVsYXlpbmcgdG8gcGVlcnM/DQo+ID4gPiA+ID4gU3BlY2lmaWNhbGx5LCB0aGVy ZSBhcmUgbGlrZWx5DQo+ID4gPiA+ID4gc29tZSBjYXNlcyB3aGVyZWluIHRoZSBzZXJ2ZXIgY291 bGQgZGVhbCB3aXRoIHRoZSBjbGllbnQgZGF0YQ0KPiA+ID4gPiA+bWVzc2FnZXMgIGxhcmdlciB0 aGFuIHRoZSByZWNvbW1lbmRlZCA1MDBCIGxpbWl0LiBPbiB0aGF0IHBvaW50LA0KPiA+ID4gPiA+ c2hvdWxkIHNlcnZlcnMgZXZlbiAgYWNjZXB0IGRhdGEgbGFyZ2VyIHRoYW4gdGhpcyByZWNvbW1l bmRlZCBzaXplID8NCj4gPiA+ID4gPi0NCj4gPiA+ID4NCj4gPiA+ID4gUGxlYXNlIHNlZQ0KPiA+ ID4gPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMt Mjcjc2VjdGlvbi0xNQ0KPiA+ID4gPiBmb3IgVENQLXRvLVVEUCByZWxheS4gSWYgdGhlIFBNVFUg aXMgbm90IGtub3duLCBhbmQgb24gbGVnYWN5IG9yDQo+ID4gPiA+IG90aGVyd2lzZSB1bnVzdWFs IG5ldHdvcmtzLA0KPiA+ID4gPiA1MDAgYnl0ZSBsaW1pdCBmb3IgYXBwbGljYXRpb24gZGF0YSBp cyByZWNvbW1lbmRlZC4NCj4gPiA+ID4NCj4gPiA+ID4gPiBTZWN0aW9uIDMuOTogVGhlcmUgbWF5 IGJlDQo+ID4gPiA+ID4gY2FzZXMgd2hlcmUgdGhlIFRMUyBjb25uZWN0aW9uIHBvc3QgVENQIGNv bm5lY3Rpb24gZXN0YWJsaXNobWVudA0KPiA+ID4gPiA+IGZhaWxzLiBJdCB3b3VsZCB0aGVyZWZv cmUgc2VlbXMgcHJ1ZGVudCB0byBub3QgZGVjbGFyZSB2aWN0b3J5DQo+ID4gPiA+ID4gZm9yIG9u ZSBjb25uZWN0aW9uIG92ZXIgdGhlIG90aGVyIHVudGlsIFRMUyBjb25uZWN0cywgdG9vLiAtDQo+ ID4gPiA+DQo+ID4gPiA+IEFncmVlZCwgRXJpYyAoYXMgcGFydCBvZiBJU0VHIHJldmlldykgc3Vn Z2VzdGVkIHRvIHNpbXBsaWZ5IHRoZQ0KPiA+ID4gPiB0ZXh0LiBJIGhhdmUNCj4gPiA+IHVwZGF0 ZWQgdGhlIHRleHQgYXMgZm9sbG93czoNCj4gPiA+ID4NCj4gPiA+ID4gICAgbyAgRm9yIFRDUCBv ciBUTFMtb3Zlci1UQ1AsIHRoZSByZXN1bHRzIG9mIHRoZSBIYXBweSBFeWViYWxscw0KPiA+ID4g PiAgICAgICBwcm9jZWR1cmUgW1JGQzgzMDVdIGFyZSB1c2VkIGJ5IHRoZSBUVVJOIGNsaWVudCBm b3Igc2VuZGluZyBpdHMNCj4gPiA+ID4gICAgICAgVFVSTiBtZXNzYWdlcyB0byB0aGUgc2VydmVy Lg0KPiA+ID4NCj4gPiA+IElzIHRoZSBlZGl0b3IncyBjb3B5IGF2YWlsYWJsZSBmb3Igdmlld2lu ZyBzb21ld2hlcmU/ICBJdCB3b3VsZCBiZQ0KPiA+ID4gZ29vZCB0byBzZWUgdGhpcyAoYW5kIG90 aGVyIGNoYW5nZXMpIGluIGNvbnRleHQuDQo+ID4NCj4gPiBZZXMsIFBsZWFzZSBzZWUgaHR0cHM6 Ly9naXRodWIuY29tL3RpcmVkZHkyL1RVUk5iaXMNCj4gDQo+IFRoYW5rcyENCj4gDQo+ID4NCj4g PiA+DQo+ID4gPiA+ID4gU2VjdGlvbiAzIGNvdWxkIGJlbmVmaXQgZnJvbSBhDQo+ID4gPiA+ID4g c3Vic2VjdGlvbiBvbiByZXBsYXlzIGFuZCB0aGUgbm9uY2Ugcm9sZS4gSW4gcGFydGljdWxhciwg YXMNCj4gPiA+ID4gPiBsYXRlciBkaXNjdXNzZWQgaW4gdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRp b25zLCBzb21lIG9mIHRoZXNlDQo+ID4gPiA+ID4gYXR0YWNrcyBhcmUgbm90IG5ldyB0byBUVVJO IGFuZCBzaG91bGQgdGhlcmVmb3JlIGJlIGRlYWx0IHdpdGgNCj4gPiA+ID4gPiBieSB0aGUgYXBw bGljYXRpb24gcHJvdG9jb2wgKFNSVFApLiBUaGlzIHNlY3Rpb24gbWlnaHQgYWxzbw0KPiA+ID4g PiA+IGRlc2NyaWJlIG5vbmNlIHJvdGF0aW9uIHBvbGljaWVzIHdpdGggbW9yZSBzcGVjaWZpY2l0 eSwgYXMgdGhpcw0KPiA+ID4gPiA+IGlzIHVuZGVyc3BlY2lmaWVkIGluIHRoZQ0KPiA+ID4gZG9j dW1lbnQuDQo+ID4gPiA+DQo+ID4gPiA+IEl0IGlzIGRpc2N1c3NlZCBpbiBTZWN0aW9uIDUgaW4g dGhlIHNwZWNpZmljYXRpb24sIHRoZSBzZXJ2ZXINCj4gPiA+ID4gc2hvdWxkIGV4cGlyZSB0aGUN Cj4gPiA+IG5vbmNlIGF0IGxlYXN0IG9uY2UgZXZlcnkgaG91ciBkdXJpbmcgdGhlIGxpZmV0aW1l IG9mIHRoZSBhbGxvY2F0aW9uLg0KPiA+ID4gPg0KPiA+ID4gPiA+LSBTZWN0aW9uIDMgY291bGQg YWxzbyBiZW5lZml0IGZyb20gIGRpc2N1c3Npb24gYWJvdXQgY2xlYXJ0ZXh0DQo+ID4gPiA+ID52 ZXJzdXMgZW5jcnlwdGlvbiB0cmFuc3BvcnRzIGJldHdlZW4gY2xpZW50cyBhbmQgIHNlcnZlcnMu DQo+ID4gPiA+DQo+ID4gPiA+IEl0IGlzIGRpc2N1c3NlZCBpbg0KPiA+ID4gPiBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm5iaXMtDQo+ID4gPiAyNyNzZWN0 aW9uLTIxLjEuNi4NCj4gPiA+DQo+ID4gPiBUaGVyZSdzIG5vdCBtdWNoIGRpc2N1c3Npb24gYWJv dXQgcG90ZW50aWFsIGluZm9ybWF0aW9uICBsZWFrYWdlIHZpYQ0KPiA+ID4gKGUuZy4pIFVTRVJO QU1FL1VTRVJIQVNILCBhbmQgcmVhbGx5IGp1c3QgYSBjbGFpbSB0aGF0IHRoZSBwZWVyDQo+ID4g PiBhZGRyZXNzIGlzIHRoZSAicHJpbWFyeSBwcm90b2NvbCBjb250ZW50Ii4NCj4gDQo+ICsxIHRv IEJlbidzIGNvbmNlcm4sIHdoaWNoIGVjaG9lcyBteSBvd24uDQo+IA0KPiA+IEFncmVlZCwgYWRk ZWQgdGhlIGZvbGxvd2luZyBwYXJhZ3JhcGggOg0KPiA+DQo+ID4gSWYgdGhlIFRVUk4gY2xpZW50 IGFuZCBzZXJ2ZXIgdXNlIHRoZSBTVFVOIEV4dGVuc2lvbiBmb3IgVGhpcmQtUGFydHkNCj4gPiBB dXRob3JpemF0aW9uIFtSRkM3NjM1XSwgdGhlIHVzZXJuYW1lIGRvZXMgbm90IHJldmVhbCB0aGUg cmVhbCB1c2VyJ3MNCj4gPiBpZGVudGl0eSwgdGhlIFVTRVJOQU1FIGF0dHJpYnV0ZSBjYXJyaWVz IGFuIGVwaGVtZXJhbCBhbmQgdW5pcXVlIGtleQ0KPiA+IGlkZW50aWZpZXIsIGFuZCB0aGUga2V5 IGlkZW50aWZpZXIgY2FuIGNoYW5nZSBwZXIgY2FsbC4NCj4gPiBJZiB0aGUgVFVSTiBjbGllbnQg YW5kIHNlcnZlciB1c2UgdGhlIFNUVU4gbG9uZy10ZXJtIGNyZWRlbnRpYWwNCj4gPiBtZWNoYW5p c20gYW5kIHRoZSB1c2VybmFtZSByZXZlYWxzIHRoZSByZWFsIHVzZXIncyBpZGVudGl0eSwgdGhl DQo+ID4gY2xpZW50IG5lZWQgdG8gZWl0aGVyIHVzZSAoRClUTFMgdHJhbnNwb3J0IGJldHdlZW4g dGhlIGNsaWVudCBhbmQgdGhlDQo+ID4gc2VydmVyIG9yIHVzZSB0aGUgVVNFUkhBU0ggYXR0cmli dXRlIGluc3RlYWQgb2YgdGhlIFVTRVJOQU1FIGF0dHJpYnV0ZQ0KPiA+IHRvIGFub255bm1pemUg dGhlIHVzZXJuYW1lLg0KPiANCj4gVGhpcyBpcyBhbiBpbXByb3ZlbWVudCAtLSB0aGFua3MhIFNo b3VsZCB1c2Ugb2YgKEQpVExTIGJlIG1hbmRhdGVkDQo+ICgiTVVTVCIgaW5zdGVhZCBvZiAibmVl ZCB0byIpIHdoZW4gbG9uZy10ZXJtIGNyZWRlbnRpYWxzIGFyZSB1c2VkPw0KDQpJIHRoaW5rIHlv dSBtZWFuIChEKVRMUyBvciBVU0VSSEFTSCBtdXN0IGJlIHVzZWQsIHVwZGF0ZWQgdGhlIGxpbmUg YXMgZm9sbG93czoNCg0KSWYgdGhlIFRVUk4gY2xpZW50IGFuZCBzZXJ2ZXIgdXNlIHRoZSBTVFVO IGxvbmctdGVybSBjcmVkZW50aWFsIG1lY2hhbmlzbSBhbmQgdGhlIHVzZXJuYW1lIHJldmVhbHMg dGhlIHJlYWwgdXNlcidzIGlkZW50aXR5LCB0aGUgY2xpZW50IE1VU1QgZWl0aGVyIHVzZSB0aGUg VVNFUkhBU0ggYXR0cmlidXRlIGluc3RlYWQgb2YgdGhlIFVTRVJOQU1FIGF0dHJpYnV0ZSB0byBh bm9ueW5taXplIHRoZSB1c2VybmFtZSBvciB1c2UgDQooRClUTFMgdHJhbnNwb3J0IGJldHdlZW4g dGhlIGNsaWVudCBhbmQgdGhlIHNlcnZlci4NCg0KPiANCj4gPiA+ID4gPiBFbmNyeXB0aW5nIHRo ZSBub25jZSwgdXNlcm5hbWUsIHJlYWxtLCBldGMuLCBhbW9uZyBvdGhlciB0aGluZ3MsDQo+ID4g PiA+ID4gaGFzIG9idmlvdXMgYmVuZWZpdHMuIC0gV2h5IGFyZSBTT0ZUV0FSRSBhbmQgRklOR0VS UFJJTlQNCj4gPiA+ID4gPiBhdHRyaWJ1dGVzIHJlY29tbWVuZGVkPyAgSXQgc2VlbXMgbGlrZSBj bGllbnRzIHNob3VsZCBiZQ0KPiA+ID4gPiA+IGRpc2NvdXJhZ2VkIGZyb20gc2VuZGluZyB0aGVz ZSBpZiBhbnl0aGluZywgZXNwZWNpYWxseSBpZiBub3QNCj4gPiA+ID4gPiB1c2VkIHRvIG1ha2Ug YWxsb2NhdGlvbiBkZWNpc2lvbnMgb24gdGhlIHNlcnZlci4NCj4gPiA+ID4NCj4gPiA+ID4gVXNl cm5hbWUgbWF5IG5vdCBiZSB0aGUgdXNlciBpZGVudGl0eSwgUGxlYXNlIHNlZQ0KPiA+ID4gaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzc2MzUpLCBJdCBjb3VsZCBiZSBhbiBlcGhlbWVy YWwgYW5kDQo+ID4gPiB1bmlxdWUga2V5IGlkZW50aWZpZXIuIEZ1cnRoZXIsIHVzZXJuYW1lIGNh biBiZSBhbm9ueW1pemVkIChwbGVhc2UNCj4gPiA+IHNlZSBodHRwczovL3Rvb2xzLmlldGYub3Jn L2h0bWwvZHJhZnQtaWV0Zi10cmFtLXN0dW5iaXMtMjEjc2VjdGlvbi0xNC40KS4NCj4gPiA+ID4g U09GVFdBUkUgYW5kIEZJTkdFUlBSSU5UIGF0dHJpYnV0ZXMgYXJlIGRlZmluZWQgaW4gdGhlIFNU VU4NCj4gPiA+IHNwZWNpZmljYXRpb24sIHNlZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi10cmFtLXN0dW5iaXMtMjEuDQo+IA0KPiBJIHJlYWxpemUgdGhleSdyZSBkZWZp bmVkIGVsc2V3aGVyZS4gTXkgY29uY2VybiB3YXMgdGhhdCB0aGlzIGRyYWZ0IHNlZW1zIHRvDQo+ IGVuY291cmFnZSBzZW5kaW5nIHRoZW0gd2hlbiBwZXJoYXBzIHRoYXQncyBub3QgbmVlZGVkLCBp LmUuLCBhcyBpcyB0aGUgY2FzZQ0KPiBmb3IgdGhlIFNPRlRXQVJFIGF0dHJpYnV0ZS4NCg0KVGhp cyAiU0hPVUxEIiB0byBzZW5kIFNPRlRXQVJFIGF0dHJpYnV0ZSBpcyBkZWZpbmVkIGluIFJGQzU3 NjYgKEFzIHlvdSBtYXkga25vdywgVFVSTiBpcyB1c2VkIGluIHRoZSBmaWVsZCBmb3Igc2V2ZXJh bCB5ZWFycykgYW5kIHR1cm5iaXMgZG9lcyBub3QgbW9kaWZ5IHRoZSBiZWhhdmlvciBmb3IgYmFj a3dhcmQgY29tcGF0aWJpbGl0eS4gVGhlIHVzZSBvZiBGSU5HRVJQUklOVCBpcyBub3QgbWFuZGF0 b3J5LCB0aGUgZHJhZnQgc2F5cyB0aGUgVFVSTiBjbGllbnQgYW5kIHNlcnZlciBtYXkgaW5jbHVk ZSB0aGUgRklOR0VSUFJJTlQgYXR0cmlidXRlLiAgDQoNCj4gDQo+ID4gPg0KPiA+ID4gVGhlc2Ug bWVjaGFuaXNtcyAgYXJlIHBhcnRpYWwgbWl0aWdhdGlvbnMgYnV0IGNhbiBzdGlsbCBiZQ0KPiA+ ID4gc3VzY2VwdGlibGUgdG8gY3Jvc3MtIGNvbm5lY3Rpb24gY29ycmVsYXRpb24gYXR0YWNrcy4N Cj4gPg0KPiA+IFRoZSB1c2Ugb2YgRklOR0VSUFJJTlQgaXMgbm90IG1hbmRhdG9yeSwgdGhlIFRV Uk4gY2xpZW50IGFuZCBzZXJ2ZXINCj4gPiBtYXkgaW5jbHVkZSB0aGUgRklOR0VSUFJJTlQgYXR0 cmlidXRlLiAgTm90ZSB0aGF0IElDRQ0KPiA+IChodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv cmZjODQ0NSkgbWFuZGF0ZXMgdGhlIHVzZSBvZiBGSU5HRVJQUklOVA0KPiA+IGF0dHJpYnV0ZS4g QWRkZWQgdGhlIGZvbGxvd2luZyBsaW5lIGZvciBTT0ZUV0FSRSBhdHRyaWJ1dGUgKFRVUk5iaXMg aXMNCj4gPiB1c2luZyB0aGUgc2FtZSBiZWhhdmlvciBkZWZpbmVkIGluIFJGQzU3NjYgdG8gdXNl IFNPRlRXQVJFIGF0dHJpYnV0ZSkgIDoNCj4gPg0KPiA+IFNPRldBVEUgYXR0cmlidXRlIGNhbiBy ZXZlYWwgdGhlIHNwZWNpZmljIHNvZnR3YXJlIHZlcnNpb24gb2YgdGhlIFRVUk4NCj4gPiBjbGll bnQgYW5kIHNlcnZlciB0byBlYXZlc2Ryb3BwZXIgYW5kIGl0IG1pZ2h0IHBvc3NpYmx5IGFsbG93 IGF0dGFja3MNCj4gPiBhZ2FpbnN0IHZ1bG5lcmFibGUgc29mdHdhcmUgdGhhdCBpcyBrbm93biB0 byBjb250YWluIHNlY3VyaXR5IGhvbGVzLg0KPiA+IElmIGl0IGlzIGltcG9ydGFudCB0byBwcmV2 ZW50IGFuIGVhdmVzZHJvcHBlciBmcm9tIGxlYXJuaW5nIHRoZQ0KPiA+IHNvZnR3YXJlIHZlcnNp b24sIFRVUk4gY2FuIGJlIHJ1biBvdmVyIChEKVRMUy4NCj4gDQo+IEknZCByZXBsYWNlICJob2xl cyIgd2l0aCAidnVsbmVyYWJpbGl0aWVzLCIgYW5kIHJld3JpdGUNCg0KRG9uZS4NCg0KPiANCj4g ICAgIklmICBpdCBpcyBpbXBvcnRhbnQgdG8gcHJldmVudCBhbiBlYXZlc2Ryb3BwZXIgZnJvbSBs ZWFybmluZyB0aGUgc29mdHdhcmUNCj4gdmVyc2lvbiwgVFVSTiBjYW4gYmUgcnVuIG92ZXIgKEQp VExTLiINCj4gDQo+IGFzIGZvbGxvd3M6DQo+IA0KPiAiVFVSTiBTSE9VTEQgYmUgcnVuIG92ZXIg KEQpVExTIHRvIHByZXZlbnQgbGVha2luZyB0aGUgU09GVFdBUkUNCj4gYXR0cmlidXRlIGluIGNs ZWFyIHRleHQuIg0KDQpXZSB3YW50IHRvIGF2b2lkIGRvdWJsZSBlbmNyeXB0aW9uIG9mIGFwcGxp Y2F0aW9uIGRhdGEsIGFuZCBTT0ZUV0FSRSBhdHRyaWJ1dGUgaGFzIGJlZW4gc2VudCBpbiBjbGVh ciB0ZXh0IGFsbCB0aGVzZSB5ZWFycyBpbiB0aGUgZmllbGQsIGFuZCBubyBhdHRhY2sgaGFzIGJl ZW4gZGV0ZWN0ZWQgYmFzZWQgb24gU09GVFdBUkUgZmllbGQuIEkgY2FuIHJldmlzZSB0aGUgdGV4 dCBhcyBmb2xsb3dzOg0KSWYgdGhlIHNvZnR3YXJlIHZlcnNpb24gaXMga25vd24gdG8gY29udGFp biBzZWN1cml0eSB2dWxuZXJhYmlsaXRpZXMsIFRVUk4gU0hPVUxEIGJlIHJ1biBvdmVyIChEKVRM UyB0byBwcmV2ZW50IGxlYWtpbmcgdGhlIFNPRlRXQVJFIGF0dHJpYnV0ZSBpbiBjbGVhciB0ZXh0 Lg0KDQo+IA0KPiA+ID4gPiAtIFNlY3Rpb24gNTogV2hlbiBzZXJ2ZXJzIHJlY2VpdmUgZGF0YSB0 aGF0IGV4Y2VlZHMgYW4NCj4gPiA+ID4gYWxsb2NhdGlvbuKAmXMNCj4gPiA+ID4gPiBiYW5kd2lk dGggcXVvdGEsIHNlcnZlcnMgc2lsZW50bHkgZGlzY2FyZCB0aGlzIGRhdGEuIFRoaXMgbWVhbnMN Cj4gPiA+ID4gPiB0aGVyZeKAmXMgbm8gYWxsb2NhdGlvbi1iYXNlZCBmbG93IGNvbnRyb2wgbWVj aGFuaXNtIGJldHdlZW4NCj4gPiA+ID4gPiBjbGllbnQgYW5kIHNlcnZlciBiZXlvbmQgd2hhdOKA mXMgcHJvdmlkZWQgYnkgdGhlIHRyYW5zcG9ydCBwcm90b2NvbCwNCj4gcmlnaHQ/DQo+ID4gPiA+ DQo+ID4gPiA+IFllcywgVURQIGRvZXMgbm90IGluY2x1ZGUgYSBjb25nZXN0aW9uIGNvbnRyb2wg bWVjaGFuaXNtLg0KPiANCj4gUmlnaHQgLS0gaXQgbWlnaHQgYmUgZ29vZCB0byBtZW50aW9uIHRo aXMgZXhwbGljaXRseS4NCg0KVXBkYXRlZC4NCg0KPiANCj4gPiA+ID4gPiBUaGlzIHNlZW1zIGZp bmUsIHRob3VnaA0KPiA+ID4gPiA+IHBlcmhhcHMgc29tZSBkaXNjdXNzaW9uIG9mIHdoeSB0aGlz IGRlc2lnbiBkZWNpc2lvbiB3YXMgbWFkZQ0KPiA+ID4gPiA+IHdvdWxkIGJlIGhlbHBmdWwuIEZv ciBleGFtcGxlLCBJIGNvdWxkIGltYWdpbmUgZXhwbGljaXQgc2lnbmFscw0KPiA+ID4gPiA+IGZy b20gc2VydmVycyB0byBjbGllbnRzIHRoYXQgaW5kaWNhdGUgc2VydmVyIHN0YXRlIHdvdWxkIHJl dmVhbA0KPiA+ID4gPiA+IGluZm9ybWF0aW9uIGFib3V0IG90aGVyIGFsbG9jYXRpb25zIG9uIHRo ZSBzZXJ2ZXIsIHdoaWNoIG1pZ2h0DQo+ID4gPiA+ID4gYmUgcHJvYmxlbWF0aWMuIC0NCj4gPiA+ ID4NCj4gPiA+ID4gVGhlIGVycm9ycyA0ODYgKEFsbG9jYXRpb24gUXVvdGEgRXhjZWVkZWQpIG9y IDUwOCAoSW5zdWZmaWNpZW50DQo+ID4gPiA+IENhcGFjaXR5KQ0KPiA+ID4gZG8gbm90IHJldmVh bCBpbmZvcm1hdGlvbiBvZiB3aGljaCBvdGhlciB1c2VycyBhcmUgdXNpbmcgdGhlIFRVUk4gc2Vy dmVyLg0KPiANCj4gUGVyaGFwcyBub3Qgd2hpY2ggb3RoZXIgKnVzZXJzKiBhcmUgdXNpbmcgdGhl IFRVUk4gc2VydmVyLCBjb3JyZWN0LiBJdCBtYXkNCj4gbGVhayBvdGhlciBpbmZvcm1hdGlvbiB0 aG91Z2gsIGFuZCBkcmF3aW5nIEhUVFAgNTAzIHJlc3BvbnNlIGNvZGUgYW5hbG9neQ0KPiB3b3Vs ZCBiZSBoZWxwZnVsLg0KDQpBZGRlZCB0aGUgZm9sbG93aW5nIGxpbmU6DQpOb3RlIHRoYXQgdGhl IGVycm9yIGNvZGUgdmFsdWVzIDQ4NiBhbmQgNTA4IGluZGljYXRlIHRvIGEgZWF2ZXNkcm9wcGVy IGFuZCB0aGUgY2xpZW50IHRoYXQgc2V2ZXJhbCBvdGhlciB1c2VycyBhcmUgdXNpbmcgdGhlIHNl cnZlciBhdCB0aGlzIHRpbWUsIHNpbWlsYXIgdG8gdGhhdCBvZiB0aGUgSFRUUCBlcnJvciByZXNw b25zZSBjb2RlIDUwMywgYnV0IGRvZXMgbm90IHJldmVhbCBhbnkgaW5mb3JtYXRpb24gYWJvdXQg dGhlIHVzZXJzIHVzaW5nIHRoZSBUVVJOIHNlcnZlci4NCg0KQ2hlZXJzLA0KLVRpcnUNCg0KPiAN Cj4gPiA+IEF0IGxlYXN0IHRoZSBsYXR0ZXIgc2VlbXMgdG8gZ2l2ZSBzb21lIGluZGljYXRpb24g dGhhdCBtYW55IG90aGVyDQo+ID4gPiB1c2VycyBhcmUgdXNpbmcgdGhlIHNlcnZlciBhdCB0aGUg IHRpbWUgKHNvIHRoYXQgaXQncyBvdmVybG9hZGVkKSwNCj4gPiA+IHRob3VnaCBub3QgaW5mb3Jt YXRpb24gYWJvdXQgKndoaWNoKiB1c2VycyB0aGF0IGlzLg0KPiA+DQo+ID4gWWVzLCBzaW1pbGFy IHRvIDUwMyBIVFRQIGVycm9yIHJlc3BvbnNlLg0KPiA+DQo+ID4gPg0KPiA+ID4gPiA+IFNlY3Rp b24gNy4yIHN1Z2dlc3RzIHRoYXQNCj4gPiA+ID4gPiBzZXJ2ZXJzIGNhbiByZWRpcmVjdCBjbGll bnQgYWxsb2NhdGlvbiByZXF1ZXN0cyB0byBvdGhlciBzZXJ2ZXJzLg0KPiA+ID4gPiA+IENhbiB0 aGlzIGNyZWF0ZSBhIGxvb3AsIHdoZXJlaW4gdHdvIFRVUk4gc2VydmVycyByZWRpcmVjdCB0byBv bmUNCj4gYW5vdGhlcj8NCj4gPiA+ID4NCj4gPiA+ID4gVGhlIGNsaWVudCBkZXRlY3QgYW5kIHN0 b3AgdGhlIGxvb3AsIGl0IGlzIHNpbWlsYXIgdG8gSFRUUCByZWRpcmVjdGlvbi4NCj4gPiA+DQo+ ID4gPiBXaGVyZSBpcyB0aGlzIHNwZWNpZmllZD8NCj4gPg0KPiA+IEl0IGlzIHNwZWNpZmllZCBp biB0aGUgbGFzdCBwYXJhZ3JhcGggb2YNCj4gPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi10cmFtLXN0dW5iaXMtMjEjc2VjdGlvbi0xMA0KPiANCj4gQWhhIC0tIEkgbWlz c2VkIHRoYXQuIFRoYW5rcyENCj4gDQo+IEJlc3QsDQo+IENocmlzDQo= From nobody Fri Jul 12 18:49: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 A763112006A; Fri, 12 Jul 2019 18:49:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 LoYkE14w9WKW; Fri, 12 Jul 2019 18:49:13 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60D0B12000E; Fri, 12 Jul 2019 18:49:12 -0700 (PDT) Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6D1n2WO019102 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 12 Jul 2019 21:49:05 -0400 Date: Fri, 12 Jul 2019 20:49:02 -0500 From: Benjamin Kaduk To: "Konda, Tirumaleswar Reddy" Cc: Christopher Wood , "secdir@ietf.org" , "draft-ietf-tram-turnbis.all@ietf.org" , "ietf@ietf.org" , "tram@ietf.org" Message-ID: <20190713014901.GQ16418@mit.edu> References: <156253133809.549.13521510978566357744@ietfa.amsl.com> <20190709203044.GD24351@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [secdir] [tram] Secdir last call review of draft-ietf-tram-turnbis-27 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, 13 Jul 2019 01:49:17 -0000 Hi Tiru, Thanks for all the updates, including further downthread with Chris. Just a couple notes inline... On Wed, Jul 10, 2019 at 12:40:37PM +0000, Konda, Tirumaleswar Reddy wrote: > Hi Ben, > > Thanks for the review. Please see inline. > > > -----Original Message----- > > From: Benjamin Kaduk > > Sent: Wednesday, July 10, 2019 2:01 AM > > To: Konda, Tirumaleswar Reddy > > Cc: Christopher Wood ; secdir@ietf.org; draft-ietf- > > tram-turnbis.all@ietf.org; ietf@ietf.org; tram@ietf.org > > Subject: Re: [tram] Secdir last call review of draft-ietf-tram-turnbis-27 > > > > This email originated from outside of the organization. Do not click links or > > open attachments unless you recognize the sender and know the content is > > safe. > > > > Chris, thanks for the review. Some more questions/comments inline as I > > prepare to ballot on this document... > > > > On Mon, Jul 08, 2019 at 02:18:26PM +0000, Konda, Tirumaleswar Reddy wrote: > > > Hi Christopher, > > > > > > Thanks for the detailed review. Please see inline > > > > > > > -----Original Message----- > > > > From: tram On Behalf Of Christopher Wood via > > > > Datatracker > > > > Sent: Monday, July 8, 2019 1:59 AM > > > > To: secdir@ietf.org > > > > Cc: draft-ietf-tram-turnbis.all@ietf.org; ietf@ietf.org; > > > > tram@ietf.org > > > > Subject: [tram] Secdir last call review of > > > > draft-ietf-tram-turnbis-27 > > > > > > > > This email originated from outside of the organization. Do not click > > > > links or open attachments unless you recognize the sender and know > > > > the content is safe. > > > > > > > > Reviewer: Christopher Wood > > > > 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. > > > > > > > > The summary of the review is: Ready with nits > > > > > > > > Summary: > > > > > > > > In general, the document is well written and clearly founded in > > > > operational experience. The security considerations are thorough, > > > > providing examples where necessary to highlight important problem > > > > areas. It draws a clear line between issues best addressed by > > > > applications outside of TURN, and provides sufficient detail for > > > > those issues in scope. My comments and questions are, hopefully, mostly > > nits. > > > > > > > > General comments: > > > > > > > > - TURN server authentication in the case of (D)TLS is > > > > underspecified. Are servers assumed to have WebPKI certificates, > > > > OOB-trusted raw public keys, or something else? Is there a preferred > > form of authentication? > > > > Relatedly, in > > > > Section 3.2, how do clients authenticate the server? > > > > > > Server certificate validation is discussed in https://tools.ietf.org/html/draft- > > ietf-tram-stunbis-21#section-6.2.3. I have modified the text as follows: > > > > > > If (D)TLS transport is used between the TURN client and the TURN > > > server, the cipher suites, server certificate validation and > > > authentication of TURN server are discussed in Section 6.2.3 of > > > [I-D.ietf-tram-stunbis] > > > > That helps, but it would still be nice to give some indication of what certificate > > PKI(s) are expected to be used. Is anything other than the Web PKI under > > consideration ? > > No. Please see https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-6.2.3, It discusses to verify the certificate path and identity of the server. > > > > > > >- Section 3.7: Could > > > > TURN servers not chunk data from stream-oriented transports (TCP or > > > >TLS) to a preferred MTU size before relaying to peers? > > > > Specifically, there are likely > > > > some cases wherein the server could deal with the client data > > > >messages larger than the recommended 500B limit. On that point, > > > >should servers even accept data larger than this recommended size ? > > > >- > > > > > > Please see > > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-27#section-15 for > > > TCP-to-UDP relay. If the PMTU is not known, and on legacy or otherwise > > > unusual networks, > > > 500 byte limit for application data is recommended. > > > > > > > Section 3.9: There may be > > > > cases where the TLS connection post TCP connection establishment > > > > fails. It would therefore seems prudent to not declare victory for > > > > one connection over the other until TLS connects, too. - > > > > > > Agreed, Eric (as part of ISEG review) suggested to simplify the text. I have > > updated the text as follows: > > > > > > o For TCP or TLS-over-TCP, the results of the Happy Eyeballs > > > procedure [RFC8305] are used by the TURN client for sending its > > > TURN messages to the server. > > > > Is the editor's copy available for viewing somewhere? It would be good to > > see this (and other changes) in context. > > Yes, Please see https://github.com/tireddy2/TURNbis > > > > > > > Section 3 could benefit from a > > > > subsection on replays and the nonce role. In particular, as later > > > > discussed in the security considerations, some of these attacks are > > > > not new to TURN and should therefore be dealt with by the > > > > application protocol (SRTP). This section might also describe nonce > > > > rotation policies with more specificity, as this is underspecified in the > > document. > > > > > > It is discussed in Section 5 in the specification, the server should expire the > > nonce at least once every hour during the lifetime of the allocation. > > > > > > >- Section 3 could also benefit from > > > > discussion about cleartext versus encryption transports between > > > >clients and servers. > > > > > > It is discussed in https://tools.ietf.org/html/draft-ietf-tram-turnbis- > > 27#section-21.1.6. > > > > There's not much discussion about potential information leakage via (e.g.) > > USERNAME/USERHASH, and really just a claim that the peer address is the > > "primary protocol content". > > Agreed, added the following paragraph : > > If the TURN client and server use the STUN Extension for Third-Party Authorization [RFC7635], the username does not reveal the > real user's identity, the USERNAME attribute carries an ephemeral and unique key identifier, and the key identifier can change per call. > If the TURN client and server use the STUN long-term credential mechanism and the username reveals the > real user's identity, the client need to either use (D)TLS transport between the client and the server or use > the USERHASH attribute instead of the USERNAME attribute to anonynmize the username. > > > > > > > Encrypting the nonce, username, realm, etc., among other things, has > > > > obvious benefits. - Why are SOFTWARE and FINGERPRINT attributes > > > > recommended? It seems like clients should be discouraged from > > > > sending these if anything, especially if not used to make allocation > > > > decisions on the server. > > > > > > Username may not be the user identity, Please see > > https://tools.ietf.org/html/rfc7635), It could be an ephemeral and unique > > key identifier. Further, username can be anonymized (please see > > https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-14.4). > > > SOFTWARE and FINGERPRINT attributes are defined in the STUN > > specification, see https://tools.ietf.org/html/draft-ietf-tram-stunbis-21. > > > > These mechanisms are partial mitigations but can still be susceptible to cross- > > connection correlation attacks. > > The use of FINGERPRINT is not mandatory, the TURN client and server may include the FINGERPRINT attribute. Note that ICE (https://tools.ietf.org/html/rfc8445) mandates the use of FINGERPRINT attribute. Added the following line for SOFTWARE attribute (TURNbis is using the same behavior defined in RFC5766 to use SOFTWARE attribute) : > > SOFWATE attribute can reveal the specific software version of the TURN client and server to eavesdropper and it might possibly allow attacks against vulnerable software that is known to contain security holes. If it is important to prevent an eavesdropper from learning the software version, TURN can be run over (D)TLS. The later suggestion was: % We want to avoid double encryption of application data, and SOFTWARE attribute has % been sent in clear text all these years in the field, and no attack has been % detected based on SOFTWARE field. I can revise the text as follows: % If the software version is known to contain security vulnerabilities, TURN SHOULD be % run over (D)TLS to prevent leaking the SOFTWARE attribute in clear text. I think some of the concern is over the risk of so-called "zero-day" exploits, where the attacker knows of a version-specific flaw but the defenders do not (and have zero days notice to protect against it). Such a concern would suggest to avoid sending SOFTWARE over enencrypted transport regardless of the state of known vulnerabilities, but in the end it is a matter of local policy. > > > > > > - Section 5: When servers receive data that exceeds an allocation’s > > > > bandwidth quota, servers silently discard this data. This means > > > > there’s no allocation-based flow control mechanism between client > > > > and server beyond what’s provided by the transport protocol, right? > > > > > > Yes, UDP does not include a congestion control mechanism. > > > > > > > This seems fine, though > > > > perhaps some discussion of why this design decision was made would > > > > be helpful. For example, I could imagine explicit signals from > > > > servers to clients that indicate server state would reveal > > > > information about other allocations on the server, which might be > > > > problematic. - > > > > > > The errors 486 (Allocation Quota Exceeded) or 508 (Insufficient Capacity) > > do not reveal information of which other users are using the TURN server. > > > > At least the latter seems to give some indication that many other users are > > using the server at the time (so that it's overloaded), though not information > > about *which* users that is. > > Yes, similar to 503 HTTP error response. > > > > > > > Section 7.2 suggests that > > > > servers can redirect client allocation requests to other servers. > > > > Can this create a loop, wherein two TURN servers redirect to one another? > > > > > > The client detect and stop the loop, it is similar to HTTP redirection. > > > > Where is this specified? > > It is specified in the last paragraph of https://tools.ietf.org/html/draft-ietf-tram-stunbis-21#section-10 > > > If the client has been redirected to a > server to which it has already sent this request within the last five > minutes, it MUST ignore the redirection and consider the transaction > to have failed. This prevents infinite ping-ponging between servers > in case of redirection loops. > Thanks for the pointer; as you saw in my ballot position I was quite pressed for time this week and only was able to look at the diff. -Ben From nobody Fri Jul 12 23:36: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 D333E120019 for ; Fri, 12 Jul 2019 23:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mcafee.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 dqN7kMq_xoHf for ; Fri, 12 Jul 2019 23:36:03 -0700 (PDT) Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [63.128.21.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D3D112008F for ; Fri, 12 Jul 2019 23:36:02 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1562999012; h=ARC-Seal: ARC-Message-Signature:ARC-Authentication-Results: From:To:CC:Subject:Thread-Topic:Thread-Index: Date:Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=HdHIBLUvxV9nBwHx9il9njs1v1KMliJoOD6aSk JnyRs=; b=oK29Fhqcgr7+eWrAvP7JXj6Xdpufr7qxmGOMT3OQ O07Hgg6OBBry7NizRcLGR5insLZKiBGb97pHE0VBoTEJ1bf5hM Y5bWSXHeKuwYRDT90YJ1i6u2f2VjkG1QxTp2XicOKhnxkL7mVh /hvVEAy0sjZ2mP3esZVyWp6i6XtpnkU= Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-64-f9efpBi6MVS1ut7ZN3N54A-1; Sat, 13 Jul 2019 02:34:11 -0400 Received: from DNVEXAPP1N06.corpzone.internalzone.com (DNVEXAPP1N06.corpzone.internalzone.com [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 6c32_3f4c_f84f959d_71c3_41ce_bc1b_9db7e5c5de58; Sat, 13 Jul 2019 00:23:30 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 13 Jul 2019 00:34:07 -0600 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Sat, 13 Jul 2019 00:34:06 -0600 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 13 Jul 2019 00:34:06 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EXw85X756G8NCkL76pr70n1cFh5ej4kQcFFUXS0d+L5ZOunudwJn09OS8dY6HG6A8KF4mo+HEcsKtItzTEBK7bZJQB0i0qQ5KhwzhWCzKrB+hFn2bO/QngtTmJr2DNkiZLw/LYc4Vr8jVYn53JXBkZKdnkjccuQcj4URuAEJNDLL/I807vFN4vji1MLIeuoKIm9bhMDbTOUFGDoDIt47WDvju/fZAv9uM+DYwKfkhB0ys/CenumcyoI/t0d1nh+noIsX2RDvHkIiI5JyQc2L5NI1LyWYe+WRltS6xVB9oSgO7i2P2qYYJV8be65eLOwnMEUuTAKY31nK3DgecpIKUw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=HdHIBLUvxV9nBwHx9il9njs1v1KMliJoOD6aSkJnyRs=; b=EIN+TWcgw3lYylIyNMR5x2FV8XUq+L5k4Vvqp0bgKbv4JwqdCKvR0LgLFeNq/qvXyGr9mgiuenbP7G/qzkZuB6zAHJ1mG9njfI57Nj2hYeO4E+1XlkfD7Y2dlM21LYpY1sfsLd5W1TAvz+5XwhIcIwPZULMu8XcgUWWZZ6heWDUnTQa/IiJXscPRRZxMZ3NuCRt8hRPagjpjHzR2E1dCFsPfO+GbVnd/5eey0CWZADmIis9fRDImaVk3Tz2pW3IkoSf13lzzpp502CcoqCKH+tRl36O9Rp9q/7b36nuZsb2DMybKsCV0Paq+TfW3BUUTjdlDseJ0+sQoLsThW4oPpg== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=mcafee.com;dmarc=pass action=none header.from=mcafee.com;dkim=pass header.d=mcafee.com;arc=none Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5SPR00MB110.namprd16.prod.outlook.com (10.174.247.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.14; Sat, 13 Jul 2019 06:34:03 +0000 Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2052.022; Sat, 13 Jul 2019 06:34:03 +0000 From: "Konda, Tirumaleswar Reddy" To: Benjamin Kaduk CC: Christopher Wood , "secdir@ietf.org" , "draft-ietf-tram-turnbis.all@ietf.org" , "ietf@ietf.org" , "tram@ietf.org" Thread-Topic: [tram] Secdir last call review of draft-ietf-tram-turnbis-27 Thread-Index: AQHVNQMAJeymFhPVnEO1ky4wx5pqrabAcMBwgAJPmICAAKIlAIAEbccAgABJSTA= Date: Sat, 13 Jul 2019 06:34:03 +0000 Message-ID: References: <156253133809.549.13521510978566357744@ietfa.amsl.com> <20190709203044.GD24351@kduck.mit.edu> <20190713014901.GQ16418@mit.edu> In-Reply-To: <20190713014901.GQ16418@mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.3.0.16 dlp-reaction: no-action x-originating-ip: [49.37.206.28] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 283f07b6-b761-4696-6c1b-08d7075c1936 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600148)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:DM5SPR00MB110; x-ms-traffictypediagnostic: DM5SPR00MB110: x-ms-exchange-purlcount: 10 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 00979FCB3A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(376002)(346002)(396003)(136003)(39860400002)(13464003)(32952001)(199004)(189003)(51914003)(6246003)(55016002)(7736002)(2171002)(6306002)(9686003)(305945005)(66066001)(81156014)(81166006)(5024004)(53936002)(53546011)(74316002)(33656002)(256004)(14444005)(54906003)(30864003)(478600001)(3846002)(476003)(486006)(102836004)(6506007)(25786009)(99286004)(7696005)(8936002)(11346002)(6116002)(76176011)(2906002)(5660300002)(6436002)(68736007)(66946007)(229853002)(316002)(86362001)(52536014)(8676002)(186003)(80792005)(4326008)(446003)(6916009)(966005)(66556008)(66446008)(76116006)(71200400001)(71190400001)(64756008)(66476007)(14454004)(26005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5SPR00MB110; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: fP6KleNox3jXAqkgTODruftalyd/njDKzBh9tSWHLoUWm+Hbu92F5BcyBQ704zg3R58t+5e748r51E60Esq4O3khvmhh40+hqbH9PlPmSGz9U94Zpj3o6TiWD43wUYGTk5QWmLo/IDWIuuLXwevOg8WZdnPlGt6xLGGZ0l21KN4t5LrS7Q0FFX9GwgYkhVbiRyLKyTMEt8F75LVF/4UDOHDzn2vGJBlU1RJw4PDOt0miRLEOe0f3w5EJmdAqxuBRuQrl3GpF5ESs6oaUS5PgKmTxs2wTi9C5WrqHpnN9rpPnYEtgMP4hEhIlh8krO8uwlpBL5JWWDryd9WNgNbe/RdSAYRudPcWx0/gSfC1O1gJvzTuXsArUMij7SJ/oHHfl4bu6kRPjx59xDQCF1z4uDBx1dhZ7FkEsTzLFfhw44n4= MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 283f07b6-b761-4696-6c1b-08d7075c1936 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jul 2019 06:34:03.5795 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5SPR00MB110 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6589> : inlines <7119> : streams <1827208> : uri <2867009> X-MC-Unique: f9efpBi6MVS1ut7ZN3N54A-1 X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [secdir] [tram] Secdir last call review of draft-ietf-tram-turnbis-27 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, 13 Jul 2019 06:36:05 -0000 SGkgQmVuLA0KDQpQbGVhc2Ugc2VlIGlubGluZQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQo+IEZyb206IEJlbmphbWluIEthZHVrIDxrYWR1a0BtaXQuZWR1Pg0KPiBTZW50OiBTYXR1 cmRheSwgSnVseSAxMywgMjAxOSA3OjE5IEFNDQo+IFRvOiBLb25kYSwgVGlydW1hbGVzd2FyIFJl ZGR5IDxUaXJ1bWFsZXN3YXJSZWRkeV9Lb25kYUBNY0FmZWUuY29tPg0KPiBDYzogQ2hyaXN0b3Bo ZXIgV29vZCA8Y2F3QGhlYXBpbmdiaXRzLm5ldD47IHNlY2RpckBpZXRmLm9yZzsgZHJhZnQtaWV0 Zi0NCj4gdHJhbS10dXJuYmlzLmFsbEBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsgdHJhbUBpZXRm Lm9yZw0KPiBTdWJqZWN0OiBSZTogW3RyYW1dIFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRy YWZ0LWlldGYtdHJhbS10dXJuYmlzLTI3DQo+IA0KPiBUaGlzIGVtYWlsIG9yaWdpbmF0ZWQgZnJv bSBvdXRzaWRlIG9mIHRoZSBvcmdhbml6YXRpb24uIERvIG5vdCBjbGljayBsaW5rcyBvcg0KPiBv cGVuIGF0dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXIgYW5kIGtub3cg dGhlIGNvbnRlbnQgaXMNCj4gc2FmZS4NCj4gDQo+IEhpIFRpcnUsDQo+IA0KPiBUaGFua3MgZm9y IGFsbCB0aGUgdXBkYXRlcywgaW5jbHVkaW5nIGZ1cnRoZXIgZG93bnRocmVhZCB3aXRoIENocmlz Lg0KPiBKdXN0IGEgY291cGxlIG5vdGVzIGlubGluZS4uLg0KPiANCj4gT24gV2VkLCBKdWwgMTAs IDIwMTkgYXQgMTI6NDA6MzdQTSArMDAwMCwgS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSB3cm90 ZToNCj4gPiBIaSBCZW4sDQo+ID4NCj4gPiBUaGFua3MgZm9yIHRoZSByZXZpZXcuIFBsZWFzZSBz ZWUgaW5saW5lLg0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4g RnJvbTogQmVuamFtaW4gS2FkdWsgPGthZHVrQG1pdC5lZHU+DQo+ID4gPiBTZW50OiBXZWRuZXNk YXksIEp1bHkgMTAsIDIwMTkgMjowMSBBTQ0KPiA+ID4gVG86IEtvbmRhLCBUaXJ1bWFsZXN3YXIg UmVkZHkNCj4gPFRpcnVtYWxlc3dhclJlZGR5X0tvbmRhQE1jQWZlZS5jb20+DQo+ID4gPiBDYzog Q2hyaXN0b3BoZXIgV29vZCA8Y2F3QGhlYXBpbmdiaXRzLm5ldD47IHNlY2RpckBpZXRmLm9yZzsN Cj4gPiA+IGRyYWZ0LWlldGYtIHRyYW0tdHVybmJpcy5hbGxAaWV0Zi5vcmc7IGlldGZAaWV0Zi5v cmc7IHRyYW1AaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJlOiBbdHJhbV0gU2VjZGlyIGxhc3Qg Y2FsbCByZXZpZXcgb2YNCj4gPiA+IGRyYWZ0LWlldGYtdHJhbS10dXJuYmlzLTI3DQo+ID4gPg0K PiA+ID4gVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0aGUgb3JnYW5pemF0 aW9uLiBEbyBub3QgY2xpY2sNCj4gPiA+IGxpbmtzIG9yIG9wZW4gYXR0YWNobWVudHMgdW5sZXNz IHlvdSByZWNvZ25pemUgdGhlIHNlbmRlciBhbmQga25vdw0KPiA+ID4gdGhlIGNvbnRlbnQgaXMg c2FmZS4NCj4gPiA+DQo+ID4gPiBDaHJpcywgdGhhbmtzIGZvciB0aGUgcmV2aWV3LiAgU29tZSBt b3JlIHF1ZXN0aW9ucy9jb21tZW50cyBpbmxpbmUNCj4gPiA+IGFzIEkgcHJlcGFyZSB0byBiYWxs b3Qgb24gdGhpcyBkb2N1bWVudC4uLg0KPiA+ID4NCj4gPiA+IE9uIE1vbiwgSnVsIDA4LCAyMDE5 IGF0IDAyOjE4OjI2UE0gKzAwMDAsIEtvbmRhLCBUaXJ1bWFsZXN3YXIgUmVkZHkNCj4gd3JvdGU6 DQo+ID4gPiA+IEhpIENocmlzdG9waGVyLA0KPiA+ID4gPg0KPiA+ID4gPiBUaGFua3MgZm9yIHRo ZSBkZXRhaWxlZCByZXZpZXcuIFBsZWFzZSBzZWUgaW5saW5lDQo+ID4gPiA+DQo+ID4gPiA+ID4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+ID4gPiBGcm9tOiB0cmFtIDx0cmFtLWJv dW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBDaHJpc3RvcGhlcg0KPiBXb29kDQo+ID4gPiA+ ID4gdmlhIERhdGF0cmFja2VyDQo+ID4gPiA+ID4gU2VudDogTW9uZGF5LCBKdWx5IDgsIDIwMTkg MTo1OSBBTQ0KPiA+ID4gPiA+IFRvOiBzZWNkaXJAaWV0Zi5vcmcNCj4gPiA+ID4gPiBDYzogZHJh ZnQtaWV0Zi10cmFtLXR1cm5iaXMuYWxsQGlldGYub3JnOyBpZXRmQGlldGYub3JnOw0KPiA+ID4g PiA+IHRyYW1AaWV0Zi5vcmcNCj4gPiA+ID4gPiBTdWJqZWN0OiBbdHJhbV0gU2VjZGlyIGxhc3Qg Y2FsbCByZXZpZXcgb2YNCj4gPiA+ID4gPiBkcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0yNw0KPiA+ ID4gPiA+DQo+ID4gPiA+ID4gVGhpcyBlbWFpbCBvcmlnaW5hdGVkIGZyb20gb3V0c2lkZSBvZiB0 aGUgb3JnYW5pemF0aW9uLiBEbyBub3QNCj4gPiA+ID4gPiBjbGljayBsaW5rcyBvciBvcGVuIGF0 dGFjaG1lbnRzIHVubGVzcyB5b3UgcmVjb2duaXplIHRoZSBzZW5kZXINCj4gPiA+ID4gPiBhbmQg a25vdyB0aGUgY29udGVudCBpcyBzYWZlLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gUmV2aWV3ZXI6 IENocmlzdG9waGVyIFdvb2QNCj4gPiA+ID4gPiBSZXZpZXcgcmVzdWx0OiBIYXMgTml0cw0KPiA+ ID4gPiA+DQo+ID4gPiA+ID4gSSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBv ZiB0aGUgc2VjdXJpdHkNCj4gPiA+ID4gPiBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRv IHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcNCj4gPiA+ID4gPiBwcm9jZXNzZWQgYnkg dGhlIElFU0cuIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yDQo+ID4g PiA+ID4gdGhlIGJlbmVmaXQgb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLg0KPiA+ID4g PiA+IERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29t bWVudHMganVzdA0KPiA+ID4gPiA+IGxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50cy4N Cj4gPiA+ID4gPg0KPiA+ID4gPiA+IFRoZSBzdW1tYXJ5IG9mIHRoZSByZXZpZXcgaXM6IFJlYWR5 IHdpdGggbml0cw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gU3VtbWFyeToNCj4gPiA+ID4gPg0KPiA+ ID4gPiA+IEluIGdlbmVyYWwsIHRoZSBkb2N1bWVudCBpcyB3ZWxsIHdyaXR0ZW4gYW5kIGNsZWFy bHkgZm91bmRlZCBpbg0KPiA+ID4gPiA+IG9wZXJhdGlvbmFsIGV4cGVyaWVuY2UuIFRoZSBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucyBhcmUNCj4gPiA+ID4gPiB0aG9yb3VnaCwgcHJvdmlkaW5nIGV4 YW1wbGVzIHdoZXJlIG5lY2Vzc2FyeSB0byBoaWdobGlnaHQNCj4gPiA+ID4gPiBpbXBvcnRhbnQg cHJvYmxlbSBhcmVhcy4gSXQgZHJhd3MgYSBjbGVhciBsaW5lIGJldHdlZW4gaXNzdWVzDQo+ID4g PiA+ID4gYmVzdCBhZGRyZXNzZWQgYnkgYXBwbGljYXRpb25zIG91dHNpZGUgb2YgVFVSTiwgYW5k IHByb3ZpZGVzDQo+ID4gPiA+ID4gc3VmZmljaWVudCBkZXRhaWwgZm9yIHRob3NlIGlzc3VlcyBp biBzY29wZS4gTXkgY29tbWVudHMgYW5kDQo+ID4gPiA+ID4gcXVlc3Rpb25zIGFyZSwgaG9wZWZ1 bGx5LCBtb3N0bHkNCj4gPiA+IG5pdHMuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBHZW5lcmFsIGNv bW1lbnRzOg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gLSBUVVJOIHNlcnZlciBhdXRoZW50aWNhdGlv biBpbiB0aGUgY2FzZSBvZiAoRClUTFMgaXMNCj4gPiA+ID4gPiB1bmRlcnNwZWNpZmllZC4gQXJl IHNlcnZlcnMgYXNzdW1lZCB0byBoYXZlIFdlYlBLSSBjZXJ0aWZpY2F0ZXMsDQo+ID4gPiA+ID4g T09CLXRydXN0ZWQgcmF3IHB1YmxpYyBrZXlzLCBvciBzb21ldGhpbmcgZWxzZT8gSXMgdGhlcmUg YQ0KPiA+ID4gPiA+IHByZWZlcnJlZA0KPiA+ID4gZm9ybSBvZiBhdXRoZW50aWNhdGlvbj8NCj4g PiA+ID4gPiBSZWxhdGVkbHksIGluDQo+ID4gPiA+ID4gU2VjdGlvbiAzLjIsIGhvdyBkbyBjbGll bnRzIGF1dGhlbnRpY2F0ZSB0aGUgc2VydmVyPw0KPiA+ID4gPg0KPiA+ID4gPiBTZXJ2ZXIgY2Vy dGlmaWNhdGUgdmFsaWRhdGlvbiBpcyBkaXNjdXNzZWQgaW4NCj4gPiA+ID4gaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LQ0KPiA+ID4gaWV0Zi10cmFtLXN0dW5iaXMtMjEjc2VjdGlv bi02LjIuMy4gIEkgaGF2ZSBtb2RpZmllZCB0aGUgdGV4dCBhcyBmb2xsb3dzOg0KPiA+ID4gPg0K PiA+ID4gPiBJZiAoRClUTFMgdHJhbnNwb3J0IGlzIHVzZWQgYmV0d2VlbiB0aGUgVFVSTiBjbGll bnQgYW5kIHRoZSBUVVJODQo+ID4gPiA+IHNlcnZlciwgdGhlIGNpcGhlciBzdWl0ZXMsIHNlcnZl ciBjZXJ0aWZpY2F0ZSB2YWxpZGF0aW9uIGFuZA0KPiA+ID4gPiBhdXRoZW50aWNhdGlvbiBvZiBU VVJOIHNlcnZlciBhcmUgZGlzY3Vzc2VkIGluIFNlY3Rpb24gNi4yLjMgb2YNCj4gPiA+ID4gW0kt RC5pZXRmLXRyYW0tc3R1bmJpc10NCj4gPiA+DQo+ID4gPiBUaGF0IGhlbHBzLCBidXQgaXQgd291 bGQgc3RpbGwgYmUgbmljZSB0byBnaXZlIHNvbWUgaW5kaWNhdGlvbiBvZg0KPiA+ID4gd2hhdCBj ZXJ0aWZpY2F0ZQ0KPiA+ID4gUEtJKHMpIGFyZSBleHBlY3RlZCB0byBiZSB1c2VkLiAgSXMgYW55 dGhpbmcgb3RoZXIgdGhhbiB0aGUgV2ViIFBLSQ0KPiA+ID4gdW5kZXIgY29uc2lkZXJhdGlvbiA/ DQo+ID4NCj4gPiBOby4gUGxlYXNlIHNlZSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaWV0Zi10cmFtLXN0dW5iaXMtDQo+IDIxI3NlY3Rpb24tNi4yLjMsIEl0IGRpc2N1c3NlcyB0 byB2ZXJpZnkgdGhlIGNlcnRpZmljYXRlIHBhdGggYW5kIGlkZW50aXR5IG9mIHRoZQ0KPiBzZXJ2 ZXIuDQo+ID4NCj4gPiA+DQo+ID4gPiA+ID4tIFNlY3Rpb24gMy43OiBDb3VsZA0KPiA+ID4gPiA+ IFRVUk4gc2VydmVycyBub3QgY2h1bmsgZGF0YSBmcm9tIHN0cmVhbS1vcmllbnRlZCB0cmFuc3Bv cnRzIChUQ1ANCj4gPiA+ID4gPm9yDQo+ID4gPiA+ID5UTFMpICB0byBhIHByZWZlcnJlZCBNVFUg c2l6ZSBiZWZvcmUgcmVsYXlpbmcgdG8gcGVlcnM/DQo+ID4gPiA+ID4gU3BlY2lmaWNhbGx5LCB0 aGVyZSBhcmUgbGlrZWx5DQo+ID4gPiA+ID4gc29tZSBjYXNlcyB3aGVyZWluIHRoZSBzZXJ2ZXIg Y291bGQgZGVhbCB3aXRoIHRoZSBjbGllbnQgZGF0YQ0KPiA+ID4gPiA+bWVzc2FnZXMgIGxhcmdl ciB0aGFuIHRoZSByZWNvbW1lbmRlZCA1MDBCIGxpbWl0LiBPbiB0aGF0IHBvaW50LA0KPiA+ID4g PiA+c2hvdWxkIHNlcnZlcnMgZXZlbiAgYWNjZXB0IGRhdGEgbGFyZ2VyIHRoYW4gdGhpcyByZWNv bW1lbmRlZCBzaXplID8NCj4gPiA+ID4gPi0NCj4gPiA+ID4NCj4gPiA+ID4gUGxlYXNlIHNlZQ0K PiA+ID4gPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXR1cm5i aXMtMjcjc2VjdGlvbi0xNQ0KPiA+ID4gPiBmb3IgVENQLXRvLVVEUCByZWxheS4gSWYgdGhlIFBN VFUgaXMgbm90IGtub3duLCBhbmQgb24gbGVnYWN5IG9yDQo+ID4gPiA+IG90aGVyd2lzZSB1bnVz dWFsIG5ldHdvcmtzLA0KPiA+ID4gPiA1MDAgYnl0ZSBsaW1pdCBmb3IgYXBwbGljYXRpb24gZGF0 YSBpcyByZWNvbW1lbmRlZC4NCj4gPiA+ID4NCj4gPiA+ID4gPiBTZWN0aW9uIDMuOTogVGhlcmUg bWF5IGJlDQo+ID4gPiA+ID4gY2FzZXMgd2hlcmUgdGhlIFRMUyBjb25uZWN0aW9uIHBvc3QgVENQ IGNvbm5lY3Rpb24gZXN0YWJsaXNobWVudA0KPiA+ID4gPiA+IGZhaWxzLiBJdCB3b3VsZCB0aGVy ZWZvcmUgc2VlbXMgcHJ1ZGVudCB0byBub3QgZGVjbGFyZSB2aWN0b3J5DQo+ID4gPiA+ID4gZm9y IG9uZSBjb25uZWN0aW9uIG92ZXIgdGhlIG90aGVyIHVudGlsIFRMUyBjb25uZWN0cywgdG9vLiAt DQo+ID4gPiA+DQo+ID4gPiA+IEFncmVlZCwgRXJpYyAoYXMgcGFydCBvZiBJU0VHIHJldmlldykg c3VnZ2VzdGVkIHRvIHNpbXBsaWZ5IHRoZQ0KPiA+ID4gPiB0ZXh0LiBJIGhhdmUNCj4gPiA+IHVw ZGF0ZWQgdGhlIHRleHQgYXMgZm9sbG93czoNCj4gPiA+ID4NCj4gPiA+ID4gICAgbyAgRm9yIFRD UCBvciBUTFMtb3Zlci1UQ1AsIHRoZSByZXN1bHRzIG9mIHRoZSBIYXBweSBFeWViYWxscw0KPiA+ ID4gPiAgICAgICBwcm9jZWR1cmUgW1JGQzgzMDVdIGFyZSB1c2VkIGJ5IHRoZSBUVVJOIGNsaWVu dCBmb3Igc2VuZGluZyBpdHMNCj4gPiA+ID4gICAgICAgVFVSTiBtZXNzYWdlcyB0byB0aGUgc2Vy dmVyLg0KPiA+ID4NCj4gPiA+IElzIHRoZSBlZGl0b3IncyBjb3B5IGF2YWlsYWJsZSBmb3Igdmll d2luZyBzb21ld2hlcmU/ICBJdCB3b3VsZCBiZQ0KPiA+ID4gZ29vZCB0byBzZWUgdGhpcyAoYW5k IG90aGVyIGNoYW5nZXMpIGluIGNvbnRleHQuDQo+ID4NCj4gPiBZZXMsIFBsZWFzZSBzZWUgaHR0 cHM6Ly9naXRodWIuY29tL3RpcmVkZHkyL1RVUk5iaXMNCj4gPg0KPiA+ID4NCj4gPiA+ID4gPiBT ZWN0aW9uIDMgY291bGQgYmVuZWZpdCBmcm9tIGENCj4gPiA+ID4gPiBzdWJzZWN0aW9uIG9uIHJl cGxheXMgYW5kIHRoZSBub25jZSByb2xlLiBJbiBwYXJ0aWN1bGFyLCBhcw0KPiA+ID4gPiA+IGxh dGVyIGRpc2N1c3NlZCBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMsIHNvbWUgb2YgdGhl c2UNCj4gPiA+ID4gPiBhdHRhY2tzIGFyZSBub3QgbmV3IHRvIFRVUk4gYW5kIHNob3VsZCB0aGVy ZWZvcmUgYmUgZGVhbHQgd2l0aA0KPiA+ID4gPiA+IGJ5IHRoZSBhcHBsaWNhdGlvbiBwcm90b2Nv bCAoU1JUUCkuIFRoaXMgc2VjdGlvbiBtaWdodCBhbHNvDQo+ID4gPiA+ID4gZGVzY3JpYmUgbm9u Y2Ugcm90YXRpb24gcG9saWNpZXMgd2l0aCBtb3JlIHNwZWNpZmljaXR5LCBhcyB0aGlzDQo+ID4g PiA+ID4gaXMgdW5kZXJzcGVjaWZpZWQgaW4gdGhlDQo+ID4gPiBkb2N1bWVudC4NCj4gPiA+ID4N Cj4gPiA+ID4gSXQgaXMgZGlzY3Vzc2VkIGluIFNlY3Rpb24gNSBpbiB0aGUgc3BlY2lmaWNhdGlv biwgdGhlIHNlcnZlcg0KPiA+ID4gPiBzaG91bGQgZXhwaXJlIHRoZQ0KPiA+ID4gbm9uY2UgYXQg bGVhc3Qgb25jZSBldmVyeSBob3VyIGR1cmluZyB0aGUgbGlmZXRpbWUgb2YgdGhlIGFsbG9jYXRp b24uDQo+ID4gPiA+DQo+ID4gPiA+ID4tIFNlY3Rpb24gMyBjb3VsZCBhbHNvIGJlbmVmaXQgZnJv bSAgZGlzY3Vzc2lvbiBhYm91dCBjbGVhcnRleHQNCj4gPiA+ID4gPnZlcnN1cyBlbmNyeXB0aW9u IHRyYW5zcG9ydHMgYmV0d2VlbiBjbGllbnRzIGFuZCAgc2VydmVycy4NCj4gPiA+ID4NCj4gPiA+ ID4gSXQgaXMgZGlzY3Vzc2VkIGluDQo+ID4gPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXRyYW0tdHVybmJpcy0NCj4gPiA+IDI3I3NlY3Rpb24tMjEuMS42Lg0KPiA+ ID4NCj4gPiA+IFRoZXJlJ3Mgbm90IG11Y2ggZGlzY3Vzc2lvbiBhYm91dCBwb3RlbnRpYWwgaW5m b3JtYXRpb24gIGxlYWthZ2UgdmlhDQo+ID4gPiAoZS5nLikgVVNFUk5BTUUvVVNFUkhBU0gsIGFu ZCByZWFsbHkganVzdCBhIGNsYWltIHRoYXQgdGhlIHBlZXINCj4gPiA+IGFkZHJlc3MgaXMgdGhl ICJwcmltYXJ5IHByb3RvY29sIGNvbnRlbnQiLg0KPiA+DQo+ID4gQWdyZWVkLCBhZGRlZCB0aGUg Zm9sbG93aW5nIHBhcmFncmFwaCA6DQo+ID4NCj4gPiBJZiB0aGUgVFVSTiBjbGllbnQgYW5kIHNl cnZlciB1c2UgdGhlIFNUVU4gRXh0ZW5zaW9uIGZvciBUaGlyZC1QYXJ0eQ0KPiA+IEF1dGhvcml6 YXRpb24gW1JGQzc2MzVdLCB0aGUgdXNlcm5hbWUgZG9lcyBub3QgcmV2ZWFsIHRoZSByZWFsIHVz ZXIncw0KPiBpZGVudGl0eSwgdGhlIFVTRVJOQU1FIGF0dHJpYnV0ZSBjYXJyaWVzIGFuIGVwaGVt ZXJhbCBhbmQgdW5pcXVlIGtleQ0KPiBpZGVudGlmaWVyLCBhbmQgdGhlIGtleSBpZGVudGlmaWVy IGNhbiBjaGFuZ2UgcGVyIGNhbGwuDQo+ID4gSWYgdGhlIFRVUk4gY2xpZW50IGFuZCBzZXJ2ZXIg dXNlIHRoZSBTVFVOIGxvbmctdGVybSBjcmVkZW50aWFsDQo+ID4gbWVjaGFuaXNtIGFuZCB0aGUg dXNlcm5hbWUgcmV2ZWFscyB0aGUgcmVhbCB1c2VyJ3MgaWRlbnRpdHksIHRoZQ0KPiA+IGNsaWVu dCBuZWVkIHRvIGVpdGhlciB1c2UgKEQpVExTIHRyYW5zcG9ydCBiZXR3ZWVuIHRoZSBjbGllbnQg YW5kIHRoZQ0KPiBzZXJ2ZXIgb3IgdXNlIHRoZSBVU0VSSEFTSCBhdHRyaWJ1dGUgaW5zdGVhZCBv ZiB0aGUgVVNFUk5BTUUgYXR0cmlidXRlIHRvDQo+IGFub255bm1pemUgdGhlIHVzZXJuYW1lLg0K PiA+DQo+ID4gPg0KPiA+ID4gPiA+IEVuY3J5cHRpbmcgdGhlIG5vbmNlLCB1c2VybmFtZSwgcmVh bG0sIGV0Yy4sIGFtb25nIG90aGVyIHRoaW5ncywNCj4gPiA+ID4gPiBoYXMgb2J2aW91cyBiZW5l Zml0cy4gLSBXaHkgYXJlIFNPRlRXQVJFIGFuZCBGSU5HRVJQUklOVA0KPiA+ID4gPiA+IGF0dHJp YnV0ZXMgcmVjb21tZW5kZWQ/ICBJdCBzZWVtcyBsaWtlIGNsaWVudHMgc2hvdWxkIGJlDQo+ID4g PiA+ID4gZGlzY291cmFnZWQgZnJvbSBzZW5kaW5nIHRoZXNlIGlmIGFueXRoaW5nLCBlc3BlY2lh bGx5IGlmIG5vdA0KPiA+ID4gPiA+IHVzZWQgdG8gbWFrZSBhbGxvY2F0aW9uIGRlY2lzaW9ucyBv biB0aGUgc2VydmVyLg0KPiA+ID4gPg0KPiA+ID4gPiBVc2VybmFtZSBtYXkgbm90IGJlIHRoZSB1 c2VyIGlkZW50aXR5LCBQbGVhc2Ugc2VlDQo+ID4gPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvcmZjNzYzNSksIEl0IGNvdWxkIGJlIGFuIGVwaGVtZXJhbCBhbmQNCj4gPiA+IHVuaXF1ZSBr ZXkgaWRlbnRpZmllci4gRnVydGhlciwgdXNlcm5hbWUgY2FuIGJlIGFub255bWl6ZWQgKHBsZWFz ZQ0KPiA+ID4gc2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0t c3R1bmJpcy0yMSNzZWN0aW9uLTE0LjQpLg0KPiA+ID4gPiBTT0ZUV0FSRSBhbmQgRklOR0VSUFJJ TlQgYXR0cmlidXRlcyBhcmUgZGVmaW5lZCBpbiB0aGUgU1RVTg0KPiA+ID4gc3BlY2lmaWNhdGlv biwgc2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRyYW0tc3R1bmJp cy0yMS4NCj4gPiA+DQo+ID4gPiBUaGVzZSBtZWNoYW5pc21zICBhcmUgcGFydGlhbCBtaXRpZ2F0 aW9ucyBidXQgY2FuIHN0aWxsIGJlDQo+ID4gPiBzdXNjZXB0aWJsZSB0byBjcm9zcy0gY29ubmVj dGlvbiBjb3JyZWxhdGlvbiBhdHRhY2tzLg0KPiA+DQo+ID4gVGhlIHVzZSBvZiBGSU5HRVJQUklO VCBpcyBub3QgbWFuZGF0b3J5LCB0aGUgVFVSTiBjbGllbnQgYW5kIHNlcnZlciBtYXkNCj4gaW5j bHVkZSB0aGUgRklOR0VSUFJJTlQgYXR0cmlidXRlLiAgTm90ZSB0aGF0IElDRQ0KPiAoaHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzg0NDUpIG1hbmRhdGVzIHRoZSB1c2Ugb2YgRklOR0VS UFJJTlQNCj4gYXR0cmlidXRlLiBBZGRlZCB0aGUgZm9sbG93aW5nIGxpbmUgZm9yIFNPRlRXQVJF IGF0dHJpYnV0ZSAoVFVSTmJpcyBpcyB1c2luZw0KPiB0aGUgc2FtZSBiZWhhdmlvciBkZWZpbmVk IGluIFJGQzU3NjYgdG8gdXNlIFNPRlRXQVJFIGF0dHJpYnV0ZSkgIDoNCj4gPg0KPiA+IFNPRldB VEUgYXR0cmlidXRlIGNhbiByZXZlYWwgdGhlIHNwZWNpZmljIHNvZnR3YXJlIHZlcnNpb24gb2Yg dGhlIFRVUk4NCj4gY2xpZW50IGFuZCBzZXJ2ZXIgdG8gZWF2ZXNkcm9wcGVyIGFuZCBpdCBtaWdo dCBwb3NzaWJseSBhbGxvdyBhdHRhY2tzIGFnYWluc3QNCj4gdnVsbmVyYWJsZSBzb2Z0d2FyZSB0 aGF0IGlzIGtub3duIHRvIGNvbnRhaW4gc2VjdXJpdHkgaG9sZXMuIElmIGl0IGlzIGltcG9ydGFu dA0KPiB0byBwcmV2ZW50IGFuIGVhdmVzZHJvcHBlciBmcm9tIGxlYXJuaW5nIHRoZSBzb2Z0d2Fy ZSB2ZXJzaW9uLCBUVVJOIGNhbg0KPiBiZSBydW4gb3ZlciAoRClUTFMuDQo+IA0KPiBUaGUgbGF0 ZXIgc3VnZ2VzdGlvbiB3YXM6DQo+IA0KPiAlIFdlIHdhbnQgdG8gYXZvaWQgZG91YmxlIGVuY3J5 cHRpb24gb2YgYXBwbGljYXRpb24gZGF0YSwgYW5kIFNPRlRXQVJFDQo+IGF0dHJpYnV0ZSBoYXMN Cj4gJSBiZWVuIHNlbnQgaW4gY2xlYXIgdGV4dCBhbGwgdGhlc2UgeWVhcnMgaW4gdGhlIGZpZWxk LCBhbmQgbm8gYXR0YWNrIGhhcyBiZWVuDQo+ICUgZGV0ZWN0ZWQgYmFzZWQgb24gU09GVFdBUkUg ZmllbGQuIEkgY2FuIHJldmlzZSB0aGUgdGV4dCBhcyBmb2xsb3dzOg0KPiAlIElmIHRoZSBzb2Z0 d2FyZSB2ZXJzaW9uIGlzIGtub3duIHRvIGNvbnRhaW4gc2VjdXJpdHkgdnVsbmVyYWJpbGl0aWVz LCBUVVJODQo+IFNIT1VMRCBiZSAlIHJ1biBvdmVyIChEKVRMUyB0byBwcmV2ZW50IGxlYWtpbmcg dGhlIFNPRlRXQVJFIGF0dHJpYnV0ZSBpbg0KPiBjbGVhciB0ZXh0Lg0KPiANCj4gSSB0aGluayBz b21lIG9mIHRoZSBjb25jZXJuIGlzIG92ZXIgdGhlIHJpc2sgb2Ygc28tY2FsbGVkICJ6ZXJvLWRh eSINCj4gZXhwbG9pdHMsIHdoZXJlIHRoZSBhdHRhY2tlciBrbm93cyBvZiBhIHZlcnNpb24tc3Bl Y2lmaWMgZmxhdyBidXQgdGhlDQo+IGRlZmVuZGVycyBkbyBub3QgKGFuZCBoYXZlIHplcm8gZGF5 cyBub3RpY2UgdG8gcHJvdGVjdCBhZ2FpbnN0IGl0KS4gIFN1Y2ggYQ0KPiBjb25jZXJuIHdvdWxk IHN1Z2dlc3QgdG8gYXZvaWQgc2VuZGluZyBTT0ZUV0FSRSBvdmVyIGVuZW5jcnlwdGVkDQo+IHRy YW5zcG9ydCByZWdhcmRsZXNzIG9mIHRoZSBzdGF0ZSBvZiBrbm93biB2dWxuZXJhYmlsaXRpZXMs IGJ1dCBpbiB0aGUgZW5kIGl0IGlzDQo+IGEgbWF0dGVyIG9mIGxvY2FsIHBvbGljeS4NCg0KQWdy ZWVkLCBmaXhpbmcgYW5kIHJlbGVhc2luZyBhIHBhdGNoIHdpbGwgdGFrZSBzb21lIHRpbWUgYW5k IG1lYW53aGlsZSB0aGUgcG9saWN5IGNhbiBiZSBtb2RpZmllZCB0byB1c2UgdGVtcG9yYXJpbHkg dXNlIChEKVRMUy4gIEkgY2FuIGFkZCB0aGUgZm9sbG93aW5nIHRleHQ6DQpJZiB6ZXJvLWRheSB2 dWxuZXJhYmlsaXRpZXMgYXJlIGRldGVjdGVkIGluIHRoZSBzb2Z0d2FyZSB2ZXJzaW9uLCB0aGUg ZW5kcG9pbnQgcG9saWN5IGNhbiBiZSBtb2RpZmllZCB0byBtYW5kYXRlIHRoZSB1c2Ugb2YgKEQp VExTIHRpbGwgdGhlIHBhdGNoIGlzIGluIHBsYWNlIHRvIGZpeCB0aGUgZmxhdy4NCg0KPiANCj4g DQo+ID4NCj4gPiA+DQo+ID4gPiA+IC0gU2VjdGlvbiA1OiBXaGVuIHNlcnZlcnMgcmVjZWl2ZSBk YXRhIHRoYXQgZXhjZWVkcyBhbg0KPiA+ID4gPiBhbGxvY2F0aW9u4oCZcw0KPiA+ID4gPiA+IGJh bmR3aWR0aCBxdW90YSwgc2VydmVycyBzaWxlbnRseSBkaXNjYXJkIHRoaXMgZGF0YS4gVGhpcyBt ZWFucw0KPiA+ID4gPiA+IHRoZXJl4oCZcyBubyBhbGxvY2F0aW9uLWJhc2VkIGZsb3cgY29udHJv bCBtZWNoYW5pc20gYmV0d2Vlbg0KPiA+ID4gPiA+IGNsaWVudCBhbmQgc2VydmVyIGJleW9uZCB3 aGF04oCZcyBwcm92aWRlZCBieSB0aGUgdHJhbnNwb3J0IHByb3RvY29sLA0KPiByaWdodD8NCj4g PiA+ID4NCj4gPiA+ID4gWWVzLCBVRFAgZG9lcyBub3QgaW5jbHVkZSBhIGNvbmdlc3Rpb24gY29u dHJvbCBtZWNoYW5pc20uDQo+ID4gPiA+DQo+ID4gPiA+ID4gVGhpcyBzZWVtcyBmaW5lLCB0aG91 Z2gNCj4gPiA+ID4gPiBwZXJoYXBzIHNvbWUgZGlzY3Vzc2lvbiBvZiB3aHkgdGhpcyBkZXNpZ24g ZGVjaXNpb24gd2FzIG1hZGUNCj4gPiA+ID4gPiB3b3VsZCBiZSBoZWxwZnVsLiBGb3IgZXhhbXBs ZSwgSSBjb3VsZCBpbWFnaW5lIGV4cGxpY2l0IHNpZ25hbHMNCj4gPiA+ID4gPiBmcm9tIHNlcnZl cnMgdG8gY2xpZW50cyB0aGF0IGluZGljYXRlIHNlcnZlciBzdGF0ZSB3b3VsZCByZXZlYWwNCj4g PiA+ID4gPiBpbmZvcm1hdGlvbiBhYm91dCBvdGhlciBhbGxvY2F0aW9ucyBvbiB0aGUgc2VydmVy LCB3aGljaCBtaWdodA0KPiA+ID4gPiA+IGJlIHByb2JsZW1hdGljLiAtDQo+ID4gPiA+DQo+ID4g PiA+IFRoZSBlcnJvcnMgNDg2IChBbGxvY2F0aW9uIFF1b3RhIEV4Y2VlZGVkKSBvciA1MDggKElu c3VmZmljaWVudA0KPiA+ID4gPiBDYXBhY2l0eSkNCj4gPiA+IGRvIG5vdCByZXZlYWwgaW5mb3Jt YXRpb24gb2Ygd2hpY2ggb3RoZXIgdXNlcnMgYXJlIHVzaW5nIHRoZSBUVVJOIHNlcnZlci4NCj4g PiA+DQo+ID4gPiBBdCBsZWFzdCB0aGUgbGF0dGVyIHNlZW1zIHRvIGdpdmUgc29tZSBpbmRpY2F0 aW9uIHRoYXQgbWFueSBvdGhlcg0KPiA+ID4gdXNlcnMgYXJlIHVzaW5nIHRoZSBzZXJ2ZXIgYXQg dGhlICB0aW1lIChzbyB0aGF0IGl0J3Mgb3ZlcmxvYWRlZCksDQo+ID4gPiB0aG91Z2ggbm90IGlu Zm9ybWF0aW9uIGFib3V0ICp3aGljaCogdXNlcnMgdGhhdCBpcy4NCj4gPg0KPiA+IFllcywgc2lt aWxhciB0byA1MDMgSFRUUCBlcnJvciByZXNwb25zZS4NCj4gPg0KPiA+ID4NCj4gPiA+ID4gPiBT ZWN0aW9uIDcuMiBzdWdnZXN0cyB0aGF0DQo+ID4gPiA+ID4gc2VydmVycyBjYW4gcmVkaXJlY3Qg Y2xpZW50IGFsbG9jYXRpb24gcmVxdWVzdHMgdG8gb3RoZXIgc2VydmVycy4NCj4gPiA+ID4gPiBD YW4gdGhpcyBjcmVhdGUgYSBsb29wLCB3aGVyZWluIHR3byBUVVJOIHNlcnZlcnMgcmVkaXJlY3Qg dG8gb25lDQo+IGFub3RoZXI/DQo+ID4gPiA+DQo+ID4gPiA+IFRoZSBjbGllbnQgZGV0ZWN0IGFu ZCBzdG9wIHRoZSBsb29wLCBpdCBpcyBzaW1pbGFyIHRvIEhUVFAgcmVkaXJlY3Rpb24uDQo+ID4g Pg0KPiA+ID4gV2hlcmUgaXMgdGhpcyBzcGVjaWZpZWQ/DQo+ID4NCj4gPiBJdCBpcyBzcGVjaWZp ZWQgaW4gdGhlIGxhc3QgcGFyYWdyYXBoIG9mDQo+ID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtdHJhbS1zdHVuYmlzLTIxI3NlY3Rpb24tMTANCj4gPg0KPiA+IDxzbmlw Pg0KPiA+IElmIHRoZSBjbGllbnQgaGFzIGJlZW4gcmVkaXJlY3RlZCB0byBhIHNlcnZlciB0byB3 aGljaCBpdCBoYXMgYWxyZWFkeQ0KPiA+IHNlbnQgdGhpcyByZXF1ZXN0IHdpdGhpbiB0aGUgbGFz dCBmaXZlIG1pbnV0ZXMsIGl0IE1VU1QgaWdub3JlIHRoZQ0KPiA+IHJlZGlyZWN0aW9uIGFuZCBj b25zaWRlciB0aGUgdHJhbnNhY3Rpb24gdG8gaGF2ZSBmYWlsZWQuICBUaGlzDQo+ID4gcHJldmVu dHMgaW5maW5pdGUgcGluZy1wb25naW5nIGJldHdlZW4gc2VydmVycyBpbiBjYXNlIG9mIHJlZGly ZWN0aW9uDQo+ID4gbG9vcHMuDQo+ID4gPC9zbmlwPg0KPiANCj4gVGhhbmtzIGZvciB0aGUgcG9p bnRlcjsgYXMgeW91IHNhdyBpbiBteSBiYWxsb3QgcG9zaXRpb24gSSB3YXMgcXVpdGUgcHJlc3Nl ZA0KPiBmb3IgdGltZSB0aGlzIHdlZWsgYW5kIG9ubHkgd2FzIGFibGUgdG8gbG9vayBhdCB0aGUg ZGlmZi4NCg0KTm8gcHJvYmxlbSwgdGhhbmtzIGZvciBoZWxwLg0KDQpDaGVlcnMsDQotVGlydQ0K DQo+IA0KPiAtQmVuDQoNCg== From nobody Sun Jul 14 14:08:44 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 E568B120183; Sun, 14 Jul 2019 14:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CP0nxsXFm0Y6; Sun, 14 Jul 2019 14:08:41 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00::f03c:91ff:feae:de77]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E710012003E; Sun, 14 Jul 2019 14:08:40 -0700 (PDT) Received: from dooku.sandelman.ca (CPE788a207f397a-CMbc4dfb96bb50.cpe.net.cable.rogers.com [174.116.121.43]) by relay.sandelman.ca (Postfix) with ESMTPS id 95B3F1F44D; Sun, 14 Jul 2019 21:08:39 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 20CDD1301; Sun, 14 Jul 2019 17:08:58 -0400 (EDT) From: Michael Richardson To: Tero Kivinen cc: "Pascal Thubert \(pthubert\)" , David Mandelberg , =?us-ascii?Q?=3D=3Futf-8=3FQ=3FMali=3DC5=3DA1a=5FVu=3DC4=3D8Dini=3DC4?= =?us-ascii?Q?=3D87=3F=3D?= , "secdir\@ietf.org" , "iesg\@ietf.org" , "draft-ietf-6tisch-architecture.all\@ietf.org" In-reply-to: <23846.21789.391089.209823@fireball.acr.fi> References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> <23846.21789.391089.209823@fireball.acr.fi> Comments: In-reply-to Tero Kivinen message dated "Thu, 11 Jul 2019 00:14:05 +0300." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Sun, 14 Jul 2019 17:08:58 -0400 Message-ID: <7925.1563138538@dooku.sandelman.ca> Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2019 21:08:43 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Tero Kivinen wrote: > Because of this I think it is better to use some other method, i.e., = if > JN just generates random cookie and sends that to JP/JRC, and JP/JRC > will then echo that same cookie back then JN will know that exchange = is > fresh, and if that was authenticated using L2 key K1, then ASN was > implictly verified also, as JP/JRC who do know correct ASN, will drop > the incoming frame as it will have wrong MIC because of wrong nonce. I think that we can do this with a (unicast)DIS/DIO message which is worth sending anyway. We need to find a container for the nonce, but I think that is easy. I'm concerned about recovery when the JN has latched onto the wrong beacon. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl0rmekACgkQlUzhVv38 QpBFwQgAom0axpOoqVpUPZnrfFO+5pFVMtWHDNXH3zGEIz6DzDBvXmzN9cBF+TYN CpgDOZyyRhTmxwC0w9IbeEUuL5cJ0Chx1y1quAksCsAbKKVpLl0+bZvHWsrs04tM DxAnGz0hnoYlGuVjvND3WQMU3RG+++L/c4bKqx/uslHvDEe9Vjuh4HZyJ60iFpdy 7pJ+HHEsAgxqc2EEnSX6mLxex2LJRl+35moCYRr6WoCED0El7vwmomNCm9tHi/Xf 470++VP9Gqf4PWIf2skKSWx6VBOACqrVDQ6/y9KjYlzPmeV6amS5JPp27vtK+04z 41t6ZdIh1GQDG88J8ZBGXAWXrCgmlQ== =F0Vk -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jul 14 14:21:40 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 1DB0C1200A3; Sun, 14 Jul 2019 14:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NxA84qeQ3--i; Sun, 14 Jul 2019 14:21:29 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E533912003E; Sun, 14 Jul 2019 14:21:28 -0700 (PDT) Received: from dooku.sandelman.ca (CPE788a207f397a-CMbc4dfb96bb50.cpe.net.cable.rogers.com [174.116.121.43]) by relay.sandelman.ca (Postfix) with ESMTPS id 7982D1F44C; Sun, 14 Jul 2019 21:21:26 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 164171301; Sun, 14 Jul 2019 17:21:45 -0400 (EDT) From: Michael Richardson To: Tero Kivinen cc: "Pascal Thubert \(pthubert\)" , malisav@ac.me, "draft-ietf-6tisch-architecture.all\@ietf.org" , "secdir\@ietf.org" , "iesg\@ietf.org" , Thomas Watteyne , David Mandelberg In-reply-to: <23847.47989.166847.374951@fireball.acr.fi> References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> <23825.24715.882644.180316@fireball.acr.fi> <23846.21029.236657.158497@fireball.acr.fi> <23847.47989.166847.374951@fireball.acr.fi> Comments: In-reply-to Tero Kivinen message dated "Fri, 12 Jul 2019 01:43:01 +0300." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Sun, 14 Jul 2019 17:21:45 -0400 Message-ID: <8391.1563139305@dooku.sandelman.ca> Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2019 21:21:31 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable Tero Kivinen wrote: > Then it sends a beacon with ASN of x, where x is close to the ASN of > packet it wants to attack. JN then packet out to JRC with ASN of x + > n1, the attacker can ack it, and then take that packet and replay that > to the JRC at ASN of y (where x !=3D y, and y > x). When JRC sends re= ply > packet at y + m, the attacker can reply it back to JN with ASN x + n2 > and JN will accept it. Now JN has properly rejoined the network (both > JN and JRC have authenticated themselves) and JN has keys K1, but > thinks ASN is x instead of y. Next packet it sends will be encrypted > with K1 and with ASN of x + n3. If x + n3 happens to be the ASN of z > the attacker gets two frames encrypted with same key k1 and nonce > generated from ASN z. If first try goes wrong it can allow JN to repl= ay > until x + n3 > z, and then it can start over again and adjust the > starting value of x so it is better guess of how long JN will take wh= en > sending frames out... I'm gonna have to draw this this to get it all, but I think that I see the point. If I understood correctly, the attacker can get the JN to be behind in the ASN game such that it can now see a packet encrypted by the JP and JN using the same ASN. It does this by storing legitimate EBs, and replaying them at a time such that the JN is offset, and the attacker relays the pack= ets. > So I do not think we can do anything in the JN <-> JRC protocol to > protect against this, the only real way to protect against this, is to > send L2 authenticated (but not encrypted) frame after authentication > phase from the JN to JRC containing random cookie, and require that J= RC > to echo it back to JN in similar authenticated but not encrypted fram= e. I think maybe somewhere here you mean JP rather than JRC, as the JN and the JRC are not connected at L2, except via the JN. > I.e., make sure the joining process is (I leave out acks in this > picture): "security level X" <--- this is an IEEE802.15.4 thing, not a new creation, right? =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl0rnOgACgkQlUzhVv38 QpD50Qf/dVB4ka6bC7YiS+Pl9gfEJjJxB8Inm67893HYKvKX9orWzxntSnk8osy8 Tj8dCIZ8EnCg85D44toWm0kCKJiLL2mfiX9aAn9mvvs3C+ZspfgBq6Cul7tzT71h utX/j7buZsIHhKknuY+W55I0Y4MR3wrHFCkVm0BL0+IJ2umwBdcynQMZMp6SlZ7z rCs/1IE8X79ZBQzlXR0sfkrOvFK7R/iPV+E7xklUx735JzJKrVyv0GRK2ZwY7AK5 QVpCGV7bQmlJezxe22uIit6/MigJs8NHZpAejCbC40FyjZmLRjJCkkM2hEM6EbUR Y4fu04IgAT/VMHx3y5z6nxgJ06BsFA== =mfNl -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Jul 15 01:56:53 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 AD47B1201D4 for ; Mon, 15 Jul 2019 01:56:42 -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.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <156318100261.27185.2868373675214966063.idtracker@ietfa.amsl.com> Date: Mon, 15 Jul 2019 01:56:42 -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: Mon, 15 Jul 2019 08:56:52 -0000 [With my vacation in Chile to see the eclipse, I have not been able to do assignments in timely manner, so this assignment contains bit more documents than normally. I will try to get back in regular schedule for the rest of summer.] Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-08-08 Reviewer LC end Draft Leif Johansson 2019-07-08 draft-ietf-manet-dlep-latency-extension-04 David Mandelberg R2019-06-26 draft-ietf-6tisch-architecture-24 Matthew Miller 2019-07-04 draft-ietf-intarea-frag-fragile-15 Kathleen Moriarty 2019-07-11 draft-ietf-ospf-xaf-te-06 Magnus Nystrom 2019-06-20 draft-ietf-mmusic-ice-sip-sdp-36 Sean Turner R2019-07-04 draft-ietf-babel-dtls-07 Last calls: Reviewer LC end Draft Shaun Cooley 2019-03-13 draft-ietf-dots-data-channel-30 Roman Danyliw 2019-06-04 draft-ietf-rtgwg-enterprise-pa-multihoming-11 Alan DeKok 2019-06-04 draft-ietf-netvc-testing-08 Daniel Gillmor 2018-03-19 draft-gutmann-scep-14 Aanchal Malhotra 2019-06-26 draft-ietf-ipwave-ipv6-over-80211ocb-49 Catherine Meadows 2019-06-25 draft-ietf-grow-bmp-adj-rib-out-06 Catherine Meadows 2019-04-12 draft-ietf-mmusic-rfc4566bis-36 Matthew Miller 2019-04-08 draft-ietf-core-multipart-ct-03 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Sandra Murphy 2019-07-08 draft-ietf-i2nsf-applicability-13 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-08 Hilarie Orman 2019-08-05 draft-ietf-iasa2-rfc2031bis-05 Radia Perlman 2019-08-01 draft-ietf-lamps-cms-hash-sig-08 Derrell Piper 2019-08-01 draft-ietf-mile-jsoniodef-09 Tim Polk 2019-08-01 draft-ietf-acme-star-06 Vincent Roca 2019-08-01 draft-ietf-oauth-mtls-15 Kyle Rose 2019-07-31 draft-ietf-mpls-rfc8287-len-clarification-02 Joseph Salowey 2019-07-19 draft-ietf-lpwan-ipv6-static-context-hc-19 Rich Salz 2019-07-18 draft-ietf-idr-bgp-extended-messages-33 Stefan Santesson 2019-07-17 draft-ietf-ospf-yang-23 Yaron Sheffer 2019-07-16 draft-ietf-tls-exported-authenticator-09 David Waltermire 2019-02-15 draft-ietf-rtcweb-ip-handling-12 Taylor Yu 2019-02-15 draft-ietf-rtcweb-security-arch-19 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 Rifaat Shekh-Yusef 2019-07-22 draft-ietf-netconf-crypto-types-10 Next in the reviewer rotation: Melinda Shore Valery Smyslov Robert Sparks Takeshi Takahashi Tina Tsou Sean Turner Carl Wallace David Waltermire Samuel Weiler Brian Weis From nobody Mon Jul 15 02:50:56 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 AE322120104; Mon, 15 Jul 2019 02:50:42 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stefan Santesson via Datatracker To: Cc: draft-ietf-ospf-yang.all@ietf.org, ietf@ietf.org, lsr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Stefan Santesson Message-ID: <156318424257.27269.7466334573453292957@ietfa.amsl.com> Date: Mon, 15 Jul 2019 02:50:42 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-ospf-yang-23 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 09:50:43 -0000 Reviewer: Stefan Santesson Review result: Has Nits This document seems to have a reasonable security considerations section. As a nit, I notice that the abbreviation OSPF is not written out or explained at all in this document. One should hope that most people that find their way to this document are familiar with OSPF, but I still believe that is is appropriate for all IETF RFC to write out and briefly explain/reference abbreviations. In summary this document seems well written From nobody Mon Jul 15 04:12:18 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEA3A120077; Mon, 15 Jul 2019 04:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Y2S/3lJY; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=MwBLMT95 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 2jz1DSF2SGSj; Mon, 15 Jul 2019 04:12:00 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 768E4120018; Mon, 15 Jul 2019 04:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1302; q=dns/txt; s=iport; t=1563189120; x=1564398720; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=xkD+PX1gjmcHrV6VlGqz3deNUlQ1JZa5BbONG3idcUo=; b=Y2S/3lJYYbufzNQn/QeF4TirDmAQOMeT5TVNmlDBvTXW9jTt6ux8vZad HQyMZ+amlMolBAjveYjRsNa+GSAnvighpSkie0AV+vEyWY/ZchLxhm14h mr4esnAAfIp4FYflpoh/jPDnCWnXV6e/+YaBNnA0pEipcE7PepZWtWRjS 8=; IronPort-PHdr: =?us-ascii?q?9a23=3ATDRzpRbNOPUnUNISeXZzExn/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20QKbRp3VvvRDjeee87vtX2AN+96giDgDa9QNHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuJfXnYgQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAAC/Xixd/5FdJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwUBAQEBCwGBQ1ADalUgBAsoCoQSg0cDhFKJfII2l3SBLoE?= =?us-ascii?q?kA1QJAQEBDAEBIwoCAQGEQAIXgkwjNAkOAQMBAQQBAQIBBW2FPAyFSwIBAxI?= =?us-ascii?q?REQwBATcBDwIBCBoCJgICAjAVEAIEAQ0FIoMAAYFqAx0BDp9XAoE4iGBxgTK?= =?us-ascii?q?CeQEBBYUJGIITAwaBDCgBi14XgX+BECgME4JMPodOMoImjnibbwkCghmPSFS?= =?us-ascii?q?DcBuCXJUujTWXUAIEAgQFAg4BAQWBUDiBWHAVOyoBgkGCQYNxhRSFP3IBAYE?= =?us-ascii?q?njWEBgSABAQ?= X-IronPort-AV: E=Sophos;i="5.63,493,1557187200"; d="scan'208";a="594950677" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Jul 2019 11:11:59 +0000 Received: from XCH-ALN-019.cisco.com (xch-aln-019.cisco.com [173.36.7.29]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x6FBBx0G023585 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 15 Jul 2019 11:11:59 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-019.cisco.com (173.36.7.29) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 15 Jul 2019 06:11:58 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 15 Jul 2019 06:11:57 -0500 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 15 Jul 2019 06:11:57 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JWYvJu3IP2MkWjBSUZU6DaPmk/wO5u/JJ88yLCAHX67YYBybljtyNLxSIJ4fylNTmKfj5TbNwKtvIEuRuuKjb4TK5TM5ZTxbie/DvjLNxrr055PlSC7qRfhiYY8uuN9edAZChG2OgcAPgDiXhNcu8tXbPM3hGQY6JTvmIr2M6GHCxcqPhz2YCp+DnzmLF5Tl8gmmrrUQh5X5Th+BQKQ5JQy41w3jwlnm9c4zyia3p6MTPBmfAy+uBr+IdOpvR3PQMcnWjFt+oykA+dPvK+BtDGwPIzPz4xNc/Az6z8aitNSeHmzl0LZNa7837B8nnxhjgLMerDTbXSqjqjLD4sC2wg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xkD+PX1gjmcHrV6VlGqz3deNUlQ1JZa5BbONG3idcUo=; b=oYY6owkY+O7uYXln2zORG2lqMvkOmetQCCMnkVZNQS/Fd50DDtiLuZp+p6eMlHqm8LBgLZCaLadrd8yuUWay90mg333DvYS//5Ue03OYje1LqiVsDSfOFmw+75BNITbLwTYMbGe61TXsmiWuBENjIqkC0ylfX2leeCbs4J8NMK/1cUTWJiZeaIS+CFwwjJAJ/CiNC0y1/KdSqpI/dgw9/RPaFVZN4C0fa0vdV/F1jdPEjZbd9lyFuXFqFe8629/1qkNn5fPk86BuVdX4DwThDNbqBYCECxdSrL7/z7YO+VAI9aQkbt6QoOLe65x44//iIAGlkGCRd2J6GzennrR1sw== ARC-Authentication-Results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cisco.com;dmarc=pass action=none header.from=cisco.com;dkim=pass header.d=cisco.com;arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=xkD+PX1gjmcHrV6VlGqz3deNUlQ1JZa5BbONG3idcUo=; b=MwBLMT95e0aRAieMZ2pDKpxPc64mJt1djBCJH3G0UXk82lQuPoGttTQPhoODqA0t9lLukxCfY1RX1FACcOzPZYA8dgU5DArwzqpY5fnUtyxfZQIiQT4VZ4trWuZ64/c48krSNM2iTTxz5YnbZm0JAa56UnZ0svEb2SY3aqJBQcE= Received: from MWHPR11MB1902.namprd11.prod.outlook.com (10.175.53.139) by MWHPR11MB1344.namprd11.prod.outlook.com (10.169.233.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2073.10; Mon, 15 Jul 2019 11:11:57 +0000 Received: from MWHPR11MB1902.namprd11.prod.outlook.com ([fe80::2456:d2d2:585d:83a2]) by MWHPR11MB1902.namprd11.prod.outlook.com ([fe80::2456:d2d2:585d:83a2%6]) with mapi id 15.20.2073.012; Mon, 15 Jul 2019 11:11:56 +0000 From: "Acee Lindem (acee)" To: Stefan Santesson , "secdir@ietf.org" CC: "draft-ietf-ospf-yang.all@ietf.org" , "ietf@ietf.org" , "lsr@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-ospf-yang-23 Thread-Index: AQHVOvLUn/JAk+YAKEWqqX6r9HFrX6bLQz8A Date: Mon, 15 Jul 2019 11:11:56 +0000 Message-ID: <71A4B5D4-2268-492C-9D9C-9023F2AC7ED8@cisco.com> References: <156318424257.27269.7466334573453292957@ietfa.amsl.com> In-Reply-To: <156318424257.27269.7466334573453292957@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=acee@cisco.com; x-originating-ip: [173.38.117.87] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: bb3e8d10-4c7a-40c8-f8c7-08d709153ffc x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:MWHPR11MB1344; x-ms-traffictypediagnostic: MWHPR11MB1344: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 00997889E7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(39860400002)(396003)(366004)(376002)(199004)(189003)(66066001)(99286004)(316002)(110136005)(54906003)(33656002)(26005)(91956017)(66946007)(4744005)(186003)(76116006)(229853002)(76176011)(64756008)(66476007)(66556008)(6506007)(102836004)(6512007)(256004)(5660300002)(14444005)(81156014)(81166006)(66446008)(486006)(2906002)(68736007)(305945005)(3846002)(6116002)(2501003)(8676002)(476003)(478600001)(8936002)(7736002)(2616005)(11346002)(446003)(6246003)(966005)(6436002)(6486002)(53936002)(4326008)(14454004)(36756003)(25786009)(86362001)(71190400001)(6306002)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1344; H:MWHPR11MB1902.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: MMmYdgg1ZQEqgDXQWWTlOJrdGivFBuol374Hu8L00rskrvr8Kk+JKfV/nqAE/Q0c3MjcEiQOfBYlnNyg4Uj5knlog0YQM0ZGwBgn2sQpfGLm6DAqXxG4N6LuZ83PKRn0e6Bka2h6ItOnC0gV7fb+A/JRPdjio1iUkFVuEXpwVqx10gT5lhsOSctZK6JMURsZwgNIXw0dH0KApehqbPZdpp7xNpe2uOGCmtkyxWoDNir5fYygRbaQ1i92nyTA6Zr938sx5YOV8dW+OhzG0OeYloguyxVe2xJs+UzYXpliRqSi8mRi0Hu1/MPdeffmZxJYgpyd04dRmXcAkI31s7a8k7x6kFRUO5N/pbvx/6RaUf4pbEjbCcjPlU7MjlvVjzck+b4I19B7iuK4jHGzj4VFLnfIYaLDoTjHuB0a7byn31Q= Content-Type: text/plain; charset="utf-8" Content-ID: <10CDD6E327D95345A8C159DEE347676B@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: bb3e8d10-4c7a-40c8-f8c7-08d709153ffc X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jul 2019 11:11:56.6249 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: acee@cisco.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1344 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.29, xch-aln-019.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-ospf-yang-23 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, 15 Jul 2019 11:12:03 -0000 SGkgU3RlZmFuLCANCg0K77u/T24gNy8xNS8xOSwgNTo1MSBBTSwgIlN0ZWZhbiBTYW50ZXNzb24g dmlhIERhdGF0cmFja2VyIiA8bm9yZXBseUBpZXRmLm9yZz4gd3JvdGU6DQoNCiAgICBSZXZpZXdl cjogU3RlZmFuIFNhbnRlc3Nvbg0KICAgIFJldmlldyByZXN1bHQ6IEhhcyBOaXRzDQogICAgDQog ICAgVGhpcyBkb2N1bWVudCBzZWVtcyB0byBoYXZlIGEgcmVhc29uYWJsZSBzZWN1cml0eSBjb25z aWRlcmF0aW9ucyBzZWN0aW9uLg0KICAgIA0KICAgIEFzIGEgbml0LCBJIG5vdGljZSB0aGF0IHRo ZSBhYmJyZXZpYXRpb24gT1NQRiBpcyBub3Qgd3JpdHRlbiBvdXQgb3IgZXhwbGFpbmVkDQogICAg YXQgYWxsIGluIHRoaXMgZG9jdW1lbnQuIE9uZSBzaG91bGQgaG9wZSB0aGF0IG1vc3QgcGVvcGxl IHRoYXQgZmluZCB0aGVpciB3YXkNCiAgICB0byB0aGlzIGRvY3VtZW50IGFyZSBmYW1pbGlhciB3 aXRoIE9TUEYsIGJ1dCBJIHN0aWxsIGJlbGlldmUgdGhhdCBpcyBpcw0KICAgIGFwcHJvcHJpYXRl IGZvciBhbGwgSUVURiBSRkMgdG8gd3JpdGUgb3V0IGFuZCBicmllZmx5IGV4cGxhaW4vcmVmZXJl bmNlDQogICAgYWJicmV2aWF0aW9ucy4NCg0KIE5vdGUgdGhhdCBPU1BGIGlzIGluIHRoZSBsaXN0 IG9mIGFiYnJldmlhdGlvbnMgdGhhdCBkb24ndCByZXF1aXJlIGV4cGFuc2lvbiAtIGh0dHBzOi8v d3d3LnJmYy1lZGl0b3Iub3JnL21hdGVyaWFscy9hYmJyZXYuZXhwYW5zaW9uLnR4dA0KDQpJbiBm YWN0LCBPU1BGIGhhZCBpdHMgb3duIFdHIGZvciBtb3JlIHRoYW4gMjAgeWVhcnMgX18gV2Ugb25s eSBjb21iaW5lZCBPU1BGIGFuZCBJUy1JUyBpbnRvIExTUiBsZXNzIHRoYW4gMiB5ZWFycyBiYWNr LiANCg0KVGhhbmtzLA0KQWNlZQ0KICAgIA0KICAgIEluIHN1bW1hcnkgdGhpcyBkb2N1bWVudCBz ZWVtcyB3ZWxsIHdyaXR0ZW4NCiAgICANCiAgICANCiAgICANCg0K From nobody Mon Jul 15 04:35:35 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 B9482120098 for ; Mon, 15 Jul 2019 04:35:26 -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=unavailable 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 m8GCWcWiSRfo for ; Mon, 15 Jul 2019 04:35:25 -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 A0C1C120077 for ; Mon, 15 Jul 2019 04:35:24 -0700 (PDT) Received: from s554.loopia.se (localhost [127.0.0.1]) by s554.loopia.se (Postfix) with ESMTP id 6F5231F163AA for ; Mon, 15 Jul 2019 13:27:29 +0200 (CEST) Received: from s498.loopia.se (unknown [172.21.200.36]) by s554.loopia.se (Postfix) with ESMTP id 4FFDA794CD1; Mon, 15 Jul 2019 13:27:29 +0200 (CEST) Received: from s476.loopia.se (unknown [172.22.191.6]) by s498.loopia.se (Postfix) with ESMTP id 4BB8A470765; Mon, 15 Jul 2019 13:27:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at amavis.loopia.se Received: from s499.loopia.se ([172.22.191.6]) by s476.loopia.se (s476.loopia.se [172.22.190.16]) (amavisd-new, port 10024) with LMTP id c-o2Vdwxj6ex; Mon, 15 Jul 2019 13:27:28 +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.1.217] (gw.aaa-sec.ideon.se [85.235.7.89]) (Authenticated sender: mailstore2@aaa-sec.com) by s499.loopia.se (Postfix) with ESMTPSA id CC7121CDADCA; Mon, 15 Jul 2019 13:27:28 +0200 (CEST) User-Agent: Microsoft-MacOutlook/10.1a.0.190609 Date: Mon, 15 Jul 2019 13:27:27 +0200 From: Stefan Santesson To: "Acee Lindem (acee)" , "secdir@ietf.org" CC: "draft-ietf-ospf-yang.all@ietf.org" , "ietf@ietf.org" , "lsr@ietf.org" Message-ID: Thread-Topic: Secdir last call review of draft-ietf-ospf-yang-23 References: <156318424257.27269.7466334573453292957@ietfa.amsl.com> <71A4B5D4-2268-492C-9D9C-9023F2AC7ED8@cisco.com> In-Reply-To: <71A4B5D4-2268-492C-9D9C-9023F2AC7ED8@cisco.com> 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-ospf-yang-23 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, 15 Jul 2019 11:35:27 -0000 Thanks for clarifying that. I just noticed that V2 of OSPF had its abbrevia= tion written out, but not V3 I stand corrected then :) Stefan Santesson=20 =EF=BB=BFOn 2019-07-15, 13:12, "Acee Lindem (acee)" wrote: Hi Stefan,=20 =20 =EF=BB=BFOn 7/15/19, 5:51 AM, "Stefan Santesson via Datatracker" wrote: =20 Reviewer: Stefan Santesson Review result: Has Nits =20 This document seems to have a reasonable security considerations se= ction. =20 As a nit, I notice that the abbreviation OSPF is not written out or= explained at all in this document. One should hope that most people that find= their way to this document are familiar with OSPF, but I still believe that i= s is appropriate for all IETF RFC to write out and briefly explain/refer= ence abbreviations. =20 Note that OSPF is in the list of abbreviations that don't require expa= nsion - https://www.rfc-editor.org/materials/abbrev.expansion.txt =20 In fact, OSPF had its own WG for more than 20 years __ We only combined= OSPF and IS-IS into LSR less than 2 years back.=20 =20 Thanks, Acee =20 In summary this document seems well written =20 =20 =20 =20 =20 From nobody Mon Jul 15 05:10:42 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 8E4BC120112 for ; Mon, 15 Jul 2019 05:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 y2ZsNNH5jAPx for ; Mon, 15 Jul 2019 05:10:39 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DBF51200F4 for ; Mon, 15 Jul 2019 05:10:39 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.27/8.16.0.27) with SMTP id x6FC7h6p028113; Mon, 15 Jul 2019 13:10:34 +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 : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=bKUlEEhcs6LN4bED4rTok6SAHRvD/RxOAF4YWS8iIi0=; b=fxL6NjG5Ggz4TDBGfVU86VQt7gx3HvegGTkrUEHlvpVYm4nADm1H7TfjKqoIVDCgISsK AtLFFZ9+sqd85ieB70cga5GHfnXnYgLAmP9VxiF1/jBks1K8hX/CccWRZZK4+VMTveJs WT12S6qoceQrSmK6zV9Vq3bZsvRUrj/kZnDkVcEaFAtCi+IX7TlhRlpqXSoht3mEvd4H EAp0mkVkr9s5lSDeiJaIt1wWvS5wL3ytFTtm+h4TyjGn01BsC8N1My5xJjxYNVytXANL JQCwFccUx2hpfwSz1/iX6nxDz5C5pAGxNiD508VrVfQtUoXGu5/woQkalhKKFZWDtKDf +A== Received: from prod-mail-ppoint7 (prod-mail-ppoint7.akamai.com [96.6.114.121] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2tq4cd16kd-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 15 Jul 2019 13:10:34 +0100 Received: from pps.filterd (prod-mail-ppoint7.akamai.com [127.0.0.1]) by prod-mail-ppoint7.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x6FC2VFK028123; Mon, 15 Jul 2019 08:10:33 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint7.akamai.com with ESMTP id 2tqamwpa0h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 15 Jul 2019 08:10:33 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 15 Jul 2019 08:10:32 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.004; Mon, 15 Jul 2019 08:10:32 -0400 From: "Salz, Rich" To: "secdir-secretary@mit.edu" , Tero Kivinen , "secdir@ietf.org" Thread-Topic: [secdir] Assignments Thread-Index: AQHVOutObb7RplY2K0GQ3TJ4gEGiCKbLlsGA Date: Mon, 15 Jul 2019 12:10:31 +0000 Message-ID: <9366DCDC-B6EF-4C0C-8C75-BA5F93CA50C6@akamai.com> References: <156318100261.27185.2868373675214966063.idtracker@ietfa.amsl.com> In-Reply-To: <156318100261.27185.2868373675214966063.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1b.0.190708 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.241] Content-Type: text/plain; charset="utf-8" Content-ID: <90B98A3B79997D4C908D648A73940612@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-15_03:, , 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=678 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907150145 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-15_03:, , 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=718 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907150146 Archived-At: Subject: Re: [secdir] Assignments 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, 15 Jul 2019 12:10:41 -0000 PiAgICBbV2l0aCBteSB2YWNhdGlvbiBpbiBDaGlsZSB0byBzZWUgdGhlIGVjbGlwc2UsIEkgaGF2 ZSBub3QgYmVlbiBhYmxlIHRvIGRvDQogIA0KSSBiZWxpZXZlIGl0IHdvdWxkIGJlIGFuIGFjY2Vw dGFibGUgdXNlIG9mIHRoaXMgbWFpbGluZyBsaXN0IGlmIHlvdSB3ZXJlIHRvIHBvc3QgYSBjb3Vw bGUgb2YgcGljdHVyZXMuICBQbGVhc2UuDQoNCg== From nobody Mon Jul 15 05:23:54 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 3D5DB120131; Mon, 15 Jul 2019 05:23:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Leif Johansson via Datatracker To: Cc: manet@ietf.org, ietf@ietf.org, draft-ietf-manet-dlep-latency-extension.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Leif Johansson Message-ID: <156319341919.27264.2473365221253891316@ietfa.amsl.com> Date: Mon, 15 Jul 2019 05:23:39 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-manet-dlep-latency-extension-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2019 12:23:40 -0000 Reviewer: Leif Johansson Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document is ready, I have no issues. From nobody Mon Jul 15 11:38:27 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D8781201C3; Mon, 15 Jul 2019 11:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 AGFqNsAR-DNN; Mon, 15 Jul 2019 11:38:20 -0700 (PDT) Received: from Mail.Yoyodyne.COM (mail.yoyodyne.com [IPv6:2604:4ec0:0:2::d]) by ietfa.amsl.com (Postfix) with SMTP id 9A9BA12014F; Mon, 15 Jul 2019 11:38:17 -0700 (PDT) Received: from [10.0.4.30] ([24.5.60.91]) by Mail.Yoyodyne.COM via Internet for (and others); Mon, 15 Jul 2019 11:38:16 PDT From: Derrell Piper Content-Type: multipart/signed; boundary="Apple-Mail=_E43C490F-D870-49A7-8F81-19173232DD2E"; protocol="application/pkcs7-signature"; micalg=sha-256 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Mon, 15 Jul 2019 11:38:15 -0700 References: <156318081142.27105.6053942334463213815.idtracker@ietfa.amsl.com> To: draft-ietf-mile-jsoniodef.all@ietf.org, secdir@ietf.org, ietf@ietf.org In-Reply-To: <156318081142.27105.6053942334463213815.idtracker@ietfa.amsl.com> Message-Id: <37A9B76B-1B71-46E0-8113-B53DEFB16911@electric-loft.org> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: [secdir] draft-ietf-mile-jsoniodef 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, 15 Jul 2019 18:38:26 -0000 --Apple-Mail=_E43C490F-D870-49A7-8F81-19173232DD2E Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Reviewer: Derrell Piper Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document is simply a JSON schema definition for IODEF RFC7970 and introduces no new security concerns. --Apple-Mail=_E43C490F-D870-49A7-8F81-19173232DD2E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCCkkw ggTpMIID0aADAgECAgRMDowbMA0GCSqGSIb3DQEBCwUAMIG0MRQwEgYDVQQKEwtFbnRydXN0Lm5l dDFAMD4GA1UECxQ3d3d3LmVudHJ1c3QubmV0L0NQU18yMDQ4IGluY29ycC4gYnkgcmVmLiAobGlt aXRzIGxpYWIuKTElMCMGA1UECxMcKGMpIDE5OTkgRW50cnVzdC5uZXQgTGltaXRlZDEzMDEGA1UE AxMqRW50cnVzdC5uZXQgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgKDIwNDgpMB4XDTExMTExMTE1 MjU1MVoXDTIxMTExMTIzMjc1MFowgaUxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1FbnRydXN0LCBJ bmMuMTkwNwYDVQQLEzB3d3cuZW50cnVzdC5uZXQvQ1BTIGlzIGluY29ycG9yYXRlZCBieSByZWZl cmVuY2UxHzAdBgNVBAsTFihjKSAyMDEwIEVudHJ1c3QsIEluYy4xIjAgBgNVBAMTGUVudHJ1c3Qg Q2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCpYPyALmJw k4z2GWJLrTZYlw5O/p2PAC4//myCDUGGIyPWk82D/o9D4eLrbSgbEbsB+uuATnNe3lrFqjozsYve eNIk+9EUvZRNkl+YNFn/2IY2HHe4YWJWWPuAVQ8DKYR96NCzpt/1Irgkv+QDrHksTX5aqBIPAfjN EJPPLRyzdGuH277CsWcjDujjxxDFAzi3yAVFoIvsJBXdyxw4X2aZCLP315HcX5cHYtxBnI7RxjX2 U6d3rmgUNaRnEz5JjW6+nyCjn6h3Gbw4u1XTYM6g/q+33EwZmpNz6Je+BT9/d/JppfedXvTg+A6w Ivs+qDYabkTEj6Rq1baljNyc87AHAgMBAAGjggEOMIIBCjAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0T AQH/BAgwBgEB/wIBADAzBggrBgEFBQcBAQQnMCUwIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmVu dHJ1c3QubmV0MDIGA1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9jcmwuZW50cnVzdC5uZXQvMjA0OGNh LmNybDA7BgNVHSAENDAyMDAGBFUdIAAwKDAmBggrBgEFBQcCARYaaHR0cDovL3d3dy5lbnRydXN0 Lm5ldC9ycGEwHQYDVR0OBBYEFEeQpKEKQyC/0HRUuJT6xHu1thwFMB8GA1UdIwQYMBaAFFXkgdER gL7YibkIozH5oSQJFrlwMA0GCSqGSIb3DQEBCwUAA4IBAQBRNMJxm4DOQpk8ZWRM0mdOp4ztTrBK BziTwUc5VbZR0WIBIGejvX4gL5Rhj8Y3/xbcABb9RUBAfkGHHIxhIyf12Jj9JTA7oavzcvrNMJ20 wrbKtOLFeUu0cFCRuxdhT0dWMJ0Z3g8bPbWd7Gu7hjIYZ5/Fhc/Hw3duZwZ1t0CpyLtuhIhJhaSO Zez4sXqT0VvgLb0AXWhWd9zzoHrnx23FqW620NhJlH6CTDbMH+JptP6NT5Xr/uGFFJhkVnYDhHx6 wMjd4KBhnYvnbYbSdamln6CWcEXVwBk2ioUtrIHjYEFYxEd7jqvZEtAu20Z5KHvMK67Tgqp0Cqgy kXqbEa+bMIIFWDCCBECgAwIBAgIQEd9X2KIWvBwAAAAATDO9SzANBgkqhkiG9w0BAQsFADCBpTEL MAkGA1UEBhMCVVMxFjAUBgNVBAoTDUVudHJ1c3QsIEluYy4xOTA3BgNVBAsTMHd3dy5lbnRydXN0 Lm5ldC9DUFMgaXMgaW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTEfMB0GA1UECxMWKGMpIDIwMTAg RW50cnVzdCwgSW5jLjEiMCAGA1UEAxMZRW50cnVzdCBDbGFzcyAxIENsaWVudCBDQTAeFw0xODEx MTMyMjAxMzBaFw0xOTExMTMyMjMxMjdaMIGfMR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0 ZWQxNzA1BgNVBAsTLkVudHJ1c3QgQ2xhc3MgMSBJZGVudGl0eSBDZXJ0aWZpY2F0aW9uIFNlcnZp Y2UxHjAcBgNVBAMMFWRkcEBlbGVjdHJpYy1sb2Z0Lm9yZzEkMCIGCSqGSIb3DQEJARYVZGRwQGVs ZWN0cmljLWxvZnQub3JnMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA04HrzV6j2isr QECHjetWFZ771HycrJfmWjXghDOMbHhotvv+Fget4HTze2EPnMtcSxT36MILnmpEDhzXZzMHnom6 M6eqo7QK17Mn1bE9oeOeNiCH0LbHwuqpYQ0EgXul5wwngHN5asgabILySG0ecF+Utuf7+yH8+Ufc OMlLe0MRONJhNCeeGDZiRkG5TrysslzBw/KsGE5w9/DIrPLDZZB1XK2hbmq8RusV9UYPB9zZhETo IOrdaoo0yIDa3e7o8RkmU3cjQxbksNmEuw0lKEnPMmku6vpXgYk/y0TmFmyoyt6hjl8SNWjVMWDs ZQS5Jh/68alzEtidEkxF0KHIwQIDAQABo4IBhjCCAYIwDgYDVR0PAQH/BAQDAgWgMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDBCBgNVHSAEOzA5MDcGC2CGSAGG+mwKAQQBMCgwJgYIKwYB BQUHAgEWGmh0dHA6Ly93d3cuZW50cnVzdC5uZXQvcnBhMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6 Ly9jcmwuZW50cnVzdC5uZXQvY2xhc3MxY2EuY3JsMGoGCCsGAQUFBwEBBF4wXDAjBggrBgEFBQcw AYYXaHR0cDovL29jc3AuZW50cnVzdC5uZXQwNQYIKwYBBQUHMAKGKWh0dHA6Ly9haWEuZW50cnVz dC5uZXQvMjA0OGNsYXNzMXNoYTIuY2VyMCAGA1UdEQQZMBeBFWRkcEBlbGVjdHJpYy1sb2Z0Lm9y ZzAfBgNVHSMEGDAWgBRHkKShCkMgv9B0VLiU+sR7tbYcBTAdBgNVHQ4EFgQU+J5uDdWXcSluFwxv Z2FeWBJX+HYwCQYDVR0TBAIwADANBgkqhkiG9w0BAQsFAAOCAQEAA5tIRug94hPDaWBEb9Tl/poX gTZjtCtVStEvz7Rs0FL6OqoeBJZhvyrgCvHbIzqMP+VU+7aLs+1DSSkekaCKj80bYFpZ+4qqpZHz AWy80jVdu+N8+GW9zKXNEcOEa3Fm8Wpl2P3agIRygKxAAa/gvqd263C7VeYaS0JX85a/dR1BItHP D/3F4Pe36QO7Te1/EXv+CScdAHR84grEtX6rwGFqzipUBAR2UfpTyBk422X+6t63nUT5FK5xYPgL 0SPHct0cvEosPGaDprzHBfVJQHVvgj0XC2b8zHy/g6tiboB2o0x/x4JQnA1+Yr1dtOmPpTPqeud6 tturBV8skRB2yDGCA/EwggPtAgEBMIG6MIGlMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNRW50cnVz dCwgSW5jLjE5MDcGA1UECxMwd3d3LmVudHJ1c3QubmV0L0NQUyBpcyBpbmNvcnBvcmF0ZWQgYnkg cmVmZXJlbmNlMR8wHQYDVQQLExYoYykgMjAxMCBFbnRydXN0LCBJbmMuMSIwIAYDVQQDExlFbnRy dXN0IENsYXNzIDEgQ2xpZW50IENBAhAR31fYoha8HAAAAABMM71LMA0GCWCGSAFlAwQCAQUAoIIC BzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTA3MTUxODM4MTZa MC8GCSqGSIb3DQEJBDEiBCA6uq2LEgzXPkvUWrGNt7JDPT0qM10gPko7rVEjI22OPjCBywYJKwYB BAGCNxAEMYG9MIG6MIGlMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNRW50cnVzdCwgSW5jLjE5MDcG A1UECxMwd3d3LmVudHJ1c3QubmV0L0NQUyBpcyBpbmNvcnBvcmF0ZWQgYnkgcmVmZXJlbmNlMR8w HQYDVQQLExYoYykgMjAxMCBFbnRydXN0LCBJbmMuMSIwIAYDVQQDExlFbnRydXN0IENsYXNzIDEg Q2xpZW50IENBAhAR31fYoha8HAAAAABMM71LMIHNBgsqhkiG9w0BCRACCzGBvaCBujCBpTELMAkG A1UEBhMCVVMxFjAUBgNVBAoTDUVudHJ1c3QsIEluYy4xOTA3BgNVBAsTMHd3dy5lbnRydXN0Lm5l dC9DUFMgaXMgaW5jb3Jwb3JhdGVkIGJ5IHJlZmVyZW5jZTEfMB0GA1UECxMWKGMpIDIwMTAgRW50 cnVzdCwgSW5jLjEiMCAGA1UEAxMZRW50cnVzdCBDbGFzcyAxIENsaWVudCBDQQIQEd9X2KIWvBwA AAAATDO9SzANBgkqhkiG9w0BAQEFAASCAQA89dUSxtWw8B9XanzPHcL9dmJ4iV3bYjBq+WcDW+VN 2cDZW4YBsiqNPQ8p+YlhNIi4JG29Dc0t+zKeeiHLvB4jwzyFtDDAdie3yQt8x0iqm/GenDw+20eY CUJe0WaWUor8/6V338jHnzEFbXv4bkdktcWt5/OsaY64ebkAF1lK4holngqgRG4ZIQz+gd1FmmRH T5nrrOErVT7X/ptY7zMlcX7SY8TM2YnUC1Y43UoPuSh6YmRbtarnUyjsMoEnb0cOjnkC3pB8wY9c r4sy3eSecDVUsvQhsCLzrUVRE2/hDVNhaUiGZ+9LNjqfyziZZVvG/Xh3exbzYYo423UDM75oAAAA AAAA --Apple-Mail=_E43C490F-D870-49A7-8F81-19173232DD2E-- From nobody Mon Jul 15 17:51:20 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 5E787120164; Mon, 15 Jul 2019 17:51:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Sean Turner via Datatracker To: Cc: draft-ietf-babel-dtls.all@ietf.org, ietf@ietf.org, babel@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.3 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Sean Turner Message-ID: <156323827231.27121.11323372537486026352@ietfa.amsl.com> Date: Mon, 15 Jul 2019 17:51:12 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-babel-dtls-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2019 00:51:12 -0000 Reviewer: Sean Turner Review result: Ready Thanks for responding to my review of -03. I have nothing new to add on -07. From nobody Tue Jul 16 12:59:46 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 A202312012B; Tue, 16 Jul 2019 12:59:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yaron Sheffer via Datatracker To: Cc: draft-ietf-tls-exported-authenticator.all@ietf.org, ietf@ietf.org, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.98.4 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Yaron Sheffer Message-ID: <156330717256.15259.2193942101748847069@ietfa.amsl.com> Date: Tue, 16 Jul 2019 12:59:32 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-tls-exported-authenticator-09 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, 16 Jul 2019 19:59:33 -0000 Reviewer: Yaron Sheffer Review result: Has Issues The document is generally clear in both its motivation and the proposed solution. I think it's playing a bit too liberal with TLS 1.3, in sort-of but not quite deprecating renegotiation, and in changing the IANA registry in a way that actually changes the protocol. Details below. Other comments: * Abstract: please reword to make it clear that it's the proof (not the cert) that is portable. * Introduction: TLS 1.3 post-handshake auth "has the disadvantage of requiring additional state to be stored as part of the TLS state machine." Why is that an issue is practice, assuming this feature is already supported by TLS libraries? Also, are we in effect deprecating this TLS 1.3 feature because of the security issue of the mismatched record boundaries? * "For simplicity, the mechanisms... require", maybe a normative REQUIRE? * Authenticator Request: please clarify that we use the TLS 1.3 format even when running on TLS 1.2. * Also, I suggest to change "is not encrypted with a handshake key" which is too specific to "is sent unencrypted within the normal TLS-protected data". * Before diving into the detailed messages in Sec. 3, it would be nice to include a quick overview of the message sequence. * Sec. 3: "SHOULD use TLS", change to MUST. There's no way it can work otherwise anyway. * "This message reuses the structure to the CertificateRequest message" - repeats the preceding paragraph. * Sec. 4: again, SHOULD use TLS -> MUST. * Is there a requirement for all protocol messages to be sent over a single TLS connection? If so, please mention it. Certainly this is true for the Authenticator message that must be sent over a single connection and cannot be multiplexed by the high-level protocol. I think this protocol actually assumes "nice" transport properties (no message reorder, reliability) that also require a single, clean TLS connection. * Why no authenticator request for servers? Don't we care about replay? OTOH if the client wants to detect replays, it would need to keep state on received authenticators, which would be very messy. * 4.1: when referencing Exporters, mention this is Sec. 7.5 of [TLS1.3]. * The discussion of Extended Master Secret only applies to TLS 1.2 - please clarify that, plus I suggest to reword this paragraph which I find hard to parse. * 4.2: "the extensions are chosen from the TLS handshake." - What does it mean exactly, and how does an application even know which extensions were used at the TLS layer? Reading further, we mention "ClientHello extensions." Maybe the authenticator should also include a ClientHello message to indicate supported extensions. Assuming we can peek into ClientHello contradicts the hopeful "even if it is possible to implement it at the application layer" in Sec. 6. * 4.2.1: the first sentence of the section is incomplete. * Can I use TLS 1.3-specific extensions (oid_filters) if I'm running on a TLS 1.2 connection? Is there a situation where a certificate is acceptable for TLS 1.3 connections but not for TLS 1.2 connections? * "using a value derived from the connection secrets" - I think we should recommend a specific construction here to ensure people do it securely. * 4.2.3: Are we computing HMAC(MAC-key, Hash(a || b || c || d))? If so, please say so. * 4.2.4: "a constant-time comparison" - why is it actually required, what is the threat? An attacker can do very little because each authenticator being sent is different. * 5: please say explicitly which messages are used in this case to construct the authenticator. * 6.1: the "MUST" is strange in a section that's only supposed to be informative. Also, the library may provide this extension (and possibly others) without requiring it as input. * 6.4: "The API MUST return a failure if the certificate_request_context of the authenticator was used in a previously validated authenticator." Are we requiring the library to keep previous contexts for replay protection? If so, please make it explicit. * 7.1: this is changing TLS 1.3 by allowing this extension in Cert Request! I think it's a really bad idea. Better to hack special support to existing libraries, allowing this specific extension for this special case, than to change the base protocol. Otherwise, this document should UPDATE 8446. * 8: I think the Security Considerations is the right place to talk about interaction between this protocol and TLS 1.3 (or 1.2) renegotiation. Even if we simply RECOMMEND not to do it. Or else explain the use cases where renegotiation is still useful if there are any. From nobody Tue Jul 16 16:25:15 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 66B3812002F for ; Tue, 16 Jul 2019 16:25:05 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 CccqSj3PuznS for ; Tue, 16 Jul 2019 16:25:02 -0700 (PDT) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 191FC12003E for ; Tue, 16 Jul 2019 16:25:02 -0700 (PDT) Received: by mail-ua1-x936.google.com with SMTP id c4so8909516uad.1 for ; Tue, 16 Jul 2019 16:25:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IJ5quSlIh0Uk0v35w2gsZ7a+TH3iS05tbcSi7VJNxvA=; b=ZyjY2tV9gINWH7fJbo0agWBN7ep5MSu2nw1piO5TE7SO/f0u6IVRAQ2nhANnqYiVQZ b9otd9hZz2jmf6n8kP+zq8nsZb7Y0E1XAt853NwU3VGHXCRHE1zPRw2jy2+s+JXQjv4r yhh0ttY4uHzvbLcfU8TzcTaWQcW2TvxRCKr2I= 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=IJ5quSlIh0Uk0v35w2gsZ7a+TH3iS05tbcSi7VJNxvA=; b=V6AWhotecDAx9CInu59fDsVFutHD04UZEA2UaSTBdDjz4/+1iwFc1isGAhG3hL87d7 nIagUTwWtoeQ2vf2BZBBpsjA44S+CWr8F6HtNfDNX2mep7lQSmGc9w55oSgC+7QCzt7v qDJ11Q5MBU1dA0/TS/EA9f6TpcN6nh6ikGn+szK1rC9U3onkZgIbks/M4HhjASjfj0xl l+klqk3s2mHE/mlflOBaC78CSWnKOK6F5IYw0bppJk3NhYofmfgM+/AkohdlkZzD/kIM sTrgjpVY5Gvv7i8mFFt0aZGDU10Rk2uMdYiChMv387uwHW4D9HJF2fqVah+ziagJT7G9 KDXA== X-Gm-Message-State: APjAAAUh5pNeQ5kxgl3FMUWm1LipE2UE7b0JgAC60Ooj4ZOx4Msh1IkQ Mhey6Eq/DqVfNNEtfr9c5WXgtyNy2K+5Hq+UUvsarg== X-Google-Smtp-Source: APXvYqydOPyUSnSAK5dq/vyORDgrMNbeiRyOli6DC+trreoDds0FAv3NhoKxDcip9n0qDJNBPcWuMt52H6DtCejutNo= X-Received: by 2002:ab0:64c4:: with SMTP id j4mr21992256uaq.97.1563319500284; Tue, 16 Jul 2019 16:25:00 -0700 (PDT) MIME-Version: 1.0 References: <156330717256.15259.2193942101748847069@ietfa.amsl.com> In-Reply-To: <156330717256.15259.2193942101748847069@ietfa.amsl.com> From: Nick Sullivan Date: Tue, 16 Jul 2019 16:24:44 -0700 Message-ID: To: Yaron Sheffer Cc: secdir@ietf.org, draft-ietf-tls-exported-authenticator.all@ietf.org, ietf@ietf.org, "" Content-Type: multipart/alternative; boundary="0000000000007c5e01058dd4af42" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-tls-exported-authenticator-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: Tue, 16 Jul 2019 23:25:06 -0000 --0000000000007c5e01058dd4af42 Content-Type: text/plain; charset="UTF-8" Yaron, Thank you for this review. I'm going to internalize it, come up with potential ways forward and get back to you soon. Best, Nick On Tue, Jul 16, 2019 at 12:59 PM Yaron Sheffer via Datatracker < noreply@ietf.org> wrote: > Reviewer: Yaron Sheffer > Review result: Has Issues > > The document is generally clear in both its motivation and the proposed > solution. > > I think it's playing a bit too liberal with TLS 1.3, in sort-of but not > quite > deprecating renegotiation, and in changing the IANA registry in a way that > actually changes the protocol. Details below. > > Other comments: > > * Abstract: please reword to make it clear that it's the proof (not the > cert) > that is portable. * Introduction: TLS 1.3 post-handshake auth "has the > disadvantage of requiring additional state to be stored as part of the TLS > state machine." Why is that an issue is practice, assuming this feature is > already supported by TLS libraries? Also, are we in effect deprecating > this TLS > 1.3 feature because of the security issue of the mismatched record > boundaries? > * "For simplicity, the mechanisms... require", maybe a normative REQUIRE? * > Authenticator Request: please clarify that we use the TLS 1.3 format even > when > running on TLS 1.2. * Also, I suggest to change "is not encrypted with a > handshake key" which is too specific to "is sent unencrypted within the > normal > TLS-protected data". * Before diving into the detailed messages in Sec. 3, > it > would be nice to include a quick overview of the message sequence. * Sec. > 3: > "SHOULD use TLS", change to MUST. There's no way it can work otherwise > anyway. > * "This message reuses the structure to the CertificateRequest message" - > repeats the preceding paragraph. * Sec. 4: again, SHOULD use TLS -> MUST. > * Is > there a requirement for all protocol messages to be sent over a single TLS > connection? If so, please mention it. Certainly this is true for the > Authenticator message that must be sent over a single connection and > cannot be > multiplexed by the high-level protocol. I think this protocol actually > assumes > "nice" transport properties (no message reorder, reliability) that also > require > a single, clean TLS connection. * Why no authenticator request for servers? > Don't we care about replay? OTOH if the client wants to detect replays, it > would need to keep state on received authenticators, which would be very > messy. > * 4.1: when referencing Exporters, mention this is Sec. 7.5 of [TLS1.3]. * > The > discussion of Extended Master Secret only applies to TLS 1.2 - please > clarify > that, plus I suggest to reword this paragraph which I find hard to parse. * > 4.2: "the extensions are chosen from the TLS handshake." - What does it > mean > exactly, and how does an application even know which extensions were used > at > the TLS layer? Reading further, we mention "ClientHello extensions." Maybe > the > authenticator should also include a ClientHello message to indicate > supported > extensions. Assuming we can peek into ClientHello contradicts the hopeful > "even > if it is possible to implement it at the application layer" in Sec. 6. * > 4.2.1: > the first sentence of the section is incomplete. * Can I use TLS > 1.3-specific > extensions (oid_filters) if I'm running on a TLS 1.2 connection? Is there a > situation where a certificate is acceptable for TLS 1.3 connections but > not for > TLS 1.2 connections? * "using a value derived from the connection secrets" > - I > think we should recommend a specific construction here to ensure people do > it > securely. * 4.2.3: Are we computing HMAC(MAC-key, Hash(a || b || c || d))? > If > so, please say so. * 4.2.4: "a constant-time comparison" - why is it > actually > required, what is the threat? An attacker can do very little because each > authenticator being sent is different. * 5: please say explicitly which > messages are used in this case to construct the authenticator. * 6.1: the > "MUST" is strange in a section that's only supposed to be informative. > Also, > the library may provide this extension (and possibly others) without > requiring > it as input. * 6.4: "The API MUST return a failure if the > certificate_request_context of the authenticator was used in a previously > validated authenticator." Are we requiring the library to keep previous > contexts for replay protection? If so, please make it explicit. * 7.1: > this is > changing TLS 1.3 by allowing this extension in Cert Request! I think it's a > really bad idea. Better to hack special support to existing libraries, > allowing > this specific extension for this special case, than to change the base > protocol. Otherwise, this document should UPDATE 8446. * 8: I think the > Security Considerations is the right place to talk about interaction > between > this protocol and TLS 1.3 (or 1.2) renegotiation. Even if we simply > RECOMMEND > not to do it. Or else explain the use cases where renegotiation is still > useful > if there are any. > > --0000000000007c5e01058dd4af42 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yaron,

Thank you for this review. I'= ;m going to internalize it, come up with potential ways forward and get bac= k to you soon.

Best,
Nick
On Tue, J= ul 16, 2019 at 12:59 PM Yaron Sheffer via Datatracker <noreply@ietf.org> wrote:
Reviewer: Yaron Sheffe= r
Review result: Has Issues

The document is generally clear in both its motivation and the proposed
solution.

I think it's playing a bit too liberal with TLS 1.3, in sort-of but not= quite
deprecating renegotiation, and in changing the IANA registry in a way that<= br> actually changes the protocol. Details below.

Other comments:

* Abstract: please reword to make it clear that it's the proof (not the= cert)
that is portable. * Introduction: TLS 1.3 post-handshake auth "has the=
disadvantage of requiring additional state to be stored as part of the TLS<= br> state machine." Why is that an issue is practice, assuming this featur= e is
already supported by TLS libraries? Also, are we in effect deprecating this= TLS
1.3 feature because of the security issue of the mismatched record boundari= es?
* "For simplicity, the mechanisms... require", maybe a normative = REQUIRE? *
Authenticator Request: please clarify that we use the TLS 1.3 format even w= hen
running on TLS 1.2. * Also, I suggest to change "is not encrypted with= a
handshake key" which is too specific to "is sent unencrypted with= in the normal
TLS-protected data". * Before diving into the detailed messages in Sec= . 3, it
would be nice to include a quick overview of the message sequence. * Sec. 3= :
"SHOULD use TLS", change to MUST. There's no way it can work = otherwise anyway.
* "This message reuses the structure to the CertificateRequest message= " -
repeats the preceding paragraph. * Sec. 4: again, SHOULD use TLS -> MUST= . * Is
there a requirement for all protocol messages to be sent over a single TLS<= br> connection? If so, please mention it. Certainly this is true for the
Authenticator message that must be sent over a single connection and cannot= be
multiplexed by the high-level protocol. I think this protocol actually assu= mes
"nice" transport properties (no message reorder, reliability) tha= t also require
a single, clean TLS connection. * Why no authenticator request for servers?=
Don't we care about replay? OTOH if the client wants to detect replays,= it
would need to keep state on received authenticators, which would be very me= ssy.
* 4.1: when referencing Exporters, mention this is Sec. 7.5 of [TLS1.3]. * = The
discussion of Extended Master Secret only applies to TLS 1.2 - please clari= fy
that, plus I suggest to reword this paragraph which I find hard to parse. *=
4.2: "the extensions are chosen from the TLS handshake." - What d= oes it mean
exactly, and how does an application even know which extensions were used a= t
the TLS layer? Reading further, we mention "ClientHello extensions.&qu= ot; Maybe the
authenticator should also include a ClientHello message to indicate support= ed
extensions. Assuming we can peek into ClientHello contradicts the hopeful &= quot;even
if it is possible to implement it at the application layer" in Sec. 6.= * 4.2.1:
the first sentence of the section is incomplete. * Can I use TLS 1.3-specif= ic
extensions (oid_filters) if I'm running on a TLS 1.2 connection? Is the= re a
situation where a certificate is acceptable for TLS 1.3 connections but not= for
TLS 1.2 connections? * "using a value derived from the connection secr= ets" - I
think we should recommend a specific construction here to ensure people do = it
securely. * 4.2.3: Are we computing HMAC(MAC-key, Hash(a || b || c || d))? = If
so, please say so. * 4.2.4: "a constant-time comparison" - why is= it actually
required, what is the threat? An attacker can do very little because each authenticator being sent is different. * 5: please say explicitly which
messages are used in this case to construct the authenticator. * 6.1: the "MUST" is strange in a section that's only supposed to be inf= ormative. Also,
the library may provide this extension (and possibly others) without requir= ing
it as input. * 6.4: "The API MUST return a failure if the
certificate_request_context of the authenticator was used in a previously validated authenticator." Are we requiring the library to keep previou= s
contexts for replay protection? If so, please make it explicit. *=C2=A0 7.1= : this is
changing TLS 1.3 by allowing this extension in Cert Request! I think it'= ;s a
really bad idea. Better to hack special support to existing libraries, allo= wing
this specific extension for this special case, than to change the base
protocol. Otherwise, this document should UPDATE 8446. * 8: I think the
Security Considerations is the right place to talk about interaction betwee= n
this protocol and TLS 1.3 (or 1.2) renegotiation. Even if we simply RECOMME= ND
not to do it. Or else explain the use cases where renegotiation is still us= eful
if there are any.

--0000000000007c5e01058dd4af42-- From nobody Wed Jul 17 10:39:29 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 008C4120848 for ; Wed, 17 Jul 2019 10:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 2afVrUBynL95 for ; Wed, 17 Jul 2019 10:39:26 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C3CF120869 for ; Wed, 17 Jul 2019 10:39:16 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6HHdDcS017286 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 17 Jul 2019 13:39:15 -0400 Date: Wed, 17 Jul 2019 12:39:12 -0500 From: Benjamin Kaduk To: secdir@ietf.org Message-ID: <20190717173912.GJ58520@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [secdir] IETF 105 secdir lunch in room "C2" (21st floor) 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, 17 Jul 2019 17:39:28 -0000 Hi all, We've been assigned the room named "C2" on the 21st floor for our secdir lunch (brown bag, of course), on tuesday July 23. See you in Montreal! -Ben From nobody Wed Jul 17 14:25:48 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 DDE6A120116 for ; Wed, 17 Jul 2019 14:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpTDtES9ZcQT for ; Wed, 17 Jul 2019 14:25:45 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A34BF120113 for ; Wed, 17 Jul 2019 14:25:44 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x6HLPT6G015815 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 18 Jul 2019 00:25:29 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x6HLPTeC026297; Thu, 18 Jul 2019 00:25:29 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23855.37449.29036.508817@fireball.acr.fi> Date: Thu, 18 Jul 2019 00:25:29 +0300 From: Tero Kivinen To: "Salz\, Rich" Cc: "secdir\@ietf.org" In-Reply-To: <9366DCDC-B6EF-4C0C-8C75-BA5F93CA50C6@akamai.com> References: <156318100261.27185.2868373675214966063.idtracker@ietfa.amsl.com> <9366DCDC-B6EF-4C0C-8C75-BA5F93CA50C6@akamai.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 0 min Archived-At: Subject: Re: [secdir] Assignments 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, 17 Jul 2019 21:25:47 -0000 Salz, Rich writes: > > [With my vacation in Chile to see the eclipse, I have not been able to do > > I believe it would be an acceptable use of this mailing list if you > were to post a couple of pictures. Please. I posted few pictures to facebook, and the album is public so anybody can see them: https://www.facebook.com/media/set/?set=a.2564092093622654&type=3 -- kivinen@iki.fi From nobody Fri Jul 19 07:13:15 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 9EC76120279; Fri, 19 Jul 2019 07:13:05 -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 P32oUcKUJ1SQ; Fri, 19 Jul 2019 07:13:02 -0700 (PDT) Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com [IPv6:2607:f8b0:4864:20::831]) (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 0E725120270; Fri, 19 Jul 2019 07:12:58 -0700 (PDT) Received: by mail-qt1-x831.google.com with SMTP id k10so31149575qtq.1; Fri, 19 Jul 2019 07:12:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :content-transfer-encoding:mime-version; bh=4Bn/UwZe1214ndB+8koUWBT7Sde3SeAb1J42cgw2z/Q=; b=uWG8vKBEVtom8SR2va+3rM+1qpIGpdPP0CMxkKmFskyQSSJxmuNYVaCyLgV/cFkcpC +BgHqysF9+5ZmKy2WSOXGEKyBvlJF68bcZsx2BzhES4xJEdE5jPiz+xroUYaCsBs9Lnt 2hiaDWKHQj0MnL2TeKrDSxOiiSWZ2Ht1PtwtAj1eqoJoGBkvDSYrEPCSHvNLsBduB+TY 845uNAiT4CQdd7Nzt2wrtFBrfOFIH9lCqzGkfOUHUD2tcqigHBXnpcqiAnoh+eWcGOM/ 7eHysJDxZIMiC3YlZHpBDGJT31RVir/Jh3uNudh73eMIjFbXhZPVHcDa2TcDWH04M7E5 tfZw== 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:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:content-transfer-encoding:mime-version; bh=4Bn/UwZe1214ndB+8koUWBT7Sde3SeAb1J42cgw2z/Q=; b=RTlS37XMR7aLEyA6yeuhr4pEm5z75F6w3ei3iZO+zlPhli0gzVO2PdYRC2UF4lD0In yqCqefEZqKzTJNcoyAm9UaHsb3f1G6XVg+V9hjXz2rGo44kNtyjRoHSt0MztrlGFGKlk QVuQxrYHuASYqh6kmn1+PgWC1F7e6EejohCZFby0GUZadGPYyRD764ITZQrUvULY6iSD qM5MoJ0G321Q3YQ7l0Wn3BtkELjZAYlOYGEzbHl/kMW7SJVZLer5+Q6Ja7XxwGFshlTU jTiC+SN+bwSfa8TRN4X0duwwempMGZkXzO4uedZhfretLEXNxjzXql5eiuHLQ/XrgDVU gsKg== X-Gm-Message-State: APjAAAWRZe0N2Ut3bSbUooewucQqFbvXA8ezET4bzp8p281ERKARhECL loSodfr2jZbzw7HuMsTu9RWCE+msf3E= X-Google-Smtp-Source: APXvYqzbLjFM/x6JVIzRCGhIZxnYBqZ/GTpTcdZpL2l9Zuj72tpeO13ZBGlpquJZCh3WWB95wHg8HA== X-Received: by 2002:ac8:37b8:: with SMTP id d53mr36781083qtc.227.1563545577202; Fri, 19 Jul 2019 07:12:57 -0700 (PDT) Received: from BYAPR19MB3415.namprd19.prod.outlook.com ([2603:1036:307:293b::5]) by smtp.gmail.com with ESMTPSA id p13sm11810489qkj.4.2019.07.19.07.12.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 19 Jul 2019 07:12:56 -0700 (PDT) From: Tarek Saad To: Valery Smyslov , "secdir@ietf.org" CC: "draft-ietf-teas-yang-te-types@ietf.org" , "ietf@ietf.org" , "teas@ietf.org" , "BRUNGARD, DEBORAH A" Thread-Topic: [Teas] Secdir Last Call review of draft-ietf-teas-yang-te-types Thread-Index: ASQ0YSRkhZYlxpY4H2/pUKK5ga9BLOITtdRO X-MS-Exchange-MessageSentRepresentingType: 1 Date: Fri, 19 Jul 2019 14:12:54 +0000 Message-ID: References: <04bd01d50577$d66c5a50$83450ef0$@smyslov.net> In-Reply-To: <04bd01d50577$d66c5a50$83450ef0$@smyslov.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] [Teas] Secdir Last Call review of draft-ietf-teas-yang-te-types 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, 19 Jul 2019 14:13:06 -0000 SGkgVmFsZXJ5LA0KDQpUaGFua3MgZm9yIHRoZSByZXZpZXcuIFJlZ2FyZGluZyB0aGUgbml0IGJl bG93LCB3ZSBoYXZlIGZvbGxvd2VkIHRoZSBndWlkZWxpbmVzIHRvIGFzIHBlciBodHRwczovL3Rv b2xzLmlldGYub3JnL2h0bWwvcmZjODQwNyNzZWN0aW9uLTMuNy4xIHdoaWNoIGhhcyBSRkM4NDQ2 IGFzIG5vcm1hdGl2ZS4NCk15IHVuZGVyc3RhbmRpbmcgaXMgdGhpcyBpcyBiZWluZyB1c2VkIGFz IGEgdGVtcGxhdGUgaW4gc2V2ZXJhbCBvdGhlciBZQU5HIFJGQ3MvZHJhZnRzLiBMZXQgdXMga25v dyBpZiB5b3Ugc3RpbGwgZmluZCBpdCBhbiBpc3N1ZSBhbmQgd2UnbGwgdHJ5IHRvIGFkZHJlc3Mg aXQuDQoNCiAgICBOaXQ6IEkgZG9uJ3QgdGhpbmsgdGhhdCByZWZlcmVuY2UgdG8gVExTMS4zIChS RkM4NDQ2KQ0KICAgIHNob3VsZCBiZSBub3JtYXRpdmUuIEluIG15IHVuZGVyc3RhbmRpbmcgcmVh ZGVycyBvZiB0aGlzIGRvY3VtZW50DQogICAgYXJlIG5vdCBvYmxpZ2VkIHRvIHJlYWQgYW5kIGZ1 bGx5IHVuZGVyc3RhbmQgdGhlIGRldGFpbHMgb2YgVExTIHRvIGJlIGFibGUNCiAgICB0byBpbXBv cnQgdGhlIGRlZmluaXRpb25zIGFuZCBjcmVhdGUgYSBURS1yZWxhdGVkIFlBTkcgbW9kdWxlLg0K DQpSZWdhcmRzLA0KVGFyZWsNCg0K77u/T24gNS84LzE5LCA0OjI4IEFNLCAiVGVhcyBvbiBiZWhh bGYgb2YgVmFsZXJ5IFNteXNsb3YiIDx0ZWFzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9m IHZhbGVyeUBzbXlzbG92Lm5ldD4gd3JvdGU6DQoNCiAgICBSZXZpZXdlcjogVmFsZXJ5IFNteXNs b3YJDQogICAgUmV2aWV3IHJlc3VsdDogUmVhZHkgd2l0aCBOaXRzDQogICAgDQogICAgSSBoYXZl IHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3Jh dGUncyANCiAgICBvbmdvaW5nIGVmZm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJl aW5nIHByb2Nlc3NlZCBieSB0aGUgDQogICAgSUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3Jp dHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSANCiAgICBzZWN1cml0eSBhcmVh IGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQg DQogICAgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVu dHMuDQogICAgDQogICAgDQogICAgVGhlIGRyYWZ0IGRlZmluZXMgYSBzZXQgb2YgY29tbW9uIFlB TkcgZWxlbWVudHMgKHR5cGVkZWZzLCBpZGVudGl0aWVzIGFuZCBncm91cGluZ3MpDQogICAgdGhh dCBhcmUgaW50ZW5kZWQgdG8gYmUgdXNlZCBpbiBUcmFmZmljIEVuZ2luZWVyaW5nIHJlbGF0ZWQg WUFORyBtb2R1bGVzLg0KICAgIFRoZSBkcmFmdCBhcyBzdWNoIGRvZXNuJ3QgaGF2ZSBzZWN1cml0 eSBpbXBsaWNhdGlvbnMuIFRoZSBTZWN1cml0eSBDb25zaWRlcmF0aW9ucw0KICAgIHNlY3Rpb24g Y29udGFpbnMgZ2VuZXJhbCBhZHZpY2VzIG9uIHVzaW5nIFlBTkcgd2l0aCBkYXRhIG1hbmFnZW1l bnQNCiAgICBwcm90b2NvbHMgKGxpa2UgTkVUQ09ORiBvciBSRVNUQ09ORiksIHdoaWNoIGFyZSBh cHBsaWNhYmxlIHdoZW4gDQogICAgdGhlc2UgZGVmaW5pdGlvbnMgYXJlIGltcG9ydGVkIGFuZCB1 c2VkIGluIG90aGVyIFlBTkcgbW9kdWxlcy4NCiAgICBUaGUgYWR2aWNlcyBpbmNsdWRlIHVzaW5n IHNlY3VyZSBwcm90b2NvbHMgKFNTSCBmb3IgTkVUQ09ORiBhbmQgVExTMS4zIGZvciBSRVNUQ09O RikNCiAgICBhbmQgaW1wbGVtZW50aW5nIGFjY2VzcyBjb250cm9sIGZvciBzZW5zaXRpdmUgWUFO RyBkYXRhIG5vZGVzLiANCiAgICANCiAgICBOaXQ6IEkgZG9uJ3QgdGhpbmsgdGhhdCByZWZlcmVu Y2UgdG8gVExTMS4zIChSRkM4NDQ2KQ0KICAgIHNob3VsZCBiZSBub3JtYXRpdmUuIEluIG15IHVu ZGVyc3RhbmRpbmcgcmVhZGVycyBvZiB0aGlzIGRvY3VtZW50DQogICAgYXJlIG5vdCBvYmxpZ2Vk IHRvIHJlYWQgYW5kIGZ1bGx5IHVuZGVyc3RhbmQgdGhlIGRldGFpbHMgb2YgVExTIHRvIGJlIGFi bGUNCiAgICB0byBpbXBvcnQgdGhlIGRlZmluaXRpb25zIGFuZCBjcmVhdGUgYSBURS1yZWxhdGVk IFlBTkcgbW9kdWxlLg0KICAgIA0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQogICAgVGVhcyBtYWlsaW5nIGxpc3QNCiAgICBUZWFzQGll dGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90ZWFzDQog ICAgDQo= From nobody Sat Jul 20 04:30: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 990521203CF; Sat, 20 Jul 2019 04:30:25 -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, 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=smyslov.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7lelEczyRGa8; Sat, 20 Jul 2019 04:30:23 -0700 (PDT) Received: from direct.host-care.com (direct.host-care.com [198.136.54.115]) (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 B096312008C; Sat, 20 Jul 2019 04:30:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smyslov.net ; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID :Date:Subject:In-Reply-To:References:Cc:To:From:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=KjNBNalhDGIomqVSegxFq69FdWKXMOvie8u9PkIl5MI=; b=1rBgne+XUMTVzD6391c1qHT3Hq G/tu/qbsOZLBwf+3G3UIuYNQvmESb1/R5v3SmRbFR9mSxW0E3dkxvtpoT98NTRX9ahOAIgq8iZ8D+ A41QBJgPWI88rq1tId1MPhk7SxvUL6CKDWd5UtBXLoPBh9OAYifQF5PSNw23FZXr35Uo84wy2MxHx o8N5tQqB+ilxhvGY7YdJsfRmkXpM/Se6RAmQPT4WeniBolnPqVunCuBV5ML3yN9VXDEUjy8z4B3AR 3BMkycOVhe8bDvyLRH2H4hC8ga61izclNk1QBgm5iIhbF1IeysqqEANH2MBITFWO+D6/PFEwvAvxT rvIK3Hbg==; Received: from modemcable142.183-83-70.mc.videotron.ca ([70.83.183.142]:51791 helo=svannotebook) by direct.host-care.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from ) id 1honZD-0005k6-KN; Sat, 20 Jul 2019 07:30:19 -0400 From: "Valery Smyslov" To: "'Tarek Saad'" , Cc: , , , "'BRUNGARD, DEBORAH A'" References: <04bd01d50577$d66c5a50$83450ef0$@smyslov.net> In-Reply-To: Date: Sat, 20 Jul 2019 14:30:16 +0300 Message-ID: <013b01d53eee$81f4f2b0$85ded810$@smyslov.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIbKM+FxiWWhTiWbx/pUKK5ga9BLAHS7SJjpjjx0cA= Content-Language: ru X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - direct.host-care.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - smyslov.net X-Get-Message-Sender-Via: direct.host-care.com: authenticated_id: valery@smyslov.net X-Authenticated-Sender: direct.host-care.com: valery@smyslov.net X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [secdir] [Teas] Secdir Last Call review of draft-ietf-teas-yang-te-types 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, 20 Jul 2019 11:30:26 -0000 Hi Tarek, thank you for providing the reasoning. I definitely have no problem with listing RFC8446 as normative, if there is a template and this is a common practice for YANG model documents. Anyway, it was just a nit. Regards, Valery. > Hi Valery, >=20 > Thanks for the review. Regarding the nit below, we have followed the > guidelines to as per https://tools.ietf.org/html/rfc8407#section-3.7.1 = which > has RFC8446 as normative. > My understanding is this is being used as a template in several other = YANG > RFCs/drafts. Let us know if you still find it an issue and we'll try = to address it. >=20 > Nit: I don't think that reference to TLS1.3 (RFC8446) > should be normative. In my understanding readers of this document > are not obliged to read and fully understand the details of TLS to = be able > to import the definitions and create a TE-related YANG module. >=20 > Regards, > Tarek >=20 > =EF=BB=BFOn 5/8/19, 4:28 AM, "Teas on behalf of Valery Smyslov" bounces@ietf.org on behalf of valery@smyslov.net> wrote: >=20 > Reviewer: Valery Smyslov > Review result: Ready with Nits >=20 > 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. >=20 >=20 > The draft defines a set of common YANG elements (typedefs, = identities and > groupings) > that are intended to be used in Traffic Engineering related YANG = modules. > The draft as such doesn't have security implications. The Security > Considerations > section contains general advices on using YANG with data = management > protocols (like NETCONF or RESTCONF), which are applicable when > these definitions are imported and used in other YANG modules. > The advices include using secure protocols (SSH for NETCONF and = TLS1.3 for > RESTCONF) > and implementing access control for sensitive YANG data nodes. >=20 > Nit: I don't think that reference to TLS1.3 (RFC8446) > should be normative. In my understanding readers of this document > are not obliged to read and fully understand the details of TLS to = be able > to import the definitions and create a TE-related YANG module. >=20 >=20 > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas >=20 From nobody Sat Jul 20 18:57:17 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14B80120041; Sat, 20 Jul 2019 18:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 hqfMAv7LNp1j; Sat, 20 Jul 2019 18:57:06 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 663A6120018; Sat, 20 Jul 2019 18:57:06 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6L1v0Ug014784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sat, 20 Jul 2019 21:57:03 -0400 Date: Sat, 20 Jul 2019 20:57:00 -0500 From: Benjamin Kaduk To: Yaron Sheffer Cc: secdir@ietf.org, draft-ietf-tls-exported-authenticator.all@ietf.org, ietf@ietf.org, tls@ietf.org Message-ID: <20190721015659.GL23137@kduck.mit.edu> References: <156330717256.15259.2193942101748847069@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <156330717256.15259.2193942101748847069@ietfa.amsl.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-tls-exported-authenticator-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: Sun, 21 Jul 2019 01:57:09 -0000 Hi Yaron, Thanks for the thoughtful review. It seems like we'll need to think about some points a bit more... On Tue, Jul 16, 2019 at 12:59:32PM -0700, Yaron Sheffer via Datatracker wrote: > Reviewer: Yaron Sheffer > Review result: Has Issues > > The document is generally clear in both its motivation and the proposed > solution. > > I think it's playing a bit too liberal with TLS 1.3, in sort-of but not quite > deprecating renegotiation, and in changing the IANA registry in a way that > actually changes the protocol. Details below. To be clear, 1.3 does not have renegotiation at all, so that deprecation has already been done and not by this document. > Other comments: > > > * Abstract: please reword to make it clear that it's the proof (not the cert) > that is portable. > * Introduction: TLS 1.3 post-handshake auth "has the > disadvantage of requiring additional state to be stored as part of the TLS > state machine." Why is that an issue is practice, assuming this feature is It requires either caching the entire handshake messages (including certificate), which can add up, or being able to "fork" a copy of internal hash state, which is a pretty uncommon API. > already supported by TLS libraries? Also, are we in effect deprecating this TLS > 1.3 feature because of the security issue of the mismatched record boundaries? I think in some peoples' minds that would be a good thing, though it's not entirely clear that we are actually doing so. > * "For simplicity, the mechanisms... require", maybe a normative REQUIRE? > * > Authenticator Request: please clarify that we use the TLS 1.3 format even when > running on TLS 1.2. > * Also, I suggest to change "is not encrypted with a > handshake key" which is too specific to "is sent unencrypted within the normal > TLS-protected data". > * Before diving into the detailed messages in Sec. 3, it > would be nice to include a quick overview of the message sequence. > * Sec. 3: > "SHOULD use TLS", change to MUST. There's no way it can work otherwise anyway. What about QUIC? > * "This message reuses the structure to the CertificateRequest message" - > repeats the preceding paragraph. > * Sec. 4: again, SHOULD use TLS -> MUST. > * Is > there a requirement for all protocol messages to be sent over a single TLS > connection? If so, please mention it. Certainly this is true for the > Authenticator message that must be sent over a single connection and cannot be > multiplexed by the high-level protocol. I think this protocol actually assumes > "nice" transport properties (no message reorder, reliability) that also require > a single, clean TLS connection. It seems like we should be more clear about what we do (and do not) require. Though IIRC we can do separate authenticators in parallel and not require them to be ordered with respect to each other. > * Why no authenticator request for servers? > Don't we care about replay? OTOH if the client wants to detect replays, it > would need to keep state on received authenticators, which would be very messy. IIUC the thinking is that there's no way to revoke an authenticator for a connection, so replay (if not detected by another layer anyway) would not cause the authentication state to change. > * 4.1: when referencing Exporters, mention this is Sec. 7.5 of [TLS1.3]. > * The > discussion of Extended Master Secret only applies to TLS 1.2 - please clarify > that, plus I suggest to reword this paragraph which I find hard to parse. (RFC 8446 tries to say "when something requires EMS, TLS 1.3 counts for that", but it's not great.) > * > 4.2: "the extensions are chosen from the TLS handshake." - What does it mean > exactly, and how does an application even know which extensions were used at > the TLS layer? Reading further, we mention "ClientHello extensions." Maybe the > authenticator should also include a ClientHello message to indicate supported > extensions. Assuming we can peek into ClientHello contradicts the hopeful "even > if it is possible to implement it at the application layer" in Sec. 6. > * 4.2.1: > the first sentence of the section is incomplete. > * Can I use TLS 1.3-specific > extensions (oid_filters) if I'm running on a TLS 1.2 connection? Is there a > situation where a certificate is acceptable for TLS 1.3 connections but not for > TLS 1.2 connections? > * "using a value derived from the connection secrets" - I > think we should recommend a specific construction here to ensure people do it > securely. > * 4.2.3: Are we computing HMAC(MAC-key, Hash(a || b || c || d))? If > so, please say so. > * 4.2.4: "a constant-time comparison" - why is it actually > required, what is the threat? An attacker can do very little because each > authenticator being sent is different. I think this text was added because of a question I asked during AD review, and we didn't put a huge amount of thought into it. > * 5: please say explicitly which > messages are used in this case to construct the authenticator. > * 6.1: the > "MUST" is strange in a section that's only supposed to be informative. Also, > the library may provide this extension (and possibly others) without requiring > it as input. > * 6.4: "The API MUST return a failure if the > certificate_request_context of the authenticator was used in a previously > validated authenticator." Are we requiring the library to keep previous > contexts for replay protection? If so, please make it explicit. > * 7.1: this is > changing TLS 1.3 by allowing this extension in Cert Request! I think it's a > really bad idea. Better to hack special support to existing libraries, allowing > this specific extension for this special case, than to change the base > protocol. Otherwise, this document should UPDATE 8446. Or, since extension codepoints are cheap, just use a newcodepoint. -Ben > * 8: I think the > Security Considerations is the right place to talk about interaction between > this protocol and TLS 1.3 (or 1.2) renegotiation. Even if we simply RECOMMEND > not to do it. Or else explain the use cases where renegotiation is still useful > if there are any. > From nobody Sun Jul 21 10:51:46 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 DAD0B1200DE for ; Sun, 21 Jul 2019 10:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mandelberg.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tdrelV8q1bAV for ; Sun, 21 Jul 2019 10:51:36 -0700 (PDT) Received: from smtp.rcn.com (smtp.rcn.com [69.168.97.78]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEB19120151 for ; Sun, 21 Jul 2019 10:51:34 -0700 (PDT) X_CMAE_Category: , , X-CNFS-Analysis: v=2.2 cv=buYOPwSi c=1 sm=1 tr=0 a=OXtaa+9CFT7WVSERtyqzJw==:117 a=OXtaa+9CFT7WVSERtyqzJw==:17 a=KGjhK52YXX0A:10 a=IkcTkHD0fZMA:10 a=NTnny0joGdQA:10 a=0o9FgrsRnhwA:10 a=bmmO2AaSJ7QA:10 a=48vgC7mUAAAA:8 a=iiazv-oawmH03g7Men8A:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22 X-CM-Score: 0 X-Scanned-by: Cloudmark Authority Engine X-Authed-Username: ZHNlb21uQHJjbi5jb20= Authentication-Results: smtp01.rcn.cmh.synacor.com header.DKIM-Signature=@mandelberg.org; dkim=pass Authentication-Results: smtp01.rcn.cmh.synacor.com header.from=david@mandelberg.org; sender-id=softfail Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.mail=david@mandelberg.org; spf=softfail; sender-id=softfail Authentication-Results: smtp01.rcn.cmh.synacor.com smtp.user=dseomn@rcn.com; auth=pass (LOGIN) Received: from [209.6.43.168] ([209.6.43.168:59044] helo=uriel.mandelberg.org) by smtp.rcn.com (envelope-from ) (ecelerity 3.6.25.56547 r(Core:3.6.25.0)) with ESMTPSA (cipher=DHE-RSA-AES256-GCM-SHA384) id 4C/00-36753-426A43D5; Sun, 21 Jul 2019 13:51:32 -0400 Received: from [192.168.1.152] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 9F8BA1C6073; Sun, 21 Jul 2019 13:51:31 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mandelberg.org; s=201903; t=1563731491; bh=Xa6bUdD35M3oJPB2WVA9UiEFkj/czZ/IlPqlvQrVg4k=; h=To:From:Subject:Date:From; b=JYS06Kwfh1UZQ0YA8eulyM7etHjSRaA3ihZXEwrVVdwQIxGABfsDDPEjWA8vkwJk2 EwtqRWigWTwLRHLCXM8lhh1coDqMj8QC4j+22pRh6PIU7QnYtiOHokJ+jnoo45QCk7 WA40i2Yngx2JOPSnKmCcJHvDeCCGk3yaD03PPAwUj2wQuGsa4BftGqU7rwSLeNjgyg J3oC8Muy8lFF391XV1FBKfSAYxNLPqPBCGzSirkMWCItYftQl3RqPTGML7AQuaPRYF T6zhWgYUotUFxHFNlslKcikzKjyQtmXm2aNlJPVMnWFf00ZTkhMNd6zCox93/ETu52 CRsA3L6pUPMwA== To: secdir@ietf.org, iesg@ietf.org, draft-ietf-6tisch-architecture.all@ietf.org From: David Mandelberg Message-ID: <69a257b0-c139-7df1-6e78-705db1a817e2@mandelberg.org> Date: Sun, 21 Jul 2019 13:51:30 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: [secdir] secdir review of draft-ietf-6tisch-architecture-24 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, 21 Jul 2019 17:51:38 -0000 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready. I reviewed -21 in https://mailarchive.ietf.org/arch/msg/secdir/tw1aZMDZaUw-32qqI3f8XjcKLaQ. My only question was discussed thoroughly, and the document was updated. From nobody Sun Jul 21 22:05:10 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11EC120163; Sun, 21 Jul 2019 22:05:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 IPrMfjYrbWqC; Sun, 21 Jul 2019 22:05:00 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE93112013D; Sun, 21 Jul 2019 22:04:59 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6M54q8e009951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 22 Jul 2019 01:04:54 -0400 Date: Mon, 22 Jul 2019 00:04:51 -0500 From: Benjamin Kaduk To: secdir@ietf.org, tls@ietf.org Cc: Martin Thomson Message-ID: <20190722050451.GU99187@kduck.mit.edu> References: <156330717256.15259.2193942101748847069@ietfa.amsl.com> <20190721015659.GL23137@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-tls-exported-authenticator-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, 22 Jul 2019 05:05:02 -0000 It seemed worth copying this to the WG list; sorry for those getting an extra copy. -Ben On Sun, Jul 21, 2019 at 10:26:56AM -0400, Martin Thomson wrote: > On Sat, Jul 20, 2019, at 21:57, Benjamin Kaduk wrote: > > > already supported by TLS libraries? Also, are we in effect deprecating this TLS > > > 1.3 feature because of the security issue of the mismatched record boundaries? > > > > I think in some peoples' minds that would be a good thing, though it's not > > entirely clear that we are actually doing so. > > This wouldn't deprecate post-HS auth. It is intended to cover the cases where post-HS auth does not work. See draft-ietf-httpbis-http2-secondary-certs. > > > > "SHOULD use TLS", change to MUST. There's no way it can work otherwise anyway. > > > > What about QUIC? > > I think that we can safely regard QUIC (at least those versions that use TLS) as TLS. An informative mention might help avoid any confusion regarding this point. We might also regard DTLS-SRTP as one such protocol. > > > > * Is > > > there a requirement for all protocol messages to be sent over a single TLS > > > connection? If so, please mention it. Certainly this is true for the > > > Authenticator message that must be sent over a single connection and cannot be > > > multiplexed by the high-level protocol. I think this protocol actually assumes > > > "nice" transport properties (no message reorder, reliability) that also require > > > a single, clean TLS connection. > > > > It seems like we should be more clear about what we do (and do not) > > require. Though IIRC we can do separate authenticators in parallel and not > > require them to be ordered with respect to each other. > > See above regarding DTLS-SRTP. Being too crisp might constrain usage inappropriately. > > > > * Why no authenticator request for servers? > > > Don't we care about replay? OTOH if the client wants to detect replays, it > > > would need to keep state on received authenticators, which would be very messy. > > > > IIUC the thinking is that there's no way to revoke an authenticator for a > > connection, so replay (if not detected by another layer anyway) would not > > cause the authentication state to change. > > Ben is correct. > > > > * 7.1: this is > > > changing TLS 1.3 by allowing this extension in Cert Request! I think it's a > > > really bad idea. Better to hack special support to existing libraries, allowing > > > this specific extension for this special case, than to change the base > > > protocol. Otherwise, this document should UPDATE 8446. > > > > Or, since extension codepoints are cheap, just use a newcodepoint. > > We might want to discuss this one this week if we can. > From nobody Mon Jul 22 08:13:02 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 96C6B1202F4; Mon, 22 Jul 2019 08:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHJ0Pmey2Nm6; Mon, 22 Jul 2019 08:12:48 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDB971202D2; Mon, 22 Jul 2019 08:12:40 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x6MFCSQ4011289 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 Jul 2019 18:12:28 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x6MFCRKP007422; Mon, 22 Jul 2019 18:12:27 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: quoted-printable Message-ID: <23861.53851.401058.513448@fireball.acr.fi> Date: Mon, 22 Jul 2019 18:12:27 +0300 From: Tero Kivinen To: Cc: "Pascal Thubert \(pthubert\)" , "draft-ietf-6tisch-architecture.all\@ietf.org" , "secdir\@ietf.org" , Michael Richardson , "iesg\@ietf.org" , Thomas Watteyne , David Mandelberg In-Reply-To: <42437526-EFD8-47F7-994C-A914049EB6A3@inria.fr> References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> <23825.24715.882644.180316@fireball.acr.fi> <23846.21029.236657.158497@fireball.acr.fi> <23847.47989.166847.374951@fireball.acr.fi> <42437526-EFD8-47F7-994C-A914049EB6A3@inria.fr> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 5 min Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 15:12:54 -0000 Mali=B9a Vu=E8ini=E6 writes: > For (2), my understanding is that we have consensus that the > protection is the existing mechanism specified in RFC8180 making the > pledge wait for MAX=5FEB=5FDELAY before selecting a JP in order to ha= ve > at least NUM=5FNEIGHBOURS=5FTO=5FWAIT distinct JP candidates, with > legitimate ones advertising a value of ASN that is higher than that > replayed by the attacker. What seems missing is a note in the > minimal-security draft that the pledge MUST remain listening on the > initial channel after receiving the first EB, in order not to enable > the attacker to desync it from the network.=20 Note, that JN cannot yet verify the EBs, and if you take the one with largest ASN, that allows very easy way for attacker to cause DoS, i.e., just send ASN of 0xffffff0000 which is very big, and all new nodes will want to join that. Also there is no way of knowing whether there is one or multiple TSCH networks in the same place. One of them could be using ASN of 0x0000123456 and the other might be using 0x0087654321. We do want to the node to be able to try both.... I do not think the node can really pick the network based on the EBs properly, and whatever the node is doing it mught make things worse and might open new attacks. --=20 kivinen@iki.fi From nobody Mon Jul 22 08:20: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 5D635120280; Mon, 22 Jul 2019 08:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.419 X-Spam-Level: X-Spam-Status: No, score=-3.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21_UKU4IepuD; Mon, 22 Jul 2019 08:20:21 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A5DA1201D3; Mon, 22 Jul 2019 08:20:21 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x6MFJxAI019395 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 Jul 2019 18:19:59 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x6MFJxVf006511; Mon, 22 Jul 2019 18:19:59 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23861.54303.322627.235190@fireball.acr.fi> Date: Mon, 22 Jul 2019 18:19:59 +0300 From: Tero Kivinen To: Michael Richardson Cc: "Pascal Thubert \(pthubert\)" , malisav@ac.me, , , , Thomas Watteyne , David Mandelberg In-Reply-To: <8391.1563139305@dooku.sandelman.ca> References: <2cced16c-d1df-88c2-eb21-7452b42f081a@mandelberg.org> <23825.24715.882644.180316@fireball.acr.fi> <23846.21029.236657.158497@fireball.acr.fi> <23847.47989.166847.374951@fireball.acr.fi> <8391.1563139305@dooku.sandelman.ca> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 7 min Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-6tisch-architecture-21 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2019 15:20:24 -0000 Michael Richardson writes: > > I.e., make sure the joining process is (I leave out acks in this > > picture): > > "security level X" <--- this is an IEEE802.15.4 thing, not a new creation, > right? Yes, i.e., Table 9-6 of 802.15.4-2015 section 9.4.1.1: Security Security Security Data Data MIC length level level field attributes confiden- authen- (octets) b2 b1 b0 tiality ticity 0 000 None OFF NO 0 1 001 MIC-32 OFF YES 4 2 010 MIC-64 OFF YES 8 3 011 MIC-128 OFF YES 16 4 100 Reserved Reserved Reserved Reserved 5 101 ENC-MIC-32 ON YES 4 6 110 ENC-MIC-64 ON YES 8 7 111 ENC-MIC-128 ON YES 16 I.e., level 0 is no security, levels 1-3 are for authentication only and levels 5-7 is authentication and encryption both. Level 4 used to be encryption only, but that was removed in 2015 revision, as there is huge security issues with it. -- kivinen@iki.fi From nobody Mon Jul 22 19:57:06 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 2FBF512013E; Mon, 22 Jul 2019 19:56:49 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rifaat Shekh-Yusef via Datatracker To: Cc: netconf@ietf.org, ietf@ietf.org, draft-ietf-netconf-crypto-types.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Rifaat Shekh-Yusef Message-ID: <156385060911.22708.13715150809401887999@ietfa.amsl.com> Date: Mon, 22 Jul 2019 19:56:49 -0700 Archived-At: Subject: [secdir] Secdir early partial review of draft-ietf-netconf-crypto-types-10 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, 23 Jul 2019 02:56:49 -0000 Review is partially done. Another assignment may be needed to complete it. Reviewer: Rifaat Shekh-Yusef Review result: Not Ready There is the open issue of the proper structure of this YANG model, which was discussed with the security ADs and IESG, and still to be discussed with IANA. Meanwhile, I have the following comments: Page 6, hash-algorithm_t Why would you include SHA1 and indicate that it is obsolete? why not just drop it? Page 8, hash-algorithm-t Why would the default be 0, i.e. NONE? I think you should select a minimum algorithm that would be considered acceptable as the default. page 17, encryption-algorithm-t Why would you include RC4 algorithms? page 19, signature-algorithm-t Why would you include dsa-sha1? page 40, grouping symmetric-key-grouping, leaf hidden-key { nacm:default-deny-write If I understand hidden-key, it is a key that is not accessible through this model. So, what is this meant to describe? page 45, grouping symmetric-key-pair-with-cert-grouping, input { leaf subject... The user of Subject field is discouraged, and the SAN field should be used instead. Take a look at the following: https://tools.ietf.org/html/rfc6125#section-4 From nobody Mon Jul 22 20:16:35 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 EAEFC12003E; Mon, 22 Jul 2019 20:16:19 -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, 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 02rVA72uOH46; Mon, 22 Jul 2019 20:16:18 -0700 (PDT) Received: from mail-lj1-x241.google.com (mail-lj1-x241.google.com [IPv6:2a00:1450:4864:20::241]) (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 21445120091; Mon, 22 Jul 2019 20:16:15 -0700 (PDT) Received: by mail-lj1-x241.google.com with SMTP id m23so39495089lje.12; Mon, 22 Jul 2019 20:16:14 -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=CGVFJmEl3lbnKEHvV6Er0ndwtckAG+UVXPBsMmiVEi0=; b=d+F8rL0doDJPAA8xtxxZ8umFQMmZCq7ckLnhg4UrT4E5lgjVeVmmKSvbcdGA+UDXXG mMBpqsBldkquDJyHmfrxXDZ42vGOkf3QKJJ2tB5VdHEF/uFclAJ8wdnLU/+4HtDaX8a6 VvNoarxUPzdO41jMyXdw9oyyEHeUGNVZvzR32d9watNUqVWclc74cqVevhWicLyDf6Sg t+jIENI4Z2IWEF1Ivgw2RiudUot+iyOM/sP/BavwEVp7vDKTL6WGD37bOkSIZm+QMAI7 yvPVXdNG+HYNARpYcwoFFtG5QUV4XlWm1mYPyACgKRJurL29c+ezxW7gJIMUhNo1WJOi 7OTw== 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=CGVFJmEl3lbnKEHvV6Er0ndwtckAG+UVXPBsMmiVEi0=; b=V65CpFTFJuJFNW0TGxpSjw5Fy644vFRA3Lbzkp3ZqZYZvKop2qvDqj0RyPxCBFJMuW dEdIZEzmyqaVSAoIig1t5H3lLyRnIsELODRMXzBfZ/00q1CWwoy1Ixj+F4sjX1X0a2BE XmK8NDoqhzqUQ6c7NZHwTpXEN44ORzM1PBpjQWsA9bNMvV5anOfbIyFBC7vl3Jp7KovB PNTnO2p51njzY08qhevS+WSK/wtYka9wI2tWmTL1nRf8slI4vDVLK63ES7eGfTFo6ILW DKRP7rau8d777Jlg4rQuS4R35eQ9MG0pndTGVVXqaE2e3Glyi+kMzDk+FVzPg+BxvHTN nOSw== X-Gm-Message-State: APjAAAVasLHeMeY3SdDoUKf/OJbUhGKn0Tt2kSbFdPkD3s2dL8+5nBP4 PLWfD9AD7mMOnY/cODWjhZwP4mmxXTQjhw/Le3Q= X-Google-Smtp-Source: APXvYqwWVE5i/t7ELDQ7tPX4XAAcl5LyMkUUXkARyynapHSOY6ZMgk96zFYAvVXyYgDsNCMctiVCw/Xq4nZ9dhdRP54= X-Received: by 2002:a2e:8602:: with SMTP id a2mr36327259lji.206.1563851773207; Mon, 22 Jul 2019 20:16:13 -0700 (PDT) MIME-Version: 1.0 References: <156385060911.22708.13715150809401887999@ietfa.amsl.com> In-Reply-To: <156385060911.22708.13715150809401887999@ietfa.amsl.com> From: Watson Ladd Date: Mon, 22 Jul 2019 20:16:01 -0700 Message-ID: To: Rifaat Shekh-Yusef Cc: secdir , draft-ietf-netconf-crypto-types.all@ietf.org, netconf@ietf.org, "" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [secdir] Secdir early partial review of draft-ietf-netconf-crypto-types-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2019 03:16:20 -0000 On Mon, Jul 22, 2019 at 7:57 PM Rifaat Shekh-Yusef via Datatracker wrote: > > > Review is partially done. Another assignment may be needed to complete it. > > Reviewer: Rifaat Shekh-Yusef > Review result: Not Ready > > There is the open issue of the proper structure of this YANG model, which was > discussed with the security ADs and IESG, and still to be discussed with IANA. > > > Meanwhile, I have the following comments: > > Page 6, hash-algorithm_t > Why would you include SHA1 and indicate that it is obsolete? why not just drop it? > > Page 8, hash-algorithm-t > Why would the default be 0, i.e. NONE? > I think you should select a minimum algorithm that would be considered acceptable as the default. Along those lines why is RSA-1024 in there? The asymmetric algorithm doesn't differentiate between encryption and signing or other more exotic things, which I guess is defensible but raises some potential gotchas. We also have an IANA registry for AEAD schemes: why not use that? This would have avoided some omissions such as AES-SIV mode. Lastly one nit: it's elliptic curve not elliptical curve. From nobody Tue Jul 23 06:46:57 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 91AC8120300 for ; Tue, 23 Jul 2019 06:46:45 -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, 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 (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GrvqqrTi9dGo for ; Tue, 23 Jul 2019 06:46:43 -0700 (PDT) Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 A8B4C1202A4 for ; Tue, 23 Jul 2019 06:46:43 -0700 (PDT) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6NDkgLM023298 for ; Tue, 23 Jul 2019 09:46:42 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x6NDkgLM023298 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1563889602; bh=IUonLG6gcfBA++KpPkhYPR9OGgKeHguIETbtij3sPTM=; h=From:To:Subject:Date:From; b=kKGhTT5jJJtRiJqum04l1J2cJghkI46HjooBVyq/IsBiJANlKBQOJ7M7/aTxzcZxB fff5B/sfRkxyIZhfEcdx5Ft2iMDCBFf5prx0RtiEpgdLJuMwjUY78yKoYJKC+cSUCE PxTE05OdP1nYXgZBqPJoAAvR+UIGRMc8yn02DKYU= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x6NDkb16029996 for ; Tue, 23 Jul 2019 09:46:37 -0400 Received: from MARCHAND.ad.sei.cmu.edu ([10.64.28.251]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Tue, 23 Jul 2019 09:46:37 -0400 From: Roman Danyliw To: secdir Thread-Topic: Recurring issues found during sec review Thread-Index: AdVBXOvbIZa03j1BSj2dTFwg8FntWA== Date: Tue, 23 Jul 2019 13:46:37 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B33E17EA@marchand> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [secdir] Recurring issues found during sec review 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, 23 Jul 2019 13:46:56 -0000 Hi! As an IESG initiatives, each of the areas is pulling together a list of "re= curring issues" found by their areas during area review (e.g., secdir, iotd= ir, genart, opsdir, tsvart) and IESG review. The intent is to provide info= rmal, but not comprehensive, guidance to draft authors and their WG chairs = with the intent to find issues earlier. Ben and I made the following initi= al list: https://trac.ietf.org/trac/sec/wiki/TypicalSECAreaIssues Welcome feedback and refinement! Regards, Roman and Ben From nobody Tue Jul 23 07:08:22 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 1DADF12028A for ; Tue, 23 Jul 2019 07:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dO0KVWRUOC-j for ; Tue, 23 Jul 2019 07:08:17 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1FFD812030C for ; Tue, 23 Jul 2019 07:07:59 -0700 (PDT) Received: from [192.168.20.169] (ottawa.ca.networkradius.com [72.137.155.194]) by mail.networkradius.com (Postfix) with ESMTPSA id 89DAC2E12; Tue, 23 Jul 2019 14:07:57 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Alan DeKok In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B33E17EA@marchand> Date: Tue, 23 Jul 2019 10:07:55 -0400 Cc: secdir Content-Transfer-Encoding: quoted-printable Message-Id: References: <359EC4B99E040048A7131E0F4E113AFC01B33E17EA@marchand> To: Roman Danyliw X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [secdir] Recurring issues found during sec review 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, 23 Jul 2019 14:08:20 -0000 On Jul 23, 2019, at 9:46 AM, Roman Danyliw wrote: >=20 > Hi! >=20 > As an IESG initiatives, each of the areas is pulling together a list = of "recurring issues" found by their areas during area review (e.g., = secdir, iotdir, genart, opsdir, tsvart) and IESG review. The intent is = to provide informal, but not comprehensive, guidance to draft authors = and their WG chairs with the intent to find issues earlier. Ben and I = made the following initial list: >=20 > https://trac.ietf.org/trac/sec/wiki/TypicalSECAreaIssues One issue I don't see covered is "what happens when things go wrong?" = This isn't quite "Broken Constraints", but it's close. The temptation is to describe how things *should* work. But that = isn't good enough. In the real world, we need to describe how to handle = the failure conditions, too. When specifications says "When a server receives X, it does Y", what = happens when the server *doesn't* receive X? What does it do? How are errors handled? Saying "When X do Y" is very much an "if" condition, even though it is = not phrased as such. The solution is to about handle the "else" case to = every "if", as with the following example: IF a server receives X THEN do Y ELSE do something else IIRC, the above behaviour is required in medical software. "No IF = without an ELSE". I believe it should be required for protocol = specifications, too. As an implementor, I can't count the number of times I've run into = this issue. Reading the specification is nice, but it doesn't give me = enough information to create a robust implementation. That experience = has influenced the standards I write, so they pretty much all have an = "else" for every "if". And it's a repeated comment I have for documents = I review. Alan DeKok. =20= From nobody Tue Jul 23 07:14: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 C90B4120375 for ; Tue, 23 Jul 2019 07:14:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSlzcbcMqTtV for ; Tue, 23 Jul 2019 07:14:17 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCE30120374 for ; Tue, 23 Jul 2019 07:14:16 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 45tL7p6fxpzDjy; Tue, 23 Jul 2019 16:14:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1563891254; bh=+TBZQzV6SGVgciFTsaibiVZWVR0TqK3ToIfrjqOyuxI=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=pl0OJziIlNd8Ko+/0R5ElggMweWuKIAH6n4fO/p7raSspFJGIk0E6sDTzTy+l4MLD 45OtbQU9cXEg06ZIhbdsuNWAhik9ZfKvL7GxWgFmQjRlUO9sqebFpkq43xRoPQZU1F Ek6qLphb9qha0Gl2uD0Tc+LupaCPD85HT5F6o2/M= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id lH2xbmGd7Dde; Tue, 23 Jul 2019 16:14:13 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 23 Jul 2019 16:14:12 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id B47AC3159D2; Tue, 23 Jul 2019 10:14:11 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca B47AC3159D2 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AAB7B406FE60; Tue, 23 Jul 2019 10:14:11 -0400 (EDT) Date: Tue, 23 Jul 2019 10:14:11 -0400 (EDT) From: Paul Wouters To: Alan DeKok cc: Roman Danyliw , secdir In-Reply-To: Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC01B33E17EA@marchand> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [secdir] Recurring issues found during sec review 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, 23 Jul 2019 14:14:26 -0000 On Tue, 23 Jul 2019, Alan DeKok wrote: > Saying "When X do Y" is very much an "if" condition, even though it is not phrased as such. The solution is to about handle the "else" case to every "if", as with the following example: > > IF a server receives X > THEN > do Y > ELSE > do something else > > IIRC, the above behaviour is required in medical software. "No IF without an ELSE". I believe it should be required for protocol specifications, too. Right. In our terms that would be more in the sense of, the client MUST send X. If the server receives a request without X, it MUST do z. That is, every MUST should have an obvious action for when it is violated. And we have the weaker version with SHOULD. For every SHOULD in the document, the authors should have at least one example of where the SHOULD case exception is valid. If they cannot come up with that exception, the SHOULD should be a MUST. In a way, this process is running a fuzzer against your proposed specification. Paul From nobody Tue Jul 23 07:24: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 D96F312024E for ; Tue, 23 Jul 2019 07:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QISxztOHlB7g for ; Tue, 23 Jul 2019 07:24:29 -0700 (PDT) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66C61120298 for ; Tue, 23 Jul 2019 07:24:10 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 600A4300AEA for ; Tue, 23 Jul 2019 10:04:52 -0400 (EDT) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id rBYB690zkN89 for ; Tue, 23 Jul 2019 10:04:51 -0400 (EDT) Received: from dhcp-88d0.meeting.ietf.org (dhcp-88d0.meeting.ietf.org [31.133.136.208]) by mail.smeinc.net (Postfix) with ESMTPSA id E5DAB300AB4; Tue, 23 Jul 2019 10:04:50 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Russ Housley In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B33E17EA@marchand> Date: Tue, 23 Jul 2019 10:24:07 -0400 Cc: IETF SecDir Content-Transfer-Encoding: quoted-printable Message-Id: <746B874F-2293-4F8D-9812-C81A94CF1ED2@vigilsec.com> References: <359EC4B99E040048A7131E0F4E113AFC01B33E17EA@marchand> To: "Roman D. Danyliw" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [secdir] Recurring issues found during sec review 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, 23 Jul 2019 14:24:31 -0000 Please add "Do not make up your own cryptography". I have not seen it = in a while, but when I see it, it is poorly done. Russ > On Jul 23, 2019, at 9:46 AM, Roman Danyliw wrote: >=20 > Hi! >=20 > As an IESG initiatives, each of the areas is pulling together a list = of "recurring issues" found by their areas during area review (e.g., = secdir, iotdir, genart, opsdir, tsvart) and IESG review. The intent is = to provide informal, but not comprehensive, guidance to draft authors = and their WG chairs with the intent to find issues earlier. Ben and I = made the following initial list: >=20 > https://trac.ietf.org/trac/sec/wiki/TypicalSECAreaIssues >=20 > Welcome feedback and refinement! >=20 > Regards, > Roman and Ben >=20 >=20 > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview From nobody Tue Jul 23 08:05:48 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 93F2012039E for ; Tue, 23 Jul 2019 08:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruQHNDJptZwK for ; Tue, 23 Jul 2019 08:05:39 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02CAF1202F3 for ; Tue, 23 Jul 2019 08:05:28 -0700 (PDT) Received: from [192.168.20.169] (ottawa.ca.networkradius.com [72.137.155.194]) by mail.networkradius.com (Postfix) with ESMTPSA id 5B8D41A64; Tue, 23 Jul 2019 15:05:25 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Alan DeKok In-Reply-To: Date: Tue, 23 Jul 2019 11:05:23 -0400 Cc: Roman Danyliw , secdir Content-Transfer-Encoding: 7bit Message-Id: <4210BF08-7564-4F9B-9E3D-2902B0351707@deployingradius.com> References: <359EC4B99E040048A7131E0F4E113AFC01B33E17EA@marchand> To: Paul Wouters X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [secdir] Recurring issues found during sec review 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, 23 Jul 2019 15:05:47 -0000 On Jul 23, 2019, at 10:14 AM, Paul Wouters wrote: > Right. In our terms that would be more in the sense of, the client MUST > send X. If the server receives a request without X, it MUST do z. > > That is, every MUST should have an obvious action for when it is > violated. That's a good phrasing. > And we have the weaker version with SHOULD. For every SHOULD in the > document, the authors should have at least one example of where the > SHOULD case exception is valid. If they cannot come up with that > exception, the SHOULD should be a MUST. I agree. Alan DeKok. From nobody Tue Jul 23 08:16:04 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1F7C120134 for ; Tue, 23 Jul 2019 08:15:55 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 duZgDq-_PFUO for ; Tue, 23 Jul 2019 08:15:53 -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 8A96912022B for ; Tue, 23 Jul 2019 08:15:53 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x6NF7Q98021461; Tue, 23 Jul 2019 16:15:45 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=BdpprmYr3sqUjfnIs0qItuTJofEf+GayumepIQ9GyLM=; b=U84fWvGVGccIWxg05aYjecSvhHJqNtHC/O8dnIP1llUWgWWIHATX4ndarAizvk0lhGMj XGIaHjs7hi5Yhh56R1+kx+smtF1rxTPHFpmdTBsTbDVUSepT/88C9lrmqe0B3vSh7+Mi A32rJuhRb5q/iioGylOHiWrYz6qBp2XdZzbFOh/Ahj/5CBio9w/5ieM9vcLqSUDbOABw BqBhvtdg8YKPRjblKrxBoqBT3++ouquSMyFVGG0y5Lcu7CfSVQg3A1E2OCgW9gfP/Nmw sFC0/hQh4TA6tQYkYYowuCKz9FxPQvjl/wORIdSVV74TKS+1yJux1Qz16x7xRI4zI082 Sg== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2twkv9b6yp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Jul 2019 16:15:45 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x6NF21GB005043; Tue, 23 Jul 2019 11:15:44 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2twkjh46ue-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 23 Jul 2019 11:15:43 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 23 Jul 2019 11:15:43 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Tue, 23 Jul 2019 11:15:43 -0400 From: "Salz, Rich" To: Alan DeKok , Paul Wouters CC: secdir Thread-Topic: [secdir] Recurring issues found during sec review Thread-Index: AdVBXOvbIZa03j1BSj2dTFwg8FntWAAJKEuAAAA4B4AAAcnEgP//v9MA Date: Tue, 23 Jul 2019 15:15:42 +0000 Message-ID: <14187E3B-4436-406E-A2D6-7A514CD95925@akamai.com> References: <359EC4B99E040048A7131E0F4E113AFC01B33E17EA@marchand> <4210BF08-7564-4F9B-9E3D-2902B0351707@deployingradius.com> In-Reply-To: <4210BF08-7564-4F9B-9E3D-2902B0351707@deployingradius.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1b.0.190715 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.217] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-23_06:, , 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=856 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907230150 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-07-23_06:2019-07-23,2019-07-23 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 mlxscore=0 priorityscore=1501 impostorscore=0 mlxlogscore=831 bulkscore=0 suspectscore=0 adultscore=0 clxscore=1011 malwarescore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1904300001 definitions=main-1907230152 Archived-At: Subject: Re: [secdir] Recurring issues found during sec review 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, 23 Jul 2019 15:15:56 -0000 DQogICAgPiBUaGF0IGlzLCBldmVyeSBNVVNUIHNob3VsZCBoYXZlIGFuIG9idmlvdXMgYWN0aW9u IGZvciB3aGVuIGl0IGlzDQogICAgPiB2aW9sYXRlZC4NCiAgICANCiAgICAgIFRoYXQncyBhIGdv b2QgcGhyYXNpbmcuDQoNCkkgc3Ryb25nbHkgZGlzYWdyZWUuICBJdCB0dXJucyBldmVyeSBNVVNU IGludG8gc29tZXRoaW5nIHRoYXQgb25seSB0aGUgcmVjaXBpZW50IG11c3QgYWN0IG9uLiAgVGhl IGJ1cmRlbiBvZiB0aGUgcHJvdG9jb2wgc2hvdWxkIGJlIG9uIGJvdGggc2lkZXMgdG8gYWN0IGNv cnJlY3RseSwgYW5kIG9uZSBzaWRlIHNob3VsZCBub3QgYmUgY29uc3RyYWluZWQgdG8gYmVoYXZl IGEgcGFydGljdWxhciB3YXkgaWYgdGhlIGNvdW50ZXItcGFydHkgbWlzYmVoYXZlcy4gQW5vdGhl ciByZWFzb24gYWdhaW5zdCB0aGlzIGlzIHRoYXQgaXQgdGVuZHMgdG8gcmVzdWx0IGluIG5hw692 ZSBiZWhhdmlvciBzdWNoIGFzIG9yYWNsZXMgb3IgIm5hbWUgbm90IGZvdW5kIiBiZWluZyBkaXN0 aW5ndWlzaGVkIGZyb20gIndyb25nIHBhc3N3b3JkIg0KDQoNCg0K From nobody Tue Jul 23 08:33:38 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C9E5120423 for ; Tue, 23 Jul 2019 08:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3O_Syzgc4RmD for ; Tue, 23 Jul 2019 08:33:25 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D6D5120383 for ; Tue, 23 Jul 2019 08:33:25 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 45tMv64jdTz5B7 for ; Tue, 23 Jul 2019 17:33:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1563896002; bh=p/NBWZxQgZIOdosWYC9R3x7X+m/y5HZ/yq5CzXhpGRQ=; h=Date:From:To:Subject:In-Reply-To:References; b=kuymZWXsJaDTJGnISlL5K/5D3MxK7sFYXSJ7xfxFvgPyd6O1Fz1+nbpDmExU8xQlZ fY3JQNzsg08aHyldPpHyDJLpYWLDZcAuZHWTxqHfPFt/7Ul0TX9UbSvxqFPsWAIV7A 0P+3HwFDKI9f3k9VWvVTUAdEDmhf1o6vZ8bb0JaA= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id RY0pfW2uB_P1 for ; Tue, 23 Jul 2019 17:33:20 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Tue, 23 Jul 2019 17:33:19 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 9D4943159D2; Tue, 23 Jul 2019 11:33:18 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 9D4943159D2 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 96A4B406FE60 for ; Tue, 23 Jul 2019 11:33:18 -0400 (EDT) Date: Tue, 23 Jul 2019 11:33:18 -0400 (EDT) From: Paul Wouters To: secdir In-Reply-To: <14187E3B-4436-406E-A2D6-7A514CD95925@akamai.com> Message-ID: References: <359EC4B99E040048A7131E0F4E113AFC01B33E17EA@marchand> <4210BF08-7564-4F9B-9E3D-2902B0351707@deployingradius.com> <14187E3B-4436-406E-A2D6-7A514CD95925@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [secdir] Recurring issues found during sec review 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, 23 Jul 2019 15:33:37 -0000 On Tue, 23 Jul 2019, Salz, Rich wrote: > > That is, every MUST should have an obvious action for when it is > > violated. > > That's a good phrasing. > > I strongly disagree. It turns every MUST into something that only the recipient must act on. Unless it is MUST ignore ? > The burden of the protocol should be on both sides to act correctly Indeed, the document would already state not to send malformed data. But the responder/server will be the endpoint dealing with those violations. > , and one side should not be constrained to behave a particular way if the counter-party misbehaves. Another reason against this is that it tends to result in naïve behavior such as oracles or "name not found" being distinguished from "wrong password" I think we are not saying different things. If the action of a MUST is not obvious (eg drop packet), and there are security issues into giving too specific error codes as the example you bring up, it is precisely why the document should tell you what to do. I'm not saying every MUST must have a specific and immediate sentence following saying what to do. For example, IKEv2 has a very limited set of error codes specifically to cover your concern here. INVALID_SYNTAX, AUTHENTICATION_FAILED and NO_PROPOSAL_CHOSEN. With the latter one being the kitchen sink of errors. Paul From nobody Tue Jul 23 08:37: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 BC80512041C for ; Tue, 23 Jul 2019 08:37:16 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] 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 AsIMi2g6H82u for ; Tue, 23 Jul 2019 08:37:14 -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 5166D12040E for ; Tue, 23 Jul 2019 08:37:14 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x6NFX29Z005455; Tue, 23 Jul 2019 16:37:14 +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 : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=OMb//9FUT+GxSBCje5xY34Eu0Uf/4QtK/TIfAfzUo9E=; b=XP8zd1x5vX8rTt1GuU7tOZuMxKA+JE/Dji1E0NifLzZUKDALQVXF7pFA9SG7mIh8AnU+ IX3Zws441A30z3jmJ/AK80+sVW3bemfdH2WhRTao1STzB0QDPc9MOTSgA7q9ctIb1MsY BSqjpW0PQalpW3/TZ+/OX+rF1fnip0rzs2Ry3sfQGySyRlT+XXMS1tRJ5ZeGHFEOC+xi K0Pis78EIHKlKgxn/5qEfGVaBSdjtettx6ZUcX7s7EQzuZCEwQEpLNnbP9TnEZUs/Avo pyV76obQ3ArL1IRo/J93Y+hrW/rVMtfJm6u7vRikkKrYwt0gwgCwdQh3n7eXqRO3xmEr BQ== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2twkv9b8v3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 23 Jul 2019 16:37:13 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x6NFYvXa004788; Tue, 23 Jul 2019 11:37:12 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2twkf14ear-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 23 Jul 2019 11:37:12 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 23 Jul 2019 11:37:12 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 23 Jul 2019 11:37:11 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Tue, 23 Jul 2019 11:37:11 -0400 From: "Salz, Rich" To: Paul Wouters , secdir Thread-Topic: [secdir] Recurring issues found during sec review Thread-Index: AdVBXOvbIZa03j1BSj2dTFwg8FntWAAJKEuAAAA4B4AAAcnEgP//v9MAgABH+QD//74IgA== Date: Tue, 23 Jul 2019 15:37:11 +0000 Message-ID: <876633B1-A352-4FC2-8A77-FDC553444183@akamai.com> References: <359EC4B99E040048A7131E0F4E113AFC01B33E17EA@marchand> <4210BF08-7564-4F9B-9E3D-2902B0351707@deployingradius.com> <14187E3B-4436-406E-A2D6-7A514CD95925@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1b.0.190715 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.217] Content-Type: text/plain; charset="utf-8" Content-ID: <9D5BE15E224E564B96F675BBD7201942@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-23_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=817 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1907230155 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:5.22.84,1.0.8 definitions=2019-07-23_07:2019-07-23,2019-07-23 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 spamscore=0 mlxscore=0 priorityscore=1501 impostorscore=0 mlxlogscore=792 bulkscore=0 suspectscore=0 adultscore=0 clxscore=1015 malwarescore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1904300001 definitions=main-1907230154 Archived-At: Subject: Re: [secdir] Recurring issues found during sec review 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, 23 Jul 2019 15:37:25 -0000 ICAgID4gICAgPiBUaGF0IGlzLCBldmVyeSBNVVNUIHNob3VsZCBoYXZlIGFuIG9idmlvdXMgYWN0 aW9uIGZvciB3aGVuIGl0IGlzDQogICAgPiAgICA+IHZpb2xhdGVkLg0KDQouLi4NCg0KICAgPiBJ J20gbm90IHNheWluZyBldmVyeSBNVVNUDQogICAgbXVzdCBoYXZlIGEgc3BlY2lmaWMgYW5kIGlt bWVkaWF0ZSBzZW50ZW5jZSBmb2xsb3dpbmcgc2F5aW5nIHdoYXQgdG8gZG8uDQogICANCg0KT2th eS4gIEZyb20gbXkgcXVvdGVzIGFib3ZlLCBJIGhvcGUgeW91IGNhbiBzZWUgd2h5IEkgbWlzdW5k ZXJzdG9vZCB5b3UuDQoNCg== From nobody Tue Jul 23 08:51:17 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E308E120193 for ; Tue, 23 Jul 2019 08:51:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlMrHNgpbuWk for ; Tue, 23 Jul 2019 08:51:13 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 138681202D1 for ; Tue, 23 Jul 2019 08:51:13 -0700 (PDT) Received: from [192.168.20.169] (ottawa.ca.networkradius.com [72.137.155.194]) by mail.networkradius.com (Postfix) with ESMTPSA id E291B7A2; Tue, 23 Jul 2019 15:51:10 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: Alan DeKok In-Reply-To: <14187E3B-4436-406E-A2D6-7A514CD95925@akamai.com> Date: Tue, 23 Jul 2019 11:51:08 -0400 Cc: Paul Wouters , secdir Content-Transfer-Encoding: quoted-printable Message-Id: References: <359EC4B99E040048A7131E0F4E113AFC01B33E17EA@marchand> <4210BF08-7564-4F9B-9E3D-2902B0351707@deployingradius.com> <14187E3B-4436-406E-A2D6-7A514CD95925@akamai.com> To: "Salz, Rich" X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [secdir] Recurring issues found during sec review 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, 23 Jul 2019 15:51:16 -0000 On Jul 23, 2019, at 11:15 AM, Salz, Rich wrote: >=20 >=20 >> That is, every MUST should have an obvious action for when it is >> violated. >=20 > That's a good phrasing. >=20 > I strongly disagree. It turns every MUST into something that only the = recipient must act on. If one party MUST send X, then there's not really any benefit to = saying "or else...". That party sends X, or it's not compliant. If = that party ignores the MUST, then there isn't any point in having an = extra clause that says "or else MUST do ...". They'll just ignore that, = too. The issue is with the other party. If the other side MUST send X, = then what does the recipient do when it doesn't receive X? That should = be stated clearly. > The burden of the protocol should be on both sides to act correctly, = and one side should not be constrained to behave a particular way if the = counter-party misbehaves. If it's about security, then absolutely one party should be = constrained to do something *safe* if the other party misbehaves. Another example is sending packetized data over TCP. i.e. sequences = of "header, length, data". What happens if the recipient can't decode a = particular message? I've seen long arguments where people say "the = recipient should try to continue". OK... HOW? If the header / length is malformed, then we have = absolutely no clue how to decode the next set of octets we receive. The = only safe thing to do is to close the connection, and start over. Hence = phrases like "the recipient MUST close the connection if the message is = malformed" I think the "else MUST" phrases really only apply to recipients. = They're not in control of the data that they receive. And they must do = *something* with that data. Perhaps the phrasing could be "if the sender MUST do X, then the = recipient MUST be able to deal with situations where that doesn't = happen". > Another reason against this is that it tends to result in na=C3=AFve = behavior such as oracles or "name not found" being distinguished from = "wrong password" I'm not clear how that applies. Alan DeKok. From nobody Thu Jul 25 14:05:53 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 0DC40120294; Thu, 25 Jul 2019 14:05:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Vincent Roca via Datatracker To: Cc: draft-ietf-oauth-mtls.all@ietf.org, ietf@ietf.org, oauth@ietf.org, vincent.roca@inria.fr X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Vincent Roca Message-ID: <156408873192.17277.1716403359777916336@ietfa.amsl.com> Date: Thu, 25 Jul 2019 14:05:32 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-oauth-mtls-15 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, 25 Jul 2019 21:05:32 -0000 Reviewer: Vincent Roca Review result: Ready Hello, 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. Summary: Ready The Security considerations and privacy considerations sections both look sound to me. Nits: * section 7.1: s/to which they where issued/to which they were issued/ Cheers. Vincent From nobody Fri Jul 26 06:09:15 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 F028D1202B4 for ; Fri, 26 Jul 2019 06:09:13 -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, 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 (1024-bit key) header.d=pingidentity.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 lPmTwRZa9Mrj for ; Fri, 26 Jul 2019 06:09:12 -0700 (PDT) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 382E712012B for ; Fri, 26 Jul 2019 06:09:12 -0700 (PDT) Received: by mail-io1-xd30.google.com with SMTP id q22so104591259iog.4 for ; Fri, 26 Jul 2019 06:09:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1PhZzXFsZQpmmX4q3mSaPo1KxDBXdeVWVXpj+JZXZiM=; b=orWlnpflykPVnTyqRbQfxJbflglTqIXiqVlWTQuyAhf9HjvWEAGx+hoD+olzfPbcfE NtMkfbWOSeFYhJKsOIHfH1a4tpFXU5Y5PZQIyaYGN4vCt/R2Zl1kNLBRq11JHHr5T2Ky FoHPWFUme/WK6BA2zPcJFdPBzPkDj/Yujh+F8= 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=1PhZzXFsZQpmmX4q3mSaPo1KxDBXdeVWVXpj+JZXZiM=; b=TWXRxY2P1gHDdA/x5uCwlb2rInOcvZqk20rqsOpZMrwb+sWLAXkAIv03TirYhDpQrn zt4lEk6A7h403ESeAB9h6IAQBYyb0uKu8Xz+6tYjkG86X3Pcvd9XEdQ64+zh1CARtdoj u84ID8+C72nZmCLYfKxmrnDJdgT3auB0dhFig3IvVW1absuy91oSG16X4rLGl0J2DM+6 o4pEYQiPT+yhY+FjHik+L8Q70ooswUoSq9eHgIuS4dS2l/lv+hgs2THOHVmOyPlGcGQC GYj5tC03+J2FruaZmBPSv5HFvlHNglCmY0eVIBPDGru34vYPtETlt5yEBq5EB5H/R9jX AGxg== X-Gm-Message-State: APjAAAURH0WcYmQbuzQEn3YYp5bVvi/vkhPXTwcPMk7p0bdeIzSGBMBB ZL5vDMCd1T1jBSfvwubKYy8FakEKOAnISX+xPIrfBtIguCgcBAB10PcpOI/6k9COyTIyN61sWmW YiZLvmSxKirNUnvg= X-Google-Smtp-Source: APXvYqyRiSyJ27dIajD1RxLABV2nVEX1e0gsnVBPOESHDkusS0MUamgf45elBZdjk8sWmD0ndfwehCWgimWLEmDAAwc= X-Received: by 2002:a5d:87c6:: with SMTP id q6mr18162536ios.115.1564146551473; Fri, 26 Jul 2019 06:09:11 -0700 (PDT) MIME-Version: 1.0 References: <156408873192.17277.1716403359777916336@ietfa.amsl.com> In-Reply-To: <156408873192.17277.1716403359777916336@ietfa.amsl.com> From: Brian Campbell Date: Fri, 26 Jul 2019 07:08:45 -0600 Message-ID: To: Vincent Roca Cc: secdir@ietf.org, draft-ietf-oauth-mtls.all@ietf.org, ietf@ietf.org, oauth Content-Type: multipart/alternative; boundary="00000000000093e883058e953f53" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-oauth-mtls-15 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, 26 Jul 2019 13:09:14 -0000 --00000000000093e883058e953f53 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks Vincent, I've fixed the nit in the source controlled editor's xml version and it'll show up in the next draft revision. On Thu, Jul 25, 2019 at 3:06 PM Vincent Roca via Datatracker < noreply@ietf.org> wrote: > Reviewer: Vincent Roca > Review result: Ready > > Hello, > > I have reviewed this document as part of the security directorate=E2=80= =99s 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 ju= st > like any other last call comments. > > Summary: Ready > > The Security considerations and privacy considerations sections both look > sound > to me. > > Nits: > * section 7.1: s/to which they where issued/to which they were issued/ > > Cheers. Vincent > > > > --=20 _CONFIDENTIALITY NOTICE: This email may contain confidential and privileged= =20 material for the sole use of the intended recipient(s). Any review, use,=20 distribution or disclosure by others is strictly prohibited.=C2=A0 If you h= ave=20 received this communication in error, please notify the sender immediately= =20 by e-mail and delete the message and any file attachments from your=20 computer. Thank you._ --00000000000093e883058e953f53 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Vincent, I've fixed the nit in the source contr= olled editor's xml version and it'll show up in the next draft revi= sion.

On Thu, Jul 25, 2019 at 3:06 PM Vincent Roca via Datatracker <= noreply@ietf.org> wrote:
Reviewer: Vincent Roca<= br> Review result: Ready

Hello,

I have reviewed this document as part of the security directorate=E2=80=99s= 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.=C2=A0 Document editors and WG chairs should treat these comments= just
like any other last call comments.

Summary: Ready

The Security considerations and privacy considerations sections both look s= ound
to me.

Nits:
* section 7.1: s/to which they where issued/to which they were issued/

Cheers.=C2=A0 Vincent




<= span style=3D"margin:0px;padding:0px;border:0px;outline:0px;vertical-align:= baseline;background:transparent;font-family:proxima-nova-zendesk,system-ui,= -apple-system,BlinkMacSystemFont,"Segoe UI",Roboto,Oxygen-Sans,Ub= untu,Cantarell,"Helvetica Neue",Arial,sans-serif;font-weight:600"= >CONFIDENTIALITY NOTICE: This email may contain confidenti= al and privileged material for the sole use of the intended recipient(s). A= ny review, use, distribution or disclosure by others is strictly prohibited= .=C2=A0 If you have received this communication in error, please notify the= sender immediately by e-mail and delete the message and any file attachmen= ts from your computer. Thank you. --00000000000093e883058e953f53-- From nobody Sun Jul 28 23:56:22 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 76F9C1200F6; Sun, 28 Jul 2019 23:56:05 -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 TLs3mdSUw1-M; Sun, 28 Jul 2019 23:56:04 -0700 (PDT) Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 02A4512008C; Sun, 28 Jul 2019 23:56:00 -0700 (PDT) Received: by mail-lj1-x236.google.com with SMTP id x25so57534410ljh.2; Sun, 28 Jul 2019 23:56:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=5T1EmNSZhIuBwdCeyKOBzZm6nUSx3Zcr2LlPGvjXvJQ=; b=EPF90ky5rQbjKkm1YpxXMwqRKG1zQfeD9HbhwSdqswcUWcUsjrw7p2hk2ZYbGvwqS7 DfzjQs2OMFwo/5PWSQ/TmIYutqoUC51MS40u7PAslQX4w8eEFiDwPa2Q2nyIVoCdjukf MB2sFSktgYyFmTHN6cauEm92VTfo1okAeYWmMp/1SRwjnWB5JyGjJJxeYqNedHPy387P LW1KUOa8G1E3sfW9zIs57LA0aDlA8Kf4B6dpMNIW7Eli4ckPxuBCl0L6TydukaszbcI5 Et/pVUn/Mq6kISAIaAR8fYq8vl7NtlEu8xEp0w1605dQZN66YntHOEnrP8pEejPNsY7z y24w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=5T1EmNSZhIuBwdCeyKOBzZm6nUSx3Zcr2LlPGvjXvJQ=; b=qC4Oas7kvu4ihqXBhF9MpuDo073tjLSFC4IH0LOhn0SVzR4pjeycefYTQXYXaDnrg1 qdViYTrIJtXbxmEcfOUHDSgTdxWAA4ClOew3VW62PoOluLg+UHLCpQby9awYNgrRQDFO Ur8A53JHzQhM5OchyZqiaeSUqy322gW9JF9OUNF7fhsE1igVTcSBxCYBw8sHNtHDSh4P icMU9jRNGvQZMPxMNnh0zKOH4DlXO4HOguFACaOeIIzzkjhgQRX1Ap7WVU1ZyQQRYfqe LEAfpsOCnz96kPXgCs+UHxExeshQIMjSDJ+03RnfhBN+4F5Mv/qKq5bNpCywMvB0akZ4 UfJQ== X-Gm-Message-State: APjAAAWEuPgSU/ns9sDedlgJD02GgzBiUX6D2QWZS3+eOp/FflvMy9uF l5nfnO4paeQcEgcBMfrSLv6jN//pPJcXtKh9raKqsXJp X-Google-Smtp-Source: APXvYqwnBbTPLxbNRgTc67fSTaONsk9v8vIt4pLULAavystF3pqzLXqJpWkBsR9QiIb3ikFjS3CYDS2dHHF/a76cMoM= X-Received: by 2002:a2e:9a19:: with SMTP id o25mr57161221lji.63.1564383358831; Sun, 28 Jul 2019 23:55:58 -0700 (PDT) MIME-Version: 1.0 From: Radia Perlman Date: Sun, 28 Jul 2019 23:55:47 -0700 Message-ID: To: secdir@ietf.org, ietf@ietf.org, draft-ietf-lamps-cms-hash-sig.all@ietf.org, The IESG Content-Type: multipart/alternative; boundary="000000000000655516058ecc62ce" Archived-At: Subject: [secdir] Secdir review of draft-ietf-lamps-cms-hash-sig-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: Mon, 29 Jul 2019 06:56:06 -0000 --000000000000655516058ecc62ce Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate=E2=80=99s= 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. Summary: Ready I don't see any problems with this. The content is thorough. Editorally, though, I might suggest that there is not really enough tutorial information for someone that is not familiar with these sorts of algorithms to understand this document, so perhaps either there could be another document that this points to, complete with figures (which is the only way to really understand these I think), or more tutorial information could be in this document, or perhaps just say in the beginning that the reader is assumed to already understand these algorithms. Radia --000000000000655516058ecc62ce Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security dire= ctorate=E2=80=99s ongoing
effort to review all IETF documents being proc= essed by the IESG. These
comments were written primarily for the benefit= of the security area
directors.=C2=A0 Document editors and WG chairs sh= ould treat these comments just
like any other last call comments.
Summary: Ready

I don't see any problems with this.=C2=A0 The co= ntent is thorough.=C2=A0 Editorally, though, I might suggest that there is = not really enough tutorial information for someone that is not familiar wit= h these sorts of algorithms to understand this document, so perhaps either = there could be another document that this points to, complete with figures = (which is the only way to really understand these I think), or more tutoria= l information could be in this document, or perhaps just say in the beginni= ng that the reader is assumed to already=C2=A0 understand these algorithms.=

Radia=C2=A0=C2=A0
--000000000000655516058ecc62ce-- From nobody Wed Jul 31 21:27:10 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 192BD12013E; Wed, 31 Jul 2019 21:26:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Salowey via Datatracker To: Cc: lp-wan@ietf.org, draft-ietf-lpwan-ipv6-static-context-hc.all@ietf.org, iesg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.99.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Joseph Salowey Message-ID: <156463361304.5240.7205361618665662244@ietfa.amsl.com> Date: Wed, 31 Jul 2019 21:26:53 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-lpwan-ipv6-static-context-hc-21 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, 01 Aug 2019 04:26:53 -0000 Reviewer: Joseph Salowey Review result: Ready I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is Ready. The document has a good discussion of problems that an attacker can cause with compression and fragmentation. My knowledge of LPWAN is limited, so I included two possible additions to the security considerations if they are relevant to the LPWAN environment. One area that is not covered in the security considerations but has been a problem with fragmentation in practice is the use of fragmentation to try to bypass network packet inspection devices such as firewalls. I don't know enough about the deployment environments to know if the fragmented packets would traverse such a device. It is not clear to me if the header to be compressed can contain secret information such as a cookie or authentication token. If these packets are going to be encrypted then compression can provide an attacker with a means to break the confidentiality on certain data in special circumstances. Examples of these are BREACH[1] and CRIME attacks. These require some specific conditions that may not exist in the use cases for this protocol. In general some secret information must be present in a packet, an attacker must be able to inject arbitrary data into the packet and the attacker must be able to observe the effect on the encrypted compressed packet-size. I don't know if this is a likely scenario in the protocols use cases. These attacks can be mitigated by not compressing values that may be secret in the header. [1] https://en.wikipedia.org/wiki/BREACH [2] https://en.wikipedia.org/wiki/CRIME