From nobody Wed Mar 1 07:01:25 2017 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 9AD9912946A; Wed, 1 Mar 2017 07:01:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5mXlMBHJ8623; Wed, 1 Mar 2017 07:01:08 -0800 (PST) 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 975A012952F; Wed, 1 Mar 2017 07:01:06 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id v21F13Eh004483 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Mar 2017 17:01:03 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v21F13MU008703; Wed, 1 Mar 2017 17:01:03 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22710.57903.142798.950727@fireball.acr.fi> Date: Wed, 1 Mar 2017 17:01:03 +0200 From: Tero Kivinen To: iesg@ietf.org, secdir@ietf.org, draft-ietf-mpls-tp-temporal-hitless-psm.all@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 8 min Archived-At: Subject: [secdir] Secdir review of draft-ietf-mpls-tp-temporal-hitless-psm-12.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 15:01:10 -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. This document seems to be problem statement and requirements document for new MPLS path segment monitoring tool. The title does not really reflect to that and from there it would look more like that this would define that actul hitless path segment monitoring mechanism. As this only provides problem statement and requiremens for it, the title should be changed to say so. The security considerations section just refers to rfc5921 and 5860. As this is problem statement and requirements document, I do not think there is real security considerations in this document, the protocol document based on this might then have more considerations. Nits: The OAM term in the document should be expanded both in the abstract and in the first use. Summary: Ready with nits. -- kivinen@iki.fi From nobody Wed Mar 1 08:37:16 2017 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 370B91295EE; Wed, 1 Mar 2017 08:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 qUdxKIpLuIjm; Wed, 1 Mar 2017 08:37:08 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 C1C5D1295ED; Wed, 1 Mar 2017 08:37:08 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id j18so34757154ioe.2; Wed, 01 Mar 2017 08:37:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=x0eBD0L5EIYvxMGOPPcSkINxTSnGeNZMrdJV5b9z6vM=; b=t2uzlrql5Oa6AtR6c2E+Q1c1CpLHjFYp/zF8X6/cBuTrn9t0YemqybZ5FZ4KGolMTd CjjgaO9svw59wq8LRnyRLbWqLxIJtiTL1YLIlzmUuiN3o8njd8Xpb64ey3msIiUTsWfV LtUExWhSlyd+BrMqJKU76OHxhn3un/duMRvuqhrnTVdF8AS3gqIxfiBNeUa4fywvM+R8 cSd66whP4zMdg+hDHYSBNVCLTAoTDuIglpyJidPRXMEQWEFDcp9EhFsSWi42S4q0tPTu rXn47d8OszEsOXZpNRzywRkEbRVpxg6Nc5MCC6AUgu2/Rk75/LZcc2nwYqNWm6AzQwJ8 3opg== 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:cc; bh=x0eBD0L5EIYvxMGOPPcSkINxTSnGeNZMrdJV5b9z6vM=; b=DJtmotqjvym9WU0rdnqp01ZVgajyC8xegHM7WEXgKJDoozP455qmce2+aoXOc4F61l FYxTQEB4EGGyHNjfGcnCtld4s7YqvvkcNPIOBR4qMXziuvoiQ6ugoANcslQbojiS1mTb eghpQg/+tsYAeE9poc9lrdPku1msufGsWwGkxFyaqAiK4k6139k+Yq6Y2u/SlpkJxtg6 NlpJBybf/jolo7HU/CK6UJ1180NMD0R31pzIOfbyEiYZrv1hQmW/cepPQOXzeSmOJUyR Y1R+SqQ0lFcz8HilWh/T/NHPU25b5xFNLea1jUaRVkGSTETZAVrN+DVM0s6Nf/FDUrZU 25cw== X-Gm-Message-State: AMke39nv4mlax7AI7+6YbJBqZ32hlePEW4SY6C3/5sO22dXym/F4lD/ZJorzSfM/0+7CITDtFjccANTytTJOhA== X-Received: by 10.107.48.142 with SMTP id w136mr8670898iow.16.1488386228103; Wed, 01 Mar 2017 08:37:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.135.215 with HTTP; Wed, 1 Mar 2017 08:36:52 -0800 (PST) From: Donald Eastlake Date: Wed, 1 Mar 2017 11:36:52 -0500 Message-ID: To: "iesg@ietf.org" , draft-leiba-rfc2119-update.all@ietf.org Content-Type: multipart/alternative; boundary=001a11444ad26a3f960549adec5b Archived-At: Cc: "secdir@ietf.org" Subject: [secdir] SECDIR review of draft-leiba-rfc2119-update-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 16:37:11 -0000 --001a11444ad26a3f960549adec5b Content-Type: text/plain; charset=UTF-8 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. Document editors and WG chairs should treat these comments just like any other last call comments. This document merely clarifies the significance of capitalization of the implementation requirement key words of RFC 2119. It's Security Considerations section correctly states that there are none. It is Ready except for a trivial editorial nit. In the sentence In many IETF documents several words are used to signify the requirements in the specification, when they are in all capitals as shown below. I believe there should either be no comma or it should be re-ordered so there are two commas as below. In many IETF documents several words, when they are in all capitals as shown below, are used to signify the requirements in the specification. The automatic nits checker has two incorrect complaints that should be ignored: 1. that "NOT RECOMMENDED" occurs in the document but not in the documents RFC 2119 key words list, which is just because the document is talking about "NOT RECOMMENDED", and 2. in contradiction, that the document doesn't use any RFC 2119 keywords but has RFC 2119 boilerplate, which is just because the document is talking about such boilerplate. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com --001a11444ad26a3f960549adec5b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security dire= ctorate's ongoing effort to review all IETF documents being processed b= y the IESG. Document editors and WG chairs should treat these comments just= like any other last call comments.

This document merely clarifies t= he significance of capitalization of the implementation requirement key wor= ds of RFC 2119. It's Security Considerations section correctly states t= hat there are none.

It is Ready except for a trivial editorial nit. = In the sentence

=C2=A0 =C2=A0In many IETF documents several words ar= e used to signify the
=C2=A0 =C2=A0requirements in the specification, wh= en they are in all capitals as
=C2=A0 =C2=A0shown below.

I believ= e there should either be no comma or it should be re-ordered so there are t= wo commas as below.

=C2=A0 =C2=A0In many IETF documents several word= s, when they are in all
=C2=A0 =C2=A0capitals as shown below, are used = to signify the requirements
=C2=A0 =C2=A0in the specification.
The automatic nits checker has two incorrect complaints that should be= ignored:
  1. that "NOT RECOMMENDED" occurs in the documen= t but not in the documents RFC 2119 key words list, which is just because t= he document is talking about "NOT RECOMMENDED", and
  2. i= n contradiction, that the document doesn't use any RFC 2119 keywords bu= t has RFC 2119 boilerplate, which is just because the document is talking a= bout such boilerplate.
Thanks,
Donald
=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D
=C2=A0Donald E. Eastlake 3rd =C2=A0 +1-508-333-2270 (cell)
= =C2=A0155 Beaver Street, Milford, MA 01757 USA
=C2=A0d3e3e3@gmail.com
--001a11444ad26a3f960549adec5b-- From nobody Wed Mar 1 08:53:42 2017 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 85EE91294F7; Wed, 1 Mar 2017 08:53:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hI-YzyN1D8MR; Wed, 1 Mar 2017 08:53:36 -0800 (PST) Received: from SNT004-OMC2S22.hotmail.com (snt004-omc2s22.hotmail.com [65.55.90.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF0EE1294EB; Wed, 1 Mar 2017 08:53:36 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com ([65.55.90.72]) by SNT004-OMC2S22.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Wed, 1 Mar 2017 08:53:36 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=F/K6HDJA/SniZuOCLL3XF9JYzN5e16am+gYPXOGJ8WY=; b=rLndWM41r4fXL6RGM5uFMwIdcS1qGv2NdBxFdWeSQA60GjKP7LIALHrdyhB1v5Lc9GJXV3Ik2+Trd8z4TQAs0gy6B8CcKK0ux0fyGjS2e75aBFqfcgeuxgo487EMBheUSX1Cd9Dqxk+ojRpRHBrNYS1xAp3yJKDtebq5iVdwUaDALR58jotTS1irRhIwYUAWY3VjzNOTnMRr+hpJqn8U9IaUQAURxKDkFfmA42fVXkxn6V6kx1OB3jLKJMluS+iKf5fKBZS6PMSy/I5Bc2J3GBk4BhGcJSR1GUtASMewW7CxZmJwgE1guLcdCicn32yGGg/91W+LCnPEm5/x1j4seA== Received: from SN1NAM02FT052.eop-nam02.prod.protection.outlook.com (10.152.72.53) by SN1NAM02HT220.eop-nam02.prod.protection.outlook.com (10.152.73.241) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.11; Wed, 1 Mar 2017 16:53:33 +0000 Received: from CY4PR17MB0997.namprd17.prod.outlook.com (10.152.72.57) by SN1NAM02FT052.mail.protection.outlook.com (10.152.72.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.11 via Frontend Transport; Wed, 1 Mar 2017 16:53:33 +0000 Received: from CY4PR17MB0997.namprd17.prod.outlook.com ([10.173.181.7]) by CY4PR17MB0997.namprd17.prod.outlook.com ([10.173.181.7]) with mapi id 15.01.0933.020; Wed, 1 Mar 2017 16:53:32 +0000 From: Charlie Kaufman To: "secdir@ietf.org" , 'The IESG' , "draft-ietf-httpbis-http2-encryption.all@tools.ietf.org" Thread-Topic: Secdir review of draft-ietf-httpbis-http2-encryption-10 Thread-Index: AQHSkqtbbEIIZ0NFOUeTELkryLureA== Date: Wed, 1 Mar 2017 16:53:32 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=outlook.com; x-incomingtopheadermarker: OriginalChecksum:985A0190DB44F194600088C413A2EBE80EE51DEF139C23C7E703A675B361783C; UpperCasedChecksum:F8F31913F01C5E1F7F971096741447D20E0A2351A9CF366F87844A781882E540; SizeAsReceived:7795; Count:37 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [TCqjT2ZL3BETgpDwlBpe6gQE0gPU5AzS] x-incomingheadercount: 37 x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; SN1NAM02HT220; 5:ezYvJEP0jGZEhnWmzP7jSaFCihuTVa4CIIpobvtOnnLfRq2eGWLeLD6SmBh+iBCAtjPU8Mf8vkmBpDuyrxsB2Vr/cYlidmP8j0QRmied9t4yUHXheRqaZjN5vF0lZBL0LiDWh0GtN7PgShuJABTosQ==; 24:foYrjQsxDzohQAmY5+OvvRe9rZUV89Y1seGquv74+WfIe3aPrQYSvxJOROypRM5s6MqzIRgrkb4F6KRe3SSCVsIFc56BO8ojWvB7/CWKxOw=; 7:hwHYTeNkGTcPPNo/lq97hPKH/Qs3t81poye7ySFJQCtENP8jqA+80XbCcyGrbi3r7uHhwb2s6RD8fF5nsZm/VXMR+wESOSo65pzUtt21nIXfvhvCCQCY/R0uBYtV4iDW9iifEx3cNQYzCZeu0Q6piJD2IOCw0Nq6cns7/6nhnxx3UzAZnLZ1vBu1Rpm/oMDh4PuVkqeySbvqx0iPnAqZZhvQ+3tGxKzQdY4UYLcRKqP5sEnHKDsZOlnOCQXNnY87Dztrn50RFOZHTCM0/Xbunm1iF0NViKa7tat9y+ZBPogcpzvzkXQ8bqu62F4JWNv5 x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900012); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1NAM02HT220; H:CY4PR17MB0997.namprd17.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: feaa6c27-5b3b-4648-75af-08d460c37eb5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(201702181095)(1603101448)(1601125254)(1701031045); SRVR:SN1NAM02HT220; x-ms-exchange-slblob-mailprops: /ntUcd07dac1NOabgpcu/Lf8xO8NWPhltzuPo1XMHrYfJdnYJcb1RhSF8WPRPbyB2hfMRf+P9e0JTD6MiH23NAjksBzuV1+ECCcqy7hzeuj8uQ6mw8DH3mvscctxbzDrc6foacdodiyXJSp5bImbiEDoKqO8HepOA1tpAs3I/wVq8lUa+2DFYvM3Ztfc27cPtayXCabgmXHXplWj4ZpYXNv7v5oHjan/kvFCGIybAkYx557mZV28xmUrNfFQ59+CR4xGFoHQt4h5h1/MCUREVU8D8lpgWLjO6e/FgMzlreHDVu6GlFlBwZThIk0CBV3Qx1Qukes/i1FohXsRvcSjPnioohRgeK415tR6LT4EZATUK/dlBimub6ElDLH+q6aPGLWfMCO0gZNkQYXtOAFdYFsu7/KvjhecEukh02+TvSBDv5ychR37zc2VATCl7J/Ss93VeyL4s5gIPB/yr9henWHmD7li5TdQdojVhqenHxvqS+DqkGV5JF83e4RlJTKBqXM9Kaz6dPUmZ1fmcCwGisRA8fIgtlMZ3mG1PNkJXiagT3Yxg9h5FRnElrMYdwuKosGrr2XFF2+N5f4lzcL6eW4io9mSbTW/iplQECc+Z4p+n45ZuucVgi2izZXPEaIfW5tCUgrtl8JM6vD8gcp8oH71vp6bTv35jOsZjcwyos8Uxmf6XJZmRVI5qUIBo3iGULLZWSc8dBeJuXcpHpBOzfojpKm0HZA3 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015087)(444000031); SRVR:SN1NAM02HT220; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM02HT220; x-forefront-prvs: 0233768B38 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR17MB0997309E466E776272827771DF290CY4PR17MB0997namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2017 16:53:32.4751 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT220 X-OriginalArrivalTime: 01 Mar 2017 16:53:36.0203 (UTC) FILETIME=[5E5821B0:01D292AC] Archived-At: Subject: [secdir] Secdir review of draft-ietf-httpbis-http2-encryption-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 16:53:38 -0000 --_000_CY4PR17MB0997309E466E776272827771DF290CY4PR17MB0997namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. Document = editors and WG chairs should treat these comments just like any other last = call comments. This document specifies a protocol allowing http servers to announce to cli= ents that they allow http queries over TLS, and for capable clients to opti= onally retrieve content over TLS. The intent is to protect against passive = eavesdropping attacks but to never cause errors due to problems with certif= icates or non-support of TLS by the origin server. It does not protect agai= nst server impersonation because there is no reliable way to learn that the= server implements this feature The design uses the alternative service adv= ertisement mechanism specified in RFC7838 and appears (at least to my na=EF= ve eyes) consistent with the syntax and spirit of that spec. It includes a = number of mechanisms designed to prevent hijacking attacks. I see no security issues with this document. It claims an intended status o= f Experimental, which seems surprising. I would expect this to be standards= track. The title of the document: "Opportunistic Security for HTTP" is a little mi= sleading since I expect many in this community would like to see opportunis= tic encryption for HTTP/1.1, which could not be implemented with this speci= fication. A better title might be "Opportunistic Encryption for HTTP/2". In general, the document has a long list of rules for when it is OK to do t= his and when it is not. It would be helpful to readers (and to people worki= ng on future revisions) if there were more explanations of why usage is so = restricted (i.e., what could go wrong if the restrictions were ignored). I = found myself wondering, for example, why server certificates needed to pass= all the same restrictions as https when there is no cryptographic protecti= on against server impersonation. I believe the answer is that without that = restriction there are scenarios where the feature could make it logisticall= y easier to impersonate a server without modifying DNS responses. But more = explanation in the document would have been helpful. Nits: Last paragraph of section 1.1, there is an ambiguous antecedent. Furthermore, this specification is not intended to replace or offer an alternative to "https", since it both preve= nts active attacks and invokes a more stringent security model in most clie= nts. Should be replaced with: Furthermore, this specification is not intended to replace or offer an alternative to "https", since https both pr= events active attacks and invokes a more stringent security model in most c= lients. --_000_CY4PR17MB0997309E466E776272827771DF290CY4PR17MB0997namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

I have reviewed this document as part of the security directorate's on= going effort to review all IETF documents being processed by the IESG. Docu= ment editors and WG chairs should treat these comments just like any other = last call comments.


This document spec= ifies a protocol allowing http servers to announce to clients that they all= ow http queries over TLS, and for capable clients to optionally retrieve co= ntent over TLS. The intent is to protect against passive eavesdropping attacks but to never cause errors due to pro= blems with certificates or non-support of TLS by the origin server. It does= not protect against server impersonation because there is no reliable way = to learn that the server implements this feature The design uses the alternative service advertisement mechani= sm specified in RFC7838 and appears (at least to my na=EFve eyes) consisten= t with the syntax and spirit of that spec. It includes a number of mechanis= ms designed to prevent hijacking attacks.

 

I see no security = issues with this document. It claims an intended status of Experimental, wh= ich seems surprising. I would expect this to be standards track.

 

The title of the d= ocument: "Opportunistic Security for HTTP" is a little misleading= since I expect many in this community would like to see opportunistic encr= yption for HTTP/1.1, which could not be implemented with this specification. A better title might be "Opportunistic Encry= ption for HTTP/2".

 

In general, the do= cument has a long list of rules for when it is OK to do this and when it is= not. It would be helpful to readers (and to people working on future revis= ions) if there were more explanations of why usage is so restricted (i.e., what could go wrong if the restrictio= ns were ignored). I found myself wondering, for example, why server certifi= cates needed to pass all the same restrictions as https when there is no cr= yptographic protection against server impersonation. I believe the answer is that without that restriction there= are scenarios where the feature could make it logistically easier to imper= sonate a server without modifying DNS responses. But more explanation in th= e document would have been helpful.

 

Nits:

 

Last paragraph of = section 1.1, there is an ambiguous antecedent.

 

Furthermore, this = specification is not

intended to replac= e or offer an alternative to "https", since it both prevents acti= ve attacks and invokes a more stringent security model in most clients.

 

Should be replaced= with:

 

Furthermore, this = specification is not

intended to replac= e or offer an alternative to "https", since https both prevents a= ctive attacks and invokes a more stringent security model in most clients.<= /font>


--_000_CY4PR17MB0997309E466E776272827771DF290CY4PR17MB0997namp_-- From nobody Wed Mar 1 09:03:48 2017 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 943E4129619; Wed, 1 Mar 2017 09:03:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 7WZn10Nsv9vW; Wed, 1 Mar 2017 09:03:42 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 230F1129617; Wed, 1 Mar 2017 09:03:42 -0800 (PST) Received: by mail-io0-x229.google.com with SMTP id f84so34260548ioj.0; Wed, 01 Mar 2017 09:03:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=uSMCXSi9Kz6IdV/FIvoeB56wmiETo05U2aTbROBBERs=; b=M5A/uk8e7VO9IoaiYPJ0vhlOsIJnNo3xjsVCVWmEUTHg7Lu56i0ccn+iK6oUciC54Q eFXnrRsrAbqMiDQcJRQ2cII5kxqN8mGvd/GR2SFevVjgU+PqE4miNG1VQgGXZGntq1IW Gs9IPaeksKC5TyVMeiq8vw1Mk+sroH06sYH5fh54qA4RiBdDwIm7nV0qzCCi85FxF6/8 LlGxadRutftgDKcqOwu7SZcayX5l7e3ZI3umMCzdNK9abjdLbtAPZMiO9B8UdlCxxhro Aqb3744kXwqNiYTyTA1TJrZjjRt+K8FoUcTUiiLHh0xgbtz7/FLWiXua0PwspRbzDM46 TdtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=uSMCXSi9Kz6IdV/FIvoeB56wmiETo05U2aTbROBBERs=; b=tsHLDQ9pVTfoelU7g3B9XT2P25X7bCVHQkhctpGvqWUV40wf9Y1EaHZgav4JZnu/cl eC9A8MdN8mViWhbPvSaWfxXawMp8BVW/tJfmoVv/zUCW+X+tHmDtCzywd3ZvFTBkW7oO 6bAKPKJ8ol1HAfmxfEMYQahwGAK/EN1Qeh/5rVR5d79oKHk4b+QdmDDagmflnqunBPvr PyMYRSBwnA0heX7girQTTZc5fX2DZ9mGspT0RmbBYF4DJBoZcydvVMMUY+c1nyi9hKjv lQzEFkLgHOpVK5v1qcul06n4P2QKU4Dy4yirD+ul02xzg8jUBl+FJiB9DMgrykZ56a1R bF/A== X-Gm-Message-State: AMke39nckMq2BsWSr8srtrCTFCttdVY/24J3gjmTKDfmE3xu6+3VDCcLHPmVJ0KxawsGCN15RKtWXvVb5YhN1A== X-Received: by 10.107.182.9 with SMTP id g9mr8646419iof.233.1488387821389; Wed, 01 Mar 2017 09:03:41 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.107.34.14 with HTTP; Wed, 1 Mar 2017 09:03:40 -0800 (PST) In-Reply-To: References: From: Barry Leiba Date: Wed, 1 Mar 2017 09:03:40 -0800 X-Google-Sender-Auth: CSZ0y_5Y12jMquYgh8Y3_6qvXIs Message-ID: To: Donald Eastlake Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-leiba-rfc2119-update.all@ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-leiba-rfc2119-update-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 17:03:43 -0000 Hi, Donald, and thanks for the review. I agree with your two-comma suggestion, and I'll put that in my working copy. Barry On Wed, Mar 1, 2017 at 8:36 AM, Donald Eastlake wrote: > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. Document > editors and WG chairs should treat these comments just like any other last > call comments. > > This document merely clarifies the significance of capitalization of the > implementation requirement key words of RFC 2119. It's Security > Considerations section correctly states that there are none. > > It is Ready except for a trivial editorial nit. In the sentence > > In many IETF documents several words are used to signify the > requirements in the specification, when they are in all capitals as > shown below. > > I believe there should either be no comma or it should be re-ordered so > there are two commas as below. > > In many IETF documents several words, when they are in all > capitals as shown below, are used to signify the requirements > in the specification. > > The automatic nits checker has two incorrect complaints that should be > ignored: > > that "NOT RECOMMENDED" occurs in the document but not in the documents RFC > 2119 key words list, which is just because the document is talking about > "NOT RECOMMENDED", and > in contradiction, that the document doesn't use any RFC 2119 keywords but > has RFC 2119 boilerplate, which is just because the document is talking > about such boilerplate. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com From nobody Wed Mar 1 09:47:46 2017 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 F2BA712962B; Wed, 1 Mar 2017 09:47:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 9mbwYAneQeeh; Wed, 1 Mar 2017 09:47:43 -0800 (PST) Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::235]) (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 CFBDF1294A9; Wed, 1 Mar 2017 09:47:43 -0800 (PST) Received: by mail-pf0-x235.google.com with SMTP id j5so13106141pfb.2; Wed, 01 Mar 2017 09:47:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nu28qp/InIkcFel5HDa5O4SElh0+x1ApVOgMkvNmGrE=; b=Jd0SQCvA0LM7xjrKTwvWl5M8slp4XMPtLMRJ9s5znDoPs/e+hyDAPfbPXDmOqPtC/U 3/IbV48QFkOeuh0HzF9eS/uRCJoQOZdigC2X7QO9vHy31bB5ixijVOlMNO1SMgEkhwhk JCpGvCLd2AWYhMzBSrJqFWC/XNJYEdpzEg7M6J3JvsvSLdCUFGFoQQHajf96fXGYPQO9 LETo9nxQS5s5+Pq58v1PPFyQcdoGShqOzMt1oJochyWZHlVSZB2L6d3Qh998iHdrzsLp iz9vuT0jlcXSfJkiZlMDa1F4F8dGJrMRc2XTJhELjDtNWg5UVOqnZ7p9cKXpNUzFJecl bFIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nu28qp/InIkcFel5HDa5O4SElh0+x1ApVOgMkvNmGrE=; b=TM/WqhPRo8vtKMUQO2qoZXrrYZOt1kDrc1SSu8ZV+ZZD18j35buyxyqNn0vXRb2a7W qNF7gpPmDRmTMjr8Wup4R5I2EAC+i3ioS0s6/wz/+NiSIk3qFAi4PMFZEo6i0wb6/yhq ujnZJ8t/1Id2GxXmfrlcqPaiPr6mdpaMWjT2QA7fshn4B9L/a9FAxd/A6xJGLEiUoRJQ +lQfNVWr9h+6VXJ+hWS6rNYlYHiYoAFap64PK/bRAXSqZImxaSskDfEn0VW/y9vwL9OD U4Djwe0iyyEYNO5ZqWt8sjXr4d2JssyizrUmqO0RXGvMCuqPRQLUK0kbi7rvx1MQLshi ML+g== X-Gm-Message-State: AMke39l1RD53Zz2jc8XTJj8E0quCx0MQmAStuaQtd3vdvgwu1xxXxxj87wmZFHm6bwED5W/LUAt/wQTNyaVqhA== X-Received: by 10.84.229.77 with SMTP id d13mr11919683pln.177.1488390463439; Wed, 01 Mar 2017 09:47:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.186.200 with HTTP; Wed, 1 Mar 2017 09:47:43 -0800 (PST) In-Reply-To: <22710.57903.142798.950727@fireball.acr.fi> References: <22710.57903.142798.950727@fireball.acr.fi> From: Kathleen Moriarty Date: Wed, 1 Mar 2017 12:47:43 -0500 Message-ID: To: Tero Kivinen Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-mpls-tp-temporal-hitless-psm.all@ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-mpls-tp-temporal-hitless-psm-12.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 17:47:45 -0000 Thanks for your review, Tero! This is helpful and I agree on the title. On Wed, Mar 1, 2017 at 10:01 AM, Tero Kivinen wrote: > 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 seems to be problem statement and requirements document > for new MPLS path segment monitoring tool. The title does not really > reflect to that and from there it would look more like that this would > define that actul hitless path segment monitoring mechanism. As this > only provides problem statement and requiremens for it, the title > should be changed to say so. > > The security considerations section just refers to rfc5921 and 5860. > As this is problem statement and requirements document, I do not think > there is real security considerations in this document, the protocol > document based on this might then have more considerations. > > Nits: The OAM term in the document should be expanded both in the > abstract and in the first use. > > Summary: Ready with nits. > -- > kivinen@iki.fi > -- Best regards, Kathleen From nobody Wed Mar 1 13:21:04 2017 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 0909C1296ED for ; Wed, 1 Mar 2017 13:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 JBMB5-5sZe2W for ; Wed, 1 Mar 2017 13:21:01 -0800 (PST) Received: from smtp66.iad3a.emailsrvr.com (smtp66.iad3a.emailsrvr.com [173.203.187.66]) (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 DA43D127076 for ; Wed, 1 Mar 2017 13:21:00 -0800 (PST) Received: from smtp25.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp25.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 19D4720F85; Wed, 1 Mar 2017 16:20:58 -0500 (EST) X-Auth-ID: ogud@ogud.com Received: by smtp25.relay.iad3a.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id E197B2553E; Wed, 1 Mar 2017 16:20:47 -0500 (EST) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-71-191-33-181.washdc.fios.verizon.net [71.191.33.181]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Wed, 01 Mar 2017 16:20:58 -0500 From: Olafur Gudmundsson Content-Type: multipart/alternative; boundary="Apple-Mail=_0F5E25F9-5D7B-4BF4-863A-F4CBE8A2ADBD" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: Date: Wed, 1 Mar 2017 16:20:47 -0500 To: draft-ietf-dime-agent-overload.all@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Cc: secdir@ietf.org Subject: [secdir] Sec-dir review of draft-ietf-dime-agent-overload X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 21:21:02 -0000 --Apple-Mail=_0F5E25F9-5D7B-4BF4-863A-F4CBE8A2ADBD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. Draft is: Ready=20 Well written, all security related points were addressed in Security = considerations of this draft or RFC7683 Olafur --Apple-Mail=_0F5E25F9-5D7B-4BF4-863A-F4CBE8A2ADBD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

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.

Draft = is: Ready 

Well = written, all security related points were addressed in Security = considerations of this draft or RFC7683

Olafur



= --Apple-Mail=_0F5E25F9-5D7B-4BF4-863A-F4CBE8A2ADBD-- From nobody Wed Mar 1 14:21:44 2017 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 17FED129581; Wed, 1 Mar 2017 14:21:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 NOy0BqStke9P; Wed, 1 Mar 2017 14:21:41 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 EC227128AB0; Wed, 1 Mar 2017 14:21:40 -0800 (PST) X-AuditID: 1209190c-da3ff7000000515e-67-58b74972d641 Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id A9.BB.20830.27947B85; Wed, 1 Mar 2017 17:21:39 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id v21MLbu3020722; Wed, 1 Mar 2017 17:21:37 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v21MLXOa019003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 1 Mar 2017 17:21:36 -0500 Date: Wed, 1 Mar 2017 16:21:33 -0600 From: Benjamin Kaduk To: iesg@ietf.org, secdir@ietf.org, draft-ietf-mpls-residence-time.all@ietf.org Message-ID: <20170301222133.GH30306@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKIsWRmVeSWpSXmKPExsUixG6nolvsuT3CYMdvTovv//axW8z4M5HZ 4sPChywOzB5LlvxkCmCM4rJJSc3JLEst0rdL4MroeXKUvWC7QEXTtIwGxom8XYycHBICJhJt O+cydzFycQgJtDFJ7Dj0nwXC2cAocfjGcjYI5wqTxPx/71hBWlgEVCQm/7nGDGKzAdkN3ZeB bA4OEYEIiR0bykDCwgJ2EstPTGQCsXmBNpw9dI4RwhaUODnzCQuIzSygJXHj30smkFZmAWmJ 5f84QMKiAsoSDTMeME9g5J2FpGMWko5ZCB0LGJlXMcqm5Fbp5iZm5hSnJusWJyfm5aUW6Rrq 5WaW6KWmlG5iBIUWpyTPDsYzb7wOMQpwMCrx8GYwbI8QYk0sK67MPcQoycGkJMq7e9W2CCG+ pPyUyozE4oz4otKc1OJDjBIczEoivBOsgcp5UxIrq1KL8mFS0hwsSuK8EhqNEUIC6Yklqdmp qQWpRTBZGQ4OJQneZR5AjYJFqempFWmZOSUIaSYOTpDhPEDDV4PU8BYXJOYWZ6ZD5E8xKkqJ 8zKCJARAEhmleXC9oNiXyN5f84pRHOgVYd7lIFU8wLQB1/0KaDAT0OAXKltBBpckIqSkGhjN nk51cmd4ciUn1T04jC1APtfZfM5+1fdfLTfXekWbXfiXm7th468u48Rv2ZMii+ubZXkSN/n7 z4xsZ1oxT1qvc/OXmoo/Za2T49+cfhIw+8ZOecHFqR22V576nSmJ3rom7+bstWsP7zX8YmUw MU+0ZomY3q7vC+Icy51P/uPca1pfoGiZPleJpTgj0VCLuag4EQDNZ2wz2AIAAA== Archived-At: Subject: [secdir] secdir re-review of draft-ietf-mpls-residence-time-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 22:21:43 -0000 I previously reviewed the -12 (https://www.ietf.org/mail-archive/web/secdir/current/msg07110.html); the -14 seems much improved. On this re-read, I have a better sense of how the various TLVs and sub-TLVs fit together to achieve the goal of having the RTM-capable nodes identify each other and collaborate to account for residence time when processing timing packets. I have no security concerns with the document, as the updated security considerations address the concerns previously raised. However, there are a couple of issues that should probably block publication (but ought to be easy to resolve): Figure 7 appears to only be 31 bits wide, not 32 -- 'Type' is 7 bits, 'Length' 8, 'I' 1, and 'Reserved' 15. Presumably Type is intended to be the full 8 bits, given the assigned values in the registry. On page 16, second paragraph: The ingress node MAY inspect the I bit flag received in each RTM_SET TLV contained in the LSP_ATTRIBUTES object of a received Resv message. Presence of the RTM_SET TLV with I bit field set to 1 indicates that some RTM nodes along the LSP could be included in the calculation of the residence time. An ingress node MAY choose to resignal the LSP to include all RTM nodes or simply notify the user via a management interface. Is that supposed to be "included" or "excluded"? My reading of the previous paragraph was that the I bit would be set when a node failed to compute the next RTM-capable node along the path, and of course, we expect normal operation to include the residence time for all RTM-capable nodes, so signalling potential inclusion is odd. I'll close off this review by noting that sections 4.3 through 4.6 seem to all talk about how to use other protocols to indicate that RTM may be used and could perhaps be grouped into an intermediate subsection, wondering whether the "Type" and "Length" fields in Figure 2 are the same octets of the packet as in Figure 1, and repeating my as-yet unfulfilled intention to send further minor editorial patches to the authors. -Ben From nobody Wed Mar 1 17:22:12 2017 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 1758A1294FF for ; Wed, 1 Mar 2017 17:22:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 6BXA2RryaCMq for ; Wed, 1 Mar 2017 17:22:10 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 3A5CD1293EB for ; Wed, 1 Mar 2017 17:22:10 -0800 (PST) Received: from [10.32.60.146] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v221M5sc032747 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 1 Mar 2017 18:22:07 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [10.32.60.146] From: "Paul Hoffman" To: secdir Date: Wed, 01 Mar 2017 17:22:07 -0800 Message-ID: <658BC77D-D7A2-466F-80FD-6A015653F2C6@vpnc.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: [secdir] SecDir review of draft-ietf-lmap-yang X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 01:22:11 -0000 This document is a fairly standard YANG data model, in this case for for LMAP measurement agents, where LMAP stands for "Large-Scale Measurement Platforms". In short, it's a data model for measuring management platforms themselves. The Security Considerations follows the YANG template of listing all the data elements that are writable (and this maybe dangerous) and those that might reveal information you might not want revealed about your networked management systems, with the appropriate platitudes about using good access control with the data. If any developer or user reads this section, that's wonderful. --Paul Hoffman From nobody Wed Mar 1 19:05:39 2017 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 E7DEE129452; Wed, 1 Mar 2017 19:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 sWxHTunzqlFY; Wed, 1 Mar 2017 19:05:35 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (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 003DF1293EE; Wed, 1 Mar 2017 19:05:34 -0800 (PST) Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id CD2A322E259; Wed, 1 Mar 2017 22:05:27 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Mark Nottingham In-Reply-To: Date: Thu, 2 Mar 2017 14:05:24 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <82B77F70-AC41-498D-A553-3E0E445936E0@mnot.net> References: To: Charlie Kaufman X-Mailer: Apple Mail (2.3259) Archived-At: Cc: HTTP Working Group , The IESG , "secdir@ietf.org" Subject: Re: [secdir] Secdir review of draft-ietf-httpbis-http2-encryption-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 03:05:38 -0000 Hi Charlie, Thanks. > On 2 Mar 2017, at 3:53 am, Charlie Kaufman = wrote: >=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. = Document editors and WG chairs should treat these comments just like any = other last call comments. >=20 > This document specifies a protocol allowing http servers to announce = to clients that they allow http queries over TLS, and for capable = clients to optionally retrieve content over TLS. The intent is to = protect against passive eavesdropping attacks but to never cause errors = due to problems with certificates or non-support of TLS by the origin = server. It does not protect against server impersonation because there = is no reliable way to learn that the server implements this feature The = design uses the alternative service advertisement mechanism specified in = RFC7838 and appears (at least to my na=C3=AFve eyes) consistent with the = syntax and spirit of that spec. It includes a number of mechanisms = designed to prevent hijacking attacks. > =20 > I see no security issues with this document. It claims an intended = status of Experimental, which seems surprising. I would expect this to = be standards track. > =20 > The title of the document: "Opportunistic Security for HTTP" is a = little misleading since I expect many in this community would like to = see opportunistic encryption for HTTP/1.1, which could not be = implemented with this specification. A better title might be = "Opportunistic Encryption for HTTP/2". That seems reasonable to me. See: https://github.com/httpwg/http-extensions/commit/93e79a9247ba8e734 =20 > In general, the document has a long list of rules for when it is OK to = do this and when it is not. It would be helpful to readers (and to = people working on future revisions) if there were more explanations of = why usage is so restricted (i.e., what could go wrong if the = restrictions were ignored). I found myself wondering, for example, why = server certificates needed to pass all the same restrictions as https = when there is no cryptographic protection against server impersonation. = I believe the answer is that without that restriction there are = scenarios where the feature could make it logistically easier to = impersonate a server without modifying DNS responses. But more = explanation in the document would have been helpful. I understand. I'm a little reluctant to start adding rationale for each = requirement en masse at this stage; it feels likely that we'd = misrepresent something. > Nits: > =20 > Last paragraph of section 1.1, there is an ambiguous antecedent. > =20 > Furthermore, this specification is not > intended to replace or offer an alternative to "https", since it both = prevents active attacks and invokes a more stringent security model in = most clients. > =20 > Should be replaced with: > =20 > Furthermore, this specification is not > intended to replace or offer an alternative to "https", since https = both prevents active attacks and invokes a more stringent security model = in most clients. See: https://github.com/httpwg/http-extensions/commit/c3e04d1539 Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Wed Mar 1 19:33:08 2017 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 C2B5A1297C3; Wed, 1 Mar 2017 19:33:06 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 Trj8v6Oif6qi; Wed, 1 Mar 2017 19:33:06 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 596B3129462; Wed, 1 Mar 2017 19:25:13 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id n127so104209306qkf.0; Wed, 01 Mar 2017 19:25:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q+8uHJcwqrseqG2GpjnkjlVLk+pPH9YHjR+64UWLfAI=; b=RqDQtkTEulbPN3RY//ojCmbfYdrdTUmDgLWTePWYKQrra71yeZRyTIwE6UGDu/2W+9 5XKZnOXa/ug/viC9MmCbS2FHLJ8u65JGzXSjbvzGYWw7pTL5dJhX7O005GQVlfHHVdO9 PzCdvyhC8mGhTfBxeXuN35mXhRr21q/qnlDssuYUM2RmAX4rcpDNegO9nbdf1ZQknrB9 qFSbZ3rnFietmJAWTw4mbSxf7jnh5M0FqZvZaIrOEzAY9aRUN8jYRtKPvlKKatVq4ew1 lPLC6ePVRNkjiux7qFQaItDDHE83k5LZt/xRNNdYar/U1gBDpNb/KkHKAqGDH5UbUypH Cv5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Q+8uHJcwqrseqG2GpjnkjlVLk+pPH9YHjR+64UWLfAI=; b=EUDsWSV7T2+i+kvHPUHDhZWTZqWU8J4MTOVrOtK5oNASTO4u/3WSqP3bu1nZeLnVl6 yNQJdT43+PmHocfxAJOj3Nor0Y8KvzZ1k258dEizPyXLqn3WHewq7TjS1gpLjcGn1i2c rgjXTqlC9Gs+fQFLMWF6gN+MQqLvekAPpwb7PRIdmzi0cTFIll1o6bz3bDdt9KyqaE1i 6aUUFt4TyOk8cMlTVJSW8C8yEpheo6zWJ5f93cVfQiSzrY9EQ6tqYFWgMCfxPUAkHcXM kVZd1HrhahF8LhEjsIUczkvzPh2AcjCvL3Kp20egSmuDaxLxLoRD5ZvVjxnFcLy2EcxC QRwQ== X-Gm-Message-State: AMke39nQSdQsPvtaASN+kMXlh7C/BS1BhzhoTHAPoLidP5EOkjua4PtdnFPjs5nVOqtm1BtlNgM6kOIiY6TJaA== X-Received: by 10.237.51.5 with SMTP id u5mr15539959qtd.247.1488425112515; Wed, 01 Mar 2017 19:25:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 1 Mar 2017 19:25:12 -0800 (PST) In-Reply-To: <82B77F70-AC41-498D-A553-3E0E445936E0@mnot.net> References: <82B77F70-AC41-498D-A553-3E0E445936E0@mnot.net> From: Martin Thomson Date: Thu, 2 Mar 2017 14:25:12 +1100 Message-ID: To: Mark Nottingham Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: HTTP Working Group , "secdir@ietf.org" , The IESG Subject: Re: [secdir] Secdir review of draft-ietf-httpbis-http2-encryption-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 03:33:07 -0000 >> I believe the answer is that without that restriction there are scenarios where the feature could make it logistically easier to impersonate a server without modifying DNS responses. But more explanation in the document would have been helpful. That's maybe *part* of the reason, which is to say that I'm not 100% confident that I could write down exactly why in a way that wouldn't be either subtly wrong, or in other ways act as an irritant. For instance, I think that part of the reason is that it is just so damned easy to get a valid cert that we create the more incentives to deploy a server that could do HTTPS, even when that is not possible for other reasons. But then, it's entirely possible that the real reason is subjective. That's why I agree with Mark: > I'm a little reluctant to start adding rationale for each requirement en masse at this stage; it feels likely that we'd misrepresent something. From nobody Wed Mar 1 21:40:00 2017 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 CF08E1293FE; Wed, 1 Mar 2017 21:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 kmpEQHQQjC0d; Wed, 1 Mar 2017 21:39:56 -0800 (PST) Received: from mail-oi0-x234.google.com (mail-oi0-x234.google.com [IPv6:2607:f8b0:4003:c06::234]) (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 B801F127077; Wed, 1 Mar 2017 21:39:56 -0800 (PST) Received: by mail-oi0-x234.google.com with SMTP id 2so33995643oif.0; Wed, 01 Mar 2017 21:39:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2e7a1jG6yEG14bdNfOsn6mSmItbq0R0BJfuNffwXg00=; b=qtUblWWUT+jAoBR4BFlB4GWR4IF+SUABJ4UkgheDNnlecuaETvLBUm85RoZzB4CPux QGkTWrkV/RCBhrMQaotiNH3Rgv0ZpSq0MbkAsqLJlRCZ7gACH+brRuFCDgANMgfCUf8Y zQxQLr2OHYXhhxePzU57cS4veAWhpImhA4w0EAjBE0Gi4H0vBDUvkfNaZDsxuauqaE9M bMtah4yi2HeXyu44HJUZH4ZYa8zhBRNO/2p0GrSPTGeWhYft9zPNUgN+tV+NRj2GhJCj /smYLGkRq3KM20OdKNkXW9THB+9oiDVCnW7EvcWgnV/V5P4K0oI57KhllNOEsCP7g8zP fFqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2e7a1jG6yEG14bdNfOsn6mSmItbq0R0BJfuNffwXg00=; b=MNJZTrrwhbfnYKoHXkiQHVXunxBJSOqafWWRmg1+MCQ5LeZmFAg5YtPf/4/jgWTqnM y3I3hHXAgIptx/ifeJVE0W+0T5XMY3n+8zCElMlZeH+Xw4tofMhn4Ah8NW43Gp4BthEc k6Z4r7Jc88BQniiowQs8SmNqJY238YUSNzzIQu+IAi+sIw1lK11shsOvA3zRKOL+VkV0 QY7S6z37BMp8aekLb5v9dJ/wDDQtzkC6IP6+eCqcvyaZD2hgbEMF/Z917+wO53+uLaCm rdSUUmueNF3ieOnHMcKfCDR9wr0q6ntdYVu6NKr1jVRx7D4q72eTOwVAaepbMxxdFN7E NacA== X-Gm-Message-State: AMke39kbakvGuTzcOKHotp6vAsgXX7iAl/ODnDFuMRFXLEZ1x0C7oOCp79v8/PMSgmqLjjNVZIjAegYOmMBjCA== X-Received: by 10.202.114.77 with SMTP id p74mr6804666oic.44.1488433195847; Wed, 01 Mar 2017 21:39:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.21.21 with HTTP; Wed, 1 Mar 2017 21:39:55 -0800 (PST) In-Reply-To: <20170301222133.GH30306@kduck.kaduk.org> References: <20170301222133.GH30306@kduck.kaduk.org> From: Greg Mirsky Date: Wed, 1 Mar 2017 21:39:55 -0800 Message-ID: To: Benjamin Kaduk Content-Type: multipart/alternative; boundary=001a1134fd38e918700549b8db80 Archived-At: Cc: draft-ietf-mpls-residence-time.all@ietf.org, "iesg@ietf.org" , secdir@ietf.org Subject: Re: [secdir] secdir re-review of draft-ietf-mpls-residence-time-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 05:39:59 -0000 --001a1134fd38e918700549b8db80 Content-Type: text/plain; charset=UTF-8 Hi Ben, sincerely appreciate your thorough review and the most helpful comments. Please fine my answers in-line and tagged GIM>>. Regards, Greg On Wed, Mar 1, 2017 at 2:21 PM, Benjamin Kaduk wrote: > I previously reviewed the -12 > (https://www.ietf.org/mail-archive/web/secdir/current/msg07110.html); > the -14 seems much improved. On this re-read, I have a better sense > of how the various TLVs and sub-TLVs fit together to achieve the > goal of having the RTM-capable nodes identify each other and > collaborate to account for residence time when processing timing > packets. > > I have no security concerns with the document, as the updated > security considerations address the concerns previously raised. > > However, there are a couple of issues that should probably block > publication (but ought to be easy to resolve): > > Figure 7 appears to only be 31 bits wide, not 32 -- 'Type' is 7 > bits, 'Length' 8, 'I' 1, and 'Reserved' 15. Presumably Type is > intended to be the full 8 bits, given the assigned values in the > registry. > GIM>> Great catch, thank you. Indeed, Type is 8 bits-long. Corrected for -15 version. > > On page 16, second paragraph: > > The ingress node MAY inspect the I bit flag received in each RTM_SET > TLV contained in the LSP_ATTRIBUTES object of a received Resv > message. Presence of the RTM_SET TLV with I bit field set to 1 > indicates that some RTM nodes along the LSP could be included in the > calculation of the residence time. An ingress node MAY choose to > resignal the LSP to include all RTM nodes or simply notify the user > via a management interface. > > Is that supposed to be "included" or "excluded"? My reading of the > previous paragraph was that the I bit would be set when a node > failed to compute the next RTM-capable node along the path, and of > course, we expect normal operation to include the residence time for > all RTM-capable nodes, so signalling potential inclusion is odd. > GIM>> I think that I've missed 'not' in that sentence. So it should be Presence of the RTM_SET TLV with I bit field set to 1 indicates that some RTM nodes along the LSP could *not *be included in the calculation of the residence time. I've made the change in -15. Would you agree that it makes text logical? > > > I'll close off this review by noting that sections 4.3 through 4.6 > seem to all talk about how to use other protocols to indicate that > RTM may be used and could perhaps be grouped into an intermediate > subsection, GIM>> Would sub-section with title be acceptable? RTM Capability Advertisement in Routing Protocols > wondering whether the "Type" and "Length" fields in > Figure 2 are the same octets of the packet as in Figure 1, GIM>> Yes indeed. Figure 1 displays generic TLV while Figure 2 displays particular TLV, PTP. > and > repeating my as-yet unfulfilled intention to send further minor > editorial patches to the authors. > -Ben > --001a1134fd38e918700549b8db80 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ben,
sincerely appreciate your thorough review and = the most helpful comments. Please fine my answers in-line and tagged GIM>= ;>.

Regards,
Greg

On Wed, Mar 1, 2017 at 2:21 PM,= Benjamin Kaduk <kaduk@mit.edu> wrote:
I previously reviewed the -12
(https://www.ietf.org/mail-ar= chive/web/secdir/current/msg07110.html);
the -14 seems much improved.=C2=A0 On this re-read, I have a better sense of how the various TLVs and sub-TLVs fit together to achieve the
goal of having the RTM-capable nodes identify each other and
collaborate to account for residence time when processing timing
packets.

I have no security concerns with the document, as the updated
security considerations address the concerns previously raised.

However, there are a couple of issues that should probably block
publication (but ought to be easy to resolve):

Figure 7 appears to only be 31 bits wide, not 32 -- 'Type' is 7
bits, 'Length' 8, 'I' 1, and 'Reserved' 15.=C2=A0 P= resumably Type is
intended to be the full 8 bits, given the assigned values in the
registry.
GIM>> Great catch, thank you. Indeed, = Type is 8 bits-long. Corrected for -15 version.=C2=A0

On page 16, second paragraph:

=C2=A0 =C2=A0The ingress node MAY inspect the I bit flag received in each R= TM_SET
=C2=A0 =C2=A0TLV contained in the LSP_ATTRIBUTES object of a received Resv<= br> =C2=A0 =C2=A0message.=C2=A0 Presence of the RTM_SET TLV with I bit field se= t to 1
=C2=A0 =C2=A0indicates that some RTM nodes along the LSP could be included = in the
=C2=A0 =C2=A0calculation of the residence time.=C2=A0 An ingress node MAY c= hoose to
=C2=A0 =C2=A0resignal the LSP to include all RTM nodes or simply notify the= user
=C2=A0 =C2=A0via a management interface.

Is that supposed to be "included" or "excluded"?=C2=A0 = My reading of the
previous paragraph was that the I bit would be set when a node
failed to compute the next RTM-capable node along the path, and of
course, we expect normal operation to include the residence time for
all RTM-capable nodes, so signalling potential inclusion is odd.
GIM>> I think that I've missed 'not' in that s= entence. So it should be=C2=A0
Presence of the RTM_SET TLV with I= bit field set to 1
=C2=A0 =C2=A0indicates that some RTM nodes along the= LSP could not be included in the
=C2=A0 =C2=A0calculation of the= residence time.
I've made the change in -15. Would you a= gree that it makes text logical?


I'll close off this review by noting that sections 4.3 through 4.6
seem to all talk about how to use other protocols to indicate that
RTM may be used and could perhaps be grouped into an intermediate
subsection,
GIM>> Would sub-section with title be a= cceptable?
RTM Capability Advertisement in Routing Protocols
=C2=A0
wonderi= ng whether the "Type" and "Length" fields in
Figure 2 are the same octets of the packet as in Figure 1,
GIM>> Yes indeed. Figure 1 displays generic TLV while Figure 2 disp= lays particular TLV, PTP.=C2=A0
and
repeating my as-yet unfulfilled intention to send further minor
editorial patches to the authors.=C2=A0

-Ben

--001a1134fd38e918700549b8db80-- From nobody Thu Mar 2 02:24:38 2017 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 4A297129473 for ; Thu, 2 Mar 2017 02:24:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148845027725.29174.13568835303909825039.idtracker@ietfa.amsl.com> Date: Thu, 02 Mar 2017 02:24:37 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 10:24:37 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-03-02 Reviewer LC end Draft Alan DeKok 2017-02-15 draft-bradner-rfc3979bis-12 Klaas Wierenga 2017-02-10 draft-ietf-dmm-hnprenum-06 For telechat 2017-03-16 Reviewer LC end Draft John Bradley 2017-03-13 draft-mm-wg-effect-encrypt-07 Alan DeKok 2017-03-10 draft-bchv-rfc6890bis-04 Shawn Emery 2017-03-01 draft-ietf-pce-inter-layer-ext-12 Daniel Franke 2017-02-28 draft-ietf-pce-stateful-sync-optimizations-09 Daniel Gillmor 2017-02-28 draft-ietf-pce-stateful-pce-18 Ólafur Guðmundsson 2017-02-27 draft-ietf-dime-load-07 Dan Harkins None draft-ietf-rtcweb-overview-17 Christian Huitema 2017-03-15 draft-ietf-ipsecme-rfc7321bis-05 Leif Johansson 2017-03-08 draft-ietf-lmap-information-model-17 Benjamin Kaduk 2017-03-07 draft-ietf-jsonbis-rfc7159bis-03 Scott Kelly 2017-03-03 draft-ietf-tls-rfc4492bis-12 Watson Ladd 2017-03-03 draft-ietf-dane-smime-15 For telechat 2017-04-13 Reviewer LC end Draft Phillip Hallam-Baker 2017-02-24 draft-ietf-dmm-lma-controlled-mag-params-03 Matthew Miller 2017-03-10 draft-ietf-bess-evpn-vpws-10 Last calls: Reviewer LC end Draft Derek Atkins None draft-ietf-i2nsf-problem-and-use-cases-09 Ben Laurie 2017-03-02 draft-ietf-dprive-dtls-and-tls-profiles-08 Barry Leiba 2017-03-02 draft-ietf-anima-grasp-09 Chris Lonvick 2017-03-15 draft-ietf-ippm-twamp-time-format-02 David Mandelberg 2017-03-14 draft-ietf-ippm-model-based-metrics-10 Catherine Meadows 2017-03-13 draft-ietf-dhc-relay-server-security-03 Yaron Sheffer 2017-03-01 draft-ietf-6man-rfc2460bis-08 Tom Yu 2017-02-20 draft-ietf-slim-negotiating-human-language-08 Early review requests: Reviewer Due Draft Daniel Gillmor 2016-02-01 draft-ietf-rtcweb-security-08 Brian Weis 2016-02-01 draft-ietf-cdni-uri-signing-10 Next in the reviewer rotation: Adam Montville Russ Mundy Sandra Murphy Yoav Nir Magnus Nystrom Hilarie Orman Radia Perlman Vincent Roca Joseph Salowey Rich Salz From nobody Thu Mar 2 07:52:41 2017 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 42C7C129517; Thu, 2 Mar 2017 07:52:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MqSUpC17VTMR; Thu, 2 Mar 2017 07:52:35 -0800 (PST) Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (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 16C911294C3; Thu, 2 Mar 2017 07:52:35 -0800 (PST) X-AuditID: c6180641-c53ff70000000a06-88-58b7f96a6173 Received: from EUSAAHC008.ericsson.se (Unknown_Domain [147.117.188.96]) by (Symantec Mail Security) with SMTP id AA.43.02566.A69F7B85; Thu, 2 Mar 2017 11:52:29 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC008.ericsson.se ([147.117.188.96]) with mapi id 14.03.0319.002; Thu, 2 Mar 2017 10:52:31 -0500 From: Daniel Migault To: Melinda Shore , "secdir@ietf.org" , "iesg@ietf.org" , "draft-sgtatham-secsh-iutf8.all@ietf.org" Thread-Topic: SECDIR review of draft-sgtatham-secsh-iutf8 Thread-Index: AQHSkG+rShKU9B7xMUeeLbjvAAWf2qGBuMCQ Date: Thu, 2 Mar 2017 15:52:30 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C11801C243@eusaamb107.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBLMWRmVeSWpSXmKPExsUyuXRPgm7uz+0RBhMWqlqcv7uAzWLGn4nM Fm1ts1gsPix8yOLA4rFz1l12jyVLfjIFMEVx2aSk5mSWpRbp2yVwZSycfZet4BpPxfI1p1gb GNfwdDFyckgImEgsf3eMFcQWEljPKNG6QxPCXsYocWm+NojNJmAk0Xaon72LkYtDROAMo8Sx 7Z9ZQBLCAhYSy09NYgKxRQQsJfY9PgVkcwDZRhLn34L1sgioSEybsocNJMwr4CuxZpociCkk YCPxcZk3SAWngK3EkovPwC5gFBCT+H5qDdhAZgFxiVtP5jNBXCkgsWTPeWYIW1Ti5eN/rBC2 ksSkpedYQUYyC2hKrN+lD9GqKDGl+yE7iM0rIChxcuYTlgmMIrOQTJ2F0DELSccsJB0LGFlW MXKUFhfk5KYbGW5iBIb/MQk2xx2Me3s9DzEKcDAq8fB+eLgtQog1say4MvcQowQHs5IIr5zI jggh3pTEyqrUovz4otKc1OJDjNIcLErivNdD7ocLCaQnlqRmp6YWpBbBZJk4OKUaGDl7Lr86 +DpPpbnTwE7yuQ8T97wgngsLD/OZqsqIdtbrP+BwDvpwQ0kyb0+CqUIs1+qvDL4fyy3qL57P binimxUb7COjqXjXQv7PnRurNu9R11F9VK4gMb02eIX9Q/Hbr29fTN1Wn2FQHjDJzFr5c3lb 7HLxpkfM0e8KZq278Ddfb0+YwoZvSizFGYmGWsxFxYkAXfCuwHsCAAA= Archived-At: Subject: Re: [secdir] SECDIR review of draft-sgtatham-secsh-iutf8 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 15:52:36 -0000 SGkgTWVsaW5kYSwgDQoNClRoYW5rIHlvdSBmb3IgcmV2aWV3aW5nIHRoZSBkcmFmdC4gV2Ugd2ls bCBtYWtlIGFwcGVhciB0aGUgcmVmZXJlbmNlIGluIHRoZSB0ZXh0LiANCg0KWW91cnMsIA0KRGFu aWVsDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNZWxpbmRhIFNob3JlIFtt YWlsdG86bWVsaW5kYS5zaG9yZUBnbWFpbC5jb21dIA0KU2VudDogU3VuZGF5LCBGZWJydWFyeSAy NiwgMjAxNyAzOjM0IFBNDQpUbzogc2VjZGlyQGlldGYub3JnOyBpZXNnQGlldGYub3JnOyBkcmFm dC1zZ3RhdGhhbS1zZWNzaC1pdXRmOC5hbGxAaWV0Zi5vcmcNClN1YmplY3Q6IFNFQ0RJUiByZXZp ZXcgb2YgZHJhZnQtc2d0YXRoYW0tc2Vjc2gtaXV0ZjgNCg0KSSBoYXZlIHJldmlld2VkIHRoaXMg ZG9jdW1lbnQgYXMgcGFydCBvZiB0aGUgc2VjdXJpdHkgZGlyZWN0b3JhdGUncyBvbmdvaW5nIGVm Zm9ydCB0byByZXZpZXcgYWxsIElFVEYgZG9jdW1lbnRzIGJlaW5nIHByb2Nlc3NlZCBieSB0aGUg SUVTRy4gIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5l Zml0IG9mIHRoZSBzZWN1cml0eSBhcmVhIGRpcmVjdG9ycy4gIERvY3VtZW50IGVkaXRvcnMgYW5k IFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhl ciBsYXN0IGNhbGwgY29tbWVudHMuDQoNClN1bW1hcnk6IHJlYWR5IHdpdGggc29tZSBpbmNyZWRp Ymx5IG1pbm9yIG5pdHMNCg0KVGhpcyBkb2N1bWVudCBhZGRzIGEgbmV3IG9wY29kZSB0byBzc2gg dGVybWluYWwgbW9kZXMsIHRvIG1hdGNoIHRoZSBpdXRmOCBmbGFnIGluIHRoZSBMaW51eCB0ZXJt aW5hbCBkcml2ZXIuICBUaGlzIGRyYWZ0IGhhcyBiZWVuIGltcGxlbWVudGVkIGluIG9wZW5zc2gg YW5kIHB1dHR5LiAgVGhlcmUgYXJlIG5vIGFkZGl0aW9uYWwgc2VjdXJpdHkgY29uY2VybnMgaW50 cm9kdWNlZCBieSB0aGlzIGRyYWZ0IGJleW9uZCB0aG9zZSBhbHJlYWR5IGRvY3VtZW50ZWQgaW4g UkZDIDQyNTQuDQoNClRoZSBuaXRzIGNoZWNrZXIgZGlkbid0IGxpa2UgdGhlIHNwYWNpbmcgaW4g dGhlIHRhYmxlIGluIHNlY3Rpb24gNC4gIFRoZXJlJ3MgYW4gdW51c2VkIHJlZmVyZW5jZSAoVU5J Q09ERSkuICBPdGhlcndpc2UgaXQncyBjbGVhbi4NCg0KTWVsaW5kYQ0KDQo= From nobody Thu Mar 2 14:49:12 2017 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 7564D128874; Thu, 2 Mar 2017 14:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 YhzqPlgZ8yYC; Thu, 2 Mar 2017 14:49:10 -0800 (PST) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A989127601; Thu, 2 Mar 2017 14:49:10 -0800 (PST) Received: by mail-it0-x231.google.com with SMTP id h10so2867792ith.1; Thu, 02 Mar 2017 14:49:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8ksP5qmfS93SQlu/z+M7uPet7APj5+aKkSV7tJKI3A8=; b=qxB9WRmnfYrI5JvjZNv49hTzhAstzzFSy2TdJ7PposkPB60INcOfwtnlbrw08xevzM d82oZpOgjs7LG5/+jO/MtM25LtOGGushEcmxDSv37TAnq+kZTOeRJa9ywFP7x/E2LKV6 s06QtWLYtiICv6ISFeKbJVZ4NY84a24ZEu4X0YH9S6V9U2YfW6YRhlddO+joeq4loSq7 3E5U5KSqTOPsDo1r5Eh2ZfC22SIm6nV7HpvbZFyjqDzVkd9yfgHs1qTahMOFQmNZncFw l9S/8A1/W1qghiIKALaEZnBxSzPHndAYJHOk4eXvRzqbw4lxUrFSn8e/qHRT2ot8DekJ +yRA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8ksP5qmfS93SQlu/z+M7uPet7APj5+aKkSV7tJKI3A8=; b=erY/pFqmbkQgr6XBXUtI6E2GvnKbaMo0lj1n55Ike1unSBFyqAbe682FXmjNk8l602 AU2dCSqcl6phnXrgwWjV5kfsJkURKslESyNviq0sGY9lrIQt6BjCk2XKTXmDaYMKyFsw /8Tm4pWbfg72fEfjE+NpaX8gZ597RN7nTygcPvF/VB4eFkIDuYc3UpPv8My/MVjxzBpf fjWN2zvE59MmZiQXoreMHkYjz4HvEJbPPmJkmB5cyJhYj1qspex9b5a/podJkjiYtNPW Ms8qWlynops9vlZey6e9Npxc4ltSXCwai7J4XQNdUcp4fEGsd6vxQeLJLsP/zUtrypru FG5w== X-Gm-Message-State: AMke39m+dHYKdakaHNubwGfu3aogNIA84jcqypnX0WxC4gpWT9ltY6DHDWH/NaUyIsbcO65sw0DKvwRmL9xJmw== X-Received: by 10.36.3.73 with SMTP id e70mr195904ite.14.1488494949403; Thu, 02 Mar 2017 14:49:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.135.215 with HTTP; Thu, 2 Mar 2017 14:48:53 -0800 (PST) In-Reply-To: References: From: Donald Eastlake Date: Thu, 2 Mar 2017 17:48:53 -0500 Message-ID: To: Daniel Franke Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-trill-directory-assist-mechanisms-all@tools.ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-trill-directory-assist-mechanisms X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 22:49:11 -0000 Hi Daniel, Thanks for your comments. See below. On Tue, Jan 17, 2017 at 12:52 PM, Daniel Franke wrote: > 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 this document is READY WITH NITS. I'm satisfied with its > normative content but the Security Considerations section could use > a bit of elaboration. OK. > I had never heard of TRILL prior to being assigned this review and > the tree of normative references is a bit daunting, so these comments > will necessarily be based only on an extremely high-level view of > the system. > > draft-ietf-trill-directory-assist-mechanisms proposes to augment > TRILL by adding directory servers which cache information about network > topology, allowing RBridges to sometimes shortcut the usual learning > algorithm that they would use to discover this information. > > Here are the fundamental points which the Security Considerations > section either addresses or ought to address: > > 1. There are three relevant security goals: > > a. Availability: packets should reach their intended destination > > b. Confidentiality: packets should not reach unintended destinations > > c. Privacy: metadata concerning network presence should not be > shared more widely than necessary > > 2. Access control to directory servers can be enforced using > pre-existing cryptographic mechanisms specified in RFCs 5304, 5310, > and 7978. Well, actually access to directory server messages. > 3. Principals authorized (duly or otherwise) to read directory data > can violate privacy. OK. > 4. Principals authorized to modify directory data can violate > availability and confidentiality. OK. > 5. Directory servers must therefore take care to implement and enforce > access control policies which are not overly permissive. > > The current text of the Security Considerations section directly > addresses points 1a, 1b, 2, and 4. The paragraph added in version 11 of > the draft obliquely implies points 1c and 3 but I wish they'd be > stated more explicitly. But the major omission is point 5: what does > a correct authorization predicate look like? What sort of access must > necessarily be authorized in order for protocol execution to succeed? > What sort of access generally ought *not* be authorized? The -12 version just posted is intended to resolve these comments. Thanks, Donald =============================== Donald E. Eastlake 3rd +1-508-333-2270 (cell) 155 Beaver Street, Milford, MA 01757 USA d3e3e3@gmail.com From nobody Thu Mar 2 14:57:25 2017 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 C8FC412941A; Thu, 2 Mar 2017 14:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.45 X-Spam-Level: X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 qRo-itwZKwuk; Thu, 2 Mar 2017 14:57:20 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 5B54E128B37; Thu, 2 Mar 2017 14:57:17 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id 90so64105100ios.1; Thu, 02 Mar 2017 14:57:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kPZZcbFfA5OPOx8ASN1wx7/bhSoNsLnEXnXNl9bE3os=; b=tGU79NZrEd3QQF51CwLfwCs5F7QZ3M277qR7vQzfRj8gA8SD6msUOW+YTLcl6643On nAb7SrIyW3iIEqBfEG3NZek324wHHHKNJyCwI45oQzysiRuEfYoA/TqJLHsJXP53UPbI fdvbQp6DsSy6gxTeSD8nU8iUFq9yjEITzlIb1Y1T2L5Vx8zPk/wYJHiajS9PL6hotgBE MseDR5ELSnnyPZoax8ug/9faLzoV7nSGXV82L97TSpvuqoa6GsdxvjM4pdZBD+2PWSVO +1589nbRJTmJA5dRYEPjfsShH3n3Us1f7Qa9FQBwuRa/92SoRnrWZpsJfJsgespl0prg PiXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kPZZcbFfA5OPOx8ASN1wx7/bhSoNsLnEXnXNl9bE3os=; b=FuGspYmt7eln/MkVzR3JjlgiN0+U3kbn+llMfWe7W/XpvZzq5wZVqUpdWJgXcgJysm sj3RCWYi0FNtOqjFWeO4brPJGirVL1KxgcrdyLQhI9Fy2mncj9bxJcXnQYjvupxymRjx cCpRZLXFy0vxKMLbr7Zxp2zAQIeMKUZ0HL4aVPIhgF1ZGmfG1MQXrXhoAJvGsthYyQ5o sFCricuVhKyyckgZmy1sL6dmgPUPU1SJaI8RWZFxulOdx3OYVq39ha917BmYj5BJ9cOd VuVU25t5mAR32yw5zyD0AEeCwEqtclHAB7GylNQlIFV9ovhBGfzcCdta3W+dG9u3uRD4 /m8g== X-Gm-Message-State: AMke39nH78tkjVT0ZLyLWjCjxRCe7tRM2rIzIjOz5yrsfKVHby2RZuZFddFvGPJhucBW8WcRacPeJ10sDJbKmg== X-Received: by 10.107.20.148 with SMTP id 142mr222682iou.12.1488495436665; Thu, 02 Mar 2017 14:57:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.135.215 with HTTP; Thu, 2 Mar 2017 14:57:01 -0800 (PST) In-Reply-To: References: From: Donald Eastlake Date: Thu, 2 Mar 2017 17:57:01 -0500 Message-ID: To: Daniel Franke Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-trill-directory-assist-mechanisms.all@ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-trill-directory-assist-mechanisms X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Mar 2017 22:57:22 -0000 Resending with draft-ietf-trill-directory-assist-mechanisms-all@tools.ietf.org replaced with draft-ietf-trill-directory-assist-mechanisms.all@ietf.org. On Thu, Mar 2, 2017 at 5:48 PM, Donald Eastlake wrote: > Hi Daniel, > > Thanks for your comments. See below. > > On Tue, Jan 17, 2017 at 12:52 PM, Daniel Franke wrote: >> 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 this document is READY WITH NITS. I'm satisfied with its >> normative content but the Security Considerations section could use >> a bit of elaboration. > > OK. > >> I had never heard of TRILL prior to being assigned this review and >> the tree of normative references is a bit daunting, so these comments >> will necessarily be based only on an extremely high-level view of >> the system. >> >> draft-ietf-trill-directory-assist-mechanisms proposes to augment >> TRILL by adding directory servers which cache information about network >> topology, allowing RBridges to sometimes shortcut the usual learning >> algorithm that they would use to discover this information. >> >> Here are the fundamental points which the Security Considerations >> section either addresses or ought to address: >> >> 1. There are three relevant security goals: >> >> a. Availability: packets should reach their intended destination >> >> b. Confidentiality: packets should not reach unintended destinations >> >> c. Privacy: metadata concerning network presence should not be >> shared more widely than necessary >> >> 2. Access control to directory servers can be enforced using >> pre-existing cryptographic mechanisms specified in RFCs 5304, 5310, >> and 7978. > > Well, actually access to directory server messages. > >> 3. Principals authorized (duly or otherwise) to read directory data >> can violate privacy. > > OK. > >> 4. Principals authorized to modify directory data can violate >> availability and confidentiality. > > OK. > >> 5. Directory servers must therefore take care to implement and enforce >> access control policies which are not overly permissive. >> >> The current text of the Security Considerations section directly >> addresses points 1a, 1b, 2, and 4. The paragraph added in version 11 of >> the draft obliquely implies points 1c and 3 but I wish they'd be >> stated more explicitly. But the major omission is point 5: what does >> a correct authorization predicate look like? What sort of access must >> necessarily be authorized in order for protocol execution to succeed? >> What sort of access generally ought *not* be authorized? > > The -12 version just posted is intended to resolve these comments. > > Thanks, > Donald > =============================== > Donald E. Eastlake 3rd +1-508-333-2270 (cell) > 155 Beaver Street, Milford, MA 01757 USA > d3e3e3@gmail.com From nobody Thu Mar 2 17:44:20 2017 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 B7C47129478; Thu, 2 Mar 2017 17:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 Kfu3Lb9TEjr7; Thu, 2 Mar 2017 17:44:14 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 806C71279EB; Thu, 2 Mar 2017 17:44:14 -0800 (PST) X-AuditID: 1209190d-61fff70000007a3a-cc-58b8ca6ca9f8 Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 6E.9F.31290.C6AC8B85; Thu, 2 Mar 2017 20:44:12 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v231iBKa008356; Thu, 2 Mar 2017 20:44:11 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v231i6ZY026556 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 2 Mar 2017 20:44:09 -0500 Date: Thu, 2 Mar 2017 19:44:06 -0600 From: Benjamin Kaduk To: Greg Mirsky Message-ID: <20170303014406.GL30306@kduck.kaduk.org> References: <20170301222133.GH30306@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrCIsWRmVeSWpSXmKPExsUixCmqrJtzakeEwd/5uhbf/+1jt/g27Smr xYw/E5ktPix8yOLA4rFz1l12jyVLfjIFMEVx2aSk5mSWpRbp2yVwZbSemsFUcF2o4uAS0wbG 1XxdjJwcEgImEnMmXmfqYuTiEBJoY5J49G8qlLOBUeJ190lGCOcKk8TV+Z+YQVpYBFQkdt+a zwRiswHZDd2XweIiAuoSnduOs4PYzAJZEufvdbOA2MICThKPfqxjBbF5gdZdePKADcQWEqiW 6Pu9jwUiLihxcuYTFoheLYkb/14CzecAsqUllv/jAAlzCgRKbDlzAaxVVEBZomHGA+YJjAKz kHTPQtI9C6F7ASPzKkbZlNwq3dzEzJzi1GTd4uTEvLzUIl0jvdzMEr3UlNJNjODAleTdwfjv rtchRgEORiUeXg37HRFCrIllxZW5hxglOZiURHmzTwCF+JLyUyozEosz4otKc1KLDzFKcDAr ifCm7QXK8aYkVlalFuXDpKQ5WJTEecU1GiOEBNITS1KzU1MLUotgsjIcHEoSvD0ngRoFi1LT UyvSMnNKENJMHJwgw3mAhrOfAhleXJCYW5yZDpE/xagoJc67D6RZACSRUZoH1wtKLBLZ+2te MYoDvSLM2wxSxQNMSnDdr4AGMwENfqGyFWRwSSJCSqqBUT933gr53Tc1fOUs958LmxltZp2o 6Nz2saKRd6XJwfoVut0bLt2du0dKWV+kMHJLesXa7r6/06aGL5BMfcqf4Vu14P28txeWxO1S LtzpttXmn7zZrsNNq9v9d7zd5dfleX69YLDgpUTXbwFbpOwd9XQvaPMXXKxQ3lG29mWOfQSP TMHposkPlFiKMxINtZiLihMByYyJQAcDAAA= Archived-At: Cc: draft-ietf-mpls-residence-time.all@ietf.org, "iesg@ietf.org" , secdir@ietf.org Subject: Re: [secdir] secdir re-review of draft-ietf-mpls-residence-time-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Mar 2017 01:44:15 -0000 On Wed, Mar 01, 2017 at 09:39:55PM -0800, Greg Mirsky wrote: > Hi Ben, > sincerely appreciate your thorough review and the most helpful comments. > Please fine my answers in-line and tagged GIM>>. > > Regards, > Greg > > On Wed, Mar 1, 2017 at 2:21 PM, Benjamin Kaduk wrote: > > > > > On page 16, second paragraph: > > > > The ingress node MAY inspect the I bit flag received in each RTM_SET > > TLV contained in the LSP_ATTRIBUTES object of a received Resv > > message. Presence of the RTM_SET TLV with I bit field set to 1 > > indicates that some RTM nodes along the LSP could be included in the > > calculation of the residence time. An ingress node MAY choose to > > resignal the LSP to include all RTM nodes or simply notify the user > > via a management interface. > > > > Is that supposed to be "included" or "excluded"? My reading of the > > previous paragraph was that the I bit would be set when a node > > failed to compute the next RTM-capable node along the path, and of > > course, we expect normal operation to include the residence time for > > all RTM-capable nodes, so signalling potential inclusion is odd. > > > GIM>> I think that I've missed 'not' in that sentence. So it should be > Presence of the RTM_SET TLV with I bit field set to 1 > indicates that some RTM nodes along the LSP could *not *be included in > the > calculation of the residence time. > I've made the change in -15. Would you agree that it makes text logical? Yes, that seems much more logical. > > > > > > I'll close off this review by noting that sections 4.3 through 4.6 > > seem to all talk about how to use other protocols to indicate that > > RTM may be used and could perhaps be grouped into an intermediate > > subsection, > > GIM>> Would sub-section with title be acceptable? > RTM Capability Advertisement in Routing Protocols Yes, that sounds good. > > > wondering whether the "Type" and "Length" fields in > > Figure 2 are the same octets of the packet as in Figure 1, > > GIM>> Yes indeed. Figure 1 displays generic TLV while Figure 2 displays > particular TLV, PTP. Ah, good to have that confirmed. > > and > > repeating my as-yet unfulfilled intention to send further minor > > editorial patches to the authors. (I am about halfway through typing them up.) -Ben From nobody Fri Mar 3 22:15:08 2017 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 E6C31129470 for ; Fri, 3 Mar 2017 22:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 y-qaLHr5ETqq for ; Fri, 3 Mar 2017 22:15:05 -0800 (PST) Received: from mail-ot0-x22b.google.com (mail-ot0-x22b.google.com [IPv6:2607:f8b0:4003:c0f::22b]) (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 719AC1293EB for ; Fri, 3 Mar 2017 22:15:05 -0800 (PST) Received: by mail-ot0-x22b.google.com with SMTP id o24so22010157otb.1 for ; Fri, 03 Mar 2017 22:15:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=wK8xwHQhSj4QNCEnPVyv+CVbveboC2Ievs8s6mczeG0=; b=mAN+sHUF5HeaelBnvRzYFdcA7lIQz26HOjI9N5EjmDLlfMo9Wok4bPWuow/2w/kBhp d0R+xHsIU0lRDj8UBWPP9mHderKiq9hoyl8z2mYDVagnLups02hCUW15ysmb20xxj6Y7 mp7ZhJWvf7r7qdnqjBg/sRS0HLhelxPw9eNDICSQLjuAXW2JmcygTxBZERYM6MV/z6bm fWKj2vVvkIsU41gp8RAAGBlOAH5GE3lf+/RHlyQN1/mTFpZ5+J+dkhp+ZnawntjvsM9V YuLjdCsT2Fm2hxJKCrAFxKoPRBIBZgYenjNgauIexjLmf3Vy+/wCTZe74Hj+wUXmldyb eXjw== 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:cc; bh=wK8xwHQhSj4QNCEnPVyv+CVbveboC2Ievs8s6mczeG0=; b=rQvdofl0PYzwqgdjJcVTapFAlIROZhGlXA8p6G9bec8SqyEz0P/m4TGmcRNtV+qLCq a+pWV61c5qFS5fVzLtqV6XJYeHzwi8uRUX+DSy2E00doIVXjOSP14qhyu4oSCxes4UAN KmluoJx6ejf8PAjbtp41WGSIstbKI+k71X18Zco79s5b0UBoPE9bVsZmPCaC66yL9eFN Zjf4vOBchow/069PIvmwY7rJ0GQvyRraXK4JbzI2+nYCuOFUzu0LhVqD5O/xfRjAaSy3 UryXYdXfqt5vKJeva0UioYQqADaNk8ZCEF0rh5fQZ7MYM9CvEckYJWn7c4HcOzNq30Uu RUXg== X-Gm-Message-State: AMke39n0TmGn3207ub+y1TsI54IcLBBvx039h1+2UtPLLBZUzA9kYyJLV2AOb/vX5FA4YC19MJiDc1gyE+Y8HQ== X-Received: by 10.157.35.230 with SMTP id t93mr2609121otb.109.1488608104730; Fri, 03 Mar 2017 22:15:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.45.118 with HTTP; Fri, 3 Mar 2017 22:15:04 -0800 (PST) From: Shawn Emery Date: Fri, 3 Mar 2017 23:15:04 -0700 Message-ID: To: secdir@ietf.org Content-Type: multipart/alternative; boundary=001a114932664ad9040549e195a9 Archived-At: Cc: draft-ietf-pce-inter-layer-ext.all@tools.ietf.org Subject: [secdir] Review of draft-ietf-pce-inter-layer-ext-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Mar 2017 06:15:07 -0000 --001a114932664ad9040549e195a9 Content-Type: text/plain; charset=UTF-8 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft discusses extensions to the Path Computation Element communication Protocol (PCEP) that allows network path information to passed through multiple technology layers. This data can be used to optimize network utilization by accounting for all of the layers in the stack instead of individual characteristics. The security considerations section does exist and states that controlling networks from inter-layer information does present security threats. The section goes on to state that a security threat is also introduced if a PCE is given full visibility of multi-layer traffic engineering information. Could you please expand on the threat specifically with visibility? To mitigate against such attacks the draft suggests the usage of the Path-Key-based (of no relation to a cryptographic key) mechanism, as described in RFC 5520. I agree with this assertion, or at least with the first threat outlined. General comments: None. Editorial comments: None. Thanks! Shawn. -- --001a114932664ad9040549e195a9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed this docu= ment as part of the security directorate's
ongoing effort to review all IETF= documents being processed by the IESG.
These comments were written primarily fo= r the benefit of the security
area directors. Document editors and WG chairs sho= uld treat these
comments just like any other last call comments.
=
This draft discusses extensions to the Path Computation Elemen= t communication Protocol (PCEP) that allows network path information to pas= sed through multiple technology layers.=C2=A0 This data can be used to opti= mize network utilization by accounting for all of the layers in the stack i= nstead of individual characteristics.

The sec= urity considerations section does exist and states that controlling=C2=A0ne= tworks from inter-layer information does present security threats.=C2=A0 Th= e section goes on to state that a security threat is also introduced if a P= CE is given full visibility of multi-layer traffic engineering information.= =C2=A0 Could you please expand on the threat specifically with visibility? = =C2=A0To mitigate against such atta= cks the draft suggests the usage of the=C2=A0Path-Key-based (of no relation to a cryptogra= phic key) mechanism, as described in RFC 5520.=C2=A0 I agree with this asse= rtion, or at least with the first threat outlined.

General comments:

N= one.

Editorial comments:

None.=C2=A0 Thanks!

Shawn.
--
--001a114932664ad9040549e195a9-- From nobody Mon Mar 6 08:39:41 2017 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 DCE9312986C; Mon, 6 Mar 2017 08:39:39 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Matthew Miller To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148881837990.15039.4330298821291699213.idtracker@ietfa.amsl.com> Date: Mon, 06 Mar 2017 08:39:39 -0800 Archived-At: Cc: ietf@ietf.org, draft-harkins-owe.all@ietf.org Subject: [secdir] Review of draft-harkins-owe-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 16:39:40 -0000 Reviewer: Matthew Miller Review result: Has Nits [ re-posting old review to get it onto the mailing list archives; some bugs prevented it the first time ] 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. Document: draft-harkins-owe-05 Reviewer: Matthew A. Miller Review Date: 2016-01-13 IETF LC End Date: 2016-01-13 IESG Telechat date: N/A Summary: This document describes an extension to 802.11 to perform opportunistic unauthenticated encryption of wireless connections. This document is ready, but has nits that ought to be addressed before publication. Major issues: NONE Minor issues: In Section 4.3 "OWE Association", the fifth paragraph states that a client "MUST include a Diffie-Hellman Parameter element ...", yet further in the the same paragraph it states that if PMK Caching is not performed, then the same element MUST be included. This seems redundant, or that there are cases where OWE can be used but the Diffie-Hellman Parameter element is not required. This might be more obvious to one that has read the 802.11 suite (which I admittedly have not), but I think it would be beneficial if this document could better clarify when the Diffie-Hellman Element parameter is needed. For instance, if it is always expected to be present whenever OWE is desired, then removing the following sentence would help: """ If "PMK caching" (see Section 4.5) is not performed, it MUST also include a Diffie-Hellman Parameter element. """ Nits/editorial comments: * Throughout, the spacing of "--" is consistent, but not expected; there is never a leading space but there is always a trailing space. * In Section 3. "802.11 Network Access", a quote is missing after Open Authentication. From nobody Mon Mar 6 08:41:20 2017 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 C51881298A5; Mon, 6 Mar 2017 08:41:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Matthew Miller To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148881846080.15058.7367435968376657921.idtracker@ietfa.amsl.com> Date: Mon, 06 Mar 2017 08:41:00 -0800 Archived-At: Cc: draft-ietf-sidr-rpki-rtr-rfc6810-bis.all@ietf.org, ietf@ietf.org, sidr@ietf.org Subject: [secdir] Review of draft-ietf-sidr-rpki-rtr-rfc6810-bis-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Mar 2017 16:41:01 -0000 Reviewer: Matthew Miller Review result: Has Nits [ re-posting old review to get it onto the mailing list archives; some bugs prevented it the first time ] 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. Document: Reviewer: Matthew A. Miller Review Date: 2017-02-14 IETF LC End Date: 2017-01-30 IESG Telechat date: 2017-02-16 Summary: This document is ready for publication as a Proposed Standard, but has a minor concern that should be addressed. This document describes a protocol for distributing RPKI information to routers from trusted caches. Major issues: NONE Minor issues: * In Section 5.1. "Fields of a PDU", for the Flags: definition, it states that: """ The remaining bits in the flags field are reserved for future use. In protocol version 1, they MUST be 0 on transmission and SHOULD be ignored on receipt. """ However, this seems backwards to me. Would it seem safer that the reserved flags "MUST be ignored on receipt". Nits/editorial comments: NONE From nobody Tue Mar 7 09:34:29 2017 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 8913B1295C8; Tue, 7 Mar 2017 09:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 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_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=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 86ciFKZZDXNT; Tue, 7 Mar 2017 09:34:26 -0800 (PST) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF8441295D5; Tue, 7 Mar 2017 09:34:26 -0800 (PST) Received: by mail-oi0-x22e.google.com with SMTP id 126so5398350oig.3; Tue, 07 Mar 2017 09:34:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mfS3EK+Hyl81XzCkvIwECThSQ/IVI5phyx+1KXhCZWs=; b=q0EU9TWn7UInuAVSoFntHEwN9oN5MY631p3Ia9EHPw/Ha9KD/Y3WiD+aHB/9rsw78P QYPm1uI3Vswx7aUSs+W1/lYNkT2BFP36xedJBwCFzHQd56ZXCvr9+dCrdTe9mPFMjb1m HXCPwGOiXAZD8YEq2SPl+JxaeEczWD78g3RkKhWUUgRXwpxyb0bGMdfowPe5434oCVgO RFHffcBEs5q0Y4CU0U5lrJUnHCLUR9QX9q+vNmSdeUlWuaDRHPh4L+E0dB+kW3dgXRnP 1Sk/DzemLK4I92cL1NDwgoCVI8mH+JpHwOvFjP3SplRrKU45wISsldct0ZgCxD5dn4ew M0Bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mfS3EK+Hyl81XzCkvIwECThSQ/IVI5phyx+1KXhCZWs=; b=CeAlgCh+T+RvgBAqyiGgmL7aZGhVavGjN4DNpXzGhnUoIYu08PhCFfe8MLAqVI9+dc NvFZ2NoExgZ4xrI6OtvkL35DH477JMNPdm2LD7P7LCRJ8m9g3wIqwOJb5aJpqeeBeTM8 L6UbtRPXkDX3xsyRxLPOF0JYCMriHpY2XTNP9v8huk46WzG0rdosjHK2srnklbaS2/sl 4b8AMgd9lYCpWZ3G0XgVtqF8raYo85vmMvwhvXYNZn4ZwHYQ1JO+qmvwlrhiA0JIGvtu c6f54H/qenSorVo+7uQcLDjNkOiSR7iX2Dxvn34MFV5sMPw4wFoFBUu1WJttj0JnWmZD eHyg== X-Gm-Message-State: AMke39n4EqTudhrlWG0+wr1PG0oWVgd9+a06PL6gXRvUtM7WekMr69lZtgUMYSFI2R4GL60tHk/wZYUFTHRunw== X-Received: by 10.202.79.13 with SMTP id d13mr881096oib.167.1488908066092; Tue, 07 Mar 2017 09:34:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.21.21 with HTTP; Tue, 7 Mar 2017 09:34:25 -0800 (PST) In-Reply-To: <20170301222133.GH30306@kduck.kaduk.org> References: <20170301222133.GH30306@kduck.kaduk.org> From: Greg Mirsky Date: Tue, 7 Mar 2017 09:34:25 -0800 Message-ID: To: Benjamin Kaduk Content-Type: multipart/alternative; boundary=001a113d80986218fb054a276c61 Archived-At: Cc: draft-ietf-mpls-residence-time.all@ietf.org, "iesg@ietf.org" , secdir@ietf.org Subject: Re: [secdir] secdir re-review of draft-ietf-mpls-residence-time-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Mar 2017 17:34:28 -0000 --001a113d80986218fb054a276c61 Content-Type: text/plain; charset=UTF-8 Hi Ben, et.al, many thanks for your the most thorough review, helpful comments and patience. I've uploaded the new version of the draft that includes all changes we've discussed and your editorial recommendations. Hope I haven't missed any of them. Regards, Greg On Wed, Mar 1, 2017 at 2:21 PM, Benjamin Kaduk wrote: > I previously reviewed the -12 > (https://www.ietf.org/mail-archive/web/secdir/current/msg07110.html); > the -14 seems much improved. On this re-read, I have a better sense > of how the various TLVs and sub-TLVs fit together to achieve the > goal of having the RTM-capable nodes identify each other and > collaborate to account for residence time when processing timing > packets. > > I have no security concerns with the document, as the updated > security considerations address the concerns previously raised. > > However, there are a couple of issues that should probably block > publication (but ought to be easy to resolve): > > Figure 7 appears to only be 31 bits wide, not 32 -- 'Type' is 7 > bits, 'Length' 8, 'I' 1, and 'Reserved' 15. Presumably Type is > intended to be the full 8 bits, given the assigned values in the > registry. > > On page 16, second paragraph: > > The ingress node MAY inspect the I bit flag received in each RTM_SET > TLV contained in the LSP_ATTRIBUTES object of a received Resv > message. Presence of the RTM_SET TLV with I bit field set to 1 > indicates that some RTM nodes along the LSP could be included in the > calculation of the residence time. An ingress node MAY choose to > resignal the LSP to include all RTM nodes or simply notify the user > via a management interface. > > Is that supposed to be "included" or "excluded"? My reading of the > previous paragraph was that the I bit would be set when a node > failed to compute the next RTM-capable node along the path, and of > course, we expect normal operation to include the residence time for > all RTM-capable nodes, so signalling potential inclusion is odd. > > > I'll close off this review by noting that sections 4.3 through 4.6 > seem to all talk about how to use other protocols to indicate that > RTM may be used and could perhaps be grouped into an intermediate > subsection, wondering whether the "Type" and "Length" fields in > Figure 2 are the same octets of the packet as in Figure 1, and > repeating my as-yet unfulfilled intention to send further minor > editorial patches to the authors. > > -Ben > --001a113d80986218fb054a276c61 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Ben, et.al,
many thanks for your the most thorough review, helpful comments and patien= ce. I've uploaded the new version of the draft that includes all change= s we've discussed and your editorial recommendations. Hope I haven'= t missed any of them.

Regards,
Greg



On Wed, Mar 1, 2017 at 2:21 PM, Benjamin Kaduk <kaduk@mit.= edu> wrote:
I previously re= viewed the -12
(https://www.ietf.org/mail-ar= chive/web/secdir/current/msg07110.html);
the -14 seems much improved.=C2=A0 On this re-read, I have a better sense of how the various TLVs and sub-TLVs fit together to achieve the
goal of having the RTM-capable nodes identify each other and
collaborate to account for residence time when processing timing
packets.

I have no security concerns with the document, as the updated
security considerations address the concerns previously raised.

However, there are a couple of issues that should probably block
publication (but ought to be easy to resolve):

Figure 7 appears to only be 31 bits wide, not 32 -- 'Type' is 7
bits, 'Length' 8, 'I' 1, and 'Reserved' 15.=C2=A0 P= resumably Type is
intended to be the full 8 bits, given the assigned values in the
registry.

On page 16, second paragraph:

=C2=A0 =C2=A0The ingress node MAY inspect the I bit flag received in each R= TM_SET
=C2=A0 =C2=A0TLV contained in the LSP_ATTRIBUTES object of a received Resv<= br> =C2=A0 =C2=A0message.=C2=A0 Presence of the RTM_SET TLV with I bit field se= t to 1
=C2=A0 =C2=A0indicates that some RTM nodes along the LSP could be included = in the
=C2=A0 =C2=A0calculation of the residence time.=C2=A0 An ingress node MAY c= hoose to
=C2=A0 =C2=A0resignal the LSP to include all RTM nodes or simply notify the= user
=C2=A0 =C2=A0via a management interface.

Is that supposed to be "included" or "excluded"?=C2=A0 = My reading of the
previous paragraph was that the I bit would be set when a node
failed to compute the next RTM-capable node along the path, and of
course, we expect normal operation to include the residence time for
all RTM-capable nodes, so signalling potential inclusion is odd.


I'll close off this review by noting that sections 4.3 through 4.6
seem to all talk about how to use other protocols to indicate that
RTM may be used and could perhaps be grouped into an intermediate
subsection, wondering whether the "Type" and "Length" f= ields in
Figure 2 are the same octets of the packet as in Figure 1, and
repeating my as-yet unfulfilled intention to send further minor
editorial patches to the authors.

-Ben

--001a113d80986218fb054a276c61-- From nobody Tue Mar 7 17:48:37 2017 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 907DA129482; Tue, 7 Mar 2017 17:48:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 6s9YZnzysVYy; Tue, 7 Mar 2017 17:48:34 -0800 (PST) Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (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 C240B129447; Tue, 7 Mar 2017 17:48:30 -0800 (PST) X-AuditID: 1209190d-af7ff70000003148-0c-58bf62ece4dc Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 45.44.12616.CE26FB85; Tue, 7 Mar 2017 20:48:28 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v281mRZg014404; Tue, 7 Mar 2017 20:48:28 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v281mOPt003933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Mar 2017 20:48:26 -0500 Date: Tue, 7 Mar 2017 19:48:24 -0600 From: Benjamin Kaduk To: secdir@ietf.org, ietf@ietf.org, draft-ietf-jsonbis-rfc7159bis.all@ietf.org Message-ID: <20170308014823.GF30306@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrOIsWRmVeSWpSXmKPExsUixCmqrPsmaX+EwbRDGhaznv1gtHi2cT6L xYeFD1kcmD2WLPnJFMAYxWWTkpqTWZZapG+XwJXR2ziTvaDHqmLHr37GBsZd+l2MnBwSAiYS s1+cYeti5OIQEmhjkrh36i8rhLOBUeL/hdXsEM4VJokHe0+wgrSwCKhIfJ83iw3EZgOyG7ov M4PYIgJ+Em+W7GcHsYUFrCTWHpjKCGLzAq1o+7mDDcIWlDg58wkLiM0soCVx499Lpi5GDiBb WmL5Pw6QsKiAskTDjAfMExh5ZyHpmIWkYxZCxwJG5lWMsim5Vbq5iZk5xanJusXJiXl5qUW6 Rnq5mSV6qSmlmxjB4SXJu4Px312vQ4wCHIxKPLweZ/dFCLEmlhVX5h5ilORgUhLlXRy9P0KI Lyk/pTIjsTgjvqg0J7X4EKMEB7OSCG+7JVCONyWxsiq1KB8mJc3BoiTOK67RGCEkkJ5Ykpqd mlqQWgSTleHgUJLgNQbGkZBgUWp6akVaZk4JQpqJgxNkOA/Q8J+JIMOLCxJzizPTIfKnGBWl xHk/JQAlBEASGaV5cL2g+JfI3l/zilEc6BVhXj6QFTzA1AHX/QpoMBPQYG3XvSCDSxIRUlIN jNYOxRkNvSuZFD49ufBlx2Gvvq9NVmbxstYXNn/16I4Rz9/bG7+js+CevfeP60n6mvemM8YL 73udac0gfOnplCnnu3JdhYttd/zxX73bNmbbXMkdH7fcqBTdGXXjuNGBb2YibI0bLQ4uYjqx baq5xY5t6W95hT3nNf6NX7dJcuLFzwwmDN+ONCqxFGckGmoxFxUnAgB18B3W2gIAAA== Archived-At: Subject: [secdir] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 01:48:35 -0000 Hi all, 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. It is rather surprising to find notable omissions with what is effectively rfc4627ter, though that seems to be my conclusion after performing this review. Luckily, they should be easy to resolve with just a touch more text in the security considerations, for the most part. As an overall summary, this document is a simple, clean, crisp writeup of the JSON interchange format, which is expected to match that of the ECMAscript standard. Since this is a data format and not a protocol, any security issues with this document are expected to be second-order effects, relating to how the format is used or could be (mis)used by consuming protocols. It is useful to give guidance on issues that may occur due to known-bad implementations, edge cases that can cause trouble, etc., and this document does so, noting that the fields in an object are unordered (but some implementations respect the order in their APIs), when comparing field names the potential for escaped characters must be taken into account, many implementations have limited precision/bounds for numbers, non-number mathematical values cannot be expressed in JSON, etc. However, I think that the security considerations section would benefit from some discussion of potential/example consequences of failing to heed those issues: Doing name comparison without respect for excaping could let an attacker inject unsanitized data into what is supposed to be a trusted structure, potentially giving privilege escalation, compromising authentication and authorization, etc. Considering only the first (or last) of duplicated name/value pairs can lead to vulnerabilities by bypassing security checks, in mixed environments. Similarly, a reliance on fields being returned in order could cause issues (certainly denial of service, potentially worse) if an attacker uses a different order than expected. Perhaps the start of section 4 could refer forward to discussion in the security considerations, which give some exposition on the consequences of breaking the "names within an object SHOULD be unique" guidance. Implementations should probably check that their numerical routines do not attempt to emit "NaN" or "Inf" or simlar, though I do not have a good picture of how that would affect real systems (hopefully, just a parse error on the receiver, as those are not permitted by the grammar). Similarly, the use of extremely large or precise numbers in mixed environments can lead to unexpected results. I expect that there could be vulnerabilities here, such as if code can be induced into a loop with incearingly large values, where a sender ends up producing numbers larger than can be represented on the receiver, which then saturates its strtonum-equivalent and hits an unexpected codepath. I'm also concerned about the freewheeling use of Unicode. While this document does discuss the potential encodings and lists UTF-8 as the default (and most interoperable), I think it would benefit from a stricter warning that parties using JSON for communication must have some out-of-band way to agree on what encoding is to be used. I would expect that this is usually going to be done by the protocol using JSON, but could see a place for the actual communicating peers to have out-of-band knowledge. (An application having to guess what encoding is being used based on heuristics is a recipe for disaster.) Additionally, the document makes no mention of Unicode normalization, which can be a minefield. The precis working group has a lot of work in this area, from which the executive summary is: it's a lot of work to do things correctly, and being sloppy usually leads to vulnerabilities. The most obvious issue would be in (the comparison of) field names using strings that can be represented differently in different normalization forms (for example, e with acute accent), which can be either U+00e9 or U+0064 and the combining character U+0301. Simply converting to Unicode code points is insufficient for an implementation to cause those strings to compare as equivalent. I think this document should at least mention that Unicode normalization forms exist and should be considered by protocol designers when using JSON with characters outside of US-ASCII. Section 9 (parsers) mentions that an implementation "may set limits" on various parameters. That seems like a good place to give some guidance on what limits are in common use and how protocols or protocol peers might discover and/or negotiate each others' implementation limits. With the proposed additions to the security considerations out of the say, on to some other minutiae. Section 3 describes that "[a] JSON value MUST be an object, array, number, or string, or one of the following three literal names: false null true"; in the introduction, this (equivalent) list is given as "object, array, number, string, boolean, or null", in the guise of "four primitive types (strings, numbers, booleans, and null) and two structured types (objects and arrays)". There may be some value in using consistent terminology between the two locations, but it would be pretty minor value and might not be worth the effort. The format for numbers (Section 6) permits an explicit (redundant) plus sign in the exponent part, but not in front of the overall number. This feels slightly strange to me, but I don't know if there are any implementations that get this wrong. (I also don't really see security consequences of getting it wrong.) Similarly, the fractional part must contain a digit (that is, a number ending in a decimal point is forbidden), which is probably harmless. I'll also note that the number 3.141592653589793238462643383279 is used as an example of a precision unrepresentable in 64-bit IEEE 754 floating-point, but the next digit in the expansion of pi is a '5', which would round up to ...80. Maybe another digit should be added to keep overly pedantic readers from worrying about rounding modes :) Should section 8.3 (string comparison) use any RFC 2119 language with respect to treating strings as equal that use escapes (or even normalization forms, as covered above)? The IANA considerations (section 11) might be a little more explicit that the IANA "Media Types" registry is what is being modified. I'm also rather curious about the claim that no "charset" parameter is needed as it "really has no effect on compliant recipients". Why is this not a good way to communicate whether UTF-8, UTF-16, or UTF-32 is in use for a given text? It might also be useful to have an example of an array object that contains elements of different type, to reinforce that this is permitted. With respect to section 1.3, I personally am more used to seeing a "changes since " section that lays out what changed inline, as opposed to with (opaque) references to specific errata. But that is rather an editorial issue so my personal preference should not bind you. -Ben From nobody Tue Mar 7 18:43:11 2017 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 3C585120724; Tue, 7 Mar 2017 18:43:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 853dDnMtxe1j; Tue, 7 Mar 2017 18:43:09 -0800 (PST) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96F7412941C; Tue, 7 Mar 2017 18:43:09 -0800 (PST) Received: by mail-it0-x229.google.com with SMTP id g138so18819207itb.0; Tue, 07 Mar 2017 18:43:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=xiFsOjdhKt4k/MeXHS5s5yhJ0hGCinPAWX7oUmvCwAY=; b=jp6uix6jFHhApv8P2skmKcBVwWoMHNBv1iVYNYSKQh9H+60osWoL4qkuiK8Qk6nNuo 10UwcYD+XW7EuQtSuBhnmVa/vA7sidWmuRloh9svfo2NVJOc1HxinzhRt3aaYpp7f51h +b2DsmyUf9jT+8zFzrReSzZlpCRF3UaIvCzsQBSLKPyyEcKNJNUJM8thazWAyN/ZGK9P kB2V7pTycaw+MqtCRb95hXqS0jDrxW1Z8x2oZjZKn7+S3dnrZ8yrT69hHSpk/WsPfvH/ L7cuc3U/vfigVVO+BNuIR3sjijzfQXx28aTVdTr1JlwC8Iy2IhuVyixzjQH25kEDEwKc 3o0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:cc:content-transfer-encoding; bh=xiFsOjdhKt4k/MeXHS5s5yhJ0hGCinPAWX7oUmvCwAY=; b=QMVhtJRY9nH8fN4OXOk50rN0UwuMxDtgXYu06d4TIB/Fuj/8ZFYWTMoajhVcHJf4gA 04sIyqOnVahFAG6nGFX+MLFJzeG2QtEZPS1pH1xroRZKNb6B4dO816eWD2UcrHcNGf88 tl3piU2iVa16VCpabviVJarN0FWiI6u+US5LSSkn+4mnUYd8W2Qsz0vrBZSrQFFs5h// MZzkUmVAhzJBHzRfwZMp0YpXAIzZRbJcWWfIrT9CqvOriPZcNWzTBnd/pKXf9VUtcQjr b6RSe0H/VajYf4IJnjmBdGys5aMZXHyQOtUL6nWDxdQS/jffimM7EMR75pkpB2L3OH+W I8VA== X-Gm-Message-State: AMke39lfONzUiojAiEkVPeI+xR3SJVOv/AVWrN2P2bzd0aIF985MLYnjIHiZQVYKJNhKXIteFt6QU0SoPwr7qQ== X-Received: by 10.36.98.65 with SMTP id d62mr23499146itc.119.1488940988530; Tue, 07 Mar 2017 18:43:08 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.107.187.7 with HTTP; Tue, 7 Mar 2017 18:43:07 -0800 (PST) From: Barry Leiba Date: Tue, 7 Mar 2017 21:43:07 -0500 X-Google-Sender-Auth: c8S4HM-R6DPpkJOORuVjiiHhZOY Message-ID: To: draft-ietf-anima-grasp.all@ietf.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IESG , anima@ietf.org, "secdir@ietf.org" Subject: [secdir] SecDir review of draft-ietf-anima-grasp-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 02:43:11 -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. First, I'm sorry this review is a few days late, and I hope that isn't a problem. Second, the document is "ready with issues". Most of the comments below are minor, and editorial. The three that are substantive are: 1. SHOULD vs MUST with respect to encryption in Sections 3.5.1 and 3.5.2.1. 2. The UTF-8 issues in Section 3.10.1. 3. Guidance for the Designated Expert in Section 7. These should all be easy to resolve. =E2=80=94 Section 1 =E2=80=94 A reference model for autonomic networking on this basis is given in [I-D.ietf-anima-reference-model]. The reader should consult this document to understand how various autonomic components fit together. Even though that document is an informative reference, I find it odd that the draft that helps us understand how this all fits together. . . is an expired draft. It makes me wonder how well baked things are. =E2=80=94 Section 3.1 =E2=80=94 The following additional terms are used throughout this document: o Autonomic Device: identical to Autonomic Node. It=E2=80=99s not a big point, but: Why? Why is it important or useful to specifically define a *new* term in this document that has the same meaning as a similar term that=E2=80=99s already defined? And, actually, now that I check, I see that =E2=80=9Cautonomic devices=E2= =80=9D is used in exactly one place, in the Abstract. I suggest changing the term in the abstract to =E2=80=9Cautonomic nodes=E2=80=9D, and removing thi= s definition. =E2=80=94 Section 3.2 =E2=80=94 Because GRASP needs to work whatever happens, especially during bootstrapping and during fault conditions, it is essential that every implementation is as robust as possible. There seems to be a missing word, or some such; I can=E2=80=99t parse =E2= =80=9CGRASP needs to work whatever happens=E2=80=9D. And picky grammatical nit: subjunctive mood is needed with =E2=80=9Cessential=E2=80=9D, so it should b= e =E2=80=9Cit is essential that every implementation be as robust as possible.=E2=80=9D =E2=80=94 Section 3.3 =E2=80=94 GRASP provides mechanisms to guarantee convergence (or failure) in a small number of steps, i.e. a timeout and a maximum number of iterations. Another nit. This is an outstanding example of why I don=E2=80=99t like to = use =E2=80=9Ci.e.=E2=80=9D: in this case, it leaves me wondering whether that= =E2=80=99s really an exhaustive list, or whether you meant =E2=80=9Ce.g.=E2=80=9D. And, to me, = it reads awkwardly anyway. I suggest one of these alternatives (the sorts that can pretty much always stand in for the overused and unnecessary =E2=80=9Ci.e.=E2=80=9D): NEW-1 GRASP provides two mechanisms to guarantee convergence (or failure) in a small number of steps: a timeout and a maximum number of iterations. NEW-2 GRASP provides a timeout and a maximum number of iterations, which together guarantee convergence (or failure) in a small number of steps. =E2=80=94 Section 3.5.1 =E2=80=94 If there is no ACP, the protocol MUST use another form of strong authentication and SHOULD use a form of strong encryption. See Section 3.5.2.1 for further discussion. Both here and in 3.5.2.1: Why is encryption SHOULD, and not MUST? Looking ahead to 3.5.2.1, how could it be considered safe to use a network configuration protocol across administrative boundaries without encryption? =E2=80=94 Section 3.5.2.2 =E2=80=94 A responder SHOULD NOT send a Discovery Response message unless it cannot be avoided. Any clue about why it might be possible that it =E2=80=9Ccannot be avoided= =E2=80=9D? =E2=80=94 Section 3.5.2.3 =E2=80=94 o Any type of GRASP message MAY be sent. This doesn=E2=80=99t feel like a =E2=80=9CMAY=E2=80=9D to me. You=E2=80=99= re not saying that there=E2=80=99s a protocol choice here, and how to handle it is optional and up to the implementation. You=E2=80=99re saying that all types of GRASP messages are permitted when you=E2=80=99re using a SONN instance. So maybe, =E2=80=9CAl= l types of GRASP messages are permitted.=E2=80=9D =E2=80=94 Section 3.10.1 =E2=80=94 All objectives are identified by a unique name which is a case- sensitive UTF-8 string. Actually, =E2=80=9Ccase-sensitive=E2=80=9D isn=E2=80=99t a sufficient descr= iptor for UTF-8, as there are issues of canonicalization and normalization, and the fact that languages differ in whether =E2=80=9Ccase=E2=80=9D makes sense at all.= This would be a bigger issue if you wanted case insensitivity, but as it is I think the fix is easy: you should just say that the name is a UTF-8 string that is compared byte by byte. This will have the effect of being case sensitive when that makes sense, and will also eliminate the issues of canonicalization and normalization: different ways of representing characters such as =E2=80=9C=C3=A4=E2=80=9D and =E2=80=9C=C3= =B4=E2=80=9D and =E2=80=9C=C3=A9=E2=80=9D will compare as different, and as these are protocol elements and not user strings, that should be fine. The other question is whether there are any restrictions on what Unicode characters can be represented. You make the colon a special character but give no other restrictions, so an objective name could include space characters (and various related Unicode characters such as tab, EN SPACE, ZERO WIDTH SPACE, and ZERO WIDTH NON-JOINER), control characters (FORM FEED, CARRIAGE RETURN, and the like), characters from every character set and language including Cuneiform and Egyptian Hieroglyphs, and even such iconic characters as MUSICAL SYMBOL G CLEF, ONCOMING POLICE CAR, and the famous PILE OF POO. If that=E2=80=99s all OK, then that=E2=80=99s fine (and maybe it is, as, again= , this is a protocol element, not a user string). I just want to make sure you thought about it. =E2=80=94 Section 7 =E2=80=94 The creation of the Specification Required registry for the Objective Names Table needs to specify guidance for the Designated Expert (see draft-leiba-cotton-iana-5226bis, Sections 4.6 and 4.5). It doesn=E2=80=99t have to be a lot, but it needs to be clear for future DEs who might not have been involved with developing this document what they need to consider as they review registration requests. Why might they push back on a registration request? Should they, for example, allow registration requests for two different Objective Names of =E2=80=9Cfrobozz= =E2=80=9D and =E2=80=9CFrobozz=E2=80=9D? What sort of documentation is sufficient fo= r a registration (is =E2=80=9Cenough that you think implementations can be writ= ten from it=E2=80=9D good enough, or are there specific things that the documentation ought to contain)? --=20 Barry From nobody Tue Mar 7 18:52:41 2017 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 66C97128B37; Tue, 7 Mar 2017 18:52:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 J198sQIeTZK1; Tue, 7 Mar 2017 18:52:39 -0800 (PST) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D434120724; Tue, 7 Mar 2017 18:52:39 -0800 (PST) Received: by mail-it0-x231.google.com with SMTP id h10so83890375ith.1; Tue, 07 Mar 2017 18:52:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=wJOp1LVW4UtJRSWiIUfPM+7tXGn2Q6qPgP1YEk6n1uk=; b=JhV8puMkw8F3nSDNDOo3jmz24ZhUgYiTkbqHsQ4ZF6KOoteqo7HmFLsc6xInxy4CdK Brp/v1MyjHtf+0zvJHG1h+Zc/goqH54EJULM/ajFll6MvsbNONT7xikQv9QQBTR06G+5 wRzLIqqxa4sW5jQt36NuVGdrHtdI9n+ZeAokLLji2Y+yFIAzBomAoN23Er1yL4wi7UcB qxZsIo6Kh6lv9+pQ5naoK1Qm75RC+jsLfIJKViHLIC7V17mGys+5nUWCKPBjDeK3lJXq pGg7Huj9Ct25grbKpv5BOWAJtUPApabHfnPiObqkjs1rdY0K9yxrnzOxk2tRLdFdGJ+A aolA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=wJOp1LVW4UtJRSWiIUfPM+7tXGn2Q6qPgP1YEk6n1uk=; b=Iu0jDuvn+IlaKrBbSU3+D3NxF0iArUIKqGmRYWer/dJFN9zODfoZbCsK8ckKnYUmyy HPBTKixBdE80zcPMya+TGeuMJ3gggV127vLxevqATevC64CiwGD1SyMDAHk/dBaRrC4I KyjNPyrsEbVT935tpJiLbgjtJSonKMTnnPccmx+ZV6KTvMOZaV9w4VED99fwIH2WHAr2 DjAq6Dzct4N+foQCZRl5j1Bzc9jXiSC9FB7Ep7TIpH6yf2QB6u4uTK8JQ1YW0lU+4N8z 8Vnaed/qRto7u6MnM/mWeNkvhDbkXvUtibEhilz2NWHB014+WKXcJrFhic77czkPoNkW /hCg== X-Gm-Message-State: AMke39nwtKApka7s1sqn7iHM4WC7bF2y+QXSpPay+gHNLUEcUG2ytcMjcDKHGfNXGbn8nzwN5kbRsLTYN27P3A== X-Received: by 10.36.184.129 with SMTP id m123mr4321768ite.120.1488941558346; Tue, 07 Mar 2017 18:52:38 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.35.200 with HTTP; Tue, 7 Mar 2017 18:52:37 -0800 (PST) In-Reply-To: <20170308014823.GF30306@kduck.kaduk.org> References: <20170308014823.GF30306@kduck.kaduk.org> From: Barry Leiba Date: Tue, 7 Mar 2017 21:52:37 -0500 X-Google-Sender-Auth: OY5Elvczs5e1sNmTDoLMMtjd1is Message-ID: To: Benjamin Kaduk Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, IETF discussion list , secdir Subject: Re: [secdir] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 02:52:40 -0000 Hi, Ben. A note on the Internationalization points: > I'm also concerned about the freewheeling use of Unicode. While > this document does discuss the potential encodings and lists UTF-8 > as the default (and most interoperable), I think it would benefit > from a stricter warning that parties using JSON for communication > must have some out-of-band way to agree on what encoding is to be > used. I would expect that this is usually going to be done by the > protocol using JSON, but could see a place for the actual > communicating peers to have out-of-band knowledge. (An application > having to guess what encoding is being used based on heuristics is a > recipe for disaster.) > > Additionally, the document makes no mention of Unicode > normalization, which can be a minefield. The precis working group > has a lot of work in this area, from which the executive summary is: > it's a lot of work to do things correctly, and being sloppy usually > leads to vulnerabilities. The most obvious issue would be in (the > comparison of) field names using strings that can be represented > differently in different normalization forms (for example, e with > acute accent), which can be either U+00e9 or U+0064 and the > combining character U+0301. Simply converting to Unicode code > points is insufficient for an implementation to cause those strings > to compare as equivalent. I think this document should at least > mention that Unicode normalization forms exist and should be > considered by protocol designers when using JSON with characters > outside of US-ASCII. I believe that all of this is the realm of the protocol *using* JSON, and doesn't belong in the JSON spec itself. The JSON spec makes it clear what the encoding options are, and leaves things such as the set of allowed characters (and any restrictions on them), the normalization and canonicalization, and the comparison rules to the next level... and I believe that's how it should be. Different uses of JSON will have different needs in these regards, and *those* specifications are the right places to say that. Barry From nobody Tue Mar 7 19:30:44 2017 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 A1B90129480; Tue, 7 Mar 2017 19:30:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 sUhQ77D-etSr; Tue, 7 Mar 2017 19:30:40 -0800 (PST) Received: from dmz-mailsec-scanner-1.mit.edu (dmz-mailsec-scanner-1.mit.edu [18.9.25.12]) (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 1D91F129469; Tue, 7 Mar 2017 19:30:40 -0800 (PST) X-AuditID: 1209190c-6c7ff70000005cc1-9f-58bf7add58da Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 72.52.23745.DDA7FB85; Tue, 7 Mar 2017 22:30:38 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-1.mit.edu (8.13.8/8.9.2) with ESMTP id v283UbdT026028; Tue, 7 Mar 2017 22:30:37 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v283UXJs001011 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 7 Mar 2017 22:30:36 -0500 Date: Tue, 7 Mar 2017 21:30:33 -0600 From: Benjamin Kaduk To: Barry Leiba Message-ID: <20170308033033.GI30306@kduck.kaduk.org> References: <20170308014823.GF30306@kduck.kaduk.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMIsWRmVeSWpSXmKPExsUixCmqrHuvan+EwbZVQhaHFl9itZj17Aej xbON81ksPix8yOLA4tGyqpfZY8mSn0wBTFFcNimpOZllqUX6dglcGZtWtjEV/Beu+H33LXsD 4x/+LkZODgkBE4m/t54xdTFycQgJtDFJHNzZxgaSEBLYwCix6wEvROIKk8TZ6c3sIAkWARWJ 0zP+sYLYbEB2Q/dlZhBbREBT4vnnKUwgNrNAucSRU9vB6oUF3CV2nf8EFOfg4AXa9mazBsT8 aokra6aBtfIKCEqcnPmEBaJVS+LGv5dg5cwC0hLL/3GAhDkFAiU27loPViIqoCzRMOMB8wRG gVlIumch6Z6F0L2AkXkVo2xKbpVubmJmTnFqsm5xcmJeXmqRrqFebmaJXmpK6SZGcNhK8uxg PPPG6xCjAAejEg+vx9l9EUKsiWXFlbmHGCU5mJREeQ9m7o8Q4kvKT6nMSCzOiC8qzUktPsQo wcGsJMLbbgmU401JrKxKLcqHSUlzsCiJ80poNEYICaQnlqRmp6YWpBbBZGU4OJQkeBsrgRoF i1LTUyvSMnNKENJMHJwgw3mAhreB1PAWFyTmFmemQ+RPMSpKifNeqgBKCIAkMkrz4HpBaUUi e3/NK0ZxoFeEeQ+AtPMAUxJc9yugwUxAg7Vd94IMLklESEk1MMZtUV8ZXJXCphC01XTy4ldn pwXI37knsOVamFZQ307tAwfuMH4PTFrPGLbUhEvf6LnK098+P2Y/05zLsT3wtLrS1OLEtd8e iWxt37s4w3Hjo8zHl0VVb1RYKGknL/jlu8ZPaael5px7b7hu25iKWDwRz5l24QzTwpyHiVVf UgN/CB6Q698pOVeJpTgj0VCLuag4EQDC+67mBgMAAA== Archived-At: Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, IETF discussion list , secdir Subject: Re: [secdir] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 03:30:42 -0000 Hi Barry, On Tue, Mar 07, 2017 at 09:52:37PM -0500, Barry Leiba wrote: > Hi, Ben. > A note on the Internationalization points: > > > I'm also concerned about the freewheeling use of Unicode. While > > this document does discuss the potential encodings and lists UTF-8 > > as the default (and most interoperable), I think it would benefit > > from a stricter warning that parties using JSON for communication > > must have some out-of-band way to agree on what encoding is to be > > used. I would expect that this is usually going to be done by the > > protocol using JSON, but could see a place for the actual > > communicating peers to have out-of-band knowledge. (An application > > having to guess what encoding is being used based on heuristics is a > > recipe for disaster.) > > > > Additionally, the document makes no mention of Unicode > > normalization, which can be a minefield. The precis working group > > has a lot of work in this area, from which the executive summary is: > > it's a lot of work to do things correctly, and being sloppy usually > > leads to vulnerabilities. The most obvious issue would be in (the > > comparison of) field names using strings that can be represented > > differently in different normalization forms (for example, e with > > acute accent), which can be either U+00e9 or U+0064 and the > > combining character U+0301. Simply converting to Unicode code > > points is insufficient for an implementation to cause those strings > > to compare as equivalent. I think this document should at least > > mention that Unicode normalization forms exist and should be > > considered by protocol designers when using JSON with characters > > outside of US-ASCII. > > I believe that all of this is the realm of the protocol *using* JSON, > and doesn't belong in the JSON spec itself. The JSON spec makes it > clear what the encoding options are, and leaves things such as the set > of allowed characters (and any restrictions on them), the > normalization and canonicalization, and the comparison rules to the > next level... and I believe that's how it should be. Different uses > of JSON will have different needs in these regards, and *those* > specifications are the right places to say that. I agree that it is appopriate for the JSON spec to merely list out the options and leave decisions to the consuming applications/protocols. However, it seems irresponsible to not mention that those designing such protocols should be aware of the potential issues. -Ben From nobody Tue Mar 7 19:44:24 2017 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 1013C12948E; Tue, 7 Mar 2017 19:44:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 CNK0IbLTnceM; Tue, 7 Mar 2017 19:44:21 -0800 (PST) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (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 41D0A129410; Tue, 7 Mar 2017 19:44:21 -0800 (PST) Received: by mail-pg0-x242.google.com with SMTP id 25so2006636pgy.3; Tue, 07 Mar 2017 19:44:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=10Qt2TLB3kVT4hwHF99Q42gLVvhvBpiYwCiV+lvtzvk=; b=JAposnM64mgS6D/8q7eLmsEqAm/JWja+0qKHSGCK+GXDBvgavP179kFRsfCwn0xlsG KQuBTO3Uyl6BiWNEJVWawInJQgRkA0uN2avzodO8I+pXVtjMI5BSU0DoIgaWKIwkqffc 5gDy05dT4V7FWRKffHrPpa+j3lndd6+jhfZCiVWpqK0WaHJBZQUrgj53nBq+OIDomWxi 9moW4AC0b1GwRcA+gsQE2iwwZxxGC5OKUqacOLUDBucJmXDAOGDXU0KsgwtYOOLJoGZh 4a0t/IFGIDfPNDk8yruOY/h058od0x19GNs2oobxtivssyZqy3xP1X7BewtKsEfDS8Vs //wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=10Qt2TLB3kVT4hwHF99Q42gLVvhvBpiYwCiV+lvtzvk=; b=gZCZidCYqUpZbNcBcp78UAi2rtPwF4ipgngatRKw2Q0kL8kgDYeVj0TPsGllkjBn4u vzQ874ObFB39GLi0lqZ+XNawkqCuSzzcpls+oe3h5G7MRzAJVQxKfcySy5yA1+Eo+6v8 DUm5F5//SW+zPwFamroPVV+f8jt2rH7UZyiZytwYfqxdJSnmsMS6sGHCT5FjIzEXUGOF EyZXqdQTK2pMjb36I6wI+5ZD3kmcGMvMf0HRCXpQJ1FofrlxkPEDYYValCe+MuEhGS7U UD9kGdwlUBmdlEh9ZZHDc2wFEhFA2W7/cztqVeXzfg9Cf5wdsv8zO3othOA8eUJz/wqU oAdA== X-Gm-Message-State: AMke39lj8EIcBezG8Q5QdoXVqdgEPLdGfh5oBZmL3qeUOyYDqWW2Wzi0URxTGLSFCchDGA== X-Received: by 10.99.233.17 with SMTP id i17mr4502541pgh.76.1488944660565; Tue, 07 Mar 2017 19:44:20 -0800 (PST) Received: from ?IPv6:2406:e007:77b4:1:28cc:dc4c:9703:6781? ([2406:e007:77b4:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 185sm2442076pfg.13.2017.03.07.19.44.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Mar 2017 19:44:20 -0800 (PST) To: Barry Leiba , draft-ietf-anima-grasp.all@ietf.org References: From: Brian E Carpenter Organization: University of Auckland Message-ID: <7752607e-ce49-f8f9-7f09-b3e842bc69b9@gmail.com> Date: Wed, 8 Mar 2017 16:44:19 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: anima@ietf.org, "secdir@ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-anima-grasp-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 03:44:23 -0000 Thanks Barry. Good comments, but we have to get a new draft out before the deadline, so I'm not sure these will all make it in until the one after. Regards Brian On 08/03/2017 15:43, Barry Leiba wrote: > 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 > First, I'm sorry this review is a few days late, and I hope that isn't > a problem. >=20 > Second, the document is "ready with issues". Most of the comments > below are minor, and editorial. The three that are substantive are: >=20 > 1. SHOULD vs MUST with respect to encryption in Sections 3.5.1 and 3.5.= 2.1. >=20 > 2. The UTF-8 issues in Section 3.10.1. >=20 > 3. Guidance for the Designated Expert in Section 7. >=20 > These should all be easy to resolve. >=20 > =E2=80=94 Section 1 =E2=80=94 >=20 > A reference model > for autonomic networking on this basis is given in > [I-D.ietf-anima-reference-model]. The reader should consult this > document to understand how various autonomic components fit together= =2E >=20 > Even though that document is an informative reference, I find it odd > that the draft that helps us understand how this all fits together. . > . is an expired draft. It makes me wonder how well baked things are. >=20 > =E2=80=94 Section 3.1 =E2=80=94 >=20 > The following additional terms are used throughout this document: >=20 > o Autonomic Device: identical to Autonomic Node. >=20 > It=E2=80=99s not a big point, but: Why? Why is it important or useful = to > specifically define a *new* term in this document that has the same > meaning as a similar term that=E2=80=99s already defined? >=20 > And, actually, now that I check, I see that =E2=80=9Cautonomic devices=E2= =80=9D is > used in exactly one place, in the Abstract. I suggest changing the > term in the abstract to =E2=80=9Cautonomic nodes=E2=80=9D, and removing= this > definition. >=20 > =E2=80=94 Section 3.2 =E2=80=94 >=20 > Because GRASP needs to work whatever happens, especially during > bootstrapping and during fault conditions, it is essential that ever= y > implementation is as robust as possible. >=20 > There seems to be a missing word, or some such; I can=E2=80=99t parse =E2= =80=9CGRASP > needs to work whatever happens=E2=80=9D. And picky grammatical nit: > subjunctive mood is needed with =E2=80=9Cessential=E2=80=9D, so it shou= ld be =E2=80=9Cit is > essential that every implementation be as robust as possible.=E2=80=9D >=20 > =E2=80=94 Section 3.3 =E2=80=94 >=20 > GRASP > provides mechanisms to guarantee convergence (or failure) in a > small number of steps, i.e. a timeout and a maximum number of > iterations. >=20 > Another nit. This is an outstanding example of why I don=E2=80=99t like= to use > =E2=80=9Ci.e.=E2=80=9D: in this case, it leaves me wondering whether th= at=E2=80=99s really an > exhaustive list, or whether you meant =E2=80=9Ce.g.=E2=80=9D. And, to = me, it reads > awkwardly anyway. I suggest one of these alternatives (the sorts that > can pretty much always stand in for the overused and unnecessary > =E2=80=9Ci.e.=E2=80=9D): >=20 > NEW-1 > GRASP > provides two mechanisms to guarantee convergence (or failure) > in a small number of steps: a timeout and a maximum number of > iterations. >=20 > NEW-2 > GRASP > provides a timeout and a maximum number of iterations, > which together guarantee convergence (or failure) in a > small number of steps. >=20 > =E2=80=94 Section 3.5.1 =E2=80=94 >=20 > If there is no ACP, the protocol MUST use another form of strong > authentication and SHOULD use a form of strong encryption. See > Section 3.5.2.1 for further discussion. >=20 > Both here and in 3.5.2.1: Why is encryption SHOULD, and not MUST? > Looking ahead to 3.5.2.1, how could it be considered safe to use a > network configuration protocol across administrative boundaries > without encryption? >=20 > =E2=80=94 Section 3.5.2.2 =E2=80=94 >=20 > A responder > SHOULD NOT send a Discovery Response message unless it cannot be > avoided. >=20 > Any clue about why it might be possible that it =E2=80=9Ccannot be avoi= ded=E2=80=9D? >=20 > =E2=80=94 Section 3.5.2.3 =E2=80=94 >=20 > o Any type of GRASP message MAY be sent. >=20 > This doesn=E2=80=99t feel like a =E2=80=9CMAY=E2=80=9D to me. You=E2=80= =99re not saying that there=E2=80=99s > a protocol choice here, and how to handle it is optional and up to the > implementation. You=E2=80=99re saying that all types of GRASP messages= are > permitted when you=E2=80=99re using a SONN instance. So maybe, =E2=80=9C= All types of > GRASP messages are permitted.=E2=80=9D >=20 > =E2=80=94 Section 3.10.1 =E2=80=94 >=20 > All objectives are identified by a unique name which is a case- > sensitive UTF-8 string. >=20 > Actually, =E2=80=9Ccase-sensitive=E2=80=9D isn=E2=80=99t a sufficient d= escriptor for UTF-8, as > there are issues of canonicalization and normalization, and the fact > that languages differ in whether =E2=80=9Ccase=E2=80=9D makes sense at = all. This > would be a bigger issue if you wanted case insensitivity, but as it is > I think the fix is easy: you should just say that the name is a UTF-8 > string that is compared byte by byte. This will have the effect of > being case sensitive when that makes sense, and will also eliminate > the issues of canonicalization and normalization: different ways of > representing characters such as =E2=80=9C=C3=A4=E2=80=9D and =E2=80=9C=C3= =B4=E2=80=9D and =E2=80=9C=C3=A9=E2=80=9D will compare as > different, and as these are protocol elements and not user strings, > that should be fine. >=20 > The other question is whether there are any restrictions on what > Unicode characters can be represented. You make the colon a special > character but give no other restrictions, so an objective name could > include space characters (and various related Unicode characters such > as tab, EN SPACE, ZERO WIDTH SPACE, and ZERO WIDTH NON-JOINER), > control characters (FORM FEED, CARRIAGE RETURN, and the like), > characters from every character set and language including Cuneiform > and Egyptian Hieroglyphs, and even such iconic characters as MUSICAL > SYMBOL G CLEF, ONCOMING POLICE CAR, and the famous PILE OF POO. If > that=E2=80=99s all OK, then that=E2=80=99s fine (and maybe it is, as, a= gain, this is a > protocol element, not a user string). I just want to make sure you > thought about it. >=20 > =E2=80=94 Section 7 =E2=80=94 >=20 > The creation of the Specification Required registry for the Objective > Names Table needs to specify guidance for the Designated Expert (see > draft-leiba-cotton-iana-5226bis, Sections 4.6 and 4.5). It doesn=E2=80= =99t > have to be a lot, but it needs to be clear for future DEs who might > not have been involved with developing this document what they need to > consider as they review registration requests. Why might they push > back on a registration request? Should they, for example, allow > registration requests for two different Objective Names of =E2=80=9Cfro= bozz=E2=80=9D > and =E2=80=9CFrobozz=E2=80=9D? What sort of documentation is sufficien= t for a > registration (is =E2=80=9Cenough that you think implementations can be = written > from it=E2=80=9D good enough, or are there specific things that the > documentation ought to contain)? >=20 From nobody Tue Mar 7 20:29:28 2017 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 2FD3E128BA2; Tue, 7 Mar 2017 20:29:25 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 gRquJqhhWV44; Tue, 7 Mar 2017 20:29:23 -0800 (PST) Received: from mail-pf0-x242.google.com (mail-pf0-x242.google.com [IPv6:2607:f8b0:400e:c00::242]) (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 C7AFE12706D; Tue, 7 Mar 2017 20:29:23 -0800 (PST) Received: by mail-pf0-x242.google.com with SMTP id j5so2329993pfb.3; Tue, 07 Mar 2017 20:29:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=HqPOzg55qjp4ZzWG208uCxfeqRyjXmy0tNJVWMH4IOk=; b=BKdjQuU8hxJiZvLKFG3RfS1UO9oaFeGRBfag29JNIQlSHhmj3wRj8N41Iwtg+lpfqJ d+MMV4dCFuM26DSbDOjDy0L2cncG1NbbzivdaQxxCcazZx2VEfB3IgKDKB27OZNz1azA oydldAU118sXGK1mt/DICq1euVOIpZtiy8eqQf8HSiH/lwD/GK9nHSxJeYA2Y5mALeSy NKTu8NAzVs0gngrUpcWgOKxnT9w18EcGEePZN5M+ez+5nNLbD6bMR/f2C2YOBCBeu8Hi +QgXR7kF+7yHm2wT4nAVB3jdoHRY11L3XH/1O6ANd9xBgswaJl9CinW59SuaglVkEOpO ezIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=HqPOzg55qjp4ZzWG208uCxfeqRyjXmy0tNJVWMH4IOk=; b=T1AVEmW6Td0rPepvFAhYYhdh4fjx1e7sAIICSR/804kb7c2ng6kygTYWTq1SMTUtth TzpFCV5ifJoSN3RPfEeqWXNIreeiYggE1Nl0jB+P5cZJUYeET/4KKCi0dJR22oUxs2hv BLI0FzaTp1ixniTbCHn9P7N+6DKElF9b7yU2HZfI3ZLrAUVJQ3RSriYQtgDxcMGfrMWq qqVSl8q4gMtoMTaKJzQLIEuzE1ahTMqXdvGZc0T37tXemplTGCox3t8W4kmfTGmNeFd1 QO+Wn5CjOyKOx/7/OWJ6PleN80pEEO6BxIHDfOa1pjYMuZhFwZZ+WlNhCCFTAev6Hpja KweQ== X-Gm-Message-State: AMke39nweQRh6GgYPUC8ab8aPtkJIHlpigWkxUAVjX8Bk0VC7onn0RVxISwgUZljGp8Z0w== X-Received: by 10.99.147.68 with SMTP id w4mr4639730pgm.32.1488947363073; Tue, 07 Mar 2017 20:29:23 -0800 (PST) Received: from ?IPv6:2406:e007:77b4:1:28cc:dc4c:9703:6781? ([2406:e007:77b4:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id f205sm2622619pfa.35.2017.03.07.20.29.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Mar 2017 20:29:22 -0800 (PST) To: Barry Leiba , draft-ietf-anima-grasp.all@ietf.org References: <7752607e-ce49-f8f9-7f09-b3e842bc69b9@gmail.com> From: Brian E Carpenter Organization: University of Auckland Message-ID: <3529ba25-09af-85dd-92da-aa9d30606bcc@gmail.com> Date: Wed, 8 Mar 2017 17:29:21 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7752607e-ce49-f8f9-7f09-b3e842bc69b9@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: anima@ietf.org, "secdir@ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-anima-grasp-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 04:29:25 -0000 Well, I take that back. I think all these points can be slipped into this week's update of the draft (I plan to submit that on Friday NZ time). Two points for the WG: >=20 > =E2=80=94 Section 3.5.1 =E2=80=94 >=20 > If there is no ACP, the protocol MUST use another form of strong > authentication and SHOULD use a form of strong encryption. See > Section 3.5.2.1 for further discussion. >=20 > Both here and in 3.5.2.1: Why is encryption SHOULD, and not MUST? > Looking ahead to 3.5.2.1, how could it be considered safe to use a > network configuration protocol across administrative boundaries > without encryption? Input please, or else you will see this as an open issue in Chicago. Personal opinion: encryption should be a MUST. On UTF-8: > The other question is whether there are any restrictions on what > Unicode characters can be represented. You make the colon a special > character but give no other restrictions, so an objective name could > include space characters (and various related Unicode characters such > as tab, EN SPACE, ZERO WIDTH SPACE, and ZERO WIDTH NON-JOINER), > control characters (FORM FEED, CARRIAGE RETURN, and the like), Once we specify byte-by-byte comparison, do we need to worry about this in a protocol document? If someone is silly enough to specify an objective called 'example.org:=D0=9D=D0=B5=D0=B4=D0=BE=D1=81=D1= =82=D0=B0=D1=82=D0=BE=D1=87=D0=BD=D0=BE=E6=8F=A1 d=C3=A9j=C3=A0 vu ' do we care, in the protocol design? Personal opinion: we don't need to say anything. Regards Brian On 08/03/2017 16:44, Brian E Carpenter wrote: > Thanks Barry. Good comments, but we have to get a new draft out > before the deadline, so I'm not sure these will all make it in > until the one after. >=20 > Regards > Brian >=20 > On 08/03/2017 15:43, Barry Leiba wrote: >> 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. >> >> First, I'm sorry this review is a few days late, and I hope that isn't= >> a problem. >> >> Second, the document is "ready with issues". Most of the comments >> below are minor, and editorial. The three that are substantive are: >> >> 1. SHOULD vs MUST with respect to encryption in Sections 3.5.1 and 3.5= =2E2.1. >> >> 2. The UTF-8 issues in Section 3.10.1. >> >> 3. Guidance for the Designated Expert in Section 7. >> >> These should all be easy to resolve. >> >> =E2=80=94 Section 1 =E2=80=94 >> >> A reference model >> for autonomic networking on this basis is given in >> [I-D.ietf-anima-reference-model]. The reader should consult this >> document to understand how various autonomic components fit togethe= r. >> >> Even though that document is an informative reference, I find it odd >> that the draft that helps us understand how this all fits together. . >> . is an expired draft. It makes me wonder how well baked things are. >> >> =E2=80=94 Section 3.1 =E2=80=94 >> >> The following additional terms are used throughout this document: >> >> o Autonomic Device: identical to Autonomic Node. >> >> It=E2=80=99s not a big point, but: Why? Why is it important or useful= to >> specifically define a *new* term in this document that has the same >> meaning as a similar term that=E2=80=99s already defined? >> >> And, actually, now that I check, I see that =E2=80=9Cautonomic devices= =E2=80=9D is >> used in exactly one place, in the Abstract. I suggest changing the >> term in the abstract to =E2=80=9Cautonomic nodes=E2=80=9D, and removin= g this >> definition. >> >> =E2=80=94 Section 3.2 =E2=80=94 >> >> Because GRASP needs to work whatever happens, especially during >> bootstrapping and during fault conditions, it is essential that eve= ry >> implementation is as robust as possible. >> >> There seems to be a missing word, or some such; I can=E2=80=99t parse = =E2=80=9CGRASP >> needs to work whatever happens=E2=80=9D. And picky grammatical nit: >> subjunctive mood is needed with =E2=80=9Cessential=E2=80=9D, so it sho= uld be =E2=80=9Cit is >> essential that every implementation be as robust as possible.=E2=80=9D= >> >> =E2=80=94 Section 3.3 =E2=80=94 >> >> GRASP >> provides mechanisms to guarantee convergence (or failure) in a >> small number of steps, i.e. a timeout and a maximum number of >> iterations. >> >> Another nit. This is an outstanding example of why I don=E2=80=99t lik= e to use >> =E2=80=9Ci.e.=E2=80=9D: in this case, it leaves me wondering whether t= hat=E2=80=99s really an >> exhaustive list, or whether you meant =E2=80=9Ce.g.=E2=80=9D. And, to= me, it reads >> awkwardly anyway. I suggest one of these alternatives (the sorts that= >> can pretty much always stand in for the overused and unnecessary >> =E2=80=9Ci.e.=E2=80=9D): >> >> NEW-1 >> GRASP >> provides two mechanisms to guarantee convergence (or failure) >> in a small number of steps: a timeout and a maximum number of >> iterations. >> >> NEW-2 >> GRASP >> provides a timeout and a maximum number of iterations, >> which together guarantee convergence (or failure) in a >> small number of steps. >> >> =E2=80=94 Section 3.5.1 =E2=80=94 >> >> If there is no ACP, the protocol MUST use another form of strong >> authentication and SHOULD use a form of strong encryption. See >> Section 3.5.2.1 for further discussion. >> >> Both here and in 3.5.2.1: Why is encryption SHOULD, and not MUST? >> Looking ahead to 3.5.2.1, how could it be considered safe to use a >> network configuration protocol across administrative boundaries >> without encryption? >> >> =E2=80=94 Section 3.5.2.2 =E2=80=94 >> >> A responder >> SHOULD NOT send a Discovery Response message unless it cannot be= >> avoided. >> >> Any clue about why it might be possible that it =E2=80=9Ccannot be avo= ided=E2=80=9D? >> >> =E2=80=94 Section 3.5.2.3 =E2=80=94 >> >> o Any type of GRASP message MAY be sent. >> >> This doesn=E2=80=99t feel like a =E2=80=9CMAY=E2=80=9D to me. You=E2=80= =99re not saying that there=E2=80=99s >> a protocol choice here, and how to handle it is optional and up to the= >> implementation. You=E2=80=99re saying that all types of GRASP message= s are >> permitted when you=E2=80=99re using a SONN instance. So maybe, =E2=80= =9CAll types of >> GRASP messages are permitted.=E2=80=9D >> >> =E2=80=94 Section 3.10.1 =E2=80=94 >> >> All objectives are identified by a unique name which is a case- >> sensitive UTF-8 string. >> >> Actually, =E2=80=9Ccase-sensitive=E2=80=9D isn=E2=80=99t a sufficient = descriptor for UTF-8, as >> there are issues of canonicalization and normalization, and the fact >> that languages differ in whether =E2=80=9Ccase=E2=80=9D makes sense at= all. This >> would be a bigger issue if you wanted case insensitivity, but as it is= >> I think the fix is easy: you should just say that the name is a UTF-8 >> string that is compared byte by byte. This will have the effect of >> being case sensitive when that makes sense, and will also eliminate >> the issues of canonicalization and normalization: different ways of >> representing characters such as =E2=80=9C=C3=A4=E2=80=9D and =E2=80=9C= =C3=B4=E2=80=9D and =E2=80=9C=C3=A9=E2=80=9D will compare as >> different, and as these are protocol elements and not user strings, >> that should be fine. >> >> The other question is whether there are any restrictions on what >> Unicode characters can be represented. You make the colon a special >> character but give no other restrictions, so an objective name could >> include space characters (and various related Unicode characters such >> as tab, EN SPACE, ZERO WIDTH SPACE, and ZERO WIDTH NON-JOINER), >> control characters (FORM FEED, CARRIAGE RETURN, and the like), >> characters from every character set and language including Cuneiform >> and Egyptian Hieroglyphs, and even such iconic characters as MUSICAL >> SYMBOL G CLEF, ONCOMING POLICE CAR, and the famous PILE OF POO. If >> that=E2=80=99s all OK, then that=E2=80=99s fine (and maybe it is, as, = again, this is a >> protocol element, not a user string). I just want to make sure you >> thought about it. >> >> =E2=80=94 Section 7 =E2=80=94 >> >> The creation of the Specification Required registry for the Objective >> Names Table needs to specify guidance for the Designated Expert (see >> draft-leiba-cotton-iana-5226bis, Sections 4.6 and 4.5). It doesn=E2=80= =99t >> have to be a lot, but it needs to be clear for future DEs who might >> not have been involved with developing this document what they need to= >> consider as they review registration requests. Why might they push >> back on a registration request? Should they, for example, allow >> registration requests for two different Objective Names of =E2=80=9Cfr= obozz=E2=80=9D >> and =E2=80=9CFrobozz=E2=80=9D? What sort of documentation is sufficie= nt for a >> registration (is =E2=80=9Cenough that you think implementations can be= written >> from it=E2=80=9D good enough, or are there specific things that the >> documentation ought to contain)? >> >=20 From nobody Tue Mar 7 23:40:11 2017 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 794D1129638; Tue, 7 Mar 2017 23:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 tzJ8W64Eygl1; Tue, 7 Mar 2017 23:39:58 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 66A4D129613; Tue, 7 Mar 2017 23:39:58 -0800 (PST) Received: from [192.168.178.20] ([93.217.100.107]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LdKs1-1c34dz37uD-00iXAJ; Wed, 08 Mar 2017 08:39:50 +0100 To: Benjamin Kaduk , secdir@ietf.org, ietf@ietf.org, draft-ietf-jsonbis-rfc7159bis.all@ietf.org, "json@ietf.org" References: <20170308014823.GF30306@kduck.kaduk.org> From: Julian Reschke Message-ID: <382aa5c8-c977-b24d-4d19-251257833b00@gmx.de> Date: Wed, 8 Mar 2017 08:39:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170308014823.GF30306@kduck.kaduk.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:EYTmLyyauoZDVxPqbNB2Y4XlnUQetAOq4i6nJRmPvAmRmgckyl/ rrbKcjiAhgBVcTX4R1MVAGl/U+fgjAEOtLdTMYuH1hBXwQVSexVgZphDBxJB8xRWTTM0kqr mEU1XhEPYbjibmKD1MlFnkHDudg6Rc/rGrZk5JKbUnj/n+Loc6xWgBfiPBCg/JBIRHY+Hcb D126Hj/HE1Gw5zpVeV3Xg== X-UI-Out-Filterresults: notjunk:1;V01:K0:perBMTujxkg=:r5rO1SlULzgIB8MUe1Ulb+ DVIjAQa52p1q/gvO9wIegLcEcGSwXrDsbgxkF+LHagkaqCK+vtEyDyE+JdL6REDC4bFIGhrnx xsxm4QShfHf5hDZcR5zAHJ9bVYMoRFMkQnkaAWM8/kJS1eax9PTOwQu7bo7hmYKzHvkhYeFIH YV5YFqBcX6udcN4qb8Fg1MKxnEML0KZj+2UI4z/GGUaqWHChdlUHHH+Lcu/DYQhtXWWeu03Xh YybWCFeUYBWOwF4Z5b/YYKwje0CazsoJN+eE9z3uO6BGBcljI21ezN/Y7khgfv4QvvPoypCLp Nx57ObEhrrlMG++qMPLfZnYLWqJ3A/Tb09PBPV4r6k6cxhjdkvW9mBpq5F8zVll5VSP+wuQED f/Z7tNyLk0QT7g3Jo3i3yStgdGOlKf87k71vHo1LN/G9Eyqp46qgSMHlNvgspfjvSoVMlUnQb wzVCKPQnoEbKBp9xvrPxs9UJ0Ozf+L9D3C2Ekw0+hF+ETYeSUBm0bbuPEAtpreIift4pd+Grj ruLsiJTW3G6ZO+mTNZYoPgW7RN+6vTnjXG1LaaQrneZ9Uv9kQkKJCnoS9eutTqxjOY3/7VWD1 E31NQNjBWsA0bBPcwrCwMCAO32LXJhSUz+UlGWEhVABcjZxaJldlZYQ7FmVItzOAC9K+HiSd1 wq1IEcH2M3tD16GybBDcRstMbHg2pDcE9YxQ7zyIOVdNdCudsN/25fLcmViQPQ4jFyHBImUFJ 9jMGmXHnUfDT4f4H2x41UilmSLgNWmBBa6cBFkmlLBFhSfehwNg2c371MDUxheUVhoYINYs2A r5rLBCZs26VrU9VdJWf8qb0oPDqNUZRi6nDC15KPMOjHRcEm0jL1Z1nC12tru1xSvkTSeiE07 c1svbH6/bQHlyIEKwR43rgM6dkjIiT4qFnFXw92SSMneOE0yOHBS/9/guKv/gk9fQSzD4PFf9 0KU0+cp2Pj/knCM2w4govzRbZ1LRKPwpaebtIozOnugnqIoaxeVvxZLvJlRSN3Oua3aD0dfqZ 1BE1S1CmeVoLYSR9BJJZxuo= Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 07:40:00 -0000 On 2017-03-08 02:48, Benjamin Kaduk wrote: > I'm also concerned about the freewheeling use of Unicode. While > this document does discuss the potential encodings and lists UTF-8 > as the default (and most interoperable), I think it would benefit > from a stricter warning that parties using JSON for communication > must have some out-of-band way to agree on what encoding is to be > used. I would expect that this is usually going to be done by the > protocol using JSON, but could see a place for the actual > communicating peers to have out-of-band knowledge. (An application > having to guess what encoding is being used based on heuristics is a > recipe for disaster.) > ... AFAIU, there is no need for out-of-band knowledge (which would be very bad). Recipients are supposed to inspect the payload and detect which of the three encoding was used. That said, we probably should make that clearer. > ... > I'm also rather curious about the claim that no "charset" parameter > is needed as it "really has no effect on compliant recipients". Why > is this not a good way to communicate whether UTF-8, UTF-16, or > UTF-32 is in use for a given text? > ... It might have been, but that's now how it is implemented. Best regards, Julian From nobody Tue Mar 7 23:47:34 2017 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 B5EBB129613; Tue, 7 Mar 2017 23:47:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, 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 D2W-Ixh5_Csb; Tue, 7 Mar 2017 23:47:28 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 5C0C412896F; Tue, 7 Mar 2017 23:47:28 -0800 (PST) Received: from [192.168.178.20] ([93.217.100.107]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Ls7MZ-1cGtcJ1JNP-013vHb; Wed, 08 Mar 2017 08:47:24 +0100 To: Benjamin Kaduk , secdir@ietf.org, ietf@ietf.org, draft-ietf-jsonbis-rfc7159bis.all@ietf.org, "json@ietf.org" References: <20170308014823.GF30306@kduck.kaduk.org> <382aa5c8-c977-b24d-4d19-251257833b00@gmx.de> From: Julian Reschke Message-ID: <456b4234-0d94-1033-507c-710878bb5159@gmx.de> Date: Wed, 8 Mar 2017 08:47:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <382aa5c8-c977-b24d-4d19-251257833b00@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:8Oqw7wVY0/DD8a7XvzdcgSqIJ8e45LLLt/e4P6dikmvYOmslNGc 3c7YrlpPUwJgB2IdgdzoE0B8Jd6dITvwdbhueX/s/XsJoGSmoUMsb2jFWeW4wGNprm1Wy87 zzUKKIpDEbiPh18UHa+wZeyPZdyORwATSgjjs8UBVRW9DfFcppERh8WaiIweQVXTrn9uwd3 D/lKmFd4VF/WKXG2KS8lg== X-UI-Out-Filterresults: notjunk:1;V01:K0:l7kQeR809eg=:qNzJhp1XQQ8LmH98LXoIs+ znoQXUT7x2LkuuTduHNxzaWVLkpnp+msMWNtxIp3cJkw2UYTXn7z2P+rLD3zb4XhRGrWFw0YQ IdvEYIa6U7lHcvtvLi/BBeZQdje2CT/UXy1qWGrYa3zDzX+03904UNYjI5ls0c6Y7L7a/k10m BH32EFjtJbgEzQ1iv9Hg7lJOXhQvWhJ7qWgGK8ORl9i0hSCGoz1vqhjyqbcDUpxBTfziQn2Ro 5gGfhrqNNgDKBMUJcdQYDk4oIA2CSsODvhjg/JMa6/MM4Tkqjyf2P7qG66rf9VmrBUssVH9vT 5uESjzMgPiagzbi0z6yEA6rMj+fWmzE7///BpAHFvZVgATbMbJC2BQUTW42nIMpfLGhSgpYyO rrS7LeM3/G/0LvugipxEGqN2NtYN47Rt3oDg2O1n/9BKdkEZTuyOWY8x/jsWDtoN1qCA7Azbp jta20R7UVDUCuke9LQY1aLQtmuKjxgBD+4z72wJdSxTFcvKnp6BmYUYisfuHx2qoDpuXcylUc GqLUzh15GuV1/W5i808Wk2ukNo2mxjDaXfMjXp5n3XtXSH0s0Hk9dSyY0Pk4KJ6Ae6PdFflAj QxEq4tXzu3sOhdkMgzN7PUe850lzx2S3duzDBRIKL3rzcFELPFjoCdKsoYyRdipAjqEGqOoGz Uk8WKQfYpuX9APj45TJ6kQKmPVyXEiBGpvkTHw2djW4DRZ3tgGlKk0d+7ax/C77CfISu/PTAd fMvUn2oNaMtjs6ViAw8HivT370GLkIEttX3XA2WOcvGC8jt48quAZ8rVKCfaTmEY/5KwQMkn5 YJMSaBX Archived-At: Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 07:47:29 -0000 On 2017-03-08 08:39, Julian Reschke wrote: > On 2017-03-08 02:48, Benjamin Kaduk wrote: >> I'm also concerned about the freewheeling use of Unicode. While >> this document does discuss the potential encodings and lists UTF-8 >> as the default (and most interoperable), I think it would benefit >> from a stricter warning that parties using JSON for communication >> must have some out-of-band way to agree on what encoding is to be >> used. I would expect that this is usually going to be done by the >> protocol using JSON, but could see a place for the actual >> communicating peers to have out-of-band knowledge. (An application >> having to guess what encoding is being used based on heuristics is a >> recipe for disaster.) >> ... > > AFAIU, there is no need for out-of-band knowledge (which would be very > bad). Recipients are supposed to inspect the payload and detect which of > the three encoding was used. > > That said, we probably should make that clearer. > >> ... >> I'm also rather curious about the claim that no "charset" parameter >> is needed as it "really has no effect on compliant recipients". Why >> is this not a good way to communicate whether UTF-8, UTF-16, or >> UTF-32 is in use for a given text? >> ... > > It might have been, but that's now how it is implemented. s/now/not/ From nobody Wed Mar 8 00:50:01 2017 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 370EF129570; Wed, 8 Mar 2017 00:49:53 -0800 (PST) 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] 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 b710WRAu6p_3; Wed, 8 Mar 2017 00:49:50 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 07726129468; Wed, 8 Mar 2017 00:49:49 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v288nkNt029277; Wed, 8 Mar 2017 09:49:46 +0100 (CET) Received: from eduroam-cart-clients-173.wlan.uni-bremen.de (eduroam-cart-clients-173.wlan.uni-bremen.de [134.102.145.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vdRzZ4WlPzDJ02; Wed, 8 Mar 2017 09:49:46 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <382aa5c8-c977-b24d-4d19-251257833b00@gmx.de> Date: Wed, 8 Mar 2017 09:49:46 +0100 X-Mao-Original-Outgoing-Id: 510655785.753134-e042b3f3f8d107f7b5e7cdf9db835f90 Content-Transfer-Encoding: quoted-printable Message-Id: <6FEE55BE-10A8-4198-A4F0-4203BE0866F4@tzi.org> References: <20170308014823.GF30306@kduck.kaduk.org> <382aa5c8-c977-b24d-4d19-251257833b00@gmx.de> To: Julian Reschke X-Mailer: Apple Mail (2.3259) Archived-At: Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, "json@ietf.org" , IETF , secdir@ietf.org Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 08:49:53 -0000 On 8 Mar 2017, at 08:39, Julian Reschke wrote: >=20 > > ... >> I'm also rather curious about the claim that no "charset" parameter >> is needed as it "really has no effect on compliant recipients". Why >> is this not a good way to communicate whether UTF-8, UTF-16, or >> UTF-32 is in use for a given text? >> ... >=20 > It might have been, but that's now how it is implemented. Indeed, and the reality is that JSON over UTF-16 or UTF-32 simply does = not exist as an interchange format, so the algorithm is to always just = assume UTF-8. Gr=C3=BC=C3=9Fe, Carsten From nobody Wed Mar 8 11:29:54 2017 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 EFB5B12955C; Wed, 8 Mar 2017 11:29:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 JLKRSvOb95oX; Wed, 8 Mar 2017 11:29:51 -0800 (PST) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 471661293FF; Wed, 8 Mar 2017 11:29:51 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id h10so111838066ith.1; Wed, 08 Mar 2017 11:29:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=+9mcPtruFdzdhcnhmVHhpUu9CsV11dZ3aSJSgdGHTSE=; b=DbLyahh/2INHmT/0peVJwfJ9il70KyNGgn4WUeZ2EUkJT3pPI82ClbNUJBfixKj7Hs CsL2yjk4BbswPysKGNtn6q2c/bojJ+2GvUv2pPEEYUtZYF7Q/YkXfBelTWgngLYM/CTN i1YH/KBD56ozhS+wzzHABOWEWulgP+haSNqCDyJYEWCUM7rBbR2PcrF8cTmeQoilHeIQ A+RL3pLlYKtuadVrq9CdADeGrmTlgJ4eM4V7LT62g6GxylqIoWrINkECKalsmjBKiQQX 1fuhOCtFZjf5DajhhxFpGOWcNCoLTF/TdBbMQSNJtqQcZWSChphaWy1wDYpRDjO60jdi sUVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc:content-transfer-encoding; bh=+9mcPtruFdzdhcnhmVHhpUu9CsV11dZ3aSJSgdGHTSE=; b=T7d4OCoRncxahPqMdNjFAHf82c+4NTo3ylC4DGbUf04r+H5EE3X9vDBNEYmMPNgTcr WzIe7mg8IOSiGMnbP6AkJqnvjXG5C/8c6i4ninXegAX/wNgrxaEuy4f+GONdoFqTU8kB j+b5Cp/P4buNzklrhM+jmWBGOLsaxToC9jx/0+abKAbNoKCi4SlHAEO/Ljx6OcopGoFk B2pzltq/OwvhCEU9ecXnVAgV8BKtSbjapZOZ+uwalfAYLNS65lm1o6XCpKWFAkSZtY6m /ZROlIsE48FOI+Qt5jeuLPn9oRo0z9ldadxaZsy8kL+bWdqbZMswIV7bM3tYz6gLHTug wY0w== X-Gm-Message-State: AMke39kKEHvWAkZfiKrKtTgQXkDEs7TdhIBU58Y3mU0Y7TOcFN1c9JQsVaVFeSRmROJ2bmAe5WRoPq8uN5f71A== X-Received: by 10.107.46.85 with SMTP id i82mr7391114ioo.85.1489001390626; Wed, 08 Mar 2017 11:29:50 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.107.35.200 with HTTP; Wed, 8 Mar 2017 11:29:50 -0800 (PST) In-Reply-To: <3529ba25-09af-85dd-92da-aa9d30606bcc@gmail.com> References: <7752607e-ce49-f8f9-7f09-b3e842bc69b9@gmail.com> <3529ba25-09af-85dd-92da-aa9d30606bcc@gmail.com> From: Barry Leiba Date: Wed, 8 Mar 2017 14:29:50 -0500 X-Google-Sender-Auth: SuvIRyg6EkpJA3WxKOgEQ2F02vY Message-ID: To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org, "secdir@ietf.org" Subject: Re: [secdir] SecDir review of draft-ietf-anima-grasp-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Mar 2017 19:29:53 -0000 > On UTF-8: > >> The other question is whether there are any restrictions on what >> Unicode characters can be represented. You make the colon a special >> character but give no other restrictions, so an objective name could >> include space characters (and various related Unicode characters such >> as tab, EN SPACE, ZERO WIDTH SPACE, and ZERO WIDTH NON-JOINER), >> control characters (FORM FEED, CARRIAGE RETURN, and the like), > > Once we specify byte-by-byte comparison, do we need to worry about > this in a protocol document? If someone is silly enough to > specify an objective called 'example.org:=D0=9D=D0=B5=D0=B4=D0=BE=D1=81= =D1=82=D0=B0=D1=82=D0=BE=D1=87=D0=BD=D0=BE=E6=8F=A1 d=C3=A9j=C3=A0 vu > ' do we care, in the protocol design? > > Personal opinion: we don't need to say anything. That's probably correct, and I just wanted to be sure y'all had thought about it -- more whether there'd be an issue with space-related characters or confusibles than about real non-Latin languages or pile-of-poo icons. Thanks for addressing my comments! Barry From nobody Wed Mar 8 21:54:11 2017 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 BBDF2127ABE; Wed, 8 Mar 2017 21:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 I3jHOIdMARNR; Wed, 8 Mar 2017 21:54:09 -0800 (PST) Received: from dmz-mailsec-scanner-5.mit.edu (dmz-mailsec-scanner-5.mit.edu [18.7.68.34]) (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 F1FBA1297CB; Wed, 8 Mar 2017 21:53:54 -0800 (PST) X-AuditID: 12074422-1a7ff70000001f4d-f9-58c0edf1de49 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 4C.84.08013.1FDE0C85; Thu, 9 Mar 2017 00:53:53 -0500 (EST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id v295rqUr019091; Thu, 9 Mar 2017 00:53:53 -0500 Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id v295rmPK016024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 9 Mar 2017 00:53:51 -0500 Date: Wed, 8 Mar 2017 23:53:48 -0600 From: Benjamin Kaduk To: Julian Reschke Message-ID: <20170309055348.GL30306@kduck.kaduk.org> References: <20170308014823.GF30306@kduck.kaduk.org> <382aa5c8-c977-b24d-4d19-251257833b00@gmx.de> <456b4234-0d94-1033-507c-710878bb5159@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <456b4234-0d94-1033-507c-710878bb5159@gmx.de> User-Agent: Mutt/1.6.1 (2016-04-27) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJIsWRmVeSWpSXmKPExsUixG6nrvvx7YEIg593rS1mPfvBaPFs43wW i3tzii02P3zDavFh4UMWB1aPDx/jPJYs+ckUwBTFZZOSmpNZllqkb5fAldH0r4W5oJ234uDV /UwNjPO5uhg5OSQETCR+z77D2sXIxSEk0MYk8e/Cb0YIZwOjxNo1M5ggnCtMErP/bmICaWER UJH49WgyK4jNBmQ3dF9mBrFFBLQkbt/bywhiMwtUSEw+sB3MFhZwleiYexusnhdo3Y7uDVAb pjBKfJ+4ngUiIShxcuYTFohmLYkb/14CLeMAsqUllv/jAAlzClhJTHr9B2yOqICyRMOMB8wT GAVmIemehaR7FkL3AkbmVYyyKblVurmJmTnFqcm6xcmJeXmpRbqmermZJXqpKaWbGMEh7KK0 g3HiP69DjAIcjEo8vALCByKEWBPLiitzDzFKcjApifIaBACF+JLyUyozEosz4otKc1KLDzFK cDArifDuugSU401JrKxKLcqHSUlzsCiJ84prNEYICaQnlqRmp6YWpBbBZGU4OJQkeJe9AWoU LEpNT61Iy8wpQUgzcXCCDOcBGh4DUsNbXJCYW5yZDpE/xagoJc67DiQhAJLIKM2D6wWlGIns /TWvGMWBXhHm/QpSxQNMT3Ddr4AGMwEN1nbdCzK4JBEhJdXA6CK2ffoffsUt9/cHnjPwT2Ox +7s+QjDNt//idxGJz8+FvEV+SzlrMyUp8oUdP/hT2+ays3F754ObKkvvMOd4KSr9NH23/Eax Y552Bf/La/bbfpvd/8Uc9Vevm3tewNcFFvN+/Jghwd3GK1geuyx/qbDBTL2Vi25IaLjfCpgd LDxfWMhVu3SvEktxRqKhFnNRcSIAVklLhwwDAAA= Archived-At: Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, "json@ietf.org" , ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 05:54:09 -0000 On Wed, Mar 08, 2017 at 08:47:24AM +0100, Julian Reschke wrote: > On 2017-03-08 08:39, Julian Reschke wrote: > > On 2017-03-08 02:48, Benjamin Kaduk wrote: > >> I'm also concerned about the freewheeling use of Unicode. While > >> this document does discuss the potential encodings and lists UTF-8 > >> as the default (and most interoperable), I think it would benefit > >> from a stricter warning that parties using JSON for communication > >> must have some out-of-band way to agree on what encoding is to be > >> used. I would expect that this is usually going to be done by the > >> protocol using JSON, but could see a place for the actual > >> communicating peers to have out-of-band knowledge. (An application > >> having to guess what encoding is being used based on heuristics is a > >> recipe for disaster.) > >> ... > > > > AFAIU, there is no need for out-of-band knowledge (which would be very > > bad). Recipients are supposed to inspect the payload and detect which of > > the three encoding was used. > > > > That said, we probably should make that clearer. If that's what's supposed to happen, it should probably be more clear, yes. (But aren't there texts that have valid interpretations in multiple encodings?) > >> ... > >> I'm also rather curious about the claim that no "charset" parameter > >> is needed as it "really has no effect on compliant recipients". Why > >> is this not a good way to communicate whether UTF-8, UTF-16, or > >> UTF-32 is in use for a given text? > >> ... > > > > It might have been, but that's now how it is implemented. > > s/now/not/ Alas. Thanks for the insight. -Ben From nobody Thu Mar 9 04:37:47 2017 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 D1A6D12955F for ; Thu, 9 Mar 2017 04:37:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148906306585.5790.783594430155484821.idtracker@ietfa.amsl.com> Date: Thu, 09 Mar 2017 04:37:45 -0800 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Reply-To: secdir-secretary@mit.edu List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 12:37:46 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-03-16 Reviewer LC end Draft John Bradley 2017-03-13 draft-mm-wg-effect-encrypt-07 Alan DeKok 2017-03-10 draft-bchv-rfc6890bis-04 Daniel Franke 2017-02-28 draft-ietf-pce-stateful-sync-optimizations-09 Daniel Gillmor 2017-02-28 draft-ietf-pce-stateful-pce-18 Ólafur Guðmundsson 2017-02-27 draft-ietf-dime-load-08 Christian Huitema 2017-03-15 draft-ietf-ipsecme-rfc7321bis-05 Leif Johansson 2017-03-08 draft-ietf-lmap-information-model-17 Scott Kelly 2017-03-03 draft-ietf-tls-rfc4492bis-14 Watson Ladd 2017-03-03 draft-ietf-dane-smime-15 For telechat 2017-04-13 Reviewer LC end Draft Phillip Hallam-Baker 2017-02-24 draft-ietf-dmm-lma-controlled-mag-params-03 Dan Harkins 2017-03-20 draft-ietf-rtcweb-overview-18 Matthew Miller 2017-03-10 draft-ietf-bess-evpn-vpws-10 Last calls: Reviewer LC end Draft Derek Atkins 2017-03-22 draft-ietf-i2nsf-problem-and-use-cases-11 Ben Laurie 2017-03-02 draft-ietf-dprive-dtls-and-tls-profiles-08 Chris Lonvick 2017-03-15 draft-ietf-ippm-twamp-time-format-04 David Mandelberg 2017-03-14 draft-ietf-ippm-model-based-metrics-10 Catherine Meadows 2017-03-13 draft-ietf-dhc-relay-server-security-03 Adam Montville 2017-03-21 draft-ietf-sipcore-status-unwanted-04 Yaron Sheffer 2017-03-01 draft-ietf-6man-rfc2460bis-08 Tom Yu 2017-02-20 draft-ietf-slim-negotiating-human-language-08 Early review requests: Reviewer Due Draft Daniel Gillmor 2016-02-01 draft-ietf-rtcweb-security-08 Brian Weis 2016-02-01 draft-ietf-cdni-uri-signing-10 Next in the reviewer rotation: Russ Mundy Sandra Murphy Yoav Nir Magnus Nystrom Hilarie Orman Radia Perlman Vincent Roca Joseph Salowey Rich Salz Yaron Sheffer From nobody Thu Mar 9 06:49:57 2017 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 0CF06129633; Thu, 9 Mar 2017 06:49:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 ZYVCTNxVbrBh; Thu, 9 Mar 2017 06:49:50 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9575312963B; Thu, 9 Mar 2017 06:49:50 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 297EE200A3; Thu, 9 Mar 2017 10:12:33 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9AFA76381A; Thu, 9 Mar 2017 09:49:47 -0500 (EST) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <3529ba25-09af-85dd-92da-aa9d30606bcc@gmail.com> References: <7752607e-ce49-f8f9-7f09-b3e842bc69b9@gmail.com> <3529ba25-09af-85dd-92da-aa9d30606bcc@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Barry Leiba , draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org, "secdir@ietf.org" Subject: Re: [secdir] [Anima] SecDir review of draft-ietf-anima-grasp-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 14:49:52 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> Both here and in 3.5.2.1: Why is encryption SHOULD, and not MUST? >> Looking ahead to 3.5.2.1, how could it be considered safe to use a >> network configuration protocol across administrative boundaries >> without encryption? > Input please, or else you will see this as an open issue in Chicago. > Personal opinion: encryption should be a MUST. I believe that we will have situations where we have a secured ACP into a NOC (to an edge router or VM hypervisor), and then we will have some unencrypted, but secured links to platforms in transition. It will be easy to add the GRASP daemon to answer resource requests to the platform, but hard to add the ACP to that platform without a forklift upgrade. This is why I think it is a SHOULD, as much as I want it to transition to being a MUST. >> The other question is whether there are any restrictions on what >> Unicode characters can be represented. You make the colon a special >> character but give no other restrictions, so an objective name could >> include space characters (and various related Unicode characters such >> as tab, EN SPACE, ZERO WIDTH SPACE, and ZERO WIDTH NON-JOINER), >> control characters (FORM FEED, CARRIAGE RETURN, and the like), > Once we specify byte-by-byte comparison, do we need to worry about this > in a protocol document? If someone is silly enough to specify an It matters, when humans have to confirm things. I think that objectives will be mostly baked into code. So, I agree with you, but I would rather exclude all that UTF stuff too. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljBa4gACgkQgItw+93Q 3WVaWAgAvOM0lRqF2w2rgVcxbkl+zEhdW3GS6mo7jWJ9b5ERLXH48xWeWoVTXkTf GxlpUUVniMmwmLtPFeU043p7wfMWAWwamD1N6cjvQGRZxgduRYxuRxucvT+OTEvA thX9gF+sCHZbVwr9OQp3X3fOoGMYo1801loDt+KPGgtrNF4pD2KEniCHrgKHhBrB xLZpMRiZ9MQAmnnoVesqpf0ZVPaPaV8wg+oPuwwUd8HJP52IYVV51kzVcIPQlErN eefWDGRX29ZcFyZI6tSeR+GPGQaefqFeKo9Jbkt+Tg2nGXRGELriOQ2QE/JXW1wD Ab+kUbOOXVm2nJzLj4mm6Qh8/bROIQ== =xqB8 -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 9 08:06:09 2017 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 00E1F12948B for ; Thu, 9 Mar 2017 08:06:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet-se.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 ALHuGkvfs4L3 for ; Thu, 9 Mar 2017 08:06:03 -0800 (PST) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 7AF6412949E for ; Thu, 9 Mar 2017 08:06:03 -0800 (PST) Received: by mail-wr0-x233.google.com with SMTP id u108so48072309wrb.3 for ; Thu, 09 Mar 2017 08:06:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=Z+p7+8Fxle2M5LLn+Ro1h8bLCsCmwtdKTr+9qqQfGf4=; b=H+ZhuxnyMooVdkaK7j5puk/jj1PXhFpRQQgSadlHaep60QIjaz6dwJqKpY6PWB03tq O6fuVrsG+GFbBEnkukPj835tFzV3CL6w/GOHp1mdxsOwlJUXzDha5SYutQxxdAUcf4bT /7mUdYSmPi4pe6jTWpHP5d5J0BCf9xMVnvSv5liGqMSIekFCs3zlo6/lDaYQeuXjmfvz LcW3qnbNhWIV0Ackl6ALFDA4k/aHPJ189qJF/2AVqavSxEhImJA07OQ+roWxVYPDHWsT eK1Rnpz584Uy4t1Zg+ZTUEXDjPhsHFRS3vbPhSAcZaDbRF8mFj966i7bs2pLfBHtjXwp f5Sg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=Z+p7+8Fxle2M5LLn+Ro1h8bLCsCmwtdKTr+9qqQfGf4=; b=AFEJkofvWmsa3WIbRNSme6fIgcZISailDWAbUCRHoQAspcQICKn8wgx32tw1KdueLQ zUey4H7YyKxE4oxmY573AQMGTE22XT8CXlfrlqoMnqQRk3+2LOGMGC2suxFJGIrYvMHT nSi0Rf1vDlUpDabBNDkE619BuLwBaQd6IumM7LK9wVTYCmgr4hnE/desy5rlYlX/1e2/ u30GfXORgW3DzPHLHUbhwVxkFffemQurTdULKY9AncNoPpqPx2UnfFs3iMdLyZpfwXt1 RbeTMeDxRddVRXA16+toP0X2fFJBXM3yI6pBB1Nq1ObIiFJnw0dqdfjS+Mrn6R2DnqoY Pq9g== X-Gm-Message-State: AMke39n+3xwUp5/oAVpmfIFOdzrJM+l72v2LWj+o2/85MU3R7U518sO3yVuoBphxLD++ng== X-Received: by 10.223.166.5 with SMTP id k5mr10902795wrc.134.1489075561607; Thu, 09 Mar 2017 08:06:01 -0800 (PST) Received: from [10.22.149.199] ([89.248.140.15]) by smtp.gmail.com with ESMTPSA id x69sm27839916wma.15.2017.03.09.08.06.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Mar 2017 08:06:01 -0800 (PST) To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-lmap-information-model.all@ietf.org From: Leif Johansson Message-ID: Date: Thu, 9 Mar 2017 17:06:00 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Subject: [secdir] secdir review of draft-ietf-lmap-information-model-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 16:06:06 -0000 Reviewer: Leif Johansson Review result: Has issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. Review: Section 3.8 begins "A Channel defines a bi-directional communication channel". First of all it is probably a good idea avoid using the term you're defining in the definition. Also in the text a Channel is described as a URL with the cert or CA of the endpoint but in the channel object definition there is only a reference to the credentials which I understood to be the client authn credential and not the server identity. This leads me to a larger issue (which may be answered in another LMAP document for all I know): what is the authentication model for LMAP? Specifically, does LMAP assume the standard Web PKI for channel end- points? If not, then you probably need to specify how to validate the server cert which may lead you to want to represent a private CA (say) in the channel object. In any case the authentication model should be referenced from the Security Considerations section and clearly match the information model for channels. Cheers Leif From nobody Thu Mar 9 08:54:03 2017 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 E4D0812948B; Thu, 9 Mar 2017 08:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 lr1izkleiMah; Thu, 9 Mar 2017 08:54:00 -0800 (PST) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 CF009128B44; Thu, 9 Mar 2017 08:54:00 -0800 (PST) Received: by mail-it0-x22a.google.com with SMTP id h10so132005865ith.1; Thu, 09 Mar 2017 08:54:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=jmE5hykQXucwIEq68YxtokGzM/Sn+zO04u9M+uvmp/o=; b=WSdAF72z7giv6Gw8PnshSLdZtlHkiaCKd8/VcvP3k8KwC90+gaQ+OFgQk3EaHroRGv 0WhpZvMne9UrXGxCHldG8cZtwYB80B4dWMcdUsv5o1oeYXbL/SP2by17UoimZU5FpbtF P3CrW7F4ZMVZ9Q8S6GS95roNAVOcgshvaYHNYbYwZaZb1leyibN64GtdqLL0ZzVOd2g3 ujO3c+dKngLxrx52SPXwdDocXj9Rdc9YKAuC2BAy0So+xWIXUHjGhp0dV5gVxdztBaA+ TfpRn+MdwCQLFsxYGXBjLQTsEYruEKqMdFx7tTqY4PoPSki0QP3D1XWU+C7sx/gak7g5 htAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=jmE5hykQXucwIEq68YxtokGzM/Sn+zO04u9M+uvmp/o=; b=U1CSR8VPX2bvhZjV4P9PBqQQJ9+YqZ5nwuKvWQIpzN2EP62BfBxGqInWVvZbcGtLwH PHStCRbCvUlFHAYhsf/8tSvuVzTWI05NziOawMAIWBljTqdQzmlhjmvx5exYedlUUcBc 4YWRgySSCoJ81hEhT9QAxgfbCPfdceBQVPae9k/ZuS8y8I+u2tSx+dMjPOnGFlL/Q9gC aqO7nhGlk/r9cQQ0SLhs85TUXvIbQgk+J28aJfGD+kTf2AJXIcUleQMRQLBkT2+Z/9xx f6S7MZ0lHXIDyORIWKF9l7A8h7xdIUc/qaiUP+9+byYxPWQywbpVcQ4rbYJeYLlNerTr QEmQ== X-Gm-Message-State: AMke39nemigSbhNKpBQgXE+8iy0fe04lCLvfB4v0p697YrOxgwTMVCx8yOgPA9lKp6UemBLj7ZJlRuldMccwRA== X-Received: by 10.36.118.68 with SMTP id z65mr30757954itb.59.1489078440001; Thu, 09 Mar 2017 08:54:00 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.107.187.7 with HTTP; Thu, 9 Mar 2017 08:53:59 -0800 (PST) In-Reply-To: <17893.1489070987@obiwan.sandelman.ca> References: <7752607e-ce49-f8f9-7f09-b3e842bc69b9@gmail.com> <3529ba25-09af-85dd-92da-aa9d30606bcc@gmail.com> <17893.1489070987@obiwan.sandelman.ca> From: Barry Leiba Date: Thu, 9 Mar 2017 11:53:59 -0500 X-Google-Sender-Auth: Y6Q64NEITJ3FyiIiTZrryh-JyEM Message-ID: To: Michael Richardson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-anima-grasp.all@ietf.org, Brian E Carpenter , anima@ietf.org, "secdir@ietf.org" Subject: Re: [secdir] [Anima] SecDir review of draft-ietf-anima-grasp-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 16:54:02 -0000 > > Personal opinion: encryption should be a MUST. > > I believe that we will have situations where we have a secured ACP into a NOC > (to an edge router or VM hypervisor), and then we will have some unencrypted, > but secured links to platforms in transition. > > It will be easy to add the GRASP daemon to answer resource requests to the > platform, but hard to add the ACP to that platform without a forklift > upgrade. > > This is why I think it is a SHOULD, as much as I want it to transition to > being a MUST. This brings up a common rant that I have: We should be putting into our protocol specs what we want the protocol to be, not some compromise that comes from knowing that not everyone will comply with everything from the start. If the right thing is to say "MUST encrypt", but we know there'll be a transition period during which that's not fully practical, then we should say that. Something like this added to Section 3.5.1: NEW In some cases there will be a transition period, in which it might not be practical to run with strong encryption right away. It's important to keep this period as short as possible, and to upgrade to a fully encrypted setup as soon as possible. END > > Once we specify byte-by-byte comparison, do we need to worry about this > > in a protocol document? If someone is silly enough to specify an > > It matters, when humans have to confirm things. I think that objectives > will be mostly baked into code. So, I agree with you, but I would rather > exclude all that UTF stuff too. That's true: if these really are protocol elements and there's no need to have them Internationalized for human consumption, perhaps limiting them to US-ASCII makes sense and avoids issues with odd character effects (code that breaks if certain characters appear in strings, or humans debugging things and being confused by characters that look the same but are encoded differently). On the other hand, if it really would be handy to be able to define objective names in Chinese, Hindi, or Hebrew, there's nothing wrong with sticking to UTF-8 as long as the possibilities are understood and folks are OK with it. Barry From nobody Thu Mar 9 09:29:01 2017 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 958B3126D74 for ; Thu, 9 Mar 2017 09:28:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 oequKjKcx2yh for ; Thu, 9 Mar 2017 09:28:55 -0800 (PST) Received: from smtp98.iad3a.emailsrvr.com (smtp98.iad3a.emailsrvr.com [173.203.187.98]) (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 4DF6C129595 for ; Thu, 9 Mar 2017 09:28:55 -0800 (PST) Received: from smtp21.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp21.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id EF39225D32; Thu, 9 Mar 2017 12:28:51 -0500 (EST) Received: from app40.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp21.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id DE71F25D1E; Thu, 9 Mar 2017 12:28:51 -0500 (EST) X-Sender-Id: scott@hyperthought.com Received: from app40.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Thu, 09 Mar 2017 12:28:51 -0500 Received: from hyperthought.com (localhost [127.0.0.1]) by app40.wa-webapps.iad3a (Postfix) with ESMTP id CDC21602A8; Thu, 9 Mar 2017 12:28:51 -0500 (EST) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Thu, 9 Mar 2017 09:28:51 -0800 (PST) Date: Thu, 9 Mar 2017 09:28:51 -0800 (PST) From: "Scott G. Kelly" To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-tls-rfc4492bis.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 X-Auth-ID: scott@hyperthought.com Message-ID: <1489080531.840519743@apps.rackspace.com> X-Mailer: webmail/12.7.10-RC Archived-At: Subject: [secdir] secdir review of draft-ietf-tls-rfc4492bis-14 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 17:28:56 -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 co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments.=0A=0AThis review is roughly a week late, I hope= it is still useful.=0A=0AI think the abstract is quite clear:=0A=0A This= document describes key exchange algorithms based on Elliptic=0A Curve Cr= yptography (ECC) for the Transport Layer Security (TLS)=0A protocol. In = particular, it specifies the use of Ephemeral Elliptic=0A Curve Diffie-He= llman (ECDHE) key agreement in a TLS handshake and the=0A use of Elliptic= Curve Digital Signature Algorithm (ECDSA) and Edwards=0A Digital Signatu= re Algorithm (EdDSA) as authentication mechanisms.=0A=0AI currently have li= ttle expertise in ECC, so please view my comments accordingly. Security con= siderations are described throughout the document, and there is also a thor= ough security considerations section. Yoav and Simon are well known to the = IETF security community, and have been actively involved in ECC-related sec= urity discussions in cfrg, so with the qualification that I am not expert i= n this area, I don't see any issues with this document.=0A=0A--Scott From nobody Thu Mar 9 11:37:53 2017 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 AB1F9129487; Thu, 9 Mar 2017 11:37:48 -0800 (PST) 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 6V5VotZqdRYU; Thu, 9 Mar 2017 11:37:47 -0800 (PST) Received: from mail-pf0-x241.google.com (mail-pf0-x241.google.com [IPv6:2607:f8b0:400e:c00::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 958CD129464; Thu, 9 Mar 2017 11:37:47 -0800 (PST) Received: by mail-pf0-x241.google.com with SMTP id j5so8235455pfb.3; Thu, 09 Mar 2017 11:37:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=cYOum7V3ozoU6HK/r4s1+GdvvgcERKcAnStAvjq9wL4=; b=iXlM1GF5eMtItB7me/w6XWH4t/QzljGH7EOfDriAnTPHzBRadWZl1gptFJmT0aIBs9 bmv4QxmYMotweBh+MaFd+vzFFrYuxEEnoDab/HT8Xht82wpHmYzTmJ3cU9wrHEwtQiEX +7vV3FwA+H+4DQdaUJK/a8DtP3lqmtK6/nVrAW4Lgrj7JPiiW2xTw/3+JUHGXpkBLxTw UqBs+tlkYdCEaL5apsn5YUkEEY2RjcLKSkxOLA16wZjz0Q0Ru+GbC4Sugd8gvlFkukVS Tk/OA9XNx5vWEUSEzaaJLUFH1C8zhKKYfqZ9Xr0OEI//+nstC0W3nRUn4ZxfijC5LPWN 8hLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=cYOum7V3ozoU6HK/r4s1+GdvvgcERKcAnStAvjq9wL4=; b=WpeBTwSEhZQiChPmBzMMxGwxzeYCKA76Bn0iXHOSCdZqSPVZjAHG8/HbLRqYnjj3U9 xUQJQ0gUU9grNZFXN8IDtay42u0D3B+KMwplp47C370tlQjRDfR9EEiTpeX2rlHAA6/o ubd7yLx7Mft+k9NR3EuwHXSmTHujTOVT9t8mLBGCBzdOyjDd4tovst9Mm7pj6qcHF1U2 WKlPHrG+a4HBU/jlGug2EaGr3H1Iix+fdqB1ayijnuNjXv6Sx4rf01el15vn7tHG5lgt 3TT486u++r05T6F3ghsgIfJqe2APlCDRYo8dCqLnpcMxa/vYih7SCGoILmdi0/1DBKoN SM5Q== X-Gm-Message-State: AMke39nz3qFAK66e683AAH4KO8Lj1NEOCx465pFdVxa1mrvTQR4b26zJbQL+5lUwUDFfqQ== X-Received: by 10.84.229.137 with SMTP id c9mr19780460plk.41.1489088267161; Thu, 09 Mar 2017 11:37:47 -0800 (PST) Received: from ?IPv6:2406:e007:4e09:1:28cc:dc4c:9703:6781? ([2406:e007:4e09:1:28cc:dc4c:9703:6781]) by smtp.gmail.com with ESMTPSA id 194sm13973771pfx.134.2017.03.09.11.37.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 09 Mar 2017 11:37:46 -0800 (PST) To: Barry Leiba , Michael Richardson References: <7752607e-ce49-f8f9-7f09-b3e842bc69b9@gmail.com> <3529ba25-09af-85dd-92da-aa9d30606bcc@gmail.com> <17893.1489070987@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <63103cc5-1c99-78eb-04a4-d8e44c2e6185@gmail.com> Date: Fri, 10 Mar 2017 08:37:50 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org, "secdir@ietf.org" Subject: Re: [secdir] [Anima] SecDir review of draft-ietf-anima-grasp-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 19:37:49 -0000 On 10/03/2017 05:53, Barry Leiba wrote: >> > Personal opinion: encryption should be a MUST. >> >> I believe that we will have situations where we have a secured ACP into a NOC >> (to an edge router or VM hypervisor), and then we will have some unencrypted, >> but secured links to platforms in transition. >> >> It will be easy to add the GRASP daemon to answer resource requests to the >> platform, but hard to add the ACP to that platform without a forklift >> upgrade. >> >> This is why I think it is a SHOULD, as much as I want it to transition to >> being a MUST. > > This brings up a common rant that I have: > We should be putting into our protocol specs what we want the protocol > to be, not some compromise that comes from knowing that not everyone > will comply with everything from the start. > > If the right thing is to say "MUST encrypt", but we know there'll be a > transition period during which that's not fully practical, then we > should say that. Something like this added to Section 3.5.1: > > NEW > In some cases there will be a transition period, in which it might not > be practical to run with strong encryption right away. It's important > to keep this period as short as possible, and to upgrade to a fully > encrypted setup as soon as possible. > END or perhaps more precisely: During initialization of nodes there will be a transition period... Whether this is phrased as an exception to the MUST or as the justification for ignoring the SHOULD is a matter of taste, I think. > >> > Once we specify byte-by-byte comparison, do we need to worry about this >> > in a protocol document? If someone is silly enough to specify an >> >> It matters, when humans have to confirm things. I think that objectives >> will be mostly baked into code. So, I agree with you, but I would rather >> exclude all that UTF stuff too. > > That's true: if these really are protocol elements and there's no need > to have them Internationalized for human consumption, perhaps limiting > them to US-ASCII makes sense and avoids issues with odd character > effects (code that breaks if certain characters appear in strings, or > humans debugging things and being confused by characters that look the > same but are encoded differently). On the other hand, if it really > would be handy to be able to define objective names in Chinese, Hindi, > or Hebrew, there's nothing wrong with sticking to UTF-8 as long as the > possibilities are understood and folks are OK with it. My thought was that these names will sometimes be visible to humans so why not allow localized names? If GRASP succeeds it might be used for local applications, not just generic applications. So I'd rather allow it from the start, and if we have to add character-set restrictions later, so be it. Brian From nobody Thu Mar 9 12:00:03 2017 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 0E687129413; Thu, 9 Mar 2017 12:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 iNMMoQUMKquG; Thu, 9 Mar 2017 12:00:00 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (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 91F311293E1; Thu, 9 Mar 2017 11:53:48 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id l7so35439382ioe.3; Thu, 09 Mar 2017 11:53:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=DkCF+UmvGJ0tMtALYFtN6asNkMdqkAbikZguw1tQcbI=; b=iob793nxeXmuzsztqtVrfSS1kf7UC8qN6VAc32fSQonTmsiU/quEf2HyTVJdxW9ULJ HrgR3W3MygO8gG2+Byu5baDduVibjzp+q6YgXoh4/a1/yZqdysddTSB8M1qi5t1Lgohj WaqB+SM9gpFTWd2rLcIKtcp9M8IozStm85cnSaY3TEhktHtgecP7kL3q7+dRAcoorrQq bDnuzQlWyMqlGvjWlqyncTibGAuVCmxKGpLu0nx7JuapcYGEPXROGC7U7X5Vp/i8xwbE tgjgyiYPbz9a3SeRmkg+Z93Gv36exJK3DQT97Y0+d1BPaH5RbyP2CIF2sjEFv0IPmsaN NJlA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=DkCF+UmvGJ0tMtALYFtN6asNkMdqkAbikZguw1tQcbI=; b=nDbnuo2qO7CBycYMDsUp0ehrq36EME/hZ+ELjSbjeowxRmTmhZURfSxhbfdM7nGMiA aUfFa7fj3JBq+JCL4fF+JfCaCOg+rD6eXTlYtZi70si8YeGGOCAdSOWkOlL6RTwquikx u0BfhhvGyMIwSGh9HixSIRYg+YjTrROh2k1QET/92i3vezkvgFOUVletnCHCzoUzqDD9 kKrVa7d4QsG58/zxVz1c9kBNLoIpHjNCM2wy7zgnldNDAs4GTCbWfRRwcXuj+rxtheC0 Xuvfa0CTUWXrjydjP0JaIUeoC950YNJjyaW1FO+vsmkce7gaJRWHH5hf53xY878WgPeJ /5qw== X-Gm-Message-State: AMke39nBpR44BFEAsLUyL2UVS7nt9ko0a+UJoCfT6lidEk8PixZPlrpyfmORIBeQOFL5yaT+K4IIkEdsGCcy4A== X-Received: by 10.107.182.9 with SMTP id g9mr11747515iof.233.1489089227965; Thu, 09 Mar 2017 11:53:47 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.107.187.7 with HTTP; Thu, 9 Mar 2017 11:53:47 -0800 (PST) In-Reply-To: <63103cc5-1c99-78eb-04a4-d8e44c2e6185@gmail.com> References: <7752607e-ce49-f8f9-7f09-b3e842bc69b9@gmail.com> <3529ba25-09af-85dd-92da-aa9d30606bcc@gmail.com> <17893.1489070987@obiwan.sandelman.ca> <63103cc5-1c99-78eb-04a4-d8e44c2e6185@gmail.com> From: Barry Leiba Date: Thu, 9 Mar 2017 14:53:47 -0500 X-Google-Sender-Auth: 6P0-7rtfBkJQ3IxvciGz9hs6mWo Message-ID: To: Brian E Carpenter Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Michael Richardson , draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org, "secdir@ietf.org" Subject: Re: [secdir] [Anima] SecDir review of draft-ietf-anima-grasp-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Mar 2017 20:00:01 -0000 >> This brings up a common rant that I have: >> We should be putting into our protocol specs what we want the protocol >> to be, not some compromise that comes from knowing that not everyone >> will comply with everything from the start. >> >> If the right thing is to say "MUST encrypt", but we know there'll be a >> transition period during which that's not fully practical, then we >> should say that. Something like this added to Section 3.5.1: >> >> NEW >> In some cases there will be a transition period, in which it might not >> be practical to run with strong encryption right away. It's important >> to keep this period as short as possible, and to upgrade to a fully >> encrypted setup as soon as possible. >> END > > or perhaps more precisely: > > During initialization of nodes there will be a transition period... Yep; better. > Whether this is phrased as an exception to the MUST or as the justification > for ignoring the SHOULD is a matter of taste, I think. I don't think it's a question of taste. If there's a long-term reason to run nodes without encryption, then SHOULD might make sense. But if we do expect the stable state to always be encrypted, and avoiding it is a short-term expedient that we want to have go away as soon as possible, then the protocol should say MUST, and the exception is clearly specified as a brief thing that mustn't last. It's a substantive difference, not one of writing style. > My thought was that these names will sometimes be visible to humans so why > not allow localized names? If GRASP succeeds it might be used for local > applications, not just generic applications. So I'd rather allow it > from the start, and if we have to add character-set restrictions later, > so be it. Makes sense to me. Carry on. Barry From nobody Fri Mar 10 08:45:48 2017 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 7FCA81295FD; Fri, 10 Mar 2017 08:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 pgg1Tw7BUijR; Fri, 10 Mar 2017 08:45:46 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E991F12949E; Fri, 10 Mar 2017 08:45:45 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 78A82E20F; Fri, 10 Mar 2017 12:08:33 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 2573F6381A; Fri, 10 Mar 2017 11:45:44 -0500 (EST) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <63103cc5-1c99-78eb-04a4-d8e44c2e6185@gmail.com> References: <7752607e-ce49-f8f9-7f09-b3e842bc69b9@gmail.com> <3529ba25-09af-85dd-92da-aa9d30606bcc@gmail.com> <17893.1489070987@obiwan.sandelman.ca> <63103cc5-1c99-78eb-04a4-d8e44c2e6185@gmail.com> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: Barry Leiba , draft-ietf-anima-grasp.all@ietf.org, anima@ietf.org, "secdir@ietf.org" Subject: Re: [secdir] [Anima] SecDir review of draft-ietf-anima-grasp-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 16:45:47 -0000 --=-=-= Content-Type: text/plain Brian E Carpenter wrote: >> NEW In some cases there will be a transition period, in which it might >> not be practical to run with strong encryption right away. It's >> important to keep this period as short as possible, and to upgrade to >> a fully encrypted setup as soon as possible. END > or perhaps more precisely: > During initialization of nodes there will be a transition period... Brian, by "initialization", do you mean bootstrapping? > Whether this is phrased as an exception to the MUST or as the > justification for ignoring the SHOULD is a matter of taste, I think. I am saying that there will be a period where legacy NOC elements will be placed into a kind of "ACP container" --- the ACP encryption will not extended into the "operating system" where the NOC element is, but likely terminated "in the stack" or "in the wire". (cf: Bump in the Stack, Bump in the Wire https://tools.ietf.org/html/rfc4301#section-3.3 ) >> or Hebrew, there's nothing wrong with sticking to UTF-8 as long as the >> possibilities are understood and folks are OK with it. > My thought was that these names will sometimes be visible to humans so > why not allow localized names? If GRASP succeeds it might be used for > local applications, not just generic applications. So I'd rather allow > it from the start, and if we have to add character-set restrictions > later, so be it. Barry, is there a way to say, "UTF-8 without all the confusing parts"? Is that what IDNxxxx is all about? -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAljC2DcACgkQgItw+93Q 3WW0owgAksTbPRz7ZbphxU7q48/gfrLs6QTUhc5fA0nScKCYQYYhM20LQ3ZPEeOS bAKmZg4Zoi/nDEw+nvzGmMijaAlz3TjOG50RfVWPfSmrU3RDNHgvV4E3zj3ZsymH kT6KhI7goxWZOCZEtfqV+THMtoiAm27nnMv/+Py6owlf2+iOVgZOkFcBMr0hRC+1 b56BTHLvIO/aXnzeuxtXslfF+h4LwaaK2xaOHeCfoY49BYTW8x9eRfSLyl+5tUMM r/bNKKCUaGNQrpR8GsGx86aSKaGzuolRZCh1RGq1sqN2iaHSpG3YgW93k7evaq9T UR3bS8MxTMPN+W6zO3DmFTEYsVxZgQ== =0lFs -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 10 10:02:34 2017 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 D4AB51294BE; Fri, 10 Mar 2017 10:02:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.229, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 gkNDRey3UF5Z; Fri, 10 Mar 2017 10:02:18 -0800 (PST) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 97A941294DD; Fri, 10 Mar 2017 10:02:18 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id w124so495563itb.0; Fri, 10 Mar 2017 10:02:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=yNzzC1AEBBuRX3HEkcYyfVn2YHEgXZxCmVZDk/0RJVA=; b=U2or3/4g8eirCeAtSvMJm8xy8Cqmj3oOs8lBRlFrnpIVSQuSI0vAfUcNrmL7Q6zeIp Y5nnciOAsF3it2WnvTyvHGyM7L5lK/nhUx6UaqgnSBOOVzksmGSsvSBewL6aF3SNaNX0 dNW/qQY2PRHi6q7S944V9tYCfXrN5SYqlXn8+tnsrVAKZ4bCoVfhMzYab2LGcLSa4TJQ S0HdCKGGFFrBgNrJtC3yT01s30/Wdp7/tZzAYOBjGnznxhmADupmsrSUKcAG8smuBys+ tkOYVx9NyEh0JlQLECP0796mGSgUGTCNe8Tmz9plkKfuIK7Fy+kb+qIr/p3fvXVferYg rIRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=yNzzC1AEBBuRX3HEkcYyfVn2YHEgXZxCmVZDk/0RJVA=; b=YAOC/IFwqClDQvq+wKxcOzl+/aLgrovTBaiSpOshAZQamz/kAXzhy6lP2vH+9wR1Ds rjFXkvQIq0bG2ovp45L0hFvKEH+dKr/fQPvJkN9Hq8Wk9GScdJbhvlvdzOU8gnPRtvZU gM6Bq0Wb1AvRGZM/+NBA+2j5pKnvGFsixL7JpHFF3m57vFHqt7sTT4IVCAy+oqHtD+A6 8CqfNkB0htUrFUT8RMzpRVSm38Uswh0lqJyPmlIO4oW4CR+irxBOS74AVwnd5KHCrCb5 7jSZ0PN2ML0z923iTLiDzZbh2FjWHmk6RzsK0x+cHonDMIaAdr2Ko28K7vXBxw+wY80x TAkg== X-Gm-Message-State: AFeK/H16fIBL/gcblRTxbxiyQ9VtiC11o3xXF0T5pT6twqVsNzkmlKqCeQWCj9Cle2VqELUENX1TwUZC4bVPgw== X-Received: by 10.36.159.195 with SMTP id c186mr280301ite.32.1489168937970; Fri, 10 Mar 2017 10:02:17 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba@gmail.com Received: by 10.107.187.7 with HTTP; Fri, 10 Mar 2017 10:02:17 -0800 (PST) In-Reply-To: <31318.1489164344@obiwan.sandelman.ca> References: <7752607e-ce49-f8f9-7f09-b3e842bc69b9@gmail.com> <3529ba25-09af-85dd-92da-aa9d30606bcc@gmail.com> <17893.1489070987@obiwan.sandelman.ca> <63103cc5-1c99-78eb-04a4-d8e44c2e6185@gmail.com> <31318.1489164344@obiwan.sandelman.ca> From: Barry Leiba Date: Fri, 10 Mar 2017 13:02:17 -0500 X-Google-Sender-Auth: Cx8GmuFN5e78J0IDmvfxd3e23_I Message-ID: To: Michael Richardson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: draft-ietf-anima-grasp.all@ietf.org, Brian E Carpenter , anima@ietf.org, "secdir@ietf.org" Subject: Re: [secdir] [Anima] SecDir review of draft-ietf-anima-grasp-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 18:02:21 -0000 > Barry, is there a way to say, "UTF-8 without all the confusing parts"? > Is that what IDNxxxx is all about? Kinda-sorta, but it won't quite work for this. The high-order answer is to reference IDNA 2008 (RFC 5892 will do) and say that characters that are PVALID are acceptable here. The trouble with that is that it limits you to lower case characters: all the upper case characters are DISALLOWED. It could work to say "PVALID characters and their upper case versions." But, really, I think Brian's right that we don't need to worry, especially because there's the designated expert in the middle, who can say, "PILE OF POO"? Really? Why do you want to use that character? Barry From nobody Fri Mar 10 13:21:33 2017 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 29A8A12946A; Fri, 10 Mar 2017 13:21:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 mWVRczAssozH; Fri, 10 Mar 2017 13:21:28 -0800 (PST) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF073129452; Fri, 10 Mar 2017 13:21:27 -0800 (PST) Received: by mail-ot0-x22e.google.com with SMTP id i1so84570927ota.3; Fri, 10 Mar 2017 13:21:27 -0800 (PST) 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=upuXRDAnmIXGLm4so76IfywgJ11uvpwvEQI6ecOdSxk=; b=TMX3RtD59TdMr9cbvsa31GKLOzSQZjZrFZmekSLAFVWnQhkzGvXMRr7HPF7SqScioH uVyq6ahAIMeUhTWpdoliPbXEi2lrmWF6tld0gpadcb1ZwBLxh9APq7Ci4Pa8sKJwNixg cFTBU0VYMw7NRyRP/Cd9gtpy1LVkt6K3gLjqc7utVxAIVltsM/GbRxcWZAvoNMgxvaex koyB/vlYwI4fWQ0oU8v/I/0lhBcNqsKJ6miEVGvYQ1Nycji+EDEu1+bs1Gjc2CJXGn1x gUWcuMOdSmuivwwUcoocumWI0g410vMi7UT3rDgOJt9RFg/2Y+0dyBk7BypdovlT57pz iOCA== 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=upuXRDAnmIXGLm4so76IfywgJ11uvpwvEQI6ecOdSxk=; b=C7n1+WwIQRqpg1bYqCWNxaT1OwZG34of/vVwAhC3eqIbpXLrwLFiPoSHL9wDjo2iwM mwNONXR/XXIy2eRpKgjksmhubHLkF+vMaH+glg0OTju4LUhHZndkVZSdC1jDwlzUxcyH 5D409rWiikZY98WE1J5n3rhq22mKdwdGvnen4UqDjNHBt5b/BNSFLsrnbmY1OGa02M5V l/qpVF6xpYPrrGcAqX4NmVr17PgsduxkrLV/mnvis1mHEt0Dzmojo0vg7S0ViRcCVOjq g25f/c2oSbSmj3Jw2NCiQY0geMlZmK1skwKcA0iIuBpW/SZrS6g9XlIxnU8X2kK+iDoA NSRA== X-Gm-Message-State: AMke39nNF6TLE9dLxXXUFF1JsIu0+hPlcXwGj61I8gx71FDIKAfy8LA4kFVwAXrM0Mfp/MXzeAqhbLaItONnrw== X-Received: by 10.157.20.102 with SMTP id h93mr10385462oth.73.1489180886939; Fri, 10 Mar 2017 13:21:26 -0800 (PST) MIME-Version: 1.0 From: Adam Montville Date: Fri, 10 Mar 2017 21:21:16 +0000 Message-ID: To: The IESG , "secdir@ietf.org" , draft-ietf-sipcore-status-unwanted.all@ietf.org Content-Type: multipart/alternative; boundary=001a1135adb0c5bfe8054a66f129 Archived-At: Subject: [secdir] secdir review of draft-ietf-sipcore-status-unwanted X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 21:21:29 -0000 --001a1135adb0c5bfe8054a66f129 Content-Type: text/plain; charset=UTF-8 I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This draft is ready with (possible) issues. This draft defines a new SIP response code, 666 "Unwanted", which allows called parties to indicate when a call is unwanted. The intent of the Unwanted response code is to provide feedback to global or user-specific filtering algorithms (implemented by carriers) from the context of a SIP-initiated call. >From a security perspective, there's nothing wrong with the draft, and the Security Considerations section addresses what one might expect (denial of service, relying on the code only when authenticated caller identities are in play, etc.) It seems that the biggest risk is false blocks, callers having their feelings hurt, or folks not getting the calls they may expect -- but implementers are made aware of these. A potential issue can be seen by taking these two sentences together: "Implementations will have to make appropriate trade-offs between falsely labeling a caller as unwanted and delivering unwanted calls", "The service provider...MAY report the calling party identity to government authorities". This gives rise to the possibility that a mislabeled caller could be reported to authorities, when there is no real reason for such. Either way, I found the document to be clear and well-written. And while I list the draft as "ready with issues" here, it may be the case that there are no issues from the perspective of the ADs for whom I have performed this review. Kind regards, Adam --001a1135adb0c5bfe8054a66f129 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed this document as part of the security= directorate's ongoing effort to review all IETF documents being proces= sed by the IESG.=C2=A0 These comments were written primarily for the benefi= t of the security area directors.=C2=A0 Document editors and WG chairs shou= ld treat these comments just like any other last call comments.
<= br>
This draft is ready with (possible) issues.

This draft defines a new SIP response code, 666 "Unwanted"= ;, which allows called parties to indicate when a call is unwanted.=C2=A0 T= he intent of the Unwanted response code is to provide feedback to global or= user-specific filtering algorithms (implemented by carriers) from the cont= ext of a SIP-initiated call.=C2=A0

From a security= perspective, there's nothing wrong with the draft, and the Security Co= nsiderations section addresses what one might expect (denial of service, re= lying on the code only when authenticated caller identities are in play, et= c.) =C2=A0It seems that the biggest risk is false blocks, callers having th= eir feelings hurt, or folks not getting the calls they may expect -- but im= plementers are made aware of these.

A potential is= sue can be seen by taking these two sentences together: "Implementatio= ns will have to make appropriate trade-offs between falsely labeling a call= er as unwanted and delivering unwanted calls", "The service provi= der...MAY report the calling party identity to government authorities"= .=C2=A0 This gives rise to the possibility that a mislabeled caller could b= e reported to authorities, when there is no real reason for such.

Either way, I found the document to be clear and well-writt= en.=C2=A0 And while I list the draft as "ready with issues" here,= it may be the case that there are no issues from the perspective of the AD= s for whom I have performed this review.

Kind rega= rds,

Adam
--001a1135adb0c5bfe8054a66f129-- From nobody Fri Mar 10 15:36:52 2017 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 77BE9129490; Fri, 10 Mar 2017 15:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-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 WX8HfWnaZ1xC; Fri, 10 Mar 2017 15:36:47 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 54FED129462; Fri, 10 Mar 2017 15:36:44 -0800 (PST) Received: from thinny.local (69-12-173-8.static.dsltransport.net [69.12.173.8]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by colo.trepanning.net (Postfix) with ESMTPSA id 123D1102241F0; Fri, 10 Mar 2017 15:36:44 -0800 (PST) From: Dan Harkins To: "iesg@ietf.org" , secdir@ietf.org, draft-ietf-rtcweb-overview.all@ietf.org Message-ID: <97ebdafb-439f-8dee-bd55-cc24eb44b287@lounge.org> Date: Fri, 10 Mar 2017 15:36:41 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------25961B6562F3BE97A846FFDE" Archived-At: Subject: [secdir] secdir review of draft-ietf-rtcweb-overview X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Mar 2017 23:36:48 -0000 This is a multi-part message in MIME format. --------------25961B6562F3BE97A846FFDE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Greetings, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This I-D is an "Applicability Statement" and does not describe a protocol but, instead, a set of building blocks that should be accessible through a Javascript API in a standard browser. These building blocks are supposed to allow browsers to communicate with each other using real-time services. The requirements this I-D places on implementations is to implement some other I-D or RFC, and that includes security relevant requirements. I did not follow the references and look at the WebRTC security draft or the WebRTC security architecture draft. As it really doesn't provide any new protocol there really aren't any security relevant vectors to look at. Having said that, the Security Considerations are well done by enumerating the points of concern regarding web-enabled real-time communications. This document is READY for publication. regards, Dan. --------------25961B6562F3BE97A846FFDE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
  Greetings,
  I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the 
IESG.  These comments were written primarily for the benefit of the 
security area directors.  Document editors and WG chairs should treat 
these comments just like any other last call comments.
  This I-D is an "Applicability Statement" and does not describe a protocol
but, instead, a set of building blocks that should be accessible through
a Javascript API in a standard browser. These building blocks are supposed
to allow browsers to communicate with each other using real-time services.

  The requirements this I-D places on implementations is to implement
some other I-D or RFC, and that includes security relevant requirements.
I did not follow the references and look at the WebRTC security draft or
the WebRTC security architecture draft.

  As it really doesn't provide any new protocol there really aren't any
security relevant vectors to look at. Having said that, the Security
Considerations are well done by enumerating the points of concern regarding
web-enabled real-time communications.

  This document is READY for publication.

  regards,

  Dan.


 --------------25961B6562F3BE97A846FFDE-- From nobody Fri Mar 10 18:09:15 2017 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 5C54B129531 for ; Fri, 10 Mar 2017 18:09:05 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ccil-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 pnben3yxtWEV for ; Fri, 10 Mar 2017 18:09:04 -0800 (PST) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::233]) (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 DC31C129538 for ; Fri, 10 Mar 2017 18:08:57 -0800 (PST) Received: by mail-wr0-x233.google.com with SMTP id g10so74736854wrg.2 for ; Fri, 10 Mar 2017 18:08:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=09DcN8lr70VIKGmVSwBDfg4zFIJpN6+l9pPEM7I/2II=; b=AaNY1fO0w02ZlBqNKKJXurf6/N9ERh4CY8zf52eHGWar/akzNoxnYnPA7EIQDAXKLg IY7xNJyuUiXbRWmg6ZyTI5Z3WBiCP73RP0UvVHZmTDHpZV5S8sN2XiAvZv+cy0CR8m8V 7ZVozdONfvTr4Pr+TPx61LWk3/LkImM4DsPNsm1luehm2yfJAKh7ANBN58oqfSEVSYgA e5gbkL7tGLN3sm5LCGcsBhb94P5xewC8dwm9ktsioxADkFdBzG7rCpY5ZGlSBY0f9y+j alMowvOhGnLFoP9v5v5GQP25GSF1YyyGJ/oHqjVl7dt6WGRxIYRJZkUB28917imtsaNb hVbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=09DcN8lr70VIKGmVSwBDfg4zFIJpN6+l9pPEM7I/2II=; b=Cod1xsOBW+7PQ7C8amlApH8pEZNPVbAeOZdh83Ew7ajKafkXLnwyM4KPnAs1VRCI+f IW/08n+zq57al9u01B4UmfO6eBWM/4xUuOnicCFaOJR/jdX1YdsG4YwNC+yHXAYDrLGy jpeIefJ5tVxDdFZWY5j35rYK1FuFuE4L6hN3RSsyw1QtxkKBHfJxfjMkCankA3pyX2cv Gu6oReaKQ/xg3ZfAW25/YUTYkO/CyRiLb7G+UTGO5XPKN99ovhwVzchEScvKtqdozfvt U0++xSYtZBvByLs9+rNlH+BSsGembxii+oeAQp5YZN2T6x75b7tRSRty2KUIxbzQXoWz /S2w== X-Gm-Message-State: AMke39lHvbSwDafOJ6SS7CJTXMBDXJBLZCxNA0h7Rgeata0xx9UjP/P9ND/dnbGwoTvr6Ig1HgqnV4U10t8SpyzM X-Received: by 10.223.152.215 with SMTP id w81mr20250782wrb.151.1489198136300; Fri, 10 Mar 2017 18:08:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.181.14 with HTTP; Fri, 10 Mar 2017 18:08:35 -0800 (PST) In-Reply-To: <20170309055348.GL30306@kduck.kaduk.org> References: <20170308014823.GF30306@kduck.kaduk.org> <382aa5c8-c977-b24d-4d19-251257833b00@gmx.de> <456b4234-0d94-1033-507c-710878bb5159@gmx.de> <20170309055348.GL30306@kduck.kaduk.org> From: John Cowan Date: Fri, 10 Mar 2017 21:08:35 -0500 Message-ID: To: Benjamin Kaduk Content-Type: multipart/alternative; boundary=001a113c36a6ea2d48054a6af5a1 Archived-At: Cc: Julian Reschke , draft-ietf-jsonbis-rfc7159bis.all@ietf.org, secdir@ietf.org, ietf@ietf.org, "json@ietf.org" Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 02:09:05 -0000 --001a113c36a6ea2d48054a6af5a1 Content-Type: text/plain; charset=UTF-8 On Thu, Mar 9, 2017 at 12:53 AM, Benjamin Kaduk wrote: If that's what's supposed to happen, it should probably be more > clear, yes. (But aren't there texts that have valid interpretations > in multiple encodings?) > Not if the content is well-formed JSON and the only possible encodings are UTF-8, UTF-16, and UTF-32. It suffices to examine the first four bytes of the input. If there are no NUL bytes in the first four bytes, it is UTF-8; if there are two NUL bytes, it is UTF-16; if there are three NUL bytes, it is UTF-32. This works because the grammar requires the first character to be in the ASCII repertoire, and the NUL *character* (U+0000) is not allowed at all. -- John Cowan http://vrici.lojban.org/~cowan cowan@ccil.org I don't know half of you half as well as I should like, and I like less than half of you half as well as you deserve. --Bilbo --001a113c36a6ea2d48054a6af5a1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Mar 9, 2017 at 12:53 AM, Benjamin Kaduk <kaduk@mit.edu> = wrote:

If that's what's supposed to happen, = it should probably be more
clear, yes.=C2=A0 (But aren't there texts that have valid interpretatio= ns
in multiple encodings?)

Not if the content = is well-formed JSON and the only possible encodings are UTF-8, UTF-16, and = UTF-32.=C2=A0 It suffices to examine the first four bytes of the input.=C2= =A0 If there are no NUL bytes=C2=A0in the first four bytes, it is UTF-8; if= there are two NUL bytes, it is UTF-16; if there are three NUL bytes, it is= UTF-32.=C2=A0 This works because the grammar requires the first character = to be in the ASCII repertoire, and the NUL *character* (U+0000) is not allo= wed at all.

--=C2=A0
J= ohn Cowan =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0http://vrici.lojban.org/~cowan =C2=A0 =C2=A0 =C2=A0 =C2=A0<= a href=3D"mailto:cowan@ccil.org">cowan@ccil.org
I don't know half of you half as well as I should like, and I = like less
than half of you half as well as = you deserve. =C2=A0--Bilbo

=
--001a113c36a6ea2d48054a6af5a1-- From nobody Fri Mar 10 18:22:12 2017 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 3B57812950E; Fri, 10 Mar 2017 18:22:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.19 X-Spam-Level: * X-Spam-Status: No, score=1.19 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L4=0.001, RCVD_IN_XBL=0.375, SPF_FAIL=0.001, SPF_HELO_FAIL=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sO8waCd6ResP; Fri, 10 Mar 2017 18:21:55 -0800 (PST) Received: from uocyb.mail.ru (24-205-251-42.static.snlo.ca.charter.com [24.205.251.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4FCA0129569; Fri, 10 Mar 2017 18:21:35 -0800 (PST) From: "bensons" To: agenda@ietf.org, "wgchairs-bounces" , "draft-ghanwani-nvo3-mcast-framework" , "IETF-Draft Submission Queue via RT" , "sfc" , "pcn" , "secdir" Date: Fri, 10 Mar 2017 22:20:52 -0400 Message-ID: <1117415111.20170311052052@queuefull.net> Content-Type: multipart/alternative; boundary="----=_NextPart_000_0007_01488FA7.1DE13791" Content-Language: en MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] =?utf-8?q?crazy!?= X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 02:22:00 -0000 ------=_NextPart_000_0007_01488FA7.1DE13791 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGV5IGZyaWVuZCwgDQoNCg0KSSd2ZSBqdXN0IHNlZW4gc29tZXRoaW5nIHJlYWxseSBjcmF6eSwg anVzdCB0YWtlIGEgIGxvb2sgIGF0IHRoYXQsIHlvdSdyZSBnb2luZyB0byBiZSBzdXJwcmlzZWQg IGh0dHA6Ly9mb2xsb3cuYmV0dGVyYmx1bnQuY29tLzQ4NDkNCg0KV2lzaGVzLCBiZW5zb25zDQoN Cg== ------=_NextPart_000_0007_01488FA7.1DE13791 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hey friend,

 

 

I've just seen something really crazy, just take a look at that, y= ou're going to be surprised message

 

Wishes, bensons

------=_NextPart_000_0007_01488FA7.1DE13791-- From nobody Fri Mar 10 22:13:02 2017 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 60964129469; Fri, 10 Mar 2017 22:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 rnqyjii5-GiD; Fri, 10 Mar 2017 22:12:52 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 065CD128BA2; Fri, 10 Mar 2017 22:12:51 -0800 (PST) Received: from [192.168.178.20] ([93.217.121.40]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LhNwC-1cQSw22LQW-00maWB; Sat, 11 Mar 2017 07:12:46 +0100 To: John Cowan , Benjamin Kaduk References: <20170308014823.GF30306@kduck.kaduk.org> <382aa5c8-c977-b24d-4d19-251257833b00@gmx.de> <456b4234-0d94-1033-507c-710878bb5159@gmx.de> <20170309055348.GL30306@kduck.kaduk.org> From: Julian Reschke Message-ID: Date: Sat, 11 Mar 2017 07:12:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:LCf1AaG3eRDHEgm3RLe10joYTBzTE+NJvIdrjH8yV4V+orhcr+k BhzWYehxmeNAzrC4qfYOiu1WDRVldvGFCKvMf2NuUZMz28aYJ1E/4W1SFUOEdLQsgW4qIkF tzCy6LzoWLe9wXy4TEQOjHTKu1MqS1U6etzGLjI25S8lAVPOCMHgCWUMUnQgIeA+F9exGIW UEvzgwtXFWTfeWd24so0Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:japFPxPXC5Q=:N+IIWiOcKYz/pHLBgRumPI 6qVqJqSP5KVQIw7VeyNZIn+ZE1QXz4GDRT86zqMl9dsv/WBoYlFfvhUiOEMTGzIj4ST31HEFB LYrSlt4x939UQuKFHlGbdmmYzgUMQQRvmeqh966bEX0Pooq7bXB2rzzmTd6x/KmMro07V6NQJ xNAkaGbMQWOVuqLpEFHJIPj8VDezsryKVQ2Yf7+bARo/l1ehz7G5lbZBjo/LKdY3CCB9GDKt3 wFanGcqyvLUYpcc0Whqc73t058dvQMcq8OnM/tbxrL0LzOeQyJG2j2Zgt/HykkT5kTxFku0Sf vPDM6vcoGvskLn2IxNQoscQJ5IkdXccq2SUkUzn9DZUGRu88lwuui45j7dnKVfrbDgHU47hoq WEB6qE0AeDFr7+nMI7q3csnEcZVeyl7Iq+dKLeOzyO7W25C7HAWAJFaIMsHT23w6DuaneBzDa OyYrTwcgNqV354e1W0g1sv652QoJ2cqJgKRu+3UrbEKaUvL6ue3uHpntbPRuPyIgmNXF6ZJCD Qk0gMqHoVcoC8mv/tpp59a8wSn9gx2UcDKFDWJEkVKAMMjgolIUS6SSX+OT6JJOTt865mpIDU gcGTtnHDRq17MFVHDFxb/uqgz0sdTNYonmzRC0PjEy455eBmWVJDqPbZTMX5aG63AOt/sBC/t 1ED23UfR9XkEOmMlY4GXqCd/uENPk3EuhBWoX83Q7tM6xZCBuxJiTqCIsEzx1B1gjS9WWWX8a ZQyWNbTrQ35BGmsCP6zsH+gQ0rQszCTH3B8GYlwEdQQwmSYb+/0QqMgROXYJuK7PZYVBfMxDb vbPWOPq Archived-At: Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, secdir@ietf.org, ietf@ietf.org, "json@ietf.org" Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 06:12:53 -0000 On 2017-03-11 03:08, John Cowan wrote: > > On Thu, Mar 9, 2017 at 12:53 AM, Benjamin Kaduk > wrote: > > If that's what's supposed to happen, it should probably be more > clear, yes. (But aren't there texts that have valid interpretations > in multiple encodings?) > > > Not if the content is well-formed JSON and the only possible encodings > are UTF-8, UTF-16, and UTF-32. It suffices to examine the first four > bytes of the input. If there are no NUL bytes in the first four bytes, > it is UTF-8; if there are two NUL bytes, it is UTF-16; if there are > three NUL bytes, it is UTF-32. This works because the grammar requires > the first character to be in the ASCII repertoire, and the NUL > *character* (U+0000) is not allowed at all. Good explanation. Maybe the spec should include it. Best regards, Julian From nobody Sat Mar 11 07:48:51 2017 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 D87D9129507; Sat, 11 Mar 2017 07:48:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.003 X-Spam-Level: X-Spam-Status: No, score=-0.003 tagged_above=-999 required=5 tests=[RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 WI45xcIi5XbC; Sat, 11 Mar 2017 07:48:46 -0800 (PST) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 D4F9912941D; Sat, 11 Mar 2017 07:48:46 -0800 (PST) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QBU8WKPNWW00OVR5@mauve.mrochek.com>; Sat, 11 Mar 2017 07:43:42 -0800 (PST) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=us-ascii; format=flowed Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QBQBR8XOKG0003XB@mauve.mrochek.com>; Sat, 11 Mar 2017 07:43:41 -0800 (PST) Message-id: <01QBU8WJOCUO0003XB@mauve.mrochek.com> Date: Sat, 11 Mar 2017 07:41:17 -0800 (PST) From: Ned Freed In-reply-to: "Your message dated Sat, 11 Mar 2017 07:12:45 +0100" References: <20170308014823.GF30306@kduck.kaduk.org> <382aa5c8-c977-b24d-4d19-251257833b00@gmx.de> <456b4234-0d94-1033-507c-710878bb5159@gmx.de> <20170309055348.GL30306@kduck.kaduk.org> To: Julian Reschke Archived-At: Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, John Cowan , ietf@ietf.org, secdir@ietf.org, "json@ietf.org" Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Mar 2017 15:48:50 -0000 > On 2017-03-11 03:08, John Cowan wrote: > > > > On Thu, Mar 9, 2017 at 12:53 AM, Benjamin Kaduk > > wrote: > > > > If that's what's supposed to happen, it should probably be more > > clear, yes. (But aren't there texts that have valid interpretations > > in multiple encodings?) > > > > > > Not if the content is well-formed JSON and the only possible encodings > > are UTF-8, UTF-16, and UTF-32. It suffices to examine the first four > > bytes of the input. If there are no NUL bytes in the first four bytes, > > it is UTF-8; if there are two NUL bytes, it is UTF-16; if there are > > three NUL bytes, it is UTF-32. This works because the grammar requires > > the first character to be in the ASCII repertoire, and the NUL > > *character* (U+0000) is not allowed at all. > Good explanation. Maybe the spec should include it. +1 This exact issue just came up in a media type review, where someone specified a charset parameter because they weren't aware of this algorithm. It would be very helpful to have this text in the RFC. Ned From nobody Sat Mar 11 18:45:01 2017 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 D370312985D; Sat, 11 Mar 2017 18:44:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 j4ARNhtC9Lwn; Sat, 11 Mar 2017 18:44:58 -0800 (PST) Received: from mail-pg0-x242.google.com (mail-pg0-x242.google.com [IPv6:2607:f8b0:400e:c05::242]) (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 D1CD412986F; Sat, 11 Mar 2017 18:44:58 -0800 (PST) Received: by mail-pg0-x242.google.com with SMTP id 25so14461734pgy.3; Sat, 11 Mar 2017 18:44:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=in+X3HMZwccAQXFXLxVC1M2lWRWbVyQVz/EUkC3rIXw=; b=qwdBpFnGRDpSiwJMLK4zddqUsIWh/9Hv6dU+MjrATJiV5cDjxmG40Mt0YcxEyp2b76 p29dlX+a/FFcOPPzGjgXVzcmZ3G0jZ/UpZ0D19IHw4H4lKV6GnkzqErUmzBKbFccvkc8 wwi85aI9ldS7sE7ixVXv9/XSNPqtZY3D18LQTdj1XD1qqo5B+0XvBBHsSRP5hVYEY6eY bGBKqF2Q+fNPxwj6rz+eWjDiPjWkIfCEeJcEXKFQ8LZfheQT08rxCcql6xdM5rhWE6WG 6t/vfHeIkbS4OUxpFfu9wzU02ciAfWxeEnr+PbE0z56i9l08PLNVhN8FKRLUJJ8pX1Rc /oiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=in+X3HMZwccAQXFXLxVC1M2lWRWbVyQVz/EUkC3rIXw=; b=ovuKaxAzCEWXNhZyxpkiWWOiG/WtB9p+ABepYYQ7xKk7MgxrN7VFhwLVh/z1sm5GIR kQ7ZKgTW0S+uMhvu73rr0KoV0MkNRQEneitUwtmRpyimrWZcD9oW30IL5NXb85YNoqxG YZYUqWFpLDZXvi9Ca6ukkeEBsZCRpkA0XWNwWKSsiYRqTIw7KSqWSra/DAer5zzull6E cAoGFgAT8YEm8vfuijsbynfd2bL9aawlOAFBNiRGU4N1d6UD9/R0otefizvjN2Q7f3BN O6LP8zT5CBvXsS8Mx2BlzAmAXS+wu2SIu7oGplktvgA1xXO5koGhYSCNuVxS6ixkVmMG zuMQ== X-Gm-Message-State: AMke39nIMRcLlHALlbw5yvKuHNpkVjwXd7TGzgSWMEdBOAeHvJi/fuwfU+bolDx9ehalFA== X-Received: by 10.84.231.207 with SMTP id g15mr37415586pln.2.1489286698292; Sat, 11 Mar 2017 18:44:58 -0800 (PST) Received: from Chriss-Air.attlocal.net ([2602:306:838b:1c40:edb9:2b32:fa09:a062]) by smtp.googlemail.com with ESMTPSA id g29sm26281341pfg.37.2017.03.11.18.44.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 11 Mar 2017 18:44:58 -0800 (PST) To: "iesg@ietf.org" , "secdir@ietf.org" , draft-ietf-ippm-twamp-time-format.all@ietf.org From: Chris Lonvick Message-ID: <58C4B625.4000102@gmail.com> Date: Sat, 11 Mar 2017 20:44:53 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------070904080001060800040607" Archived-At: Subject: [secdir] SECDIR review of draft-ietf-ippm-twamp-time-format-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 02:45:00 -0000 This is a multi-part message in MIME format. --------------070904080001060800040607 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document is ready with minor nits. The document calls for the change of designation of a field in an established protocol. This is called out throughout Section 2 and will need to be ratified by the IANA in Section 3. The previous documents set the bit to MUST BE ZERO and this document uses it to signal an option to use either the NTP timestamp (still using 0) or a more recently adopted 1588 timestamp (1). The Security Considerations section appropriately names the prior documents and references their Security Considerations sections. Minor nits: The last sentence of the first paragraph of Section 1 is: "And of mentioned solutions will be subject to additional queuing delays that negatively affect data plane clock accuracy." Perhaps should be "Any of the mentioned..." The second sentence of the first paragraph of Section 2 is: "In these procedures, the Modes field been used to identify and select specific communication capabilities." Perhaps should be "...has been used..." I didn't do a thorough read through the document so there may be other minor nits. Regards, Chris --------------070904080001060800040607 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi,

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

The document is ready with minor nits. The document calls for the change of designation of a field in an established protocol. This is called out throughout Section 2 and will need to be ratified by the IANA in Section 3. The previous documents set the bit to MUST BE ZERO and this document uses it to signal an option to use either the NTP timestamp (still using 0) or a more recently adopted 1588 timestamp (1). The Security Considerations section appropriately names the prior documents and references their Security Considerations sections.

Minor nits:

The last sentence of the first paragraph of Section 1 is:
"And of mentioned solutions will be subject to additional queuing delays that negatively affect data plane clock accuracy."
Perhaps should be "Any of the mentioned..."

The second sentence of the first paragraph of Section 2 is:
"In these procedures, the Modes field been used to identify and select specific communication capabilities."
Perhaps should be "...has been used..."

I didn't do a thorough read through the document so there may be other minor nits.

Regards,
Chris
--------------070904080001060800040607-- From nobody Sat Mar 11 18:59:10 2017 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 E0E311294CC for ; Sat, 11 Mar 2017 18:59:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ccil-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 9jAKAIhioI0y for ; Sat, 11 Mar 2017 18:59:03 -0800 (PST) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (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 E47E1129443 for ; Sat, 11 Mar 2017 18:59:02 -0800 (PST) Received: by mail-wr0-x234.google.com with SMTP id g10so85105756wrg.2 for ; Sat, 11 Mar 2017 18:59:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HTuqMJ0eIgT7tTLAXbRgrHVav8Y0LsJygzS2gF95pX0=; b=o+5VkRdFFUVJWFtbEpFKYtgpSFQamsl2Enybw0Ri+36h512oB68bgxuRMtjDlNl+KY WNm4LhTnE7jHXajLdT9qof3zWCT8Vaj6945ELRrONncDm81teEBe6p4N1zeO6oYJzGsq qLLdpDTIxOUYDAzEeAjnMUp2QrY1dfVOT2wuFhjE6xqGPizBwsK2wcMJLK835CEwk8/d s7l5+RVVSF6BRBCjyR/km6l4jwxLNrpqujOWeNLO5fpV9Z6H1CsA9hfaTfjBZvrlEwF6 8IzM4K2CG+EpIAvehqoigm1TM36s/GVPVJPbKz0/gf7A2mZ8PKjD/M0CRffGNQq5l3K4 1stA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HTuqMJ0eIgT7tTLAXbRgrHVav8Y0LsJygzS2gF95pX0=; b=dWCfBQ9abtxgkP6iZRAiu0BeGq3ikWlBQknACNKrGfTPSSp7o80k6WaveSM2IXUEFy YeQ8Biz5wPQOcYBQ7mh1IrJ35U6maiN5ps1d0Nil2GgcxsYyF0dH6WihzthVRdTGo9It hXx1dkgQnuzbnZzn1tPyMog9sae8vymUqDCEkv6+/CYXbgNe9bP4zuj3qSousbjR6Uc9 ZEUuszRWFfibIeIBdxYH+RTX+eMa/21itw+la1HO5B3ZYuXWSLjWtgVmdUilDLk3xD32 V7SVQtSD7sJsWLUoJHS9yAiey/Qi9nCCxYWg7EndJ8Wf01nhcvbAKC8cGbXFM2xNmIur olTg== X-Gm-Message-State: AMke39kFGSEp+1MxcHQNXVIkh2/+iSUtzx640CilOUNU0Pze5bWDoAHif+b5TJNnWoL8FBI85GaU1dh2Fzor35bb X-Received: by 10.223.152.215 with SMTP id w81mr24691006wrb.151.1489287541232; Sat, 11 Mar 2017 18:59:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.181.14 with HTTP; Sat, 11 Mar 2017 18:58:40 -0800 (PST) In-Reply-To: <01QBU8WJOCUO0003XB@mauve.mrochek.com> References: <20170308014823.GF30306@kduck.kaduk.org> <382aa5c8-c977-b24d-4d19-251257833b00@gmx.de> <456b4234-0d94-1033-507c-710878bb5159@gmx.de> <20170309055348.GL30306@kduck.kaduk.org> <01QBU8WJOCUO0003XB@mauve.mrochek.com> From: John Cowan Date: Sat, 11 Mar 2017 21:58:40 -0500 Message-ID: To: Ned Freed Content-Type: multipart/alternative; boundary=001a113c36a6dd285e054a7fc6ea Archived-At: Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, ietf@ietf.org, secdir@ietf.org, Julian Reschke , "json@ietf.org" Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 02:59:05 -0000 --001a113c36a6dd285e054a7fc6ea Content-Type: text/plain; charset=UTF-8 On Sat, Mar 11, 2017 at 10:41 AM, Ned Freed wrote: This exact issue just came up in a media type review, where someone > specified a charset parameter because they weren't aware of this algorithm. > > It would be very helpful to have this text in the RFC. Feel free, whoever is the editor now, to add it. -- John Cowan http://vrici.lojban.org/~cowan cowan@ccil.org But that, he realized, was a foolish thought; as no one knew better than he that the Wall had no other side. --Arthur C. Clarke, "The Wall of Darkness" > > Ned > --001a113c36a6dd285e054a7fc6ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sat, Mar 11, 2017 at 10:41 AM, Ned Freed <ned.freed@mrochek.com= > wrote:

This exact issue just came up in a media type review, where someone
specified a charset parameter because they weren't aware of this algori= thm.

It would be very helpful to have this text in the RFC.
Feel free, whoever is the editor now, to add it.

=
--=C2=A0
But that, he realized, was a foolish thought; as no one k= new better than
he that the Wall had no other side.
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 --Arthur C. Clarke, "The Wall of Darkness&quo= t;=C2=A0



=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ned

--001a113c36a6dd285e054a7fc6ea-- From nobody Sun Mar 12 01:10:04 2017 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 8F1BE1293FD; Sun, 12 Mar 2017 01:09:55 -0800 (PST) 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] 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 MRq2vriQ6M-Z; Sun, 12 Mar 2017 01:09:53 -0800 (PST) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 770C9126D73; Sun, 12 Mar 2017 01:09:53 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2C99lQl008734; Sun, 12 Mar 2017 10:09:47 +0100 (CET) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vgwDq3PQ6zDHsX; Sun, 12 Mar 2017 10:09:47 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <01QBU8WJOCUO0003XB@mauve.mrochek.com> Date: Sun, 12 Mar 2017 10:09:46 +0100 X-Mao-Original-Outgoing-Id: 511002586.144963-2ff5f2a34eda08f56731e4c680bd2c78 Content-Transfer-Encoding: quoted-printable Message-Id: <9F2F2116-4985-4561-BFD3-24B374E4C4ED@tzi.org> References: <20170308014823.GF30306@kduck.kaduk.org> <382aa5c8-c977-b24d-4d19-251257833b00@gmx.de> <456b4234-0d94-1033-507c-710878bb5159@gmx.de> <20170309055348.GL30306@kduck.kaduk.org> <01QBU8WJOCUO0003XB@mauve.mrochek.com> To: ned+ietf@mauve.mrochek.com X-Mailer: Apple Mail (2.3259) Archived-At: Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, John Cowan , IETF , secdir@ietf.org, Julian Reschke , "json@ietf.org" Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 09:09:55 -0000 On 11 Mar 2017, at 16:41, ned+ietf@mauve.mrochek.com wrote: >=20 > It would be very helpful to have this text in the RFC. That would be a regression. A better change would be to remove the fiction that JSON exists in = UTF-16 or UTF-32 forms. Gr=C3=BC=C3=9Fe, Carsten From nobody Sun Mar 12 01:13:10 2017 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 7D919129B00 for ; Sun, 12 Mar 2017 01:13:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.92 X-Spam-Level: X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dg4UqlZQPkLS for ; Sun, 12 Mar 2017 01:13:08 -0800 (PST) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66C80126D73 for ; Sun, 12 Mar 2017 01:13:08 -0800 (PST) Received: (qmail 1030 invoked from network); 12 Mar 2017 08:59:10 +0000 Received: from host109-158-230-32.range109-158.btcentralplus.com (HELO ?192.168.1.72?) (109.158.230.32) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 12 Mar 2017 08:59:10 +0000 To: Ned Freed , Julian Reschke References: <20170308014823.GF30306@kduck.kaduk.org> <382aa5c8-c977-b24d-4d19-251257833b00@gmx.de> <456b4234-0d94-1033-507c-710878bb5159@gmx.de> <20170309055348.GL30306@kduck.kaduk.org> <01QBU8WJOCUO0003XB@mauve.mrochek.com> From: Peter Cordell Message-ID: <6d97dee7-7cf3-9142-aacf-f2ca4909103d@codalogic.com> Date: Sun, 12 Mar 2017 09:06:24 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <01QBU8WJOCUO0003XB@mauve.mrochek.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, John Cowan , ietf@ietf.org, secdir@ietf.org, "json@ietf.org" Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 09:13:09 -0000 On 11/03/2017 15:41, Ned Freed wrote: >> On 2017-03-11 03:08, John Cowan wrote: >> > >> > On Thu, Mar 9, 2017 at 12:53 AM, Benjamin Kaduk > > > wrote: >> > >> > If that's what's supposed to happen, it should probably be more >> > clear, yes. (But aren't there texts that have valid >> interpretations >> > in multiple encodings?) >> > >> > >> > Not if the content is well-formed JSON and the only possible encodings >> > are UTF-8, UTF-16, and UTF-32. It suffices to examine the first four >> > bytes of the input. If there are no NUL bytes in the first four bytes, >> > it is UTF-8; if there are two NUL bytes, it is UTF-16; if there are >> > three NUL bytes, it is UTF-32. This works because the grammar requires >> > the first character to be in the ASCII repertoire, and the NUL >> > *character* (U+0000) is not allowed at all. > >> Good explanation. Maybe the spec should include it. > > +1 > > This exact issue just came up in a media type review, where someone > specified a charset parameter because they weren't aware of this algorithm. > > It would be very helpful to have this text in the RFC. Although it does need slightly more detail to take into account endian-ness in the case of UTF-16 and -32. The XML spec may offer some example text: https://www.w3.org/TR/2008/REC-xml-20081126/#sec-guessing Pete Cordell Codalogic Ltd Read & write XML in C++, http://www.xml2cpp.com From nobody Sun Mar 12 01:14:40 2017 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 80DA7129B01; Sun, 12 Mar 2017 01:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 xPwwWuK9R5zL; Sun, 12 Mar 2017 01:14:33 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 BC607129B00; Sun, 12 Mar 2017 01:14:32 -0800 (PST) Received: from [192.168.178.20] ([93.217.89.49]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Ld0E0-1cMlZt0Pwm-00iAfB; Sun, 12 Mar 2017 10:14:05 +0100 To: Peter Cordell , Ned Freed References: <20170308014823.GF30306@kduck.kaduk.org> <382aa5c8-c977-b24d-4d19-251257833b00@gmx.de> <456b4234-0d94-1033-507c-710878bb5159@gmx.de> <20170309055348.GL30306@kduck.kaduk.org> <01QBU8WJOCUO0003XB@mauve.mrochek.com> <6d97dee7-7cf3-9142-aacf-f2ca4909103d@codalogic.com> From: Julian Reschke Message-ID: Date: Sun, 12 Mar 2017 10:14:04 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <6d97dee7-7cf3-9142-aacf-f2ca4909103d@codalogic.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:EBZZbuwf0wSMyEt5vpfTrDMD2A2TLrR/v0XrY+AFn9pTUiYCtQn 1JfsTBIPy8gpy4+ZzArmk3beM13BFRcinJzwghAXdFt2GZDVvyQTfvmOs+vdUcJsH4dpqAL /hE+EDxmuv0xshk/6X3blC6gekmdD03LwLNlXc8eLsl6TTEV4apZpMoIX6G0O1RSYDnGunB S+B0OClX0XzR41rmzuU0g== X-UI-Out-Filterresults: notjunk:1;V01:K0:XR2BrSIL2Yo=:3bGUZ2Dop4QI8MYQmVx/xF 61IyODJT8d7ulKG3BZeDQCONozTzTQJ4MJe3W47QtEVe0GQYjt4COVoD7qQ3xrAdF6+cSiJGe bXJv6xKz6jsIgNCp9tip6C7Y2lOOyM0oEjbHhnI+33U2gvEiZ7GaRvLDOmmH5BoYZKSZ00ABV vTRXLvjTWMGBRnPp/L08c4SyVNn3tyIEg/JjzTWyJrxWIx00Lvtl7knHy1HsF5K44NRyvRl3Q jlpvRXAvNKYFTjXxSkxXHE1VmcS3HhXbVURUeDWf9EeJM9sS3O0LxBH4FChzrbDtZ56WAkHwt 7btAJKCSUeW+ufUNHVLv57swS8q/cEYge8Rwx5l3ykhxVp7hb5/FZbyQeujt89gLupTkHnfJU gDQTB2SQg61L/cIT3CQvWpXrGcF3Trv+9oxDXecrUhLUrBUX82VqCIfO7ZGgD8mVxCYec6nW8 YvX1RUEsRL6TX7BOJsWBLE+KQYLhyzT7PF3RZVR4ZDy7H1qfTQ4x/e8IHC7A4J/XSq+l/Yvm/ nJiq5cE38Xfs4g2ZSd6E6KkwnrhKF3V6kBtbGo9tm6q/k9vPSdQpztGWhOnPfSVzlKtnThKcq e3+eYG8LsY92EBSZc2NxaIQchkh2Za1exyosCQ+2Q9blvdgUENxqY+vZG67JN5zeRbKTepb3m k9RR3oTOlE3vpQOgQ12FOYr3iQlrXpSCyZSPPtVH+B9s/Z5XeVFpbsBh89eHmEwxI5kytbnav aZvaoaNVMgjZz6oRaI+L1+dvCM3GMKrkC6CEpSBQSnlTwjiwdG6O+mnZJJ+KRVF2XgeJxjl/w hH3ofg6 Archived-At: Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, John Cowan , ietf@ietf.org, secdir@ietf.org, "json@ietf.org" Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 09:14:34 -0000 On 2017-03-12 10:06, Peter Cordell wrote: > ... >> This exact issue just came up in a media type review, where someone >> specified a charset parameter because they weren't aware of this >> algorithm. >> >> It would be very helpful to have this text in the RFC. > > > Although it does need slightly more detail to take into account > endian-ness in the case of UTF-16 and -32. > ... Does anybody recall why we removed : > 3. Encoding > > JSON text SHALL be encoded in Unicode. The default encoding is > UTF-8. > > Since the first two characters of a JSON text will always be ASCII > characters [RFC0020], it is possible to determine whether an octet > stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking > at the pattern of nulls in the first four octets. > > 00 00 00 xx UTF-32BE > 00 xx 00 xx UTF-16BE > xx 00 00 00 UTF-32LE > xx 00 xx 00 UTF-16LE > xx xx xx xx UTF-8 ? Best regards, Julian From nobody Sun Mar 12 04:52:00 2017 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 4835F1293EB; Sun, 12 Mar 2017 04:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 eXD2OuKZKW0I; Sun, 12 Mar 2017 04:51:58 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC824128DF6; Sun, 12 Mar 2017 04:51:57 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B27B5700; Sun, 12 Mar 2017 12:51:56 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id nfFOhxeJc-OG; Sun, 12 Mar 2017 12:51:54 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sun, 12 Mar 2017 12:51:56 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3804520038; Sun, 12 Mar 2017 12:51:56 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mH_N5N2E_gwJ; Sun, 12 Mar 2017 12:51:55 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A807B20036; Sun, 12 Mar 2017 12:51:55 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B5C263EB7364; Sun, 12 Mar 2017 12:52:00 +0100 (CET) Date: Sun, 12 Mar 2017 12:52:00 +0100 From: Juergen Schoenwaelder To: Leif Johansson Message-ID: <20170312115200.GD50035@elstar.local> Mail-Followup-To: Leif Johansson , "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-lmap-information-model.all@ietf.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: draft-ietf-lmap-information-model.all@ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] secdir review of draft-ietf-lmap-information-model-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 11:51:59 -0000 On Thu, Mar 09, 2017 at 05:06:00PM +0100, Leif Johansson wrote: > > Reviewer: Leif Johansson > Review result: Has issues > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written primarily for the benefit of the > security area directors. Document editors and WG chairs should treat > these comments just like any other last call comments. > > Review: > > Section 3.8 begins "A Channel defines a bi-directional communication > channel". First of all it is probably a good idea avoid using the > term you're defining in the definition. I can s/channel/mechanism/ to avoid the usage of channel while defining Channel (not sure it adds clarity though). > Also in the text a Channel is described as a URL with the cert or CA > of the endpoint but in the channel object definition there is only a > reference to the credentials which I understood to be the client authn > credential and not the server identity. > > This leads me to a larger issue (which may be answered in another LMAP > document for all I know): what is the authentication model for LMAP? > Specifically, does LMAP assume the standard Web PKI for channel end- > points? If not, then you probably need to specify how to validate the > server cert which may lead you to want to represent a private CA (say) > in the channel object. In any case the authentication model should be > referenced from the Security Considerations section and clearly match > the information model for channels. This being an information model, we aim at staying away from being too specific. The information model is mapped today to a YANG data model (IETF) and a data model for TR-69 (BBF). The YANG data model may be accessed today via NETCONF or RESTCONF. There may be other protocols in the future. RESTCONF runs over HTTP/TLS, NETCONF runs by default over SSH (which supportes a number of authentication mechanisms), NETCONF may also run over TLS. In other words, the concrete details how authentication is done is specific to the protocols used to access instantiations of specific data models. This is why we talk about rather opaque credentials in the definition of ma-channel-obj and section 2 "Notation" says: credentials An opaque type representing credentials needed by a cryptographic mechanism to secure communication. Data models must expand this opaque type as needed and required by the security protocols utilized. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Sun Mar 12 05:11:51 2017 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 2C48B1293EB; Sun, 12 Mar 2017 05:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.903 X-Spam-Level: X-Spam-Status: No, score=-1.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 H3hYilvbTrdP; Sun, 12 Mar 2017 05:11:44 -0700 (PDT) Received: from mauve.mrochek.com (mauve.mrochek.com [68.183.62.69]) (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 7A8BD128DF6; Sun, 12 Mar 2017 05:11:44 -0700 (PDT) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QBVHP8004000PMAR@mauve.mrochek.com>; Sun, 12 Mar 2017 05:06:40 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: TEXT/PLAIN; CHARSET=US-ASCII Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01QBQBR8XOKG0003XB@mauve.mrochek.com>; Sun, 12 Mar 2017 05:06:37 -0700 (PDT) Message-id: <01QBVHP5YAYE0003XB@mauve.mrochek.com> Date: Sun, 12 Mar 2017 04:56:29 -0700 (PDT) From: Ned Freed In-reply-to: "Your message dated Sun, 12 Mar 2017 10:09:46 +0100" <9F2F2116-4985-4561-BFD3-24B374E4C4ED@tzi.org> References: <20170308014823.GF30306@kduck.kaduk.org> <382aa5c8-c977-b24d-4d19-251257833b00@gmx.de> <456b4234-0d94-1033-507c-710878bb5159@gmx.de> <20170309055348.GL30306@kduck.kaduk.org> <01QBU8WJOCUO0003XB@mauve.mrochek.com> <9F2F2116-4985-4561-BFD3-24B374E4C4ED@tzi.org> To: Carsten Bormann Archived-At: Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, John Cowan , IETF , secdir@ietf.org, ned+ietf@mauve.mrochek.com, "json@ietf.org" , Julian Reschke Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 12:11:45 -0000 > On 11 Mar 2017, at 16:41, ned+ietf@mauve.mrochek.com wrote: > > > > It would be very helpful to have this text in the RFC. > That would be a regression. On the contrary - what you have now is incomplete if not actually broken, and this completes/fixes it. You have a specification that says (a) JSON can be encoded in UTF-8, UTF-16, or UTF-32 and that (b) That no charset parameter is needed to distinguish the charset and moreover one has "no effect". But you don't explain how why this is the the case, or what compliant implementation do to determine the charset. If you believe clarifying this is problemtic in some way, you need to explain why. > A better change would be to remove the fiction that JSON exists in UTF-16 or > UTF-32 forms. That's of course another way to fix the problem. But it's a far more significant change, and I have to wonder if there is a consensus to do it. Personally, I have no preference as to the approach that's used. But moving forward as-is is really not acceptable. Ned From nobody Sun Mar 12 08:32:01 2017 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 59C20126BF6; Sun, 12 Mar 2017 08:31:52 -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] 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 yKfHguuWtDsQ; Sun, 12 Mar 2017 08:31:50 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 10C3D129509; Sun, 12 Mar 2017 08:31:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2CFVhYC020320; Sun, 12 Mar 2017 16:31:43 +0100 (CET) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vh4jW01q0zDHvr; Sun, 12 Mar 2017 16:31:42 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: Date: Sun, 12 Mar 2017 16:31:42 +0100 X-Mao-Original-Outgoing-Id: 511025502.207779-be1eff5230d4761fb1f26c2a4fa3d8de Content-Transfer-Encoding: quoted-printable Message-Id: <38DEEE0A-EE2C-4ADA-9D7A-9DBBAEACB77E@tzi.org> References: <20170308014823.GF30306@kduck.kaduk.org> <382aa5c8-c977-b24d-4d19-251257833b00@gmx.de> <456b4234-0d94-1033-507c-710878bb5159@gmx.de> <20170309055348.GL30306@kduck.kaduk.org> <01QBU8WJOCUO0003XB@mauve.mrochek.com> <6d97dee7-7cf3-9142-aacf-f2ca4909103d@codalogic.com> To: Julian Reschke X-Mailer: Apple Mail (2.3259) Archived-At: Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, John Cowan , Ned Freed , IETF , Peter Cordell , secdir@ietf.org, "json@ietf.org" Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 15:31:52 -0000 On 12 Mar 2017, at 10:14, Julian Reschke wrote: >=20 > Does anybody recall why we removed = : I seem to remember that the advice simply is no longer working since = JSON was extended from 4627 to 7159. Instead of trying to come up with = an updated algorithm, the WG recognized that this is not a real-world = problem. If 7159bis is supposed to be an Internet Standard, it should focus on = the variants that actually interoperate. Re-encoding JSON into UTF-16 = (or UTF-32) is not really interoperable with today=E2=80=99s = implementations*). Gr=C3=BC=C3=9Fe, Carsten *) (Given the large number of JSON implementations, I don=E2=80=99t = doubt you will find two implementations that do interoperate on this. = It is not the widely interoperable =E2=80=9CJSON=E2=80=9D thing, = though.) From nobody Sun Mar 12 12:31:20 2017 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 E84891293D6; Sun, 12 Mar 2017 12:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 KExavq3Z8k74; Sun, 12 Mar 2017 12:31:17 -0700 (PDT) Received: from mail-ot0-x22c.google.com (mail-ot0-x22c.google.com [IPv6:2607:f8b0:4003:c0f::22c]) (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 7E5CF128B38; Sun, 12 Mar 2017 12:31:17 -0700 (PDT) Received: by mail-ot0-x22c.google.com with SMTP id o24so101895408otb.1; Sun, 12 Mar 2017 12:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fm1m5fpFgs9HzjJuHUCMK5F2QntATXtqIJPsUOcuUaw=; b=XDQt4nbYlcBMi8qxNYSFba8MMHxlsm+QCqBkpbTeFDcrTpxaBSZhx8gyLDew+Uqejl gGZirrF2h84OqEtDFk7S6W6nVvfOGOKZA87G1K7oG/RhROhL1dboerZYW/ddcHBHIuc2 E+9L9ed2TkxBTeC7R32HHCRzhx3IR7dbsJPcVAhSiPefFevNRIel6ADA/AG8EwA+124t BmZ/6XRpyN7gFIqWorJCgv48p+QFsWQk84tFV4X+P2aBz9kIlOa9wImNOPdE3NA3oJM8 PmxrwSuczlMpibBVE+WbzXOiOP0HsgKLCjyzmhHE/Wvaj9RLOVcr3+Pg3cAMMT/ZuhTi OVkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fm1m5fpFgs9HzjJuHUCMK5F2QntATXtqIJPsUOcuUaw=; b=bnPSQcz2asUcWncah/WQ6E9lnzxPrtY9gm0a+9AZiRlpJx9ADejnC5nTb2u45Rim0x JPW1hAr1Zs9WJfZsi17UiWnY6fnAB755JYbwiT8+jsjjitzacKM5bPWzboncw5XrZxBu 6Cobm7fDl/RCmeWeXEeDyCppz3y4VrtTrrIZqs6wUhcNWt8+VDisbcvmHDkclQNyQ2ce hTlxjcx1KOY+4zYTxXWRlzK+dU1s6emjTE3zr9JSkVot+jbTZEYehetUOJ9jgEKWhAu1 eHM3TlVH5Uutj1ylc/AP8n7f3HXxSIPjj3lmjooDRionuWwOJwxLtSorMq0+Qzk+XWZh AsQA== X-Gm-Message-State: AMke39k8i8s/SEhDThW+5b7sYiF2yjkoIktJSwF6mxQI06pqvKs0SQznc2+sHzlgZJwXRWHxDRwHOQZBUGddBA== X-Received: by 10.157.82.22 with SMTP id e22mr17695164oth.76.1489347076900; Sun, 12 Mar 2017 12:31:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.21.21 with HTTP; Sun, 12 Mar 2017 12:31:16 -0700 (PDT) In-Reply-To: <58C4B625.4000102@gmail.com> References: <58C4B625.4000102@gmail.com> From: Greg Mirsky Date: Sun, 12 Mar 2017 12:31:16 -0700 Message-ID: To: Chris Lonvick Content-Type: multipart/alternative; boundary=f403043546d8774d2c054a8da345 Archived-At: Cc: draft-ietf-ippm-twamp-time-format.all@ietf.org, "iesg@ietf.org" , "secdir@ietf.org" Subject: Re: [secdir] SECDIR review of draft-ietf-ippm-twamp-time-format-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 19:31:19 -0000 --f403043546d8774d2c054a8da345 Content-Type: text/plain; charset=UTF-8 Hi Chris, the most sincere thanks for the review and comments you've shared. I've applied both changes and posted as -05 version already. Best regards, Greg On Sat, Mar 11, 2017 at 6:44 PM, Chris Lonvick wrote: > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments just > like any other last call comments. > > The document is ready with minor nits. The document calls for the change > of designation of a field in an established protocol. This is called out > throughout Section 2 and will need to be ratified by the IANA in Section 3. > The previous documents set the bit to MUST BE ZERO and this document uses > it to signal an option to use either the NTP timestamp (still using 0) or a > more recently adopted 1588 timestamp (1). The Security Considerations > section appropriately names the prior documents and references their > Security Considerations sections. > > Minor nits: > > The last sentence of the first paragraph of Section 1 is: > "And of mentioned solutions will be subject to additional queuing delays > that negatively affect data plane clock accuracy." > Perhaps should be "Any of the mentioned..." > > The second sentence of the first paragraph of Section 2 is: > "In these procedures, the Modes field been used to identify and select > specific communication capabilities." > Perhaps should be "...has been used..." > > I didn't do a thorough read through the document so there may be other > minor nits. > > Regards, > Chris > --f403043546d8774d2c054a8da345 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Chris,
the most sincere thanks for the r= eview and comments you've shared. I've applied both changes and pos= ted as -05 version already.

Best regards,
Greg

On Sat, Mar 11, 2017 at 6:44 PM, Chris Lonvick <lonvick.ietf@gmail.c= om> wrote:
=20 =20 =20
Hi,

=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.

The document is ready with minor nits. The document calls for the change of designation of a field in an established protocol. This is called out throughout Section 2 and will need to be ratified by the IANA in Section 3. The previous documents set the bit to MUST BE ZERO and this document uses it to signal an option to use either the NTP timestamp (still using 0) or a more recently adopted 1588 timestamp (1). The Security Considerations section appropriately names the prior documents and references their Security Considerations sections.

Minor nits:

The last sentence of the first paragraph of Section 1 is:
=20 "And of mentioned solutions will be subject to additional queuing delays that negatively affect data plane clock accuracy."
Perhaps should be "Any of the mentioned..."

The second sentence of the first paragraph of Section 2 is:
=20 "In these procedures, the Modes field been used to identify and select specific communication capabilities."
Perhaps should be "...has been used..."

I didn't do a thorough read through the document so there may be other minor nits.

Regards,
Chris

--f403043546d8774d2c054a8da345-- From nobody Sun Mar 12 14:14:27 2017 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 2CA05126CD8 for ; Sun, 12 Mar 2017 14:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yahoo.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 3qCnkUM1ZUIn for ; Sun, 12 Mar 2017 14:14:21 -0700 (PDT) Received: from nm19-vm3.access.bullet.mail.gq1.yahoo.com (nm19-vm3.access.bullet.mail.gq1.yahoo.com [216.39.63.77]) (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 6E0B71293FB for ; Sun, 12 Mar 2017 14:14:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1489353260; bh=l86TH49w9ozpdk6NfGvcpZxME/lBOB7p2edKmRKYslQ=; h=To:From:Subject:Date:From:Subject; b=ZEttXQ0TCPFwjE8UDKOjjNFXh3aHT6GSnWGwk329BlnKfB16+wbXoTynx+Orzv5SuQOI1OWpvjqdMqdsLS7J1+gAnU+cnkRfHB4NrAH6oGYlxu5DMfqjjqrAvnDvpIXjSxsfPYUz618Ax3G2WUZFX+nRzEmco672cFhfHwYtWjAcBleOVTya7inx375YcG6x14wggJbIpyPes3Q8QX+QQAi0jxkDQjqHg12/Y3v4d1b9hdhRYGKpmc1AtNwW5ZHxzJytux1CsDjB6Hud9m1/7X0lqvVjCr3jIiTtY3QZNkmKY+U3gPdkCqBS67WnrjfWiheoKcROUR9ptxLMJBoDSg== Received: from [216.39.60.172] by nm19.access.bullet.mail.gq1.yahoo.com with NNFMP; 12 Mar 2017 21:14:20 -0000 Received: from [98.138.226.243] by tm8.access.bullet.mail.gq1.yahoo.com with NNFMP; 12 Mar 2017 21:14:20 -0000 Received: from [127.0.0.1] by smtp114.sbc.mail.ne1.yahoo.com with NNFMP; 12 Mar 2017 21:14:20 -0000 X-Yahoo-Newman-Id: 321652.22938.bm@smtp114.sbc.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: hd47o3MVM1nZM06_jzkP52dh4UHcevU1o9fnGKWaGKCDM95 9rnHMw8ygXH45jTXbc7eDDIrFX_a8.sIoU1M7yASP4itktixVcFM79hipEtW BSyXZ2wGn.urq_Zq.0sxoraSVLPgG3q_ffLQgo4rlwIKIJ2AbB8zA8uoU.kK M6MZIGcq9HlnJm5Y7o5JHlWLNU5YjKaDS_rredPo3kHuYQA22Ehe_czzq_6c nji2xNoRCbOnkaDYYWZH5PCWnqJj1xzlUtUtF5fpG0a_xhxNH802dx7N7NMJ s1LkfLOGyukJbmW.7UrpnPF_03gZGt9iCJgDdJUGgvoBRLIOVXc8PdMNSNk8 JnsyRhDO9hg.fWeRmYR5VVGCNB8jB4on1wfpAqzIapvyOFeu3Cw4DU_26YAZ zu8.sUJJhkQudt1r1TsJilP.AeTmaUw6CBL6SX95YBSKuxGFXRVRCxR63dlE QaK1LXV12bZ5wTcXRC4I7uejk1nqkLCk64nAi0oJPVn4jcV0.dZQKlSkQtWw Z2Z9ZJCkSkNWxpdOj5akDFHzqzXl9jExBZjgQjl5Bpg-- X-Yahoo-SMTP: 4kJJK.qswBDPuwyc5wW.BPAQqNXdy5j09UNyeAS0pyOQ708- Received: from [192.168.1.152] (DD-WRT [192.168.1.1]) by uriel.mandelberg.org (Postfix) with ESMTPSA id 248D81C6034; Sun, 12 Mar 2017 17:14:19 -0400 (EDT) To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ippm-model-based-metrics.all@ietf.org From: David Mandelberg Message-ID: <5e4d6947-30ed-60c6-d9ab-b2af4485f82c@mandelberg.org> Date: Sun, 12 Mar 2017 17:14:15 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="PXX7hQvDGpWn6QLNa47nPtsNJxRDinrMu" Archived-At: Subject: [secdir] secdir review of draft-ietf-ippm-model-based-metrics-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 21:14:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PXX7hQvDGpWn6QLNa47nPtsNJxRDinrMu Content-Type: multipart/mixed; boundary="wnNrJmkjQRfEUr625TMFUP7nOSvTdOlgT" From: David Mandelberg To: iesg@ietf.org, secdir@ietf.org, draft-ietf-ippm-model-based-metrics.all@ietf.org Message-ID: <5e4d6947-30ed-60c6-d9ab-b2af4485f82c@mandelberg.org> Subject: secdir review of draft-ietf-ippm-model-based-metrics-10 --wnNrJmkjQRfEUr625TMFUP7nOSvTdOlgT Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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. This experimental draft "provides a framework for designing suites of IP diagnostic tests" to measure a network path's bulk transport capacity. As mentioned in the security considerations, actual attempts at measurement might be subject to manipulation by an attacker. As I understand it, the framework in this document neither attempts to prevent such attacks, nor makes them any more likely. The only other relevant potential security issue I could think of is whether measurement system(s) using this framework could be co-opted by an attacker to cause a denial of service to a specific network path. I think this would depend entirely on the implementation of a system designed using the framework in this document, and is therefore pretty far removed from this document itself. An attack like this also might not be possible because of some part of the framework that I missed. So I'll trust the authors' and/or working group's judgment on what to do with this comment. I think this draft is somewhere between (inclusive) Ready and Ready With Issues, depending on how far off-base my point about denial of service is. I'm leaning towards Ready. --=20 David Eric Mandelberg / dseomn http://david.mandelberg.org/ --wnNrJmkjQRfEUr625TMFUP7nOSvTdOlgT-- --PXX7hQvDGpWn6QLNa47nPtsNJxRDinrMu Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAljFuicACgkQRKlmUHCg4sDbVwCZAeX6fl7Sg/oXx3I+QqCOp2a1 5toAniEdOHqf5MHoOwnTrvDjTlTtyyu1 =MPAx -----END PGP SIGNATURE----- --PXX7hQvDGpWn6QLNa47nPtsNJxRDinrMu-- From nobody Sun Mar 12 16:38:18 2017 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 F131F129413; Sun, 12 Mar 2017 16:38:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o2ACz6TGtvvs; Sun, 12 Mar 2017 16:38:09 -0700 (PDT) Received: from b-painless.mh.aa.net.uk (b-painless.mh.aa.net.uk [81.187.30.52]) (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 426C812940C; Sun, 12 Mar 2017 16:38:09 -0700 (PDT) Received: from f.6.d.d.7.f.3.e.8.2.f.e.4.f.0.3.1.0.0.0.f.b.0.0.0.b.8.0.1.0.0.2.ip6.arpa ([2001:8b0:bf:1:30f4:ef28:e3f7:dd6f]) by b-painless.mh.aa.net.uk with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1cnCae-0007SI-2h; Sun, 12 Mar 2017 23:07:52 +0000 Date: Sun, 12 Mar 2017 23:07:40 +0000 Message-ID: Importance: normal From: Elwyn Davies To: Peter Cordell , Ned Freed , Julian Reschke MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.samsung.android.email_4565109410242090" Archived-At: Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, John Cowan , ietf@ietf.org, secdir@ietf.org, "json@ietf.org" Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Mar 2017 23:38:12 -0000 ----_com.samsung.android.email_4565109410242090 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 KHdpdGggaGFsZiBhIEdlbi1hcnQgaGF0IG9uLi4uKQpEb2VzIHRoZSBXRyByZWFsbHkgd2FudCB0 byByZXZpc2l0IHRoZSBhbmd1aXNoZWQgZGlzY3Vzc2lvbnMgdGhhdCByZXN1bHRlZCBpbiB0aGUg Y2hhbmdlcyB0byBTZWN0aW9uIDguMSBvZiBkcmFmdC1pZXRmLWpzb24tcmZjNDYyN2JpcyBiZXR3 ZWVuIHZlcnNpb25zIDA3IGFuZCAwOCBiYWNrIGluIGxhdGUgTm92ZW1iZXIgMjAxMz8KU2VlwqBo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2pzb24vY3VycmVudC9tc2cwMjA1 My5odG1sIGFuZCBtYW55LCBtYW55IG1lc3NhZ2VzIGJlb3JlIHRoaXMuCkNoZWVycyxFbHd5bgoK ClNlbnQgZnJvbSBTYW1zdW5nIHRhYmxldC4KLS0tLS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0t LS0tLUZyb206IFBldGVyIENvcmRlbGwgPHBldGVqc29uQGNvZGFsb2dpYy5jb20+IERhdGU6IDEy LzAzLzIwMTcgIDA5OjA2ICAoR01UKzAwOjAwKSBUbzogTmVkIEZyZWVkIDxuZWQuZnJlZWRAbXJv Y2hlay5jb20+LCBKdWxpYW4gUmVzY2hrZSA8anVsaWFuLnJlc2Noa2VAZ214LmRlPiBDYzogZHJh ZnQtaWV0Zi1qc29uYmlzLXJmYzcxNTliaXMuYWxsQGlldGYub3JnLCBKb2huIENvd2FuIDxjb3dh bkBjY2lsLm9yZz4sIGlldGZAaWV0Zi5vcmcsIHNlY2RpckBpZXRmLm9yZywganNvbkBpZXRmLm9y ZywgQmVuamFtaW4gS2FkdWsgPGthZHVrQG1pdC5lZHU+IFN1YmplY3Q6IFJlOiBbSnNvbl0gc2Vj ZGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLWpzb25iaXMtcmZjNzE1OWJpcy0wMyAKT24gMTEvMDMv MjAxNyAxNTo0MSwgTmVkIEZyZWVkIHdyb3RlOgo+PiBPbiAyMDE3LTAzLTExIDAzOjA4LCBKb2hu IENvd2FuIHdyb3RlOgo+PiA+Cj4+ID4gT24gVGh1LCBNYXIgOSwgMjAxNyBhdCAxMjo1MyBBTSwg QmVuamFtaW4gS2FkdWsgPGthZHVrQG1pdC5lZHUKPj4gPiA8bWFpbHRvOmthZHVrQG1pdC5lZHU+ PiB3cm90ZToKPj4gPgo+PiA+wqDCoMKgwqAgSWYgdGhhdCdzIHdoYXQncyBzdXBwb3NlZCB0byBo YXBwZW4sIGl0IHNob3VsZCBwcm9iYWJseSBiZSBtb3JlCj4+ID7CoMKgwqDCoCBjbGVhciwgeWVz LsKgIChCdXQgYXJlbid0IHRoZXJlIHRleHRzIHRoYXQgaGF2ZSB2YWxpZAo+PiBpbnRlcnByZXRh dGlvbnMKPj4gPsKgwqDCoMKgIGluIG11bHRpcGxlIGVuY29kaW5ncz8pCj4+ID4KPj4gPgo+PiA+ IE5vdCBpZiB0aGUgY29udGVudCBpcyB3ZWxsLWZvcm1lZCBKU09OIGFuZCB0aGUgb25seSBwb3Nz aWJsZSBlbmNvZGluZ3MKPj4gPiBhcmUgVVRGLTgsIFVURi0xNiwgYW5kIFVURi0zMi7CoCBJdCBz dWZmaWNlcyB0byBleGFtaW5lIHRoZSBmaXJzdCBmb3VyCj4+ID4gYnl0ZXMgb2YgdGhlIGlucHV0 LsKgIElmIHRoZXJlIGFyZSBubyBOVUwgYnl0ZXMgaW4gdGhlIGZpcnN0IGZvdXIgYnl0ZXMsCj4+ ID4gaXQgaXMgVVRGLTg7IGlmIHRoZXJlIGFyZSB0d28gTlVMIGJ5dGVzLCBpdCBpcyBVVEYtMTY7 IGlmIHRoZXJlIGFyZQo+PiA+IHRocmVlIE5VTCBieXRlcywgaXQgaXMgVVRGLTMyLsKgIFRoaXMg d29ya3MgYmVjYXVzZSB0aGUgZ3JhbW1hciByZXF1aXJlcwo+PiA+IHRoZSBmaXJzdCBjaGFyYWN0 ZXIgdG8gYmUgaW4gdGhlIEFTQ0lJIHJlcGVydG9pcmUsIGFuZCB0aGUgTlVMCj4+ID4gKmNoYXJh Y3RlciogKFUrMDAwMCkgaXMgbm90IGFsbG93ZWQgYXQgYWxsLgo+Cj4+IEdvb2QgZXhwbGFuYXRp b24uIE1heWJlIHRoZSBzcGVjIHNob3VsZCBpbmNsdWRlIGl0Lgo+Cj4gKzEKPgo+IFRoaXMgZXhh Y3QgaXNzdWUganVzdCBjYW1lIHVwIGluIGEgbWVkaWEgdHlwZSByZXZpZXcsIHdoZXJlIHNvbWVv bmUKPiBzcGVjaWZpZWQgYSBjaGFyc2V0IHBhcmFtZXRlciBiZWNhdXNlIHRoZXkgd2VyZW4ndCBh d2FyZSBvZiB0aGlzIGFsZ29yaXRobS4KPgo+IEl0IHdvdWxkIGJlIHZlcnkgaGVscGZ1bCB0byBo YXZlIHRoaXMgdGV4dCBpbiB0aGUgUkZDLgoKCkFsdGhvdWdoIGl0IGRvZXMgbmVlZCBzbGlnaHRs eSBtb3JlIGRldGFpbCB0byB0YWtlIGludG8gYWNjb3VudCAKZW5kaWFuLW5lc3MgaW4gdGhlIGNh c2Ugb2YgVVRGLTE2IGFuZCAtMzIuCgpUaGUgWE1MIHNwZWMgbWF5IG9mZmVyIHNvbWUgZXhhbXBs ZSB0ZXh0OgoKaHR0cHM6Ly93d3cudzMub3JnL1RSLzIwMDgvUkVDLXhtbC0yMDA4MTEyNi8jc2Vj LWd1ZXNzaW5nCgpQZXRlIENvcmRlbGwKQ29kYWxvZ2ljIEx0ZApSZWFkICYgd3JpdGUgWE1MIGlu IEMrKywgaHR0cDovL3d3dy54bWwyY3BwLmNvbQoK ----_com.samsung.android.email_4565109410242090 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keT48ZGl2Pih3aXRoIGhhbGYgYSBHZW4t YXJ0IGhhdCBvbi4uLik8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkRvZXMgdGhlIFdHIHJlYWxs eSB3YW50IHRvIHJldmlzaXQgdGhlIGFuZ3Vpc2hlZCBkaXNjdXNzaW9ucyB0aGF0IHJlc3VsdGVk IGluIHRoZSBjaGFuZ2VzIHRvIFNlY3Rpb24gOC4xIG9mIGRyYWZ0LWlldGYtanNvbi1yZmM0NjI3 YmlzIGJldHdlZW4gdmVyc2lvbnMgMDcgYW5kIDA4IGJhY2sgaW4gbGF0ZSBOb3ZlbWJlciAyMDEz PzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+U2VlJm5ic3A7aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbC1hcmNoaXZlL3dlYi9qc29uL2N1cnJlbnQvbXNnMDIwNTMuaHRtbCBhbmQgbWFueSwgbWFu eSBtZXNzYWdlcyBiZW9yZSB0aGlzLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+Q2hlZXJzLDwv ZGl2PjxkaXY+RWx3eW48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxi cj48L2Rpdj48ZGl2IGlkPSJjb21wb3Nlcl9zaWduYXR1cmUiPjxkaXYgc3R5bGU9ImZvbnQtc2l6 ZTo4NSU7Y29sb3I6IzU3NTc1NyIgZGlyPSJhdXRvIj5TZW50IGZyb20gU2Ftc3VuZyB0YWJsZXQu PC9kaXY+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1zaXplOjEwMCU7Y29s b3I6IzAwMDAwMCI+PCEtLSBvcmlnaW5hbE1lc3NhZ2UgLS0+PGRpdj4tLS0tLS0tLSBPcmlnaW5h bCBtZXNzYWdlIC0tLS0tLS0tPC9kaXY+PGRpdj5Gcm9tOiBQZXRlciBDb3JkZWxsICZsdDtwZXRl anNvbkBjb2RhbG9naWMuY29tJmd0OyA8L2Rpdj48ZGl2PkRhdGU6IDEyLzAzLzIwMTcgIDA5OjA2 ICAoR01UKzAwOjAwKSA8L2Rpdj48ZGl2PlRvOiBOZWQgRnJlZWQgJmx0O25lZC5mcmVlZEBtcm9j aGVrLmNvbSZndDssIEp1bGlhbiBSZXNjaGtlICZsdDtqdWxpYW4ucmVzY2hrZUBnbXguZGUmZ3Q7 IDwvZGl2PjxkaXY+Q2M6IGRyYWZ0LWlldGYtanNvbmJpcy1yZmM3MTU5YmlzLmFsbEBpZXRmLm9y ZywgSm9obiBDb3dhbiAmbHQ7Y293YW5AY2NpbC5vcmcmZ3Q7LCBpZXRmQGlldGYub3JnLCBzZWNk aXJAaWV0Zi5vcmcsIGpzb25AaWV0Zi5vcmcsIEJlbmphbWluIEthZHVrICZsdDtrYWR1a0BtaXQu ZWR1Jmd0OyA8L2Rpdj48ZGl2PlN1YmplY3Q6IFJlOiBbSnNvbl0gc2VjZGlyIHJldmlldyBvZiBk cmFmdC1pZXRmLWpzb25iaXMtcmZjNzE1OWJpcy0wMyA8L2Rpdj48ZGl2Pjxicj48L2Rpdj48L2Rp dj5PbiAxMS8wMy8yMDE3IDE1OjQxLCBOZWQgRnJlZWQgd3JvdGU6PGJyPiZndDsmZ3Q7IE9uIDIw MTctMDMtMTEgMDM6MDgsIEpvaG4gQ293YW4gd3JvdGU6PGJyPiZndDsmZ3Q7ICZndDs8YnI+Jmd0 OyZndDsgJmd0OyBPbiBUaHUsIE1hciA5LCAyMDE3IGF0IDEyOjUzIEFNLCBCZW5qYW1pbiBLYWR1 ayAmbHQ7a2FkdWtAbWl0LmVkdTxicj4mZ3Q7Jmd0OyAmZ3Q7ICZsdDttYWlsdG86a2FkdWtAbWl0 LmVkdSZndDsmZ3Q7IHdyb3RlOjxicj4mZ3Q7Jmd0OyAmZ3Q7PGJyPiZndDsmZ3Q7ICZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgSWYgdGhhdCdzIHdoYXQncyBzdXBwb3NlZCB0byBoYXBwZW4s IGl0IHNob3VsZCBwcm9iYWJseSBiZSBtb3JlPGJyPiZndDsmZ3Q7ICZndDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgY2xlYXIsIHllcy4mbmJzcDsgKEJ1dCBhcmVuJ3QgdGhlcmUgdGV4dHMgdGhh dCBoYXZlIHZhbGlkPGJyPiZndDsmZ3Q7IGludGVycHJldGF0aW9uczxicj4mZ3Q7Jmd0OyAmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGluIG11bHRpcGxlIGVuY29kaW5ncz8pPGJyPiZndDsm Z3Q7ICZndDs8YnI+Jmd0OyZndDsgJmd0Ozxicj4mZ3Q7Jmd0OyAmZ3Q7IE5vdCBpZiB0aGUgY29u dGVudCBpcyB3ZWxsLWZvcm1lZCBKU09OIGFuZCB0aGUgb25seSBwb3NzaWJsZSBlbmNvZGluZ3M8 YnI+Jmd0OyZndDsgJmd0OyBhcmUgVVRGLTgsIFVURi0xNiwgYW5kIFVURi0zMi4mbmJzcDsgSXQg c3VmZmljZXMgdG8gZXhhbWluZSB0aGUgZmlyc3QgZm91cjxicj4mZ3Q7Jmd0OyAmZ3Q7IGJ5dGVz IG9mIHRoZSBpbnB1dC4mbmJzcDsgSWYgdGhlcmUgYXJlIG5vIE5VTCBieXRlcyBpbiB0aGUgZmly c3QgZm91ciBieXRlcyw8YnI+Jmd0OyZndDsgJmd0OyBpdCBpcyBVVEYtODsgaWYgdGhlcmUgYXJl IHR3byBOVUwgYnl0ZXMsIGl0IGlzIFVURi0xNjsgaWYgdGhlcmUgYXJlPGJyPiZndDsmZ3Q7ICZn dDsgdGhyZWUgTlVMIGJ5dGVzLCBpdCBpcyBVVEYtMzIuJm5ic3A7IFRoaXMgd29ya3MgYmVjYXVz ZSB0aGUgZ3JhbW1hciByZXF1aXJlczxicj4mZ3Q7Jmd0OyAmZ3Q7IHRoZSBmaXJzdCBjaGFyYWN0 ZXIgdG8gYmUgaW4gdGhlIEFTQ0lJIHJlcGVydG9pcmUsIGFuZCB0aGUgTlVMPGJyPiZndDsmZ3Q7 ICZndDsgKmNoYXJhY3RlciogKFUrMDAwMCkgaXMgbm90IGFsbG93ZWQgYXQgYWxsLjxicj4mZ3Q7 PGJyPiZndDsmZ3Q7IEdvb2QgZXhwbGFuYXRpb24uIE1heWJlIHRoZSBzcGVjIHNob3VsZCBpbmNs dWRlIGl0Ljxicj4mZ3Q7PGJyPiZndDsgKzE8YnI+Jmd0Ozxicj4mZ3Q7IFRoaXMgZXhhY3QgaXNz dWUganVzdCBjYW1lIHVwIGluIGEgbWVkaWEgdHlwZSByZXZpZXcsIHdoZXJlIHNvbWVvbmU8YnI+ Jmd0OyBzcGVjaWZpZWQgYSBjaGFyc2V0IHBhcmFtZXRlciBiZWNhdXNlIHRoZXkgd2VyZW4ndCBh d2FyZSBvZiB0aGlzIGFsZ29yaXRobS48YnI+Jmd0Ozxicj4mZ3Q7IEl0IHdvdWxkIGJlIHZlcnkg aGVscGZ1bCB0byBoYXZlIHRoaXMgdGV4dCBpbiB0aGUgUkZDLjxicj48YnI+PGJyPkFsdGhvdWdo IGl0IGRvZXMgbmVlZCBzbGlnaHRseSBtb3JlIGRldGFpbCB0byB0YWtlIGludG8gYWNjb3VudCA8 YnI+ZW5kaWFuLW5lc3MgaW4gdGhlIGNhc2Ugb2YgVVRGLTE2IGFuZCAtMzIuPGJyPjxicj5UaGUg WE1MIHNwZWMgbWF5IG9mZmVyIHNvbWUgZXhhbXBsZSB0ZXh0Ojxicj48YnI+aHR0cHM6Ly93d3cu dzMub3JnL1RSLzIwMDgvUkVDLXhtbC0yMDA4MTEyNi8jc2VjLWd1ZXNzaW5nPGJyPjxicj5QZXRl IENvcmRlbGw8YnI+Q29kYWxvZ2ljIEx0ZDxicj5SZWFkICZhbXA7IHdyaXRlIFhNTCBpbiBDKyss IGh0dHA6Ly93d3cueG1sMmNwcC5jb208YnI+PGJyPjwvYm9keT48L2h0bWw+ ----_com.samsung.android.email_4565109410242090-- From nobody Sun Mar 12 17:03:53 2017 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 844C1129417; Sun, 12 Mar 2017 17:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 QfqPcwrPQ-m6; Sun, 12 Mar 2017 17:03:47 -0700 (PDT) Received: from mail-wr0-x229.google.com (mail-wr0-x229.google.com [IPv6:2a00:1450:400c:c0c::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 489EC12940C; Sun, 12 Mar 2017 17:03:47 -0700 (PDT) Received: by mail-wr0-x229.google.com with SMTP id g10so94107071wrg.2; Sun, 12 Mar 2017 17:03:47 -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=NUbutvCzy+8Jgju5y8dTSxxDEaKS7uvnJAwLrXNLakY=; b=bRcWmNn+7rRPfMOWxXdS8CAy+ae0yssvvESaeefKdS/AOOtxoc/H7BHSs46p7WLsD4 tpXu3WhHCB+cDgyBN60VWjKLivLQTBT4Xw+qXCZa0NhziSsCX72vGTMgJRH5YPSu8IfA HYjxQ0kozn/eY/V961tBBkN/medY3ZUP2XmdQUD8YTFAfWDoee7uHro8W49GoOZzuCty b3aXWUAqXWQijRhgLJrG6GLgybTh9XHR62Qs37Fdj/V/0jJJhwnVXLlrmaQi8IuUJa+O 0lH/Qjx49zk9CwEES0Tsu8YsR0RWEjxLdEhhITqVgh9J/ursTLoy8WDlYsV/xa09tPqC javA== 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=NUbutvCzy+8Jgju5y8dTSxxDEaKS7uvnJAwLrXNLakY=; b=hmdkcjF8XGX/Co2eopidSOrIDdDH2f5Ti0fxodQE8h3x8Jd16qDiUkewnpMHCmIPRt 8V8b/biySPTHoo5Whbm+QAw8meXKdSfXFQnfHhA7lkQ6/AuY6nbn3blvr5jmqwqK2/cH kQwgGJDESKcZeDho+YgXxHbxbbbz8rgkN4tUipeIzWbEZF2Mlpxks1C336Ew9WqRoYqS L9nbbRcMYkK6Kr/a11U4uP5eMacH8PSR+hCUVKHdGcpkjJhVugxqJd1SXhrRAP87pgTW +vlquocPUKQRxqD7yY1Ihu8lF6SOcV7OTbyxbgYs1Jao99geaB9od5ZV3800ytqdgQrl 4XGg== X-Gm-Message-State: AMke39nR6TZ/BTwP9o1u/tdbY7WMwcWy0RKZODJOKTkzJHpcjCPEO2s9KS0k+Y/tAO+7tnHXd3294BK4VtWvDw== X-Received: by 10.223.153.39 with SMTP id x36mr26037818wrb.64.1489363425697; Sun, 12 Mar 2017 17:03:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.163.2 with HTTP; Sun, 12 Mar 2017 17:03:45 -0700 (PDT) From: Watson Ladd Date: Sun, 12 Mar 2017 17:03:45 -0700 Message-ID: To: "" , secdir@ietf.org, draft-ietf-dane-smime.all@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [secdir] Review of draft-ietf-dane-smime-15 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 00:03:48 -0000 Dear all, I apologize for the last-minute nature of this review. I think this draft is ready only because it is experimental: there are several pieces missing from a comprehensive solution, but it is worth getting the experience from a real deployment before proceeding further. Sincerely, Watson Ladd From nobody Sun Mar 12 23:23:59 2017 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 20A69129540; Sun, 12 Mar 2017 23:23:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 aHxwCLL0wakQ; Sun, 12 Mar 2017 23:23:51 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 7E161128B37; Sun, 12 Mar 2017 23:23:50 -0700 (PDT) Received: from [192.168.178.20] ([93.217.107.79]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LhTjQ-1cROm21uBk-00mZwW; Mon, 13 Mar 2017 07:23:22 +0100 To: Elwyn Davies , Peter Cordell , Ned Freed References: From: Julian Reschke Message-ID: <0d3258fa-0f9d-cc5d-06d7-fcba943349ad@gmx.de> Date: Mon, 13 Mar 2017 07:23:20 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ONAqVCTvpdU/oTq78wPt92ZoUiWczEgP+MlfZwRy2qEVtlFKnSA p1ebcexiZx5Nc33PxzOMmpeICWFJvTXl86sY0vvwt9PTFS+DUL+tJgSenbqqqo9ipcxUCL1 0e3g72J030txLwaop68Lkut4jNUgh07fOUumSc3YVIrWbNOmekZmYCCVPmIRBt8KO3hRSiG mQeKnrCNdT9s75Usbs0Eg== X-UI-Out-Filterresults: notjunk:1;V01:K0:8bWtMcdviHI=:tsV1/zi7YPzEWA9zPU02wZ Qn1QQMA1Z/V6Mz3s/tbuyoK6NNu1n+W26wyFligSGhq4+k4X2nA0AgTHGTQwR5ZF1ZEtwYuw4 S8boytoF9IFmUPBxR0vai/hWrjQi8xLTHhz+j7tC1gu7u8T6rSIfKiXk3T5XWUhZYlkF3mSWM RUtU4hFfy//NIS+ACroOVat2vGwtC1m2rPDHYB4m8wYeo+dJDV/uydazEXi2jGIV8QNgYfjCn vxIYkAenSBlZw1SFClmBg08nHLVnFQUt1Yo55OrTieABa/otwjCfuqpiWoRPwfu1idEz86y+0 4L7qRu4DOqYoxH3dB3YktoqG07UfI3Kp6k0P+PcMxxK9qMfrpU3vkpF5evyV9o/8Giznjuh8m P4lkM2heiorEoL4Ozr8hHnD/prZKKjFWQAwMNNy/okguAkeylTBE9RTNY1qBXplLTJOIz1auZ zvaifaa9tyUmQUXnCZQvFGCqJYr8pxiYgklSNhci8MCbagQpK60P+/8c5e+eHBD/k++9eaCM1 rHOzvU6YS1g5aUNFJJSGXyRU+Cn0DzzoDMdQ4GUMn6MwqMGUI8GvT5/cAHxEyj/D/9SdRa2dL 2Pi2mqYAQjAg3ffv3w38YxeICfGsXtQAPkBtlQe/AmS1WHl5baN59jaYWI+n9gz/YeCi9x1g9 3L8fyByb7d/lXHI6fl30pdEJIgUqkzctd4V2GoUoyb2qSJr0t3HrVhkj8Pm88MuH522KRFATH DilpeNRGsu7km+PB+2m0rEfY9APvetxg6V8ZI9kAAZP7eMW8RmZ4dj1XLK5TTkpZMfd+N/2LE 4NRozLK Archived-At: Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, John Cowan , ietf@ietf.org, secdir@ietf.org, "json@ietf.org" Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 06:23:52 -0000 On 2017-03-13 00:07, Elwyn Davies wrote: > (with half a Gen-art hat on...) > > Does the WG really want to revisit the anguished discussions that > resulted in the changes to Section 8.1 of draft-ietf-json-rfc4627bis > between versions 07 and 08 back in late November 2013? > > See https://www.ietf.org/mail-archive/web/json/current/msg02053.html and > many, many messages beore this. > > Cheers, > Elwyn No, but on the other hand, we should acknowledge that apparently the text both about what's mandatory and how auto detection works is not as clear as it should. Best regards, Julian From nobody Mon Mar 13 00:46:12 2017 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 4FF51129549 for ; Mon, 13 Mar 2017 00:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet-se.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 81NOli1vK21K for ; Mon, 13 Mar 2017 00:46:08 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (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 6B5F4129502 for ; Mon, 13 Mar 2017 00:46:08 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id l37so97923307wrc.1 for ; Mon, 13 Mar 2017 00:46:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=0554eQA7VfYvNyUyzsXNu7vsXpKYKL2yj3OPNp9WKxM=; b=yRut22T9ppd0OG5g26y5Xx/qBrKBNjxAXK5L2HcC6uIKeG7lDHmWmlgb71N74Xz5b9 bD64P2XXWIxOEgIBzgoW0jJ/lvf0EUINFGICpWie6JqtW+mGItbVSS7pR+XF63kfA64x LmNaJZN/DHVqAmT8J27LiabqarVDNbR55k62SdaB2Lz7byl6xUihkjfV6Vm/ZRGNFX5J eANjTVQuKBQUfV7M+a0jZpJexEQLfJctuLuMC6epMTqs97+UnSs75zbpphzNQAyqeH0l vAW45yMio4Pqdl+AL3IGzbPYlNx6Tl2YZRT3fFUB3qukRe7dR03gOrXWBCKxvvIMx4jk r1pQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=0554eQA7VfYvNyUyzsXNu7vsXpKYKL2yj3OPNp9WKxM=; b=BR0/v7A4VGeohGon06TFM5Z9bMB6lySqxKKg1yT/L7PNhI9oIzGSB8WHGByLhB8uIZ d6ykLxi0NxgZLbbRzF6Vyq9+pXRRaS6RGpy6G/w841VNUVDkU3u8oyaOIT+YAlLH1tij 6plLimH8yL+WMJdxwTZqGOlKO9CRPl6vZFBr55URH/DsUeiuhZc6DIFjpE/TdLkzZJ2i WkcIyK5lWQe8kZvwURL5vj+GEmVu2EjOvmcAOot+587Ef6ycI7H0+7vdwQE6pOQ1pnvh LAk/foutm5N3SlnQzrI6TKZuNm8juh1FZbgZVvbBfZFwvh6T6RWRerinnot4hRmma5v0 kDxQ== X-Gm-Message-State: AMke39kF/vYaJkgzpFnl7FqsBylEGQ7CdOvE2p3w50++iQG+tBuZhsETbXdFW1rPmOLmCw== X-Received: by 10.223.173.76 with SMTP id p70mr25121134wrc.168.1489391166720; Mon, 13 Mar 2017 00:46:06 -0700 (PDT) Received: from [109.105.104.193] (dhcp59.se-tug.nordu.net. [109.105.104.193]) by smtp.gmail.com with ESMTPSA id x18sm10193158wmd.14.2017.03.13.00.46.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 00:46:06 -0700 (PDT) To: "secdir@ietf.org" , "iesg@ietf.org" , draft-ietf-lmap-information-model.all@ietf.org References: <20170312115200.GD50035@elstar.local> From: Leif Johansson Message-ID: <4250948b-3919-2ebc-5d93-d0f1bbc41605@sunet.se> Date: Mon, 13 Mar 2017 08:46:05 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <20170312115200.GD50035@elstar.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-lmap-information-model-17 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 07:46:10 -0000 On 2017-03-12 12:52, Juergen Schoenwaelder wrote: > On Thu, Mar 09, 2017 at 05:06:00PM +0100, Leif Johansson wrote: >> >> Reviewer: Leif Johansson >> Review result: Has issues >> >> I have reviewed this document as part of the security directorate's >> ongoing effort to review all IETF documents being processed by the >> IESG. These comments were written primarily for the benefit of the >> security area directors. Document editors and WG chairs should treat >> these comments just like any other last call comments. >> >> Review: >> >> Section 3.8 begins "A Channel defines a bi-directional communication >> channel". First of all it is probably a good idea avoid using the >> term you're defining in the definition. > > I can s/channel/mechanism/ to avoid the usage of channel while > defining Channel (not sure it adds clarity though). > >> Also in the text a Channel is described as a URL with the cert or CA >> of the endpoint but in the channel object definition there is only a >> reference to the credentials which I understood to be the client authn >> credential and not the server identity. >> >> This leads me to a larger issue (which may be answered in another LMAP >> document for all I know): what is the authentication model for LMAP? >> Specifically, does LMAP assume the standard Web PKI for channel end- >> points? If not, then you probably need to specify how to validate the >> server cert which may lead you to want to represent a private CA (say) >> in the channel object. In any case the authentication model should be >> referenced from the Security Considerations section and clearly match >> the information model for channels. > > This being an information model, we aim at staying away from being too > specific. The information model is mapped today to a YANG data model > (IETF) and a data model for TR-69 (BBF). The YANG data model may be > accessed today via NETCONF or RESTCONF. There may be other protocols > in the future. RESTCONF runs over HTTP/TLS, NETCONF runs by default > over SSH (which supportes a number of authentication mechanisms), > NETCONF may also run over TLS. In other words, the concrete details > how authentication is done is specific to the protocols used to access > instantiations of specific data models. This is why we talk about > rather opaque credentials in the definition of ma-channel-obj and > section 2 "Notation" says: > > credentials An opaque type representing credentials needed by a > cryptographic mechanism to secure communication. Data > models must expand this opaque type as needed and > required by the security protocols utilized. > > /js > The level of abstraction is beside the point. If you want your model to reflect authentication for client then you need a credential in the model (which you have). If in addition, you need to control how you validate the server cert then you need something in the model that represents that. Given your model that could be a credential too. It depends on what you want to do but it doesn't depend on the level of abstraction of your model. Cheers Leif From nobody Mon Mar 13 00:52:05 2017 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 E6070129545; Mon, 13 Mar 2017 00:52:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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=itaoyama.onmicrosoft.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 hbN1UAZ5ZJts; Mon, 13 Mar 2017 00:52:01 -0700 (PDT) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0123.outbound.protection.outlook.com [104.47.92.123]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5770A1294B2; Mon, 13 Mar 2017 00:52:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RpcTQuyV2LNcidqlEQUoSnzjBpZ0DGp8PzdYi/LZUr8=; b=Y5wzBoLRYEgicdKDouFdRjqydWcwfRFnq9hjHsBjDW468u485MIButBlqRhagvo3iGHCGDuBlyokgNznNhjJSiQdqBCSp8cSKT31/p+CIytXmhPdxLbmQ0dE3/PtYxsS/vJ7YOafFzmtRkJsrihYieiJ+oA3+ctZ9qqsyHoNnfY= Authentication-Results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [192.168.160.103] (122.220.198.115) by TY1PR01MB0651.jpnprd01.prod.outlook.com (10.167.158.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Mon, 13 Mar 2017 07:51:59 +0000 To: Julian Reschke , Elwyn Davies , Peter Cordell , Ned Freed References: <0d3258fa-0f9d-cc5d-06d7-fcba943349ad@gmx.de> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Mon, 13 Mar 2017 16:51:58 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <0d3258fa-0f9d-cc5d-06d7-fcba943349ad@gmx.de> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [122.220.198.115] X-ClientProxiedBy: TYXPR0101CA0006.jpnprd01.prod.outlook.com (10.168.40.144) To TY1PR01MB0651.jpnprd01.prod.outlook.com (10.167.158.14) X-MS-Office365-Filtering-Correlation-Id: 2915304f-a10e-477d-44c1-08d469e5d411 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:TY1PR01MB0651; X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0651; 3:8+HBGMAzDoRqvKKKeT8C1MlX6ZjzDq1fyx8BgZVEDQVJoCEpd068pQM1VgQEuWKixaxeteDN+xbipsh1cL4LntQau+HxdNu086xt5uLqiWoCU1qjjg6eBCfYkRP7YLsoyBwekiC5zWjvzH23wmne11kgCtLn81SopkKTApAVGuVY2P/Dm5a6kRJSGJDPymqCmXlhw/boWTpByA1rmtAam+RrrxKw2uSKNF0fJi1poxm4zNkAb52AzJXWHQOBVfs55MAEen0haEuRsSM7T0l3XA==; 25:9+RF5SUINutkc0i0H2erNtbf3bJtAnecbaV7D+48jp7g+kI46+LMXjfcVv1hNPGqTw8imyaP29WBzQ/3TrJG5kJixiyySlI2H/rkIwM0djo80mloE5lQhPQVwKNIqjiqrC7X6nd99ehvccDHbL79O1i6tqL852kWveW5oroEYPvYDsvySlJ1LBqGkmKxWE0cvQcnnXXdl28dW3ekj78W7Eqefq81zzP/wZXKUKypEJ5glaXQ/F+MK10zWC36rpeSJnHisx3GFeJVvjlOwIAICBMvDIg/WjRpGxWLJjKeZzWwyYWJ3VjXRcsuDxSnERlcD+EqrMTgpVJ1wPEYjYlHuflNKuC538c4i0mERP4WK5WyMu5vEaS/VT+edwx4fpbAQgvzjL5f6PU7WazA7BAO0F6xohNsXFQDHMXaUUFYIpSi7yr1Zt6/8+6Oaqa0xcAAmEGDX2Fd+71W57jiY9xDlw== X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0651; 31:+vD2YF3L8PtL2jWHSSLNu2tZq2OVnuGW3Zzgs4IquEZjQMHq+W/WTQ+Qnoca9BncnlPCMCNaxBPS63hQiLIb02sGRG9f9xr3ETqxGqwFhz8FjgXjFRAOoakYVPa3QI4HgLy9WOVw7qwBFOH2QBFrsnWW5ONhAs9gyd5C6oGE8llrTzhtsk/YZToiaxwoTslTALdatyVrCL5YjeFc1Q0ss/BiIS6rGzhywe+prUD2hLZIdCemh2cEsbyN1Ph0IcI0NpxT8Paxdp71aRdbpMI7OA==; 4:hJ73WhB33GvDr5NcAZN2y9TEjW0qiygN9FusMd8Dep8mNyaF5h0n8bKFhrFHd4UmvzCJw65FptNoEFIRh+y4wrVVtcAsYHmYFRn88Dr5LaPvMF2zSOZ6MOneSsSas6pH4c7tWs8QBasJgBZFg2gqfxlnweQdo8Zn/B368h7EnxI+r37sw4GQOzgmjId5WID0Moa9Pf2AfZxiibb/QmyqMR8hnSTpvx4YReWBvDMBt+6/90NP4ab+r+vRVcxk+JYVq3JJxhEN7XIk3K4T8lPuEkVnP1bqimsnaM+fGf17oOHK56uzmXjhQoxTfpQaMtJUjyIlrGfgcPeljBT3XFadTBGZYAovh4itIpa0Amx1B/8sN6+JIWwpq9Q/0rTgjGVzu5WUMs6s3KzGaBuB07pzhkBGs3wkXQebehhDQamfbjCX2ZE8pHaz5CwPeCJF58AbKpekIg6YWtoL49IwoLuI2QLkqqVxY4v7XWfkwTzcelCFIrE2I409THd5qDDu9C1tiT5h327X3chTpXGQDxoWhgwFLvFxWE0lGqEEO+lYWBWao3ryi6Nkll+G1e4HtRJyVbJOIlp6NCvmxMTXYZveAufqQYW1MtJzYUD4nvDSmECZRS5cn8YwyjUlVBrTqJL1GKV0kcCvaHgHwYIB7RYyZg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(100405760836317); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123558025)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148); SRVR:TY1PR01MB0651; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0651; X-Forefront-PRVS: 0245702D7B X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(39450400003)(24454002)(377424004)(25786008)(31696002)(305945005)(90366009)(6306002)(64126003)(50986999)(54356999)(76176999)(8666007)(117156001)(230783001)(42186005)(31686004)(6486002)(77096006)(53936002)(229853002)(81166006)(8676002)(7416002)(2906002)(74482002)(2950100002)(42882006)(3846002)(6116002)(33646002)(5660300001)(86362001)(230700001)(7736002)(66066001)(65956001)(65806001)(6246003)(53546006)(47776003)(23676002)(189998001)(38730400002)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB0651; H:[192.168.160.103]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWTFQUjAxTUIwNjUxOzIzOnhJOWdVMFNkbktJa2g3MWxqcmZEOHM2Wk13?= =?utf-8?B?ditYUkxMTFdSZjA0cWRqbm1aOXpMSmUrMTRMRTltaWFvQXBINHd4NHdwbnhJ?= =?utf-8?B?THpIcEJ6MHZHYmtSYUwxbmtnUU1LUVl5V3l1cGxwelJKblBoSy9wTm9rZW0r?= =?utf-8?B?OHdnRHlYY0dva3RrS0gxSys1SzI3Q3VsakI1VWxpLzFxa3l3VE9wQXZDWjdH?= =?utf-8?B?ak1ESGNEM29xNGJiUEdjWkhYbEhvUEIyWWNLUDdsMVJ2MmVJdHNGTHVVR0dH?= =?utf-8?B?cHV1WlczU0xjR2R6djYySXc5cTJ0d2VlS3krdGZ2T3ZROWtvWXA3a1V0aXFs?= =?utf-8?B?Tjg1NERheVA0cEdQcUxRUnJFdzRWYllxcllsaXY5V2pFWlhNcWlXQ1FkdzJM?= =?utf-8?B?dXBINytscXdlRHdtVUJsbHZDc2FrbDlpMjY0ZENQWUZwVmVWMTQxQUNFNTgz?= =?utf-8?B?ekRYZ1dZT2FHQzJDZnllZS9YNitBcWVFSUhyeE5JanVVL05YdEU0aFg4R0ZZ?= =?utf-8?B?QVp0dS8rYmc4THlnNnoxR0tyQVJyUjFYbUsxTnVRdHVGa2lpeFoveHlEajNs?= =?utf-8?B?Z0hOZTJqejBHckJWZnYzNG5NN1IvajRuL090SUFIUGZuRlVHNm1kaTdmRkh6?= =?utf-8?B?YnpCcjY4WC80KzVUanhaaG85TDNMVTJEcHZEeHJyUkk5S0pXNVIxN1E0SGhz?= =?utf-8?B?SSt3TUdmZjNKaHFRQ2Y2Ny8wZis0TVB2YmhJaDRFVnB5ZllFNmhwTUZzc2Zv?= =?utf-8?B?blpZc1lEckRKSUFKbUhCd0tod05rVlZ6Mjd6ZVd1Y1lxd1VCYjhrZlduR0tN?= =?utf-8?B?NFBMdW5ob0pDaW1uVTFSUlJ2K21pZThkRkJnRUEvOEdZdldvNVNtTk5UczF1?= =?utf-8?B?RGQrcU0xSENYb2xhc3BEcEJoemhzdnExeFZWaWhyV2pKeUMwY1IwQnBzS3lp?= =?utf-8?B?RTQ2cGUyV0dKRnhQL3hVSzE4b2ZOOUhsZHBlRkZFR1lHR1ZRM0ZEUkxlSGN4?= =?utf-8?B?NENWdzFoWjJNOG51YVB5UWwxS0RWNU1vWTJ1cmY3MXNGOVcvLy9iRVBvRE44?= =?utf-8?B?dmVRSzJEdXd6Y09RODBqSVJlQlhZWWtwMjRiNE1oZ0lTbWJuNlJJem9kSE9n?= =?utf-8?B?Q1lYYzRKWTh0cmtCK2RNNkNjWkNWb0VpSjQ5WFBmWXFnWmNLaVk0L25OS2Ey?= =?utf-8?B?dksvR3o5Mml6K2FVKzd5a2d0VUZ2Ry8wUjdKK2RpbTVCQnNJKzRhR2JreWRR?= =?utf-8?B?MEJJNnNzU09Nc09ZUi8wWDZnMFBSY21FemhkQitmN3BXKy9VZXJPa3kvZGxX?= =?utf-8?B?MUFBSVh0a3pVNk5IWnlDbUF2NXFoU0pqbmJoemlacEdRSGRKaVZGQWhGZ3Ex?= =?utf-8?B?czZLQWo5WCtLRFVLRXIyazk0bjU5dnNhQVl3ZmxRaUhxNkJBWkFWa0F5QS9M?= =?utf-8?B?ZVJPRElwT2w2U3J0ZUc1dEZ4andBOXYwdWhiYkltUmpkd2JiQmtvK2pHY1d5?= =?utf-8?B?YmVEcFhMQkxLaThWdEN5dlRxeHU1RGczdFJMMVNGRVpOdy9HWHEwVVg3aThr?= =?utf-8?B?S1dDNlJiaGNMU2lKRjNuQ01FLzU4aUE9PQ==?= X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0651; 6:3p/hbXCXKLcBCHRxqVzgOap/4PLK061GLgFFDyhlPFb51JjR/cdkSV7HV2Gg3TA4jtbXXYrKsMnmnFFDITUSYzulFYouzvvcIuDShJAZVNGSi0v1xT7M7oEpsJ0vx3q8O/IaFdPGeFtCQgCH0gvQh9XLtH3etYq1jiHWh9AasIFWkFZyemivpmB41Cbi3VezMW22AU1uDj5nUikJHHK1uEWarEvpXPns4PmZWL9h3zgwCZVY61GfjE7LeENxwYzVRmhi3bRkiuBll9jA4AK63WJ51o5HMoJ8lFk+gAVr7tjNxhfm9SB6P6L/gkVnDXTcBcSTuyGqMSK/dNCjnqs/DoctvsqziqNhBPcuymxuUPbaf5q/S3WVLwU7+erR4vtznX9CP9mAdRBcGzrxyeWHqg==; 5:TFtby1T1G7MY8LOExlEaLDl4Y8LpTC4ZldcPugwiglI/JZBs/84A98llAt3Lw1aLMriK86XIKkuQRCakCC3qdLTkZlhKafwjnVP+m3Hh4rUQqAZDWJTG1qVlJY6pOH46xDJiJ1yTERaz3XyC3gLLyu9DQ8z3RQltgtJISjB8ihI=; 24:4S0cBWFwWhv9bycJdB2ZeewKWsi6x06DscltCBYEf8N5MUaOPKmhhLK27zFFjXjaXrH0F+tStnFAysKh//JHo/E5Z9FPemL58XBPd32NR+8= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0651; 7:9PsJd5BeWTQOYblC3dWCQH1Ru+uRDaHGj1o82mFj0ouKQtZCOlJ2wIofk1KBLxummOnKn9JbcBQty2fbeZYXVAtju+eSNLMxQK1cZ9h4CiV/PABAP+7rp/B12IS3rg8tRArS9th3dFMcH2nmH5C+MX0VAQYisHIkoye3IgM7erK2v1yzymr0qFvlfwlS7IgqZa3eiJNlVSDljQc1Aze1rBRVjkUGhwMkrxC/yOzuDpiu1LQfsS+ylg9gk3kfAyTT2G/rLuQDWwShSkNLG+vTeZG9SGizgXeEUCIh4kCcXp11fD7TpxfopE7XEaA0O21iLv/6pltcT2dRW60hPhtP/w== X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Mar 2017 07:51:59.0379 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0651 Archived-At: Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, John Cowan , ietf@ietf.org, secdir@ietf.org, "json@ietf.org" Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 07:52:04 -0000 On 2017/03/13 15:23, Julian Reschke wrote: > On 2017-03-13 00:07, Elwyn Davies wrote: >> Does the WG really want to revisit the anguished discussions that >> resulted in the changes to Section 8.1 of draft-ietf-json-rfc4627bis >> between versions 07 and 08 back in late November 2013? >> >> See https://www.ietf.org/mail-archive/web/json/current/msg02053.html and >> many, many messages beore this. > No, but on the other hand, we should acknowledge that apparently the > text both about what's mandatory and how auto detection works is not as > clear as it should. It looks to me as if at the time of the above message in the WG, the chairs were successful in presenting a consensus, probably at a stage when the participants in the discussion where getting tired. It seems that when put in the wider context of the IETF, that compromise now looks somewhat shaky. My personal opinion is that we could try to fix this by changing the following: >>>> JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32 [UNICODE] (Section 3). The default encoding is UTF-8, and JSON texts that are encoded in UTF-8 are interoperable in the sense that they will be read successfully by the maximum number of implementations; there are many implementations that cannot successfully read texts in other encodings (such as UTF-16 and UTF-32). >>>> to something like the following: >>>> JSON text SHOULD be encoded in UTF-8 [UNICODE] (Section 3). JSON texts that are encoded in UTF-8 are interoperable in the sense that they will be read successfully by the maximum number of implementations. There are many implementations that cannot successfully read texts in other encodings (such as UTF-16 and UTF-32). JSON text MAY be encoded in UTF-16 or UTF-32 [UNICODE] (Section 3) if the sender is sure that the intended recipients can read them. >>>> That should then go together with a MIME registration that only lists UTF-8. Regards, Martin. From nobody Mon Mar 13 01:14:58 2017 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 5CFC512954F; Mon, 13 Mar 2017 01:14:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 7MoIEE3uTZNk; Mon, 13 Mar 2017 01:14:56 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 B308C12954B; Mon, 13 Mar 2017 01:14:55 -0700 (PDT) Received: from [192.168.178.20] ([93.217.107.79]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LtmK9-1c4cIa29Jt-011E0q; Mon, 13 Mar 2017 09:14:21 +0100 To: Carsten Bormann References: <20170308014823.GF30306@kduck.kaduk.org> <382aa5c8-c977-b24d-4d19-251257833b00@gmx.de> <456b4234-0d94-1033-507c-710878bb5159@gmx.de> <20170309055348.GL30306@kduck.kaduk.org> <01QBU8WJOCUO0003XB@mauve.mrochek.com> <6d97dee7-7cf3-9142-aacf-f2ca4909103d@codalogic.com> <38DEEE0A-EE2C-4ADA-9D7A-9DBBAEACB77E@tzi.org> From: Julian Reschke Message-ID: Date: Mon, 13 Mar 2017 09:14:16 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <38DEEE0A-EE2C-4ADA-9D7A-9DBBAEACB77E@tzi.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:fWQpqIOlZcKxDu5xBlzvlzJnn26z6FzeULN6WCf50r/8/Yne2mh e1MkUm3aEJWfG+K79cVEwYHhM3XjF2TfUTPgXvUjnOeTVppMGmk6GTqMr2pfgXTqycuBp8h J1luWn3ohP+H8RICiE6aBNp7v3wddMcHfr38VppEp9K3D1OqZNX48juJL63oeofujQV5T7N 4WU42vS1URl/lOweYEoaA== X-UI-Out-Filterresults: notjunk:1;V01:K0:xdE/QCy07zU=:V99Oi0COQu3ylkgTUKN2Su rVXu6hlj0Lz1UbszMqWHJB37Rx9tWvBY2+yt3AjFS9+OYxQX6NUzD3ydpKafeOPfAm4myFyVc XTUJJnko3S7ImVTW7G+zfPx5euYz7EfYvGkAH1UtZd0ci4I2uYwIWfC4HBzUH+Y9A/mbQfCPj TfQ/jH5WdzafW0KMyTnC3V6z+sfT2An/9RPfFeFfe0cQfVMFaTvgAC1WZVeJBMPqMgpGN6kdJ Do9i8zYD/0LzmUbcKft/x0dkwHqfavOFhKIC37xNVVvFlrUpZMbjxRMtUzPVZpSq4dDGooi2b F/TlYtWgtk0YJ3FURoiH7EbwJ0bp3JeCqskRVfzNr9OBMucRLeNIWfr219dEQI0FZL9/9IjEY P8XWchbf76hjVCcyj0V1m9JTkcJtVTqFX+kCJGZzriRWyYe8ZlD0/fYn/IKPAIdCcNntVMwZ6 PDRycNWw1+JvIQVTcznQaimPTXNfR5/YLlB621IBjygSS/0QZfwk/jHfD5K1ij2+yRGNy1tvG sG2t+J5g02FxuFFptNTjNXHM5XBxHxAakbA7x/xdqtpaRmCbgTTobxxJ923rXDlcODTUw0fbV EtMMDYthnkPEvKtmWQvFlNt4Iz86aNhmY39UFh7QFohdM5g4k5Qy6cd1DtqeyE/VuFdLD2LOY yOewJvJsUv8Myg0KZKliiIqY03QReq3qBM3WkF8jRsMGpREFRJrrzDLvbV6SwoWljcKQUItHP 72/AmhRmbdDOWN/uL2E7GyWY62CookgZk+Tw6DoHgMXIO2+dmeWp/6O30DfoUT6ewiyxEhIQt FQVTzW9 Archived-At: Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, John Cowan , Ned Freed , IETF , Peter Cordell , secdir@ietf.org, "json@ietf.org" Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 08:14:57 -0000 On 2017-03-12 16:31, Carsten Bormann wrote: > On 12 Mar 2017, at 10:14, Julian Reschke wrote: >> >> Does anybody recall why we removed : > > I seem to remember that the advice simply is no longer working since JSON was extended from 4627 to 7159. Instead of trying to come up with an updated algorithm, the WG recognized that this is not a real-world problem. > ... So the changes in RFC 7159 allow top-level strings, so we can't rely on the first *two* characters being US-ASCII. But we *can* rely on the first one being US-ASCII, no? So the following should still be correct: > Since the first character of a JSON text will always be an ASCII > character [RFC0020], it is possible to determine whether an octet > stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking > at the pattern of nulls in the first four octets. > > 00 00 00 xx UTF-32BE > 00 xx xx xx UTF-16BE > xx 00 00 00 UTF-32LE > xx 00 xx xx UTF-16LE > xx xx xx xx UTF-8 Best regards, Julian From nobody Mon Mar 13 08:53:40 2017 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 CC8001294AE; Mon, 13 Mar 2017 08:53:38 -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, 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 aYeFjNAOA0KG; Mon, 13 Mar 2017 08:53:36 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 54A7C129461; Mon, 13 Mar 2017 08:53:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2DFrUlt001074; Mon, 13 Mar 2017 16:53:30 +0100 (CET) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vhj896ZJ7zDGsw; Mon, 13 Mar 2017 16:53:29 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: Date: Mon, 13 Mar 2017 16:53:29 +0100 X-Mao-Original-Outgoing-Id: 511113208.935962-e14c9edb15ee0368788f9baba5fa33a5 Content-Transfer-Encoding: quoted-printable Message-Id: <0602D025-05FF-4D60-8F92-A2A9DF4FACE3@tzi.org> References: <0d3258fa-0f9d-cc5d-06d7-fcba943349ad@gmx.de> To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= X-Mailer: Apple Mail (2.3259) Archived-At: Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, John Cowan , Ned Freed , IETF , Peter Cordell , secdir@ietf.org, Julian Reschke , "json@ietf.org" , Elwyn Davies Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 15:53:39 -0000 +1000 Gr=C3=BC=C3=9Fe, Carsten > On 13 Mar 2017, at 08:51, Martin J. D=C3=BCrst = wrote: >=20 > On 2017/03/13 15:23, Julian Reschke wrote: >> On 2017-03-13 00:07, Elwyn Davies wrote: >=20 >>> Does the WG really want to revisit the anguished discussions that >>> resulted in the changes to Section 8.1 of draft-ietf-json-rfc4627bis >>> between versions 07 and 08 back in late November 2013? >>>=20 >>> See https://www.ietf.org/mail-archive/web/json/current/msg02053.html = and >>> many, many messages beore this. >=20 >> No, but on the other hand, we should acknowledge that apparently the >> text both about what's mandatory and how auto detection works is not = as >> clear as it should. >=20 > It looks to me as if at the time of the above message in the WG, the = chairs were successful in presenting a consensus, probably at a stage = when the participants in the discussion where getting tired. >=20 > It seems that when put in the wider context of the IETF, that = compromise now looks somewhat shaky. >=20 > My personal opinion is that we could try to fix this by changing the = following: >=20 > >>>> > JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32 [UNICODE] > (Section 3). The default encoding is UTF-8, and JSON texts that are > encoded in UTF-8 are interoperable in the sense that they will be > read successfully by the maximum number of implementations; there = are > many implementations that cannot successfully read texts in other > encodings (such as UTF-16 and UTF-32). > >>>> >=20 > to something like the following: >=20 > >>>> > JSON text SHOULD be encoded in UTF-8 [UNICODE] > (Section 3). JSON texts that are > encoded in UTF-8 are interoperable in the sense that they will be > read successfully by the maximum number of implementations. >=20 > There are > many implementations that cannot successfully read texts in other > encodings (such as UTF-16 and UTF-32). JSON text MAY be encoded in > UTF-16 or UTF-32 [UNICODE] (Section 3) if the sender is sure that > the intended recipients can read them. > >>>> >=20 > That should then go together with a MIME registration that only lists = UTF-8. >=20 > Regards, Martin. >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json >=20 From nobody Mon Mar 13 08:56:46 2017 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 C9E16129432; Mon, 13 Mar 2017 08:56:39 -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, 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 G5Czki8HfRA5; Mon, 13 Mar 2017 08:56:38 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 63F381270B4; Mon, 13 Mar 2017 08:56:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2DFuY68002705; Mon, 13 Mar 2017 16:56:34 +0100 (CET) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vhjCk4LlrzDGt5; Mon, 13 Mar 2017 16:56:34 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: Date: Mon, 13 Mar 2017 16:56:33 +0100 X-Mao-Original-Outgoing-Id: 511113393.671415-a4a40423d1a75bc00add897e6d0ad1b2 Content-Transfer-Encoding: quoted-printable Message-Id: <3DFA075D-3F19-48B3-821D-79EA3CB4A908@tzi.org> References: <0d3258fa-0f9d-cc5d-06d7-fcba943349ad@gmx.de> To: =?utf-8?B?Ik1hcnRpbiBKLiBEw7xyc3Qi?= X-Mailer: Apple Mail (2.3259) Archived-At: Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, "json@ietf.org" , IETF , secdir@ietf.org Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 15:56:40 -0000 +1000 Gr=C3=BC=C3=9Fe, Carsten > On 13 Mar 2017, at 08:51, Martin J. D=C3=BCrst = wrote: >=20 > On 2017/03/13 15:23, Julian Reschke wrote: >> On 2017-03-13 00:07, Elwyn Davies wrote: >=20 >>> Does the WG really want to revisit the anguished discussions that >>> resulted in the changes to Section 8.1 of draft-ietf-json-rfc4627bis >>> between versions 07 and 08 back in late November 2013? >>>=20 >>> See https://www.ietf.org/mail-archive/web/json/current/msg02053.html = and >>> many, many messages beore this. >=20 >> No, but on the other hand, we should acknowledge that apparently the >> text both about what's mandatory and how auto detection works is not = as >> clear as it should. >=20 > It looks to me as if at the time of the above message in the WG, the = chairs were successful in presenting a consensus, probably at a stage = when the participants in the discussion where getting tired. >=20 > It seems that when put in the wider context of the IETF, that = compromise now looks somewhat shaky. >=20 > My personal opinion is that we could try to fix this by changing the = following: >=20 >>>>>=20 > JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32 [UNICODE] > (Section 3). The default encoding is UTF-8, and JSON texts that are > encoded in UTF-8 are interoperable in the sense that they will be > read successfully by the maximum number of implementations; there are > many implementations that cannot successfully read texts in other > encodings (such as UTF-16 and UTF-32). >>>>>=20 >=20 > to something like the following: >=20 >>>>>=20 > JSON text SHOULD be encoded in UTF-8 [UNICODE] > (Section 3). JSON texts that are > encoded in UTF-8 are interoperable in the sense that they will be > read successfully by the maximum number of implementations. >=20 > There are > many implementations that cannot successfully read texts in other > encodings (such as UTF-16 and UTF-32). JSON text MAY be encoded in > UTF-16 or UTF-32 [UNICODE] (Section 3) if the sender is sure that > the intended recipients can read them. >>>>>=20 >=20 > That should then go together with a MIME registration that only lists = UTF-8. >=20 > Regards, Martin. >=20 > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json >=20 From nobody Mon Mar 13 08:58:52 2017 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 0E1F612978C for ; Mon, 13 Mar 2017 08:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 WdJXKqvD3cJh for ; Mon, 13 Mar 2017 08:58:44 -0700 (PDT) Received: from mailrelay2-2.pub.mailoutpod1-wdc1.one.com (mailrelay2-2.pub.mailoutpod1-wdc1.one.com [104.37.35.58]) (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 77FC2129762 for ; Mon, 13 Mar 2017 08:58:44 -0700 (PDT) X-HalOne-Cookie: 1f4312dc1e1547aeaeedc47e66f3cdb426d1b9e7 X-HalOne-ID: ec0903d5-0805-11e7-a84d-549f35fe7f6e Received: from [10.86.247.37] (unknown [198.135.0.233]) by mailrelay2-1.pub.mailoutpod1-wdc1.one.com (Halon) with ESMTPSA id ec0903d5-0805-11e7-a84d-549f35fe7f6e; Mon, 13 Mar 2017 15:58:41 +0000 (UTC) To: =?UTF-8?Q?Martin_J._D=c3=bcrst?= , Julian Reschke , Elwyn Davies , Peter Cordell , Ned Freed References: <0d3258fa-0f9d-cc5d-06d7-fcba943349ad@gmx.de> From: Stefan Hagen Message-ID: Date: Mon, 13 Mar 2017 16:58:38 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, John Cowan , ietf@ietf.org, secdir@ietf.org, "json@ietf.org" Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 15:58:48 -0000 Yes, tired is a good match && I second the proposed change. "Stefan" On 13/03/17 08:51, Martin J. Dürst wrote: > On 2017/03/13 15:23, Julian Reschke wrote: >> On 2017-03-13 00:07, Elwyn Davies wrote: > >>> Does the WG really want to revisit the anguished discussions that >>> resulted in the changes to Section 8.1 of draft-ietf-json-rfc4627bis >>> between versions 07 and 08 back in late November 2013? >>> >>> See https://www.ietf.org/mail-archive/web/json/current/msg02053.html and >>> many, many messages beore this. > >> No, but on the other hand, we should acknowledge that apparently the >> text both about what's mandatory and how auto detection works is not as >> clear as it should. > > It looks to me as if at the time of the above message in the WG, the > chairs were successful in presenting a consensus, probably at a stage > when the participants in the discussion where getting tired. > > It seems that when put in the wider context of the IETF, that compromise > now looks somewhat shaky. > > My personal opinion is that we could try to fix this by changing the > following: > >>>>> > JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32 [UNICODE] > (Section 3). The default encoding is UTF-8, and JSON texts that are > encoded in UTF-8 are interoperable in the sense that they will be > read successfully by the maximum number of implementations; there are > many implementations that cannot successfully read texts in other > encodings (such as UTF-16 and UTF-32). >>>>> > > to something like the following: > >>>>> > JSON text SHOULD be encoded in UTF-8 [UNICODE] > (Section 3). JSON texts that are > encoded in UTF-8 are interoperable in the sense that they will be > read successfully by the maximum number of implementations. > > There are > many implementations that cannot successfully read texts in other > encodings (such as UTF-16 and UTF-32). JSON text MAY be encoded in > UTF-16 or UTF-32 [UNICODE] (Section 3) if the sender is sure that > the intended recipients can read them. >>>>> > > That should then go together with a MIME registration that only lists > UTF-8. > > Regards, Martin. > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From nobody Mon Mar 13 09:02:06 2017 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 D13B1129771 for ; Mon, 13 Mar 2017 09:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Wbg4aFPRb77J for ; Mon, 13 Mar 2017 09:02:00 -0700 (PDT) Received: from mailrelay2.pub.mailoutpod1-wdc1.one.com (mailrelay2.pub.mailoutpod1-wdc1.one.com [104.37.35.57]) (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 CCF1312941A for ; Mon, 13 Mar 2017 09:02:00 -0700 (PDT) X-HalOne-Cookie: 9db20b3b3eef183271b7f381933937b44264d427 X-HalOne-ID: 601bc2a5-0806-11e7-b39d-549f35fe4221 Received: from [10.86.247.37] (unknown [198.135.0.233]) by mailrelay1.pub.mailoutpod1-wdc1.one.com (Halon) with ESMTPSA id 601bc2a5-0806-11e7-b39d-549f35fe4221; Mon, 13 Mar 2017 16:01:58 +0000 (UTC) To: =?UTF-8?Q?Martin_J._D=c3=bcrst?= References: <0d3258fa-0f9d-cc5d-06d7-fcba943349ad@gmx.de> From: Stefan Hagen Message-ID: Date: Mon, 13 Mar 2017 17:01:52 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, "json@ietf.org" , ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 16:02:03 -0000 Yes, tired is a good match && I second the proposed change. "Stefan" On 13/03/17 08:51, Martin J. Dürst wrote: > On 2017/03/13 15:23, Julian Reschke wrote: >> On 2017-03-13 00:07, Elwyn Davies wrote: > >>> Does the WG really want to revisit the anguished discussions that >>> resulted in the changes to Section 8.1 of draft-ietf-json-rfc4627bis >>> between versions 07 and 08 back in late November 2013? >>> >>> See https://www.ietf.org/mail-archive/web/json/current/msg02053.html and >>> many, many messages beore this. > >> No, but on the other hand, we should acknowledge that apparently the >> text both about what's mandatory and how auto detection works is not as >> clear as it should. > > It looks to me as if at the time of the above message in the WG, the > chairs were successful in presenting a consensus, probably at a stage > when the participants in the discussion where getting tired. > > It seems that when put in the wider context of the IETF, that compromise > now looks somewhat shaky. > > My personal opinion is that we could try to fix this by changing the > following: > >>>>> > JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32 [UNICODE] > (Section 3). The default encoding is UTF-8, and JSON texts that are > encoded in UTF-8 are interoperable in the sense that they will be > read successfully by the maximum number of implementations; there are > many implementations that cannot successfully read texts in other > encodings (such as UTF-16 and UTF-32). >>>>> > > to something like the following: > >>>>> > JSON text SHOULD be encoded in UTF-8 [UNICODE] > (Section 3). JSON texts that are > encoded in UTF-8 are interoperable in the sense that they will be > read successfully by the maximum number of implementations. > > There are > many implementations that cannot successfully read texts in other > encodings (such as UTF-16 and UTF-32). JSON text MAY be encoded in > UTF-16 or UTF-32 [UNICODE] (Section 3) if the sender is sure that > the intended recipients can read them. >>>>> > > That should then go together with a MIME registration that only lists > UTF-8. > > Regards, Martin. > > _______________________________________________ > json mailing list > json@ietf.org > https://www.ietf.org/mailman/listinfo/json From nobody Mon Mar 13 09:20:31 2017 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 0CE67129705 for ; Mon, 13 Mar 2017 09:20:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.919 X-Spam-Level: X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u7I_3g8u-oJh for ; Mon, 13 Mar 2017 09:20:29 -0700 (PDT) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C63611297E8 for ; Mon, 13 Mar 2017 09:20:18 -0700 (PDT) Received: (qmail 19535 invoked from network); 13 Mar 2017 16:12:59 +0000 Received: from host109-158-230-32.range109-158.btcentralplus.com (HELO ?192.168.1.72?) (109.158.230.32) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 13 Mar 2017 16:12:59 +0000 To: =?UTF-8?Q?Martin_J._D=c3=bcrst?= , Julian Reschke , Elwyn Davies , Ned Freed References: <0d3258fa-0f9d-cc5d-06d7-fcba943349ad@gmx.de> From: Peter Cordell Message-ID: <8cf40994-0bfe-56bc-e2b0-62ebbb81f400@codalogic.com> Date: Mon, 13 Mar 2017 16:20:14 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, John Cowan , ietf@ietf.org, secdir@ietf.org, "json@ietf.org" Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 16:20:30 -0000 On 13/03/2017 07:51, Martin J. Dürst wrote: > On 2017/03/13 15:23, Julian Reschke wrote: > > My personal opinion is that we could try to fix this by changing the > following: > >>>>> > JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32 [UNICODE] > (Section 3). The default encoding is UTF-8, and JSON texts that are > encoded in UTF-8 are interoperable in the sense that they will be > read successfully by the maximum number of implementations; there are > many implementations that cannot successfully read texts in other > encodings (such as UTF-16 and UTF-32). >>>>> > > to something like the following: > >>>>> > JSON text SHOULD be encoded in UTF-8 [UNICODE] > (Section 3). JSON texts that are > encoded in UTF-8 are interoperable in the sense that they will be > read successfully by the maximum number of implementations. > > There are > many implementations that cannot successfully read texts in other > encodings (such as UTF-16 and UTF-32). JSON text MAY be encoded in > UTF-16 or UTF-32 [UNICODE] (Section 3) if the sender is sure that > the intended recipients can read them. >>>>> My only thought is to perhaps reflect that JSON isn't only transmitted, and JSON can be used for file based configuration etc, (even if this isn't strictly IETFs concern). So perhaps s/sender/encoder/ in the last sentence, plus a few other tweaks yielding something like: There are many implementations that cannot successfully read texts in other encodings (such as UTF-16 and UTF-32 [UNICODE]). JSON text MAY be encoded in other encodings if the encoder is sure that the intended recipients can read them. Pete. -- --------------------------------------------------------------------- Pete Cordell Codalogic Ltd http://json-content-rules.org/ --------------------------------------------------------------------- From nobody Mon Mar 13 09:33:45 2017 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 4B5A6129513 for ; Mon, 13 Mar 2017 09:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.919 X-Spam-Level: X-Spam-Status: No, score=-0.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id whvRx2axyV8L for ; Mon, 13 Mar 2017 09:33:41 -0700 (PDT) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C31B12984A for ; Mon, 13 Mar 2017 09:33:35 -0700 (PDT) Received: (qmail 27794 invoked from network); 13 Mar 2017 16:26:18 +0000 Received: from host109-158-230-32.range109-158.btcentralplus.com (HELO ?192.168.1.72?) (109.158.230.32) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 13 Mar 2017 16:26:18 +0000 To: =?UTF-8?Q?Martin_J._D=c3=bcrst?= , Ned Freed References: <0d3258fa-0f9d-cc5d-06d7-fcba943349ad@gmx.de> From: Peter Cordell Message-ID: <0631d12c-f447-8904-6e2d-81e02cc6e8d3@codalogic.com> Date: Mon, 13 Mar 2017 16:33:33 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, "json@ietf.org" , ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 16:33:42 -0000 On 13/03/2017 07:51, Martin J. Dürst wrote: > My personal opinion is that we could try to fix this by changing the > following: > >>>>> > JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32 [UNICODE] > (Section 3). The default encoding is UTF-8, and JSON texts that are > encoded in UTF-8 are interoperable in the sense that they will be > read successfully by the maximum number of implementations; there are > many implementations that cannot successfully read texts in other > encodings (such as UTF-16 and UTF-32). >>>>> > > to something like the following: > >>>>> > JSON text SHOULD be encoded in UTF-8 [UNICODE] > (Section 3). JSON texts that are > encoded in UTF-8 are interoperable in the sense that they will be > read successfully by the maximum number of implementations. > > There are > many implementations that cannot successfully read texts in other > encodings (such as UTF-16 and UTF-32). JSON text MAY be encoded in > UTF-16 or UTF-32 [UNICODE] (Section 3) if the sender is sure that > the intended recipients can read them. >>>>> My only thought is to perhaps reflect that JSON isn't only transmitted, and JSON can be used for file based configuration etc, (even if this isn't strictly IETFs concern). So perhaps s/sender/encoder/ in the last sentence, plus a few other tweaks yielding something like: There are many implementations that cannot successfully read texts in other encodings (such as UTF-16 and UTF-32 [UNICODE]). JSON text MAY be encoded in other encodings if the encoder is sure that the intended recipients can read them. Pete. -- --------------------------------------------------------------------- Pete Cordell Codalogic Ltd http://json-content-rules.org/ --------------------------------------------------------------------- From nobody Mon Mar 13 10:36:03 2017 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 39C74129975; Mon, 13 Mar 2017 10:35:56 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Matthew Miller To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148942655619.16823.16137723889627774034@ietfa.amsl.com> Date: Mon, 13 Mar 2017 10:35:56 -0700 Archived-At: Cc: draft-ietf-bess-evpn-vpws.all@ietf.org, ietf@ietf.org, bess@ietf.org Subject: [secdir] Review of draft-ietf-bess-evpn-vpws-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 17:35:56 -0000 Reviewer: Matthew Miller 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. Document: draft-ietf-bess-evpn-vpws-11 Reviewer: Matthew A. Miller Review Date: 2017-03-13 IETF LC End Date: 2017-03-10 IESG Telechat date: 2017-04-13 Summary: This document is ready for publication as a Proposed Standard. This document describes a method of supporting VPWS using the principles of EVPN from RFC 7432. In essence, a profile of RFC 7432 for implementing VPWS. Major Issues: NONE Minor Issues: NONE Nits: NONE From linuxwolf@outer-planes.net Mon Mar 13 10:54:35 2017 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 4A473129992 for ; Mon, 13 Mar 2017 10:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outer-planes-net.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 rSUfws_MO_Dd for ; Mon, 13 Mar 2017 10:54:34 -0700 (PDT) Received: from mail-ot0-x241.google.com (mail-ot0-x241.google.com [IPv6:2607:f8b0:4003:c0f::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 1486212998B for ; Mon, 13 Mar 2017 10:54:34 -0700 (PDT) Received: by mail-ot0-x241.google.com with SMTP id 19so17054812oti.0 for ; Mon, 13 Mar 2017 10:54:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outer-planes-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=wEbeRnfrEJpJCcOfo7g1t8EaTyJZIPY3KDqJZdcUzPk=; b=Zfif2koxCi00cBJulqzDvjWpIOzV9L6euL24Av4Ijo7ZS0Yrh6WNOQ0SAAnGyJDDuw 8LjBlfWv/IJzDEG7R/vDl680L9/iTmSB6UIAOltXBFJ1fWFLplm007xGNF6Tt/knN0Sc 2vZTqob98VrdG8LSjFZ36EkN1PWsEqSm9SQ9y7Ee0vGYvx42Lx9UZKFXG9G+XMk28Fbb SO96WOt0b5eCalMBH+BqH2JmO7kqbNPK+maAF6rMDkrGL+3wqlpSqaGxHotkaEvxQTYA 0/cloTgwiL+xtRK1+6JNhOCnTDrF3fyiAzmWyv8g/0H/kbjqCKgq+QK3cYCbLo2JokTc zHjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=wEbeRnfrEJpJCcOfo7g1t8EaTyJZIPY3KDqJZdcUzPk=; b=fVtFF3vnKxdlTvvlKNd91caORNOqehDjPzcZhWbkg5NHPSVYxJ+NBZxg/u8xpwm0GU uPBp61T24PeAKuaH889/Y7kmDvPmyCMr0XpLhN0d8jfk/hmKVX6MNZWqWaqmzrwXds8n Zk4j88JE0uav3b+kV7y539jPjR8iyY0IJXGn7o0s6kO8hxOtqYIWSmoLrz9lkCUUAZS+ eq5MMQbdAghBDpMOa9qlMg++IHky706f/PrgprxqdO1y0iMBCpriMRnRV0Bm9oYeMBLQ KTzA/CXKjKXfoiE6rMQ/dxawTT6MfM8S8pzNu7wgi+ZmVJmeLQ/zD7zitmURzNL+B1w+ q34w== X-Gm-Message-State: AMke39mIg4h8Q6Z222ni2y4r4wluW/qO3SpiHzCB+1xvqDihNORcBNSzJXcj9Wme8U2VLQ== X-Received: by 10.157.84.10 with SMTP id j10mr16695392oth.257.1489427673447; Mon, 13 Mar 2017 10:54:33 -0700 (PDT) Received: from [10.6.23.170] ([128.177.113.102]) by smtp.gmail.com with ESMTPSA id g10sm986961oic.16.2017.03.13.10.54.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Mar 2017 10:54:32 -0700 (PDT) To: Peter Cordell , =?UTF-8?Q?Martin_J._D=c3=bcrst?= , Ned Freed References: <0d3258fa-0f9d-cc5d-06d7-fcba943349ad@gmx.de> <0631d12c-f447-8904-6e2d-81e02cc6e8d3@codalogic.com> From: "Matthew A. Miller" Message-ID: <1e075450-d958-db9c-ae63-3cbf3733024c@outer-planes.net> Date: Mon, 13 Mar 2017 11:54:31 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <0631d12c-f447-8904-6e2d-81e02cc6e8d3@codalogic.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3VcLRe0FKbLrdelu3P9lctLR4SQJkGBjp" Archived-At: Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, "json@ietf.org" , ietf@ietf.org, secdir@ietf.org Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 17:55:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3VcLRe0FKbLrdelu3P9lctLR4SQJkGBjp Content-Type: multipart/mixed; boundary="P4ru045D3n6aVvw0WOfe56vt1MQRTpI0D"; protected-headers="v1" From: "Matthew A. Miller" To: Peter Cordell , =?UTF-8?Q?Martin_J._D=c3=bcrst?= , Ned Freed Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, ietf@ietf.org, secdir@ietf.org, "json@ietf.org" Message-ID: <1e075450-d958-db9c-ae63-3cbf3733024c@outer-planes.net> Subject: Re: [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 References: <0d3258fa-0f9d-cc5d-06d7-fcba943349ad@gmx.de> <0631d12c-f447-8904-6e2d-81e02cc6e8d3@codalogic.com> In-Reply-To: <0631d12c-f447-8904-6e2d-81e02cc6e8d3@codalogic.com> --P4ru045D3n6aVvw0WOfe56vt1MQRTpI0D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 17/03/13 10:33, Peter Cordell wrote: > On 13/03/2017 07:51, Martin J. D=C3=BCrst wrote: >> My personal opinion is that we could try to fix this by changing the >> following: >> >>>>>> >> JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32 [UNICODE] >> (Section 3). The default encoding is UTF-8, and JSON texts that ar= e >> encoded in UTF-8 are interoperable in the sense that they will be >> read successfully by the maximum number of implementations; there a= re >> many implementations that cannot successfully read texts in other >> encodings (such as UTF-16 and UTF-32). >>>>>> >> >> to something like the following: >> >>>>>> >> JSON text SHOULD be encoded in UTF-8 [UNICODE] >> (Section 3). JSON texts that are >> encoded in UTF-8 are interoperable in the sense that they will be >> read successfully by the maximum number of implementations. >> >> There are >> many implementations that cannot successfully read texts in other >> encodings (such as UTF-16 and UTF-32). JSON text MAY be encoded in >> UTF-16 or UTF-32 [UNICODE] (Section 3) if the sender is sure that >> the intended recipients can read them. >>>>>> >=20 > My only thought is to perhaps reflect that JSON isn't only transmitted,= > and JSON can be used for file based configuration etc, (even if this > isn't strictly IETFs concern). So perhaps s/sender/encoder/ in the las= t > sentence, plus a few other tweaks yielding something like: >=20 > There are many implementations that cannot successfully read texts > in other encodings (such as UTF-16 and UTF-32 [UNICODE]). JSON > text MAY be encoded in other encodings if the encoder is sure that > the intended recipients can read them. >=20 > Pete. /me doffs hat I like this change myself. /me dons hat As I recall, the table was removed mostly because the vast majority of implementations did not support any encoding other than UTF-8, and no one (that I recall) reported implementing the detection table. - m&m Matthew A. Miller < http://goo.gl/LM55L > --P4ru045D3n6aVvw0WOfe56vt1MQRTpI0D-- --3VcLRe0FKbLrdelu3P9lctLR4SQJkGBjp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJYxtzXAAoJEOz0ck4QngW72TMH/jkoqrQRrPao/VDYEP1PGOkc BWzlZ0KS/UXrD2NEe0yx79A7iJaLeoLo0qLqdOXN/YJz8Cxp/iFOzAD2kFWe9hKf 82qb/vVqUSprF5gaLB3PhQ1Jdk0nLZPxR9CeuKY94atv4diV84amhkcpUpVe1Wua OGvmstik2raeic/5eauMsX6dFgW1mifTbCKvBRlrH4nGQ7ovor+eqoua5DC72avI t4u6buv/iLXzIZqqBj3Y2hl9meXq4KaqB024fPc25+eRps/8o9+izUFCXBAu56pA 2i3Y+YqaOktXWxaClIEJ9zCeH69sKQ8osuq7lLuJ53Ub2jbkVsFAES0N5JiWg9Y= =jVS2 -----END PGP SIGNATURE----- --3VcLRe0FKbLrdelu3P9lctLR4SQJkGBjp-- From nobody Mon Mar 13 11:15:41 2017 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 E92D71299C0; Mon, 13 Mar 2017 11:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.501 X-Spam-Level: X-Spam-Status: No, score=-1.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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 ussgnInrpS35; Mon, 13 Mar 2017 11:15:39 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57C891299B5; Mon, 13 Mar 2017 11:15:39 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id DE498A04E8C1; Mon, 13 Mar 2017 11:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=7GhDPymm6L2zak 9IaA5N6WJc+Qc=; b=jB4Jyp+tWcRj2Fh7/yBUtOOCEbjlAkS9QujnRvCAIH4YGK 1CLMWElg6YQ+5GvSJJyLTjmUmjMPu0g356Z/MRzDFvshdiG0wZCbI7B1jqr2PZ1N iKOmKhfyiVgOcBgBI4n5RtnhWsHBbNY8vdT2ZiNQpyCyQY/oKKP60mEJmRyK0= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id E4346A04E8C3; Mon, 13 Mar 2017 11:15:37 -0700 (PDT) Date: Mon, 13 Mar 2017 13:15:34 -0500 From: Nico Williams To: Julian Reschke Message-ID: <20170313181534.GD543@localhost> References: <382aa5c8-c977-b24d-4d19-251257833b00@gmx.de> <456b4234-0d94-1033-507c-710878bb5159@gmx.de> <20170309055348.GL30306@kduck.kaduk.org> <01QBU8WJOCUO0003XB@mauve.mrochek.com> <6d97dee7-7cf3-9142-aacf-f2ca4909103d@codalogic.com> <38DEEE0A-EE2C-4ADA-9D7A-9DBBAEACB77E@tzi.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, John Cowan , Ned Freed , IETF , Peter Cordell , secdir@ietf.org, "json@ietf.org" , Carsten Bormann Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 18:15:40 -0000 On Mon, Mar 13, 2017 at 09:14:16AM +0100, Julian Reschke wrote: > So the changes in RFC 7159 allow top-level strings, so we can't rely on the > first *two* characters being US-ASCII. But we *can* rely on the first one > being US-ASCII, no? Correct. If one OR two bytes of the first four are NULs, then the encoding is UTF-16 (or something else or invalid): > So the following should still be correct: > > > Since the first character of a JSON text will always be an ASCII > > character [RFC0020], it is possible to determine whether an octet > > stream is UTF-8, UTF-16 (BE or LE), or UTF-32 (BE or LE) by looking > > at the pattern of nulls in the first four octets. > > > > 00 00 00 xx UTF-32BE > > 00 xx xx xx UTF-16BE > > xx 00 00 00 UTF-32LE > > xx 00 xx xx UTF-16LE > > xx xx xx xx UTF-8 Count the number of NULs in the first four bytes: - if zero -> UTF-8 - if one or two -> UTF-16 - if three -> UTF-32 Nico -- From nobody Mon Mar 13 11:37:22 2017 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 06495129A23; Mon, 13 Mar 2017 11:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 zLDoGf9Vj3q1; Mon, 13 Mar 2017 11:37:19 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D824C1299E4; Mon, 13 Mar 2017 11:37:19 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id 71B2BA04E8C1; Mon, 13 Mar 2017 11:37:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=jpyGA/EMeqfrnRqFPCK1jLr5zCA=; b=sgf77j1lAKQ lELAPDBqTnWvBXPyxP0WR9BE4/ilDTQFQqFC95q6KZ0EjD4t2qwE3uEirJVSvdj4 vuyHOpM/4dggjoXnamJJ4yDXNYNR5Z6GL9qz8wvr+6QiBnp4+RxbkGTE74JhNHZ4 Td3WbEpwZltfElSPV7N/ZotAPfBi8nVg= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 8097AA000B32; Mon, 13 Mar 2017 11:37:18 -0700 (PDT) Date: Mon, 13 Mar 2017 13:36:29 -0500 From: Nico Williams To: Martin =?iso-8859-1?Q?J=2E_D=FCrst?= Message-ID: <20170313183628.GE543@localhost> References: <0d3258fa-0f9d-cc5d-06d7-fcba943349ad@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Content-Transfer-Encoding: quoted-printable Archived-At: Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, John Cowan , Ned Freed , ietf@ietf.org, Peter Cordell , secdir@ietf.org, Julian Reschke , "json@ietf.org" , Elwyn Davies Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 18:37:21 -0000 On Mon, Mar 13, 2017 at 04:51:58PM +0900, Martin J. D=FCrst wrote: > My personal opinion is that we could try to fix this by changing the > following: >=20 > >>>> > JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32 [UNICODE] > (Section 3). The default encoding is UTF-8, and JSON texts that are > encoded in UTF-8 are interoperable in the sense that they will be > read successfully by the maximum number of implementations; there ar= e > many implementations that cannot successfully read texts in other > encodings (such as UTF-16 and UTF-32). > >>>> >=20 > to something like the following: >=20 > >>>> > JSON text SHOULD be encoded in UTF-8 [UNICODE] > (Section 3). JSON texts that are > encoded in UTF-8 are interoperable in the sense that they will be > read successfully by the maximum number of implementations. >=20 > There are > many implementations that cannot successfully read texts in other > encodings (such as UTF-16 and UTF-32). JSON text MAY be encoded in > UTF-16 or UTF-32 [UNICODE] (Section 3) if the sender is sure that > the intended recipients can read them. > >>>> >=20 > That should then go together with a MIME registration that only lists U= TF-8. +1. I would restore the text from an older draft about how counting the number of NULs in the first four bytes can be used to determine which of UTF-8, 16, or 32 the text is encoded in, modified to avoid all talk of BOMs (which had no consensus): Implementors MAY count the number of ASCII NULs in the first four bytes of any JSON text to detect which of UTF-8, UTF-16, or UTF-32 the text is encoded in: - if the count is zero, then the text is encoded in UTF-8 - if the count is one or two, then the text is encoded in UTF-16 - if the count is three, then the text is encoded in UTF-32 This results from a) JSON texts having to start with an ASCII character, b) no unescaped NULs being allowed in JSON strings, and c) any type being allowed at the top-level, thus the first character may be a double-quote and the second may be any permissible, unescaped Unicode codepoint. An ASCII character requires a NUL-valued byte in UTF-16 encoding, three in UTF-32, and none in UTF-8. Note the "MAY". The idea is that we should be sending (and storing) JSON texts encoded in UTF-8 per the text I +1'ed above, so we shouldn't bother recommending or requiring the use of this UTF detection scheme. But there's no harm in describing it. See https://www.ietf.org/mail-archive/web/json/current/msg02053.html The encoding detection algorithm can be optimized a bit since if neither the first nor the second bytes are NUL-valued then the encoding must be UTF-8. The algorithm can also be combined with an understanding of byte ordering to detect encoding by looking only at the first two bytes in some cases, but whatever. ASIDE: I don't see any reason not to also include text discussing byte-order detection in the UTF-16 and UTF-32 cases, but I don't care very much about it, and given the prior lack of consensus for it, there's no need to relitigate that point now. Also, it's pretty obvious how to detect byte-order anyways, at least given the text on how to detect encoding: just looking at the first two bytes will tell you what the byte order is! If the first byte is zero-valued, then the byte order is big-endian, if the first is not zero-valued but the second is, then the byte order is little-endian, and if both, the first and second bytes are zero-valued, then the byte order is big-endian; if neither the first nor the second bytes are zero-valued then the encoding is UTF-8 and byte-order is irrelevant. Cheers, Nico --=20 From nobody Mon Mar 13 12:08:08 2017 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 3B60E12945C; Mon, 13 Mar 2017 12:08:03 -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, 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 crgrWPBgPlOC; Mon, 13 Mar 2017 12:08:01 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 875BC129A94; Mon, 13 Mar 2017 12:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2DJ7vNH006994; Mon, 13 Mar 2017 20:07:57 +0100 (CET) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vhnSY3CyjzDGxN; Mon, 13 Mar 2017 20:07:57 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: <1e075450-d958-db9c-ae63-3cbf3733024c@outer-planes.net> Date: Mon, 13 Mar 2017 20:07:56 +0100 X-Mao-Original-Outgoing-Id: 511124876.759257-e2d29302f2c69dd400e93e811df86b3f Content-Transfer-Encoding: quoted-printable Message-Id: <8D76CB96-8AB6-4547-99C1-54490EC83DEF@tzi.org> References: <0d3258fa-0f9d-cc5d-06d7-fcba943349ad@gmx.de> <0631d12c-f447-8904-6e2d-81e02cc6e8d3@codalogic.com> <1e075450-d958-db9c-ae63-3cbf3733024c@outer-planes.net> To: "Matthew A. Miller" X-Mailer: Apple Mail (2.3259) Archived-At: Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, secdir@ietf.org, IETF , "json@ietf.org" Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 19:08:03 -0000 On 13 Mar 2017, at 18:54, Matthew A. Miller = wrote: >=20 > no > one (that I recall) reported implementing the detection table. There even was one that implemented something for UTF-16/32: Jackson. The author said: "Most other libraries just punt the problem by requiring caller to pass in Reader = that does byte->char decoding=E2=80=9D (He did not say whether his code was ever exercised outside of his test = cases :-) He also mentioned that, by contrast, most XML libraries do implement = auto-detection (as they should). Gr=C3=BC=C3=9Fe, Carsten From nobody Mon Mar 13 12:52:07 2017 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 6D653129481; Mon, 13 Mar 2017 12:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, 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 QydQ3BhgZX0V; Mon, 13 Mar 2017 12:51:58 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 CA194129453; Mon, 13 Mar 2017 12:51:57 -0700 (PDT) Received: from [192.168.178.20] ([93.217.107.79]) by mail.gmx.com (mrgmx102 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lr46Z-1cII7f2Pwp-00eZ4m; Mon, 13 Mar 2017 20:51:28 +0100 To: "Matthew A. Miller" , Peter Cordell , =?UTF-8?Q?Martin_J._D=c3=bcrst?= , Ned Freed References: <0d3258fa-0f9d-cc5d-06d7-fcba943349ad@gmx.de> <0631d12c-f447-8904-6e2d-81e02cc6e8d3@codalogic.com> <1e075450-d958-db9c-ae63-3cbf3733024c@outer-planes.net> From: Julian Reschke Message-ID: Date: Mon, 13 Mar 2017 20:51:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1e075450-d958-db9c-ae63-3cbf3733024c@outer-planes.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:1sAicka5ZreYlgL3dmOPevOFdNLbwwASwmL592XDQhUODyR/9j0 Z55OW11qeLclxeRQ4IWhQ2Lj7++AsU3bgKXrF7nw0gKYcwY2PlHKhnSlOsNrQLr/Ufaw4Xw Lqzef12hAraov6tGWzoD5YGoLXh+u7p/VG5HBiA2nUI2sPXoEq7VdpIjVwurCDu5hPqNRbI MiKYPP4TY8iLye5i/ZScw== X-UI-Out-Filterresults: notjunk:1;V01:K0:m5fVRV6aOxM=:mtb318PYufka5wgDsdyaUC eoNLxhXxxmYFhcl0NDb7S+8D6eT1UiOGiftQ5cdpld/iZdYjjJAorO4yZBFI9hnkjHolfVuZa MxQA252CDYr++/5XYRhiCB0QnorN35A35HRRCXqyxMxE1xvynoPiQOOerwFS/aoyOoCi96M5m 3Ex4N0gW8YBkk9uOHUqw9gXIdL/jIwXVWrVuMUximSJYN7+bBmc3s6dwzoG6HGMqYw7fW6IwW yAo1nG6P5JTLIorVh04H5JWVNTVuHx49UDynvPddYbaVYaN1P5nD7j0KZN2vXFMlr5/cc/V4X aiJWajTjfXj0M/QNEb3yNZED2+esf6UDMxIiM6WG4isW/jyC2XTB4ZFMQ/kIcGKHWRbilHoHH Bfhb7CgUGvA38j0c/mmSH/a6/OpkT2YIheXaI03zxh4NhrQ9srdqtiiOYWqlIS4UDZmJvFBjX gkOPIdAJ7hn8AN9RiHps6Ynp6gHY4lfUZxVVItxLqr9aOcX9eJZg8MJq8EV0UqTc7Q0J+GObF YEcu1oEmqLJQt96S28Vnlblx2InUIWLZ7fFC1wEs8OSZjhwqb/sBTdf8Dc3M8z2aJ0j+ymx2s 8pVNbw891MBoUqTG/CWkzl42hVbAP2dr2Gwxl8CTUDPxTYGV7i7gDDv3bTO9esLtlAJ960/sA WYswXD+sScHd4tJfiRI99npB1I5XBkqI1W23anCaE4G2jLQWCys6iWZuymTea4OSgdN3xegQz xQU8mLDSUI0fGC4F9yvhQNx603pCJlln6nNGFTBWsthJmqntQVL34Uwvk2Lb3BVwExONCEo1z gLqqcyx Archived-At: Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, secdir@ietf.org, ietf@ietf.org, "json@ietf.org" Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 19:51:59 -0000 On 2017-03-13 18:54, Matthew A. Miller wrote: > ... > /me doffs hat > > I like this change myself. > > /me dons hat > > As I recall, the table was removed mostly because the vast majority of > implementations did not support any encoding other than UTF-8, and no > one (that I recall) reported implementing the detection table. > ... Well, if we allow UTF-16 and UTF-32 - even if we discourage their use - we should say how to detect those... Alternatively we could forbid them, but that would be a normative change from RFC 7159. Best regards, Julian From nobody Mon Mar 13 12:57:07 2017 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 790DE129AE7; Mon, 13 Mar 2017 12:57:06 -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, 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 d-Xc_lINaLJl; Mon, 13 Mar 2017 12:57:05 -0700 (PDT) Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 6683812949D; Mon, 13 Mar 2017 12:57:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [134.102.201.11]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id v2DJv1dH015347; Mon, 13 Mar 2017 20:57:01 +0100 (CET) Received: from [192.168.217.124] (p5DCCCDC2.dip0.t-ipconnect.de [93.204.205.194]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3vhpY91p64zDGy0; Mon, 13 Mar 2017 20:57:01 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Carsten Bormann In-Reply-To: Date: Mon, 13 Mar 2017 20:57:00 +0100 X-Mao-Original-Outgoing-Id: 511127819.861928-19cd0691562856b3248a975cd733437d Content-Transfer-Encoding: quoted-printable Message-Id: <1F1D1DCB-767F-490D-A425-AB5E66D51D3E@tzi.org> References: <0d3258fa-0f9d-cc5d-06d7-fcba943349ad@gmx.de> <0631d12c-f447-8904-6e2d-81e02cc6e8d3@codalogic.com> <1e075450-d958-db9c-ae63-3cbf3733024c@outer-planes.net> To: Julian Reschke X-Mailer: Apple Mail (2.3259) Archived-At: Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, "json@ietf.org" , IETF , secdir@ietf.org Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Mar 2017 19:57:06 -0000 On 13 Mar 2017, at 20:51, Julian Reschke wrote: >=20 > Well, if we allow UTF-16 and UTF-32 - even if we discourage their use = - we should say how to detect those... Consistency is the hobgoblin of the little minds. (Apparently, not having that nonsense in there did not hurt for 7159? If people want to implement something useless and cannot figure this = stuff out, should we help them?) Putting back any form of apparent support for UTF-16 and UTF-32 is a = regression. Gr=C3=BC=C3=9Fe, Carsten From nobody Tue Mar 14 06:59:04 2017 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 A3CF81203D2 for ; Tue, 14 Mar 2017 06:59:02 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ccil-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 d8QG01JJodBZ for ; Tue, 14 Mar 2017 06:59:01 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (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 6D88A1275FB for ; Tue, 14 Mar 2017 06:59:01 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id v203so13755642wmg.0 for ; Tue, 14 Mar 2017 06:59:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=92DQ99N52Mv2iShepHhQgM+fTsrrCOj13qiSSVkxp8w=; b=xJUXLSzDkpNLOU16JTwrnKOqLGmy6l3AUQuYrhVp6/mSh6gWIeQ/06IicQCgzpxUnH UWrqEgBkPCS1BlVCb10KW1o5NnDQLdzDgPXUn4HJS1RNQd0q0t1zAJbJiY2LIkanMAXd N4M2OJfYJMczhyxXdnMZu4bLmEKeX3mTyBfbsiaKkO+mjqoqDKvy6mf2L2xrtajnzzzF u0bcDuesC2mBB71xaySaEQDQbDfSFGTRnIJ2Clf2OIccdx3XUFb/XhsZ88oD2UoZjLMN Y4/B0grgTeCYg6Vx5y3rKaKPzgmAk0jcr9I5gw20wgkY3en+tqfm53UvWeHIkrh9QkJK 8YtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=92DQ99N52Mv2iShepHhQgM+fTsrrCOj13qiSSVkxp8w=; b=S3CyJHDa/cTGXHOHAbJ5I0LUj5ydUNtL9ExMId3EYXm4NEfVM20azSpbdSGBlkKWY1 E72awPVm/SUeAGENApG2J2oRbKu0b7kRdJPByRS8UlxlWmzeVHQgDF4PpjI84ndrMy9i UTtmPSpaqbdP+FGM8RQYX4ldWhJ5oBE4q/gOlKgY5ZOSRsIMTTL506JHQZVuuO4SVnGc Ddv7WxZidsICO10R0NQnJKZ2j0fYsh1Jdg4l7rKGpxh9xX4Y3uNnl5AwXrRXwD+vd1MH +mM5jZk1rcJmzK/xAQEfztbhv/sn90MJFf0vH1YHCS4WDr59O+4H+uNSdDSpTQaSn+Xx gWjA== X-Gm-Message-State: AFeK/H2xo8Vmo3uu/g+b9mpQUSWMuL5F0lmw1+EEksstulbkeZdDrFWrBZ66HVCpjpB9IlNPVhFuu3ZJskcIuGho X-Received: by 10.28.107.14 with SMTP id g14mr15885450wmc.106.1489499939764; Tue, 14 Mar 2017 06:58:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.181.14 with HTTP; Tue, 14 Mar 2017 06:58:39 -0700 (PDT) In-Reply-To: <1F1D1DCB-767F-490D-A425-AB5E66D51D3E@tzi.org> References: <0d3258fa-0f9d-cc5d-06d7-fcba943349ad@gmx.de> <0631d12c-f447-8904-6e2d-81e02cc6e8d3@codalogic.com> <1e075450-d958-db9c-ae63-3cbf3733024c@outer-planes.net> <1F1D1DCB-767F-490D-A425-AB5E66D51D3E@tzi.org> From: John Cowan Date: Tue, 14 Mar 2017 09:58:39 -0400 Message-ID: To: Carsten Bormann Content-Type: multipart/alternative; boundary=001a11442d9ecda206054ab13aeb Archived-At: Cc: Julian Reschke , draft-ietf-jsonbis-rfc7159bis.all@ietf.org, secdir@ietf.org, IETF , "json@ietf.org" Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Mar 2017 13:59:02 -0000 --001a11442d9ecda206054ab13aeb Content-Type: text/plain; charset=UTF-8 On Mon, Mar 13, 2017 at 3:57 PM, Carsten Bormann wrote: Consistency is the hobgoblin of the little minds. > The actual quotation says "foolish consistency". But not all consistency is foolish. > (Apparently, not having that nonsense in there did not hurt for 7159? > If people want to implement something useless and cannot figure this stuff > out, should we help them?) > > Putting back any form of apparent support for UTF-16 and UTF-32 is a > regression. > In my opinion, we should either take all references to UTF-16 or UTF-32 out, or add back a correct detection algorithm. UTF-8 is what is actually interoperable, and interoperability is what RFCs are supposed to be all about. -- --001a11442d9ecda206054ab13aeb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Mar 13, 2017 at 3:57 PM, Carsten Bormann <cabo@tzi.org> w= rote:

Consistency is the hob= goblin of the little minds.

The a= ctual quotation says "foolish consistency".=C2=A0 But not all con= sistency is foolish.
=C2=A0
<= div id=3D":1d9" class=3D"a3s aXjCH m15ac93eeec0f9dd1"> (Apparently, not having that nonsense in there did not hurt for 7159?
If people want to implement something useless and cannot figure this stuff = out, should we help them?)

Putting back any form of apparent support for UTF-16 and UTF-32 is a regres= sion.

In my op= inion, we should either take all references to UTF-16 or UTF-32 out, or add= back a correct detection algorithm. UTF-8 is what is actually interoperabl= e, and interoperability is what RFCs are supposed to be all about.
--=C2=A0
=


--001a11442d9ecda206054ab13aeb-- From nobody Tue Mar 14 17:54:49 2017 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 4D14813176A for ; Tue, 14 Mar 2017 17:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 OHsDbNk4uAh7 for ; Tue, 14 Mar 2017 17:54:46 -0700 (PDT) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 7A7FF131766 for ; Tue, 14 Mar 2017 17:54:46 -0700 (PDT) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx36.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1cnxDA-0000eW-N7 for secdir@ietf.org; Wed, 15 Mar 2017 01:54:45 +0100 Received: from internal.xmail03.myhosting.com ([10.5.2.13] helo=xmail03.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cnxD9-00021V-6G for secdir@ietf.org; Tue, 14 Mar 2017 20:54:44 -0400 Received: (qmail 23767 invoked from network); 15 Mar 2017 00:54:42 -0000 Received: from unknown (HELO [192.168.1.100]) (Authenticated-user:_huitema@huitema.net@[172.56.42.159]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 15 Mar 2017 00:54:41 -0000 From: Christian Huitema To: The IESG , secdir@ietf.org, draft-ietf-ipsecme-rfc7321bis.all@ietf.org Message-ID: <2927d78d-7293-ba53-4aa3-0351e0a6e7b2@huitema.net> Date: Tue, 14 Mar 2017 17:54:39 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------60F4C3F8F1706AE1B463A015" X-Originating-IP: 168.144.250.177 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.14) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49L/N1imVzxQGuMdyq1ILpVFTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXoHYbDgNOedI2ngcqbsFM2eRcOb18WfxGyg6Om6u4YYm+QyIeXTCPs5oMtU Fzks8ig5hjoyEb9Oq0NWpyO3vrfYNrJwCbVSZviV1vzVlxiUlT3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBe34TY+s3lj/RgDQoaICKQ3TFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0CCRf8dnm s7AEHX18dEIK27bRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmjLzCyMdOETT xDqixVDal2Zqxiuap5uKiBpffUsHYsfmrbtbs8GJuRKR6hnrta1usy6F/SOWlhnS7qkS/mOkSgAg eNjxIyqtWcsHzPElnaBFglzR8EKamCCPLRQqfIrw/hvxLqd67w5ZW6bZsK3PVhKokBKK3jt6GcQw FAZLjDEKGyoCJJa3e874rwXXGPuEmSKg33smtlc64dR/aNUnR+kcQlvCYTspYJdGl64rm9ixxYJS vH1uwzGpXypuXzvU+ePe1gM7ipZJnJOKSsr7OvUQxK4Q6pnz1PG2i0Jcu7De X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: [secdir] secdir review of draft-ietf-ipsecme-rfc7321bis-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 00:54:48 -0000 This is a multi-part message in MIME format. --------------60F4C3F8F1706AE1B463A015 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. The document revises RFC 7321. It updates the Cryptographic Algorithm=20 Implementation Requirements for ESP and AH. The new recommendations emphasize using authenticated encryption, support for 256 bit keys, and modern algorithms. The recommendations appear sound, even if there are some compromises made, in particular in the name of IoT. This document is ready for publication as a Proposed Standard, with some = nits. My first set of nits concerns the keywords "SHOULD+", "SHOULD-" and "MUST= -" that the=20 draft is defining. These keywords would make an interesting update to RFC= 6919. I=20 understand that "SHOULD+" and "MUST-" are already defined and used in RFC= 7321, and=20 that you have at places to say "RFC 7321 said SHOULD+, but we change that= to MUST".=20 So maybe you should just note that "RFC 7321 defines these additional key= words". Also, you never use SHOULD- in the text, so there is no need to define it= =2E You only MUST- once, to downgrade "AUTH_HMAC_SHA1_96" from MUST to MUST-. You= could save=20 space in the document by just adding a footnote for the SHA1 entry in the= table, stating that "this MUST means REALLY SHOULD NOT." Or maybe you really wan= t to update RFC 6919. The second set of nits contains manual keying. According to the draft, an= yone using=20 manual keying is punished for doing so, and will only be able to use ENCR= _AES_CBC. I=20 assume that there is WG consensus on that, but the justification that oth= er algorithms really require IKEv2 is a bit weak. If there is an API to configure encry= ption with the results of an IKEv2 negotiation, it could just as well be used with the r= esults of a manual configuration. Not sure that the definition of algorithms is the b= est place to deprecate manual configuration, even if there are some pretty good reason= s to do that. My last set of nits concerns the relation between this draft and the IANA= registry of=20 Internet Key Exchange Version 2 (IKEv2) Parameters. I understand that we = have five states=20 of specification or recommendation: * MUST implement and MAY use algorithms such as ENCR_AES_GCM_16; * SHOULD implement and MAY use algorithms such as ENCR_CHACHA20_POLY1305;= * SHOULD implement and MAY use but only for IoT devices, e.g. ENCR_AES_CC= M_8; * SHOULD NOT implement and MUST NOT use, e.g. ENCR_DES; Presumably, the c= ode=20 has to be yanked from existing implementations. * and then MAY implement and MAY use, e.g. ENCR_CAMELLIA_CBC. But the fifth category is only specified by default, as "those algorithms= that are listed in the IANA registry but not referenced in the draft." I wonde= r whether there is a way to express that clearly in the draft. -- Christian Huitema --------------60F4C3F8F1706AE1B463A015 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit 
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 revises RFC 7321. It updates the Cryptographic Algorithm 
Implementation Requirements for ESP and AH. The new recommendations
emphasize using authenticated encryption, support for 256 bit keys,
and modern algorithms. The recommendations appear sound, even if there
are some compromises made, in particular in the name of IoT.

This document is ready for publication as a Proposed Standard, with some nits.

My first set of nits concerns the keywords "SHOULD+", "SHOULD-" and "MUST-" that the 
draft is defining. These keywords would make an interesting update to RFC 6919. I 
understand that "SHOULD+" and "MUST-" are already defined and used in RFC 7321, and 
that you have at places to say "RFC 7321 said SHOULD+, but we change that to MUST". 
So maybe you should just note that "RFC 7321 defines these additional keywords".
Also, you never use SHOULD- in the text, so there is no need to define it. You
only MUST- once, to downgrade "AUTH_HMAC_SHA1_96" from MUST to MUST-. You could save 
space in the document by just adding a footnote for the SHA1 entry in the table,
stating that "this MUST means REALLY SHOULD NOT." Or maybe you really want to
update RFC 6919.

The second set of nits contains manual keying. According to the draft, anyone using 
manual keying is punished for doing so, and will only be able to use ENCR_AES_CBC. I 
assume that there is WG consensus on that, but the justification that other algorithms
really require IKEv2 is a bit weak. If there is an API to configure encryption with the
results of an IKEv2 negotiation, it could just as well be used with the results of a
manual configuration. Not sure that the definition of algorithms is the best place to
deprecate manual configuration, even if there are some pretty good reasons to do that.

My last set of nits concerns the relation between this draft and the IANA registry of 
Internet Key Exchange Version 2 (IKEv2) Parameters. I understand that we have five states 
of specification or recommendation:
* MUST implement and MAY use algorithms such as ENCR_AES_GCM_16;
* SHOULD implement and MAY use algorithms such as ENCR_CHACHA20_POLY1305;
* SHOULD implement and MAY use but only for IoT devices, e.g. ENCR_AES_CCM_8;
* SHOULD NOT implement and MUST NOT use, e.g. ENCR_DES; Presumably, the code 
  has to be yanked from existing implementations.
* and then MAY implement and MAY use, e.g. ENCR_CAMELLIA_CBC.
But the fifth category is only specified by default, as "those algorithms that
are listed in the IANA registry but not referenced in the draft." I wonder whether there
is a way to express that clearly in the draft.

-- Christian Huitema
--------------60F4C3F8F1706AE1B463A015-- From nobody Tue Mar 14 18:09:10 2017 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 4CAA0129468 for ; Tue, 14 Mar 2017 18:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 vss_71njgpUE for ; Tue, 14 Mar 2017 18:09:06 -0700 (PDT) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 EED481293DA for ; Tue, 14 Mar 2017 18:09:05 -0700 (PDT) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx36.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1cnxR2-0006x4-Co for secdir@ietf.org; Wed, 15 Mar 2017 02:09:05 +0100 Received: from internal.xmail04.myhosting.com ([10.5.2.14] helo=xmail04.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cnxR0-0003gu-Gl for secdir@ietf.org; Tue, 14 Mar 2017 21:09:03 -0400 Received: (qmail 20328 invoked from network); 15 Mar 2017 01:09:01 -0000 Received: from unknown (HELO [192.168.1.100]) (Authenticated-user:_huitema@huitema.net@[172.56.42.159]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 15 Mar 2017 01:09:00 -0000 To: The IESG , secdir@ietf.org, draft-ietf-ipsecme-rfc7321bis.all@ietf.org, pwouters@redhat.com References: <2927d78d-7293-ba53-4aa3-0351e0a6e7b2@huitema.net> From: Christian Huitema Message-ID: Date: Tue, 14 Mar 2017 18:08:58 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <2927d78d-7293-ba53-4aa3-0351e0a6e7b2@huitema.net> Content-Type: multipart/alternative; boundary="------------4523A8E5FF303AC99C7468AD" X-Originating-IP: 168.144.250.177 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.10) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49L/N1imVzxQGuMdyq1ILpVFTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXodEeY0nW8ORiOPwbvZ3gVSRcOb18WfxGyg6Om6u4YYm4CEsXX+JLAGfJ2I 9AedaiI5hjoyEb9Oq0NWpyO3vrfYNrJwCbVSZviV1vzVlxiUlT3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBe34TY+s3lj/RgDQoaICKQ3TFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0LGMrf2Uz nKq2aEbLwJWA77bRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmjLzCyMdOETT xDqixVDal2Zqxiuap5uKiBpffUsHYsfmkrboF55pyqAvfOP9PRiFk64VFGHGL6a4Aiv0Hpn+svlW gWWsfzmdEBxk/w4+z2XWHxcEeYXaEh7Ip8nBmIzXZwpqT8auRNlXQctohljUCg88OBwlL8z3WodL Hrx14/4LKhBaevb8pkwVq3+XN9bPyjRMyLUEno1frs9vZR0iI5iTGneI1cCMIcE6R6jtJ8btb7sy ltanepIHrA9+HqSAzcyb5coZOTT3LhJUAej3FHNf/tvEsq8ECzFNZ6L8s8pn X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-ipsecme-rfc7321bis-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 01:09:09 -0000 This is a multi-part message in MIME format. --------------4523A8E5FF303AC99C7468AD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Adding Paul explicitly, since the forwarding through the draft.all alias does not pass through the gates of redhat. On 3/14/2017 5:54 PM, Christian Huitema wrote: > 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 revises RFC 7321. It updates the Cryptographic Algorithm > Implementation Requirements for ESP and AH. The new recommendations > emphasize using authenticated encryption, support for 256 bit keys, > and modern algorithms. The recommendations appear sound, even if there > are some compromises made, in particular in the name of IoT. > > This document is ready for publication as a Proposed Standard, with some nits. > > My first set of nits concerns the keywords "SHOULD+", "SHOULD-" and "MUST-" that the > draft is defining. These keywords would make an interesting update to RFC 6919. I > understand that "SHOULD+" and "MUST-" are already defined and used in RFC 7321, and > that you have at places to say "RFC 7321 said SHOULD+, but we change that to MUST". > So maybe you should just note that "RFC 7321 defines these additional keywords". > Also, you never use SHOULD- in the text, so there is no need to define it. You > only MUST- once, to downgrade "AUTH_HMAC_SHA1_96" from MUST to MUST-. You could save > space in the document by just adding a footnote for the SHA1 entry in the table, > stating that "this MUST means REALLY SHOULD NOT." Or maybe you really want to > update RFC 6919. > > The second set of nits contains manual keying. According to the draft, anyone using > manual keying is punished for doing so, and will only be able to use ENCR_AES_CBC. I > assume that there is WG consensus on that, but the justification that other algorithms > really require IKEv2 is a bit weak. If there is an API to configure encryption with the > results of an IKEv2 negotiation, it could just as well be used with the results of a > manual configuration. Not sure that the definition of algorithms is the best place to > deprecate manual configuration, even if there are some pretty good reasons to do that. > > My last set of nits concerns the relation between this draft and the IANA registry of > Internet Key Exchange Version 2 (IKEv2) Parameters. I understand that we have five states > of specification or recommendation: > * MUST implement and MAY use algorithms such as ENCR_AES_GCM_16; > * SHOULD implement and MAY use algorithms such as ENCR_CHACHA20_POLY1305; > * SHOULD implement and MAY use but only for IoT devices, e.g. ENCR_AES_CCM_8; > * SHOULD NOT implement and MUST NOT use, e.g. ENCR_DES; Presumably, the code > has to be yanked from existing implementations. > * and then MAY implement and MAY use, e.g. ENCR_CAMELLIA_CBC. > But the fifth category is only specified by default, as "those algorithms that > are listed in the IANA registry but not referenced in the draft." I wonder whether there > is a way to express that clearly in the draft. > > -- Christian Huitema > > > > > --------------4523A8E5FF303AC99C7468AD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Adding Paul explicitly, since the forwarding through the draft.all alias does not pass through the gates of redhat.


On 3/14/2017 5:54 PM, Christian Huitema wrote:
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 revises RFC 7321. It updates the Cryptographic Algorithm 
Implementation Requirements for ESP and AH. The new recommendations
emphasize using authenticated encryption, support for 256 bit keys,
and modern algorithms. The recommendations appear sound, even if there
are some compromises made, in particular in the name of IoT.

This document is ready for publication as a Proposed Standard, with some nits.

My first set of nits concerns the keywords "SHOULD+", "SHOULD-" and "MUST-" that the 
draft is defining. These keywords would make an interesting update to RFC 6919. I 
understand that "SHOULD+" and "MUST-" are already defined and used in RFC 7321, and 
that you have at places to say "RFC 7321 said SHOULD+, but we change that to MUST". 
So maybe you should just note that "RFC 7321 defines these additional keywords".
Also, you never use SHOULD- in the text, so there is no need to define it. You
only MUST- once, to downgrade "AUTH_HMAC_SHA1_96" from MUST to MUST-. You could save 
space in the document by just adding a footnote for the SHA1 entry in the table,
stating that "this MUST means REALLY SHOULD NOT." Or maybe you really want to
update RFC 6919.

The second set of nits contains manual keying. According to the draft, anyone using 
manual keying is punished for doing so, and will only be able to use ENCR_AES_CBC. I 
assume that there is WG consensus on that, but the justification that other algorithms
really require IKEv2 is a bit weak. If there is an API to configure encryption with the
results of an IKEv2 negotiation, it could just as well be used with the results of a
manual configuration. Not sure that the definition of algorithms is the best place to
deprecate manual configuration, even if there are some pretty good reasons to do that.

My last set of nits concerns the relation between this draft and the IANA registry of 
Internet Key Exchange Version 2 (IKEv2) Parameters. I understand that we have five states 
of specification or recommendation:
* MUST implement and MAY use algorithms such as ENCR_AES_GCM_16;
* SHOULD implement and MAY use algorithms such as ENCR_CHACHA20_POLY1305;
* SHOULD implement and MAY use but only for IoT devices, e.g. ENCR_AES_CCM_8;
* SHOULD NOT implement and MUST NOT use, e.g. ENCR_DES; Presumably, the code 
  has to be yanked from existing implementations.
* and then MAY implement and MAY use, e.g. ENCR_CAMELLIA_CBC.
But the fifth category is only specified by default, as "those algorithms that
are listed in the IANA registry but not referenced in the draft." I wonder whether there
is a way to express that clearly in the draft.

-- Christian Huitema

--------------4523A8E5FF303AC99C7468AD-- From nobody Wed Mar 15 06:21:01 2017 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 CC091131498; Wed, 15 Mar 2017 06:20:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.903 X-Spam-Level: X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 BpB33XQ1OKkN; Wed, 15 Mar 2017 06:20:52 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 620D5131496; Wed, 15 Mar 2017 06:20:52 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E08CB2BC7FD; Wed, 15 Mar 2017 13:12:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E08CB2BC7FD Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=pwouters@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com E08CB2BC7FD Received: from thinkpad.nohats.ca (vpn-235-251.phx2.redhat.com [10.3.235.251]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id v2FDCMFs017460; Wed, 15 Mar 2017 09:12:23 -0400 To: Christian Huitema , The IESG , secdir@ietf.org, draft-ietf-ipsecme-rfc7321bis.all@ietf.org, ipsec@ietf.org References: <2927d78d-7293-ba53-4aa3-0351e0a6e7b2@huitema.net> From: Paul Wouters Message-ID: Date: Wed, 15 Mar 2017 09:12:21 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 15 Mar 2017 13:12:25 +0000 (UTC) Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-ipsecme-rfc7321bis-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 13:20:54 -0000 On 03/14/2017 09:08 PM, Christian Huitema wrote: Thanks for your review Christian! > Adding Paul explicitly, since the forwarding through the draft.all alias > does not pass through the gates of redhat. Thanks, sorry for DMARC'ing issues. I did report it to our IT, but I doubt things will change :( >> This document is ready for publication as a Proposed Standard, with some nits. >> >> My first set of nits concerns the keywords "SHOULD+", "SHOULD-" and "MUST-" that the >> draft is defining. These keywords would make an interesting update to RFC 6919. I >> understand that "SHOULD+" and "MUST-" are already defined and used in RFC 7321, and >> that you have at places to say "RFC 7321 said SHOULD+, but we change that to MUST". >> So maybe you should just note that "RFC 7321 defines these additional keywords". >> Also, you never use SHOULD- in the text, so there is no need to define it. You >> only MUST- once, to downgrade "AUTH_HMAC_SHA1_96" from MUST to MUST-. You could save >> space in the document by just adding a footnote for the SHA1 entry in the table, >> stating that "this MUST means REALLY SHOULD NOT." Or maybe you really want to >> update RFC 6919. We really tried to keep the bis documents 4307bis and 7321bis close to the original so that updates read easily. So even if we do not use one of the keywords now, we might in a new version, so I think it is good for this set of documents to try and keep the same keyword list. >> The second set of nits contains manual keying. According to the draft, anyone using >> manual keying is punished for doing so, and will only be able to use ENCR_AES_CBC. I >> assume that there is WG consensus on that, but the justification that other algorithms >> really require IKEv2 is a bit weak. If there is an API to configure encryption with the >> results of an IKEv2 negotiation, it could just as well be used with the results of a >> manual configuration. Not sure that the definition of algorithms is the best place to >> deprecate manual configuration, even if there are some pretty good reasons to do that. I answered this in the list already, but the short version is that any algorithm that requires IVs to never repeat can never use manual keying because then there is no mechanism to prevent re-using IVs, as most IV's are implemented as counters, which at some point will overflow back to 0 and then the attacker can gain the private key knowledge. Additionally, thre is no PFS when using manual keying, so any compromise could decrypt all previous traffic. With IKE we are talking about 1-8 hours of session key lifetimes, which are just beyond manual keying that stays in place with the same key for months, years or worse. I'm willing to explain the text a bit on this to clarify. >> My last set of nits concerns the relation between this draft and the IANA registry of >> Internet Key Exchange Version 2 (IKEv2) Parameters. I understand that we have five states >> of specification or recommendation: >> * MUST implement and MAY use algorithms such as ENCR_AES_GCM_16; >> * SHOULD implement and MAY use algorithms such as ENCR_CHACHA20_POLY1305; >> * SHOULD implement and MAY use but only for IoT devices, e.g. ENCR_AES_CCM_8; >> * SHOULD NOT implement and MUST NOT use, e.g. ENCR_DES; Presumably, the code >> has to be yanked from existing implementations. >> * and then MAY implement and MAY use, e.g. ENCR_CAMELLIA_CBC. >> But the fifth category is only specified by default, as "those algorithms that >> are listed in the IANA registry but not referenced in the draft." I wonder whether there >> is a way to express that clearly in the draft. Since the tables are pretty big, that's a bit hard to do, and it would distract from the very few prime algorithms we would like them to focus on. Implementers I guess should have the IANA IKEv2 page open along with the RFC for the full picture. I do want to say that for ipsec, the algorithms that are only in MAY are either pretty new and have no deployment yet (curve25519, chacha20-poly1305) or are kind of obsolete but no known attack against them has been successful (cast, serpent, twofish) Paul From nobody Wed Mar 15 09:47:17 2017 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 BAD3013171A; Wed, 15 Mar 2017 09:47:09 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Daniel Franke To: Cc: draft-ietf-pce-stateful-sync-optimizations.all@ietf.org, pce@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148959642972.14125.7359898996904258228@ietfa.amsl.com> Date: Wed, 15 Mar 2017 09:47:09 -0700 Archived-At: Subject: [secdir] Review of draft-ietf-pce-stateful-sync-optimizations-09 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 16:47:10 -0000 Reviewer: Daniel Franke Review result: Has Issues I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. I believe this document is READY WITH a minor ISSUE addressed below. The Security Considerations section of this document, along with its companion draft-ietf-pce-stateful-pce-18, appears to do a thorough job of enumerating the ways in which the newly-introduced message types can contribute to the ability of misbehaving PCCs and PCEs to disrupt each other, with consequences that generally strike me as acceptable. It duly recommends that PCEP be run over an authenticated channel to prevent these messages from being spoofed by a third party. I am unsure how this final recommendation is going to be implemented in practice. RFC 5440 characterizes channel security for PCEP as a work-in-progress as of 2009, and I lack sufficient familiarity with this area to know if the status quo has improved since then in practice. The TCP authentication option, cited in RFC 5440 as WIP, is now RFC 5925, but I don't know whether anyone actually uses it for this application. TLS is mentioned as another alternative, but existing standards documents give insufficient instruction on how to implement this interoperably, since there is no mention of port allocations, a STARTTLS scheme, an ALPN identification sequence, or anything else that would explain how to go about initiating the TLS session. It looks like draft-ietf-pce-pceps intends to rectify this. Addressing whatever deficiencies exist in PCEP security mechanisms obviously falls well outside the scope of this particular document to address. Even if the administrator fails to provide channel security for PCEP as recommended, adding support for stateful sync optimizations will not leave the network meaningfully worse-off than it was already. However -- and here's the ISSUE -- as Alvaro Retana already sort of touched on, the introduction of the Speaker Entity ID TLV means that implementation of stateful sync optimizations can't be entirely agnostic with respect to the choice of channel security mechanism. Implementations need to verify that the Speaker Entity ID is consistent with the cryptographic identity of the channel peer in order to prevent one PCC from spoofing the identity of another. Until PCEP channel security matures a bit I'm not how much concrete advice we can give implementers on how to do this properly, but somewhere in the document there should at least be an observation that this check should be present. I also second Retana's desire for greater consistency between this document, draft-ietf-pce-stateful-pce, and RFC 5440 as to which channel security mechanisms are recommended and/or required. PS - sorry about the last minute review. From nobody Wed Mar 15 15:19:47 2017 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 BE6ED129C47 for ; Wed, 15 Mar 2017 15:19:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.47.1 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secretary@mit.edu Message-ID: <148961638573.14246.58963668660095998.idtracker@ietfa.amsl.com> Date: Wed, 15 Mar 2017 15:19:45 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Mar 2017 22:19:46 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-03-16 Reviewer LC end Draft John Bradley 2017-03-13 draft-mm-wg-effect-encrypt-08 Alan DeKok 2017-03-10 draft-bchv-rfc6890bis-05 Daniel Gillmor 2017-02-28 draft-ietf-pce-stateful-pce-18 Ólafur Guðmundsson 2017-02-27 draft-ietf-dime-load-08 For telechat 2017-04-13 Reviewer LC end Draft Phillip Hallam-Baker 2017-02-24 draft-ietf-dmm-lma-controlled-mag-params-04 Russ Mundy None draft-ietf-ipsecme-tcp-encaps-09 Last calls: Reviewer LC end Draft Derek Atkins 2017-03-22 draft-ietf-i2nsf-problem-and-use-cases-11 Ben Laurie 2017-03-02 draft-ietf-dprive-dtls-and-tls-profiles-08 Catherine Meadows 2017-03-13 draft-ietf-dhc-relay-server-security-03 Sandra Murphy 2017-03-27 draft-ietf-dnsop-nsec-aggressiveuse-08 Yoav Nir 2017-03-27 draft-ietf-aqm-codel-07 Magnus Nystrom 2017-03-27 draft-ietf-alto-multi-cost-07 Tom Yu 2017-02-20 draft-ietf-slim-negotiating-human-language-08 Early review requests: Reviewer Due Draft Daniel Gillmor 2016-02-01 draft-ietf-rtcweb-security-08 Brian Weis 2016-02-01 draft-ietf-cdni-uri-signing-10 Next in the reviewer rotation: Hilarie Orman Radia Perlman Vincent Roca Joseph Salowey Rich Salz Yaron Sheffer Rifaat Shekh-Yusef Melinda Shore Robert Sparks Takeshi Takahashi From nobody Thu Mar 16 03:28:45 2017 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 0BF88127333 for ; Thu, 16 Mar 2017 03:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.92 X-Spam-Level: X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zuq-wtH66IL5 for ; Thu, 16 Mar 2017 03:28:38 -0700 (PDT) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B131A127735 for ; Thu, 16 Mar 2017 03:28:37 -0700 (PDT) Received: (qmail 25859 invoked from network); 16 Mar 2017 10:21:12 +0000 Received: from host109-158-230-32.range109-158.btcentralplus.com (HELO ?192.168.1.72?) (109.158.230.32) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 16 Mar 2017 10:21:12 +0000 To: John Cowan , Carsten Bormann References: <0d3258fa-0f9d-cc5d-06d7-fcba943349ad@gmx.de> <0631d12c-f447-8904-6e2d-81e02cc6e8d3@codalogic.com> <1e075450-d958-db9c-ae63-3cbf3733024c@outer-planes.net> <1F1D1DCB-767F-490D-A425-AB5E66D51D3E@tzi.org> Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, secdir@ietf.org, "json@ietf.org" From: Peter Cordell Message-ID: Date: Thu, 16 Mar 2017 10:28:28 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 10:28:40 -0000 On 14/03/2017 13:58, John Cowan wrote: > In my opinion, we should either take all references to UTF-16 or UTF-32 > out, or add back a correct detection algorithm. UTF-8 is what is > actually interoperable, and interoperability is what RFCs are supposed > to be all about. Combining the original (Tim's) & Martin's proposal with my tweak, plus John & Carsten's direction, how about: 8.1. Character Encoding JSON text SHOULD be encoded in UTF-8 [UNICODE] (Section 3). JSON texts that are encoded in UTF-8 are interoperable in the sense that they will be read successfully by the maximum number of implementations. There are many implementations that cannot successfully read texts in other encodings. JSON text MAY be encoded in other encodings if the generator is sure that the intended parsers can read them. Implementations MUST NOT add a byte order mark to the beginning of a JSON text. In the interests of interoperability, implementations that parse JSON texts MAY ignore the presence of a byte order mark rather than treating it as an error. Are "generator" and "parser" the correct terms to use in this instance, or does that functionality sit above the character encoding layer? Pete Cordell Codalogic Ltd Rules for Describing JSON Content, http://json-content-rules.org From nobody Thu Mar 16 03:49:15 2017 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 7BF8E127599; Thu, 16 Mar 2017 03:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, RCVD_IN_SORBS_SPAM=0.5, 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 McVTyBCBo8Co; Thu, 16 Mar 2017 03:49:13 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 9E19012704B; Thu, 16 Mar 2017 03:49:12 -0700 (PDT) Received: from [192.168.1.57] ([5.10.171.186]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Metpl-1cZHUM07Pl-00OYms; Thu, 16 Mar 2017 11:49:03 +0100 To: Peter Cordell , John Cowan , Carsten Bormann References: <0d3258fa-0f9d-cc5d-06d7-fcba943349ad@gmx.de> <0631d12c-f447-8904-6e2d-81e02cc6e8d3@codalogic.com> <1e075450-d958-db9c-ae63-3cbf3733024c@outer-planes.net> <1F1D1DCB-767F-490D-A425-AB5E66D51D3E@tzi.org> Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, "json@ietf.org" , secdir@ietf.org From: Julian Reschke Message-ID: <1f87f5d4-cbb0-9350-2d08-31350fa7438d@gmx.de> Date: Thu, 16 Mar 2017 11:49:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:SDb14aQDgdMjeZw2EkBAOt1KuhE5K6pJxb0Em0KbEu+w1WrJtEg 1/7Vs5oJISTu1tFeJcWo9RWKdhFAteNbt6PBkXZ0hFVMOShS+/f3Z8EoNk6SE7uW9M/RFlQ DVQcodpD0gVTP9dFnQNng+S7Eiv0sBCk3M/YrLa9DM75SoZuICihHfqVVzTULjypzLmQhMZ 7/nMjm6UPy/SNyFyKBfkg== X-UI-Out-Filterresults: notjunk:1;V01:K0:aticPsBUu1E=:VtK4KfPTHKShq4t+uI5T1+ 56aRoHYvNTjj5dEvS0u2kpsmh+/8YkfQZzSBKz4UHKIlvzu0ykSJwpEgifQA8C1SGGDBWrg0K MB+i16dTYCsDblU1TRFqpWEMAawC86/BC8/uh/VnK0LoADyt2BA7JTWHipObt4deiM5Fm/cFO 63z80NAGHLAxlWcjH3N79fnOvyQD1aYEwsO/aAO5tyUcuUlahbl/Mi0nu4CvoBLUyflpwWj3H b/imawiPeN1wQtcZOdSS58DsIaHvUNLMeIB8YzuvLzNkpOgvbmABFLVgjmiSmTshoIGcmib8M I8LrKR+2EKeIeKNoN0M1BmltCOXl7MQ9kwuPQq98ZeGUfNW7eYZQeISPOZXfRE+OZDYsTfpOu Hpi+JzJzT+d4NrTkylkC1/Qq3igCosUbeH6M6JUVM0mxftXk8R0/Tp6zDBJm96ZT1oskzVC8Y vvoENQtSV8AqxrS5Y9cBPJEWPvSHHBIZ1fZE9odVPpp8PZak+7JYAwgWdTpoKz2AMPUSabPbp YB2gJW4wCfJ9ueWKPVh6EqWyLZr7T7CYLAxYhyCSLxCEhv1b90oKIAlLd61B38LEX+qG6KnCg vvo+WUntxep0yA0Ztw0s/+NiJkIBryv3HCvFnZgxEL22uNAO1jPoRrJXyikgn7n6ZV31lLiSo 8l/SHZnxUr9eyjhIsnXfucZI/O81vjDS2BtOaymwYuOaWS5EA0FFYpMNOaB48bC4jCfrLudm+ EgfZOIhPuoq1nHm0exfQXaAxXcbscYtmIOjMgZecurwcH8bGE3k6mqiY3Z5wh8xQoxSy0QMiR 64yZYUF Archived-At: Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 10:49:14 -0000 On 2017-03-16 11:28, Peter Cordell wrote: > On 14/03/2017 13:58, John Cowan wrote: >> In my opinion, we should either take all references to UTF-16 or UTF-32 >> out, or add back a correct detection algorithm. UTF-8 is what is >> actually interoperable, and interoperability is what RFCs are supposed >> to be all about. > > Combining the original (Tim's) & Martin's proposal with my tweak, plus > John & Carsten's direction, how about: > > > 8.1. Character Encoding > > JSON text SHOULD be encoded in UTF-8 [UNICODE] (Section 3). JSON > texts that are encoded in UTF-8 are interoperable in the sense that > they will be read successfully by the maximum number of > implementations. > > There are many implementations that cannot successfully read texts > in other encodings. JSON text MAY be encoded in other encodings if > the generator is sure that the intended parsers can read them. > > Implementations MUST NOT add a byte order mark to the beginning of a > JSON text. In the interests of interoperability, implementations > that parse JSON texts MAY ignore the presence of a byte order mark > rather than treating it as an error. > > Are "generator" and "parser" the correct terms to use in this instance, > or does that functionality sit above the character encoding layer? > ... Not convinced. a) It's not constrained to UTF-8/16/32, so people might decide to support ISO-8859-1, or UTF-7- b) It doesn't state that the only way to support encodings other than UTF-8 is to inspect the leading octets for zeros (or their lack of). Best regards, Julian From nobody Thu Mar 16 04:24:00 2017 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 EF8BA1292FD for ; Thu, 16 Mar 2017 04:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.92 X-Spam-Level: X-Spam-Status: No, score=-0.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cRxf1dS-PL_X for ; Thu, 16 Mar 2017 04:23:56 -0700 (PDT) Received: from ppsa-online.com (lvps217-199-162-192.vps.webfusion.co.uk [217.199.162.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C49F1292F5 for ; Thu, 16 Mar 2017 04:23:56 -0700 (PDT) Received: (qmail 28182 invoked from network); 16 Mar 2017 11:16:32 +0000 Received: from host109-158-230-32.range109-158.btcentralplus.com (HELO ?192.168.1.72?) (109.158.230.32) by lvps217-199-162-217.vps.webfusion.co.uk with ESMTPSA (DHE-RSA-AES128-SHA encrypted, authenticated); 16 Mar 2017 11:16:32 +0000 To: Julian Reschke , John Cowan , Carsten Bormann References: <0d3258fa-0f9d-cc5d-06d7-fcba943349ad@gmx.de> <0631d12c-f447-8904-6e2d-81e02cc6e8d3@codalogic.com> <1e075450-d958-db9c-ae63-3cbf3733024c@outer-planes.net> <1F1D1DCB-767F-490D-A425-AB5E66D51D3E@tzi.org> <1f87f5d4-cbb0-9350-2d08-31350fa7438d@gmx.de> Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, "json@ietf.org" , secdir@ietf.org From: Peter Cordell Message-ID: <24d37dc6-eee2-5e0c-6d33-d3450750e886@codalogic.com> Date: Thu, 16 Mar 2017 11:23:47 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1f87f5d4-cbb0-9350-2d08-31350fa7438d@gmx.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 11:23:58 -0000 On 16/03/2017 10:49, Julian Reschke wrote: > On 2017-03-16 11:28, Peter Cordell wrote: >> >> 8.1. Character Encoding >> >> JSON text SHOULD be encoded in UTF-8 [UNICODE] (Section 3). JSON >> texts that are encoded in UTF-8 are interoperable in the sense that >> they will be read successfully by the maximum number of >> implementations. >> >> There are many implementations that cannot successfully read texts >> in other encodings. JSON text MAY be encoded in other encodings if >> the generator is sure that the intended parsers can read them. >> >> Implementations MUST NOT add a byte order mark to the beginning of a >> JSON text. In the interests of interoperability, implementations >> that parse JSON texts MAY ignore the presence of a byte order mark >> rather than treating it as an error. >> >> Are "generator" and "parser" the correct terms to use in this instance, >> or does that functionality sit above the character encoding layer? >> ... > > Not convinced. > > a) It's not constrained to UTF-8/16/32, so people might decide to > support ISO-8859-1, or UTF-7- Why is that a problem if the generator knows the parser can read it? If someone wants to use EBCDIC for whatever reason, are they not allowed to call it JSON? > b) It doesn't state that the only way to support encodings other than > UTF-8 is to inspect the leading octets for zeros (or their lack of). UTF detection is one way. It's not the only way. If you want to go the UTF detection way or some other way, rfc7159bis shouldn't prevent it, but it doesn't have to tell you how to do it. Cheers, Pete Cordell Codalogic Ltd C++ tools for C++ programmers, http://codalogic.com Read & write XML in C++, http://www.xml2cpp.com --------------------------------------------------------------------- From nobody Thu Mar 16 04:35:58 2017 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 F2C6F1293DA; Thu, 16 Mar 2017 04:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.896 X-Spam-Level: X-Spam-Status: No, score=-4.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, RCVD_IN_SORBS_SPAM=0.5, 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 kfRkaeN2dBB1; Thu, 16 Mar 2017 04:35:53 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 3D04F1293F3; Thu, 16 Mar 2017 04:35:48 -0700 (PDT) Received: from [192.168.1.57] ([5.10.171.186]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LpKY5-1cLBDr1zuP-00f8L7; Thu, 16 Mar 2017 12:35:38 +0100 To: Peter Cordell , John Cowan , Carsten Bormann References: <0d3258fa-0f9d-cc5d-06d7-fcba943349ad@gmx.de> <0631d12c-f447-8904-6e2d-81e02cc6e8d3@codalogic.com> <1e075450-d958-db9c-ae63-3cbf3733024c@outer-planes.net> <1F1D1DCB-767F-490D-A425-AB5E66D51D3E@tzi.org> <1f87f5d4-cbb0-9350-2d08-31350fa7438d@gmx.de> <24d37dc6-eee2-5e0c-6d33-d3450750e886@codalogic.com> Cc: draft-ietf-jsonbis-rfc7159bis.all@ietf.org, secdir@ietf.org, "json@ietf.org" From: Julian Reschke Message-ID: Date: Thu, 16 Mar 2017 12:35:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <24d37dc6-eee2-5e0c-6d33-d3450750e886@codalogic.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:QvYKNl+YIL28AD0XU1A2JGKp6S6M3DOUVc1EaGB/G+UkBAFivk3 +AAJJB9OaotXw776xLwx6N5o4mq1iyiLqDsXPymrzhzaAjv7dZTPo3w/RYHpDrEqTqaOBHm m7vb/dgyziSA+4B6e2/utSbSYTtLrQHsHR9p6b9GUSDw4/+uxni+eJhhdNMjjYVBrfOiR18 QVCYbFGDRZ1b2ynAkEl4w== X-UI-Out-Filterresults: notjunk:1;V01:K0:JMA4pUnV9jM=:yOcAwhox+cAoqmRwsIggql 0LsLsmfc5GzrT2+KEMmrfJQ0gacMRmobSLuk6VpTPmVd847EznRn18B9C1tPjpBMoG1ZAjV8a RCjCu0vsP5CHcaf+wVirFO2skmAac3nGO1dfdDJirfu5Ui0HJgKNvtMbMAqW4lWMWLUdadXVE 6oIAxU/Z9nhFG7uu5qIPStKcdwDtMYnKqRSx9qYoKGa2vFgsl5IPCLBU2XBcegXw+CEvjlhJB tLi7GFYjcLWDNYIcYoj6brByYskswdVYcB6xbrCOU9plGkEl72CqPaP4riTvy+plW1rmGEVW7 DbphptrLIydRo8Y400DHBK0o+OMsKTjlKJXwZ1TxvxsnNX/T+122p7xKxoGhmO98yRS7foY4f rHRzaTt4R391PbYCpUoL1L//vPXrM5cz3XEkYIOn6/7r9TmBnH7IC+3TigcNabO/KpkVOfKbM 1oPXFviF5eyj9x25HTkIwcJ8nc+6WNIkOpp/qxw6LkRfeyq6JHtVwhGAyLiiMHWm6yK2i6Dlo Qd225aUvi/HRd/ueGeHUo6NB+NR7oKRs1JYw4z2dQx8nCjCk5VoB3D4rZ1fucJQXdIraVFzJh 992v3FT7WUf8RcOcMzDQZce8ZuYkKcddU4S6L5yybxe2FULE7lT+KL2AeRT/XroSP0DhvyfPC gGKrLmk8kQIaMAuF0xVpwVPDcNK2AvOl54o9sjkPMowYCdbbLMitZ4JLB7ZtB7E1zRNWlXfI/ 5F2DnwL7w3chISCDxYFLrrUvyD9VqsRKHn9Ebzyb+he3CXnlxJZ4rwyEPKYn1uZ3y7oT7pCso IRfJOQd Archived-At: Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 11:35:56 -0000 On 2017-03-16 12:23, Peter Cordell wrote: > On 16/03/2017 10:49, Julian Reschke wrote: >> On 2017-03-16 11:28, Peter Cordell wrote: >>> >>> 8.1. Character Encoding >>> >>> JSON text SHOULD be encoded in UTF-8 [UNICODE] (Section 3). JSON >>> texts that are encoded in UTF-8 are interoperable in the sense that >>> they will be read successfully by the maximum number of >>> implementations. >>> >>> There are many implementations that cannot successfully read texts >>> in other encodings. JSON text MAY be encoded in other encodings if >>> the generator is sure that the intended parsers can read them. >>> >>> Implementations MUST NOT add a byte order mark to the beginning of a >>> JSON text. In the interests of interoperability, implementations >>> that parse JSON texts MAY ignore the presence of a byte order mark >>> rather than treating it as an error. >>> >>> Are "generator" and "parser" the correct terms to use in this instance, >>> or does that functionality sit above the character encoding layer? >>> ... >> >> Not convinced. >> >> a) It's not constrained to UTF-8/16/32, so people might decide to >> support ISO-8859-1, or UTF-7- > > Why is that a problem if the generator knows the parser can read it? If > someone wants to use EBCDIC for whatever reason, are they not allowed to > call it JSON? For application/json, it would violate a SHOULD-level requirement... : "JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32. The default encoding is UTF-8, and JSON texts that are encoded in UTF-8 are interoperable in the sense that they will be read successfully by the maximum number of implementations; there are many implementations that cannot successfully read texts in other encodings (such as UTF-16 and UTF-32)." So I agree it's technically allowed. >> b) It doesn't state that the only way to support encodings other than >> UTF-8 is to inspect the leading octets for zeros (or their lack of). > > UTF detection is one way. It's not the only way. If you want to go the > UTF detection way or some other way, rfc7159bis shouldn't prevent it, > but it doesn't have to tell you how to do it. Oh, it's not the only way? How do we interoperate then? Best regards, Julian From nobody Thu Mar 16 05:19:12 2017 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 979ED129471; Thu, 16 Mar 2017 05:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fastmail.fm header.b=Q82Sti7Z; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=DzChXsvu 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 zbcHSJjOkoZ3; Thu, 16 Mar 2017 05:18:58 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3442129456; Thu, 16 Mar 2017 05:18:57 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 4B47E20932; Thu, 16 Mar 2017 08:18:57 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute7.internal (MEProxy); Thu, 16 Mar 2017 08:18:57 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.fm; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=qpjA8AxfsaCeZWbx1P RFHo+7D4Y=; b=Q82Sti7ZxyriBWyw6o9TivOR4zpadA+Y7JIO3U6ZG8zsCjTq4F gnyzhR8OVI+gzL/hKOV6yC5Wd+z96G+B0EGdgVqn1EBVXDH2TLqyGVfxxaldYf4D 3ZHaZ0IsrMuvdJdtTD+RWA51np5Tq5aioQjW23Xipytrvpf/FnPR+p0epwtYMTTR jPMNfMQzjYuRmKoScNEdA4X2g5qca/9XoqEBYD7LXRbqtOCGDrUQf11vaqeeIGNs uUaahbNC15AJ9w1brb0ZGsgZNbgttCIOC/sQ5ikL3pUaNQMGyuZ4Z4dyCxPHT94H UqufYH1/rXGsY45BAsoBRgUGrN5zi//fNE6w== DKIM-Signature: v=1; a=rsa-sha1; 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-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=qpjA8AxfsaCeZWbx1PRFHo+7D4Y=; b=DzChXsvuewY7va6/FKyz7DgG CsYV1J4vrLAph3U/W+qU8uqQwCUjq+vmPfB3I75EZD2a7f7UeguUzFaHjk46MEMk 6TAoytqkApQVWyIsX0rh4j58WRWO8kDP3GtDKSu39h69serKegvp+1iz27FjGJeY Fs//dZeppp4QkxFWiHsHdElbYhjdSPN646Dc5UpNtTP71ayP1yiIuFk7lho+NQSg cYwTz5AOMazlwHyfRggDxLN7ZGqLY264S3wupBF2TjFEEKjRLxzHth0PXJ8zyyk0 3fheLZsbpRsE4yFxj6nrExQaR6Z7BRBDeJIneXtygb/Lg+kAW9IJiLLP52HrqQ== X-ME-Sender: X-Sasl-enc: TC0jBlsX8n8Fnn38lv8TDxhH1i0CUJDSuFknC+/YAlUL 1489666736 Received: from [172.22.50.14] (unknown [62.232.206.186]) by mail.messagingengine.com (Postfix) with ESMTPA id E12A724591; Thu, 16 Mar 2017 08:18:56 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Alexey Melnikov X-Mailer: iPad Mail (14A456) In-Reply-To: Date: Thu, 16 Mar 2017 12:38:45 +0000 Cc: Peter Cordell , John Cowan , Carsten Bormann , draft-ietf-jsonbis-rfc7159bis.all@ietf.org, secdir@ietf.org, "json@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <0d3258fa-0f9d-cc5d-06d7-fcba943349ad@gmx.de> <0631d12c-f447-8904-6e2d-81e02cc6e8d3@codalogic.com> <1e075450-d958-db9c-ae63-3cbf3733024c@outer-planes.net> <1F1D1DCB-767F-490D-A425-AB5E66D51D3E@tzi.org> <1f87f5d4-cbb0-9350-2d08-31350fa7438d@gmx.de> <24d37dc6-eee2-5e0c-6d33-d3450750e886@codalogic.com> To: Julian Reschke Archived-At: Subject: Re: [secdir] [Json] secdir review of draft-ietf-jsonbis-rfc7159bis-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 12:19:05 -0000 > On 16 Mar 2017, at 11:35, Julian Reschke wrote: >=20 >> On 2017-03-16 12:23, Peter Cordell wrote: >>> On 16/03/2017 10:49, Julian Reschke wrote: >>>> On 2017-03-16 11:28, Peter Cordell wrote: >>>>=20 >>>> 8.1. Character Encoding >>>>=20 >>>> JSON text SHOULD be encoded in UTF-8 [UNICODE] (Section 3). JSON >>>> texts that are encoded in UTF-8 are interoperable in the sense that >>>> they will be read successfully by the maximum number of >>>> implementations. >>>>=20 >>>> There are many implementations that cannot successfully read texts >>>> in other encodings. JSON text MAY be encoded in other encodings if >>>> the generator is sure that the intended parsers can read them. >>>>=20 >>>> Implementations MUST NOT add a byte order mark to the beginning of a >>>> JSON text. In the interests of interoperability, implementations >>>> that parse JSON texts MAY ignore the presence of a byte order mark >>>> rather than treating it as an error. >>>>=20 >>>> Are "generator" and "parser" the correct terms to use in this instance,= >>>> or does that functionality sit above the character encoding layer? >>>> ... >>>=20 >>> Not convinced. >>>=20 >>> a) It's not constrained to UTF-8/16/32, so people might decide to >>> support ISO-8859-1, or UTF-7- >>=20 >> Why is that a problem if the generator knows the parser can read it? If >> someone wants to use EBCDIC for whatever reason, are they not allowed to >> call it JSON? >=20 > For application/json, it would violate a SHOULD-level requirement... : >=20 > "JSON text SHALL be encoded in UTF-8, UTF-16, or UTF-32. The default encod= ing is UTF-8, and JSON texts that are encoded in UTF-8 are interoperable in t= he sense that they will be read successfully by the maximum number of implem= entations; there are many implementations that cannot successfully read text= s in other encodings (such as UTF-16 and UTF-32)." >=20 > So I agree it's technically allowed. As this document is intended to be Internet Standard, it should strive to re= move number of choices and generally non interoperable features. So listing t= he minimal list of allowed encodings in this document would be a good thing.= From nobody Thu Mar 16 13:26:54 2017 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 518CA129A54; Thu, 16 Mar 2017 13:26:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 YKYVuDnht4MO; Thu, 16 Mar 2017 13:26:44 -0700 (PDT) Received: from ccs.nrl.navy.mil (mx0.ccs.nrl.navy.mil [IPv6:2001:480:20:118:118::211]) (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 ADDC6129A4C; Thu, 16 Mar 2017 13:26:41 -0700 (PDT) Received: from ashurbanipal.fw5540.net (fw5540.nrl.navy.mil [132.250.196.100]) by ccs.nrl.navy.mil (8.14.4/8.14.4) with ESMTP id v2GKQdt8029108 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Thu, 16 Mar 2017 16:26:39 -0400 From: Catherine Meadows Content-Type: multipart/alternative; boundary="Apple-Mail=_51BE93A2-523F-48AD-A05C-AA83D00034B9" Date: Thu, 16 Mar 2017 16:26:39 -0400 Message-Id: <7CDA5C79-8242-43A3-90DE-DBF1872EFC77@nrl.navy.mil> To: draft-ietf-dhc-relay-server-security.all@ietf.org, iesg@ietf.org, secdir@ietf.org Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-CCS-MailScanner: No viruses found. X-CCS-MailScanner-Info: See: http://www.nrl.navy.mil/ccs/support/email Archived-At: Subject: [secdir] SecDir review of draft-ietf-dhc-relay-server-security-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Mar 2017 20:26:47 -0000 --Apple-Mail=_51BE93A2-523F-48AD-A05C-AA83D00034B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I have reviewed this document as part of the security directorate's=20 ongoing effort to review all IETF documents being processed by the=20 IESG. These comments were written primarily for the benefit of the=20 security area directors. Document editors and WG chairs should treat=20 these comments just like any other last call comments. This brief draft gives requirements for securing relay to really and = relay to server communication for DHCPv6 and relay to server = communication for DHCPv4. Previously no such guidance existed. The new guidance is that in both = cases the draft REQUIRES that communication be IPSec encrypted. The security considerations section points out the limitations of this = document , e.g. it does not address communications between the client = and the server or first hop relay agent. This section gives some recommendations for security in = this case. It also points out the limitations of some practices that = are allowed by the document but not encouraged, e.g. use of manual keys. I believe this is a good = use of the Security Considerations section for a document of this kind, = which recommends a specific solution to one part of the security problem, but does not attempt to = propose a complete security solution.=20 I think this document is Ready. Cathy Meadows Catherine Meadows Naval Research Laboratory Code 5543 4555 Overlook Ave., S.W. Washington DC, 20375 phone: 202-767-3490 fax: 202-404-7942 email: catherine.meadows@nrl.navy.mil = --Apple-Mail=_51BE93A2-523F-48AD-A05C-AA83D00034B9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

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 = brief draft gives requirements for securing relay to really and relay to = server communication for DHCPv6 and relay to server communication for = DHCPv4.
Previously no  such guidance existed. =  The new guidance is that in both cases the draft REQUIRES that = communication be IPSec encrypted.

The security considerations section = points out the limitations of this document , e.g. it does not address = communications between the client and the server or first hop
relay agent.  This section gives some recommendations = for security in this case.  It also points out the limitations of = some practices that are allowed by the document
but = not encouraged, e.g. use of manual keys.  I believe this is a good = use of the Security Considerations section for a document of this kind, = which recommends a specific
solution to one part of = the security problem, but does not attempt to propose a complete = security solution. 

I think this document is Ready.

Cathy Meadows


Catherine Meadows
Naval Research = Laboratory
Code 5543
4555 Overlook Ave., = S.W.
Washington DC, 20375
phone: = 202-767-3490
fax: 202-404-7942
email: catherine.meadows@nrl.navy.mil

= --Apple-Mail=_51BE93A2-523F-48AD-A05C-AA83D00034B9-- From nobody Fri Mar 17 06:18:37 2017 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 65AA3126C26; Fri, 17 Mar 2017 02:05:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1489741533; bh=Yw/zC9bo6WHeSBxGQScK7NVpUdpT8e7NJatSzNGcCtA=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=lOEyYkxxvV4a7AKnrQCeKPHP/krxJNaCiGxxIAcP2pRaaR9h67iv0uq2wACNKKAk4 nuIdL0Y2OgW5EOPAieO83LvdcEktBK8DrRGzR00dkUcZ3+GPyBFV9z8yYpxp6M+DuX QVA1l86dxAU8CAPa1uLye4rHCygQW6DL7idLLcV8= 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 C6347126BF6 for ; Fri, 17 Mar 2017 02:05:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDH___l_UGMI for ; Fri, 17 Mar 2017 02:05:30 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (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 581D21250B8 for ; Fri, 17 Mar 2017 02:05:30 -0700 (PDT) Received: from [2001:da8:203:80:f156:1fbd:b675:9ebb] by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1conpA-000FRe-Ff for new-work@ietf.org; Fri, 17 Mar 2017 09:05:28 +0000 To: new-work@ietf.org From: Xueyuan Jia Message-ID: <4dd1ce63-4dce-1441-6e45-0f63e6cff036@w3.org> Date: Fri, 17 Mar 2017 17:07:45 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.22 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 17 Mar 2017 06:18:36 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: TV Control Working Group (until 2017-04-28) 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, 17 Mar 2017 09:05:33 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to review a draft charter for the TV Control Working Group: https://www.w3.org/2017/03/tvcontrol.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 2017-04-28 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 Francois Daoust, Entertainment Champion and Team Contact . Thank you, Xueyuan Jia, W3C Marketing & Communications [1] http://www.w3.org/Consortium/Member/List _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Mon Mar 20 13:15:07 2017 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 462AE12951D for ; Mon, 20 Mar 2017 13:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.666 X-Spam-Level: X-Spam-Status: No, score=-0.666 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, LONGWORDS=2.035, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 uKZnPld3KXmX for ; Mon, 20 Mar 2017 13:15:03 -0700 (PDT) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E90061294CF for ; Mon, 20 Mar 2017 13:15:02 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id v198so97557878ywc.2 for ; Mon, 20 Mar 2017 13:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CpbU4CgOO1cw44ITtgx5ZqB2plHsqJf0aJc1HveIUM4=; b=l2q9ed52+bBoPNqmEWw1cGNDKVfwSXJGcq5Zl5UCRZ7Bf8K9ilHy3b7ytZpFYS3ejK Vikk7iK0MgLi+YcNdLkpnJ6tjtXitEFp910+MIKeym8fDwRT9jKdDa9JbfuGbtIkjac4 djZqND3RIOQveonwKvlNQIL7fyJvjomT12eE29LbD0f/x6XnXOVWXVLQ0Ol7hAV3j5qR rdyi/irCz2WHTW0TXlxtN8E1nVJXsyIjtVJNnByz29ZZ7MUVdNg5QOXkJwAYopRziXe1 Ra+9a/ga6jOE+SbBqLxJGAmjKwcAQDk5L79myNDdpi1Js3jEcIhDFi8KGmnwxJXTxDOr v26Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CpbU4CgOO1cw44ITtgx5ZqB2plHsqJf0aJc1HveIUM4=; b=HLyiPx9M/nz5U7Igt+q1wDBFwjt6cOmLbFLFFQjpJ0z/Xy2/UtFTn5IhBpqU5zP6Oe xEmFFYFds97aYjeZgtGB20nheIoT4AdHoo6ejCnenV9ktCTIkh5OxEJI3Vg+guu7Ah81 u9yiLZCk5UCedPGhR+RL/uRtpspxSHqHi6GHAjeipKRb3Soz8TMhLW/1MiL1jpFQayHN c+Iwt2L3i+sHBNj87WeLLG+jfJAEAFMSgSf6VysOpwF1JQo6+LDxfzsXQXtZbkDuaFiP lwCQPbSrYKcG9cLey2G1u2qn+ZEZe00hbMrJpyK5fVW+5L6pttlkRjAhuh6SSCpkurrU 4vCA== X-Gm-Message-State: AFeK/H3qpBdUQXf+4RhnNxNm3b7t8kdzrCYqi4JCb/8ozKTEoR2/qsxRgW29/7msHIgrFH3H8Wkremibe1/MYm8k X-Received: by 10.13.222.71 with SMTP id h68mr16529449ywe.173.1490040901950; Mon, 20 Mar 2017 13:15:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.59.81 with HTTP; Mon, 20 Mar 2017 13:14:41 -0700 (PDT) In-Reply-To: <5e4d6947-30ed-60c6-d9ab-b2af4485f82c@mandelberg.org> References: <5e4d6947-30ed-60c6-d9ab-b2af4485f82c@mandelberg.org> From: Matt Mathis Date: Mon, 20 Mar 2017 13:14:41 -0700 Message-ID: To: David Mandelberg Cc: secdir@ietf.org, draft-ietf-ippm-model-based-metrics.all@ietf.org Content-Type: multipart/alternative; boundary=94eb2c07cef4aa1249054b2f2ed2 Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-ippm-model-based-metrics-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Mar 2017 20:15:05 -0000 --94eb2c07cef4aa1249054b2f2ed2 Content-Type: text/plain; charset=UTF-8 (Dropping iesg from the follow up chatter). I am adding a paragraph to the security section: Note that in situ measurements sometimes require sending synthetic measurement traffic between arbitrary locations in the network, and as such are potentially attractive platforms for launching DDOS attacks. All active measurement tools and protocols must be deigned to minimize the opportunities for these misuses. Thanks for the feedback! Thanks, --MM-- The best way to predict the future is to create it. - Alan Kay Privacy matters! We know from recent events that people are using our services to speak in defiance of unjust governments. We treat privacy and security as matters of life and death, because for some users, they are. On Sun, Mar 12, 2017 at 2:14 PM, David Mandelberg wrote: > 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. > > This experimental draft "provides a framework for designing suites of IP > diagnostic tests" to measure a network path's bulk transport capacity. > > As mentioned in the security considerations, actual attempts at > measurement might be subject to manipulation by an attacker. As I > understand it, the framework in this document neither attempts to > prevent such attacks, nor makes them any more likely. > > The only other relevant potential security issue I could think of is > whether measurement system(s) using this framework could be co-opted by > an attacker to cause a denial of service to a specific network path. I > think this would depend entirely on the implementation of a system > designed using the framework in this document, and is therefore pretty > far removed from this document itself. An attack like this also might > not be possible because of some part of the framework that I missed. So > I'll trust the authors' and/or working group's judgment on what to do > with this comment. > > I think this draft is somewhere between (inclusive) Ready and Ready With > Issues, depending on how far off-base my point about denial of service > is. I'm leaning towards Ready. > > -- > David Eric Mandelberg / dseomn > http://david.mandelberg.org/ > > --94eb2c07cef4aa1249054b2f2ed2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(Dropping iesg from the follow up chatter).

=
I am adding a paragraph to the security section:
= =C2=A0 =C2=A0 =C2=A0 <t>Note that in situ measurements sometimes requ= ire sending
=C2=A0 =C2=A0 =C2=A0 synthetic measurement traffic be= tween arbitrary locations in the
=C2=A0 =C2=A0 =C2=A0 network, an= d as such are potentially attractive platforms for
=C2=A0 =C2=A0 = =C2=A0 launching DDOS attacks.=C2=A0 All active measurement tools and
=
=C2=A0 =C2=A0 =C2=A0 protocols must be deigned to minimize the opportu= nities for
=C2=A0 =C2=A0 =C2=A0 these misuses.</t>

Thanks for the feedback!

Thanks,
--MM--The best way to predict the future is to create it. =C2=A0- Alan Kay
Privacy matters!=C2=A0 We know from recent events that people are using o= ur services to speak in defiance of unjust governments. =C2=A0 We treat pri= vacy and security as matters of life and death, because for some users, the= y are.

On Sun, Mar 12, 2017 at 2:14 PM, David Mande= lberg <david@mandelberg.org> wrote:
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.=C2=A0 These comments were written primarily for the benefit of the security area directors.=C2=A0 Document editors and WG chairs should treat<= br> these comments just like any other last call comments.

This experimental draft "provides a framework for designing suites of = IP
diagnostic tests" to measure a network path's bulk transport capac= ity.

As mentioned in the security considerations, actual attempts at
measurement might be subject to manipulation by an attacker. As I
understand it, the framework in this document neither attempts to
prevent such attacks, nor makes them any more likely.

The only other relevant potential security issue I could think of is
whether measurement system(s) using this framework could be co-opted by
an attacker to cause a denial of service to a specific network path. I
think this would depend entirely on the implementation of a system
designed using the framework in this document, and is therefore pretty
far removed from this document itself. An attack like this also might
not be possible because of some part of the framework that I missed. So
I'll trust the authors' and/or working group's judgment on what= to do
with this comment.

I think this draft is somewhere between (inclusive) Ready and Ready With Issues, depending on how far off-base my point about denial of service
is. I'm leaning towards Ready.

--
David Eric Mandelberg / dseomn
http://david.mandelberg.org/


--94eb2c07cef4aa1249054b2f2ed2-- From nobody Tue Mar 21 01:03:13 2017 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 2793D12964F; Tue, 21 Mar 2017 01:03:06 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yoav Nir To: Cc: draft-ietf-aqm-codel.all@ietf.org, ietf@ietf.org, aqm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.47.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149008338604.24977.6083947817909590331@ietfa.amsl.com> Date: Tue, 21 Mar 2017 01:03:06 -0700 Archived-At: Subject: [secdir] Review of draft-ietf-aqm-codel-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 08:03:06 -0000 Reviewer: Yoav Nir Review result: Has Nits Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The document describes the CoDel (controlled delay) framework for reducing bufferbloat. It does a good job of describing the problem, outlining the solution and providing both a description of the algorithm (including pseudo-code) and linking to real world implementations. Two nits: 1. A lot of terms are used long before they are explained, such as Estimator, Sojourn time, Interval (BTW: if this is a moving interval the spec should probably say so). When reading sections 3 I concluded that the document was aimed at peopel who already knew all these terms and didn't need definitions, but then reading section 5 gave me a lot of a-ha moments about what I had read previously. 2. The security considerations section says "There are no specific security exposures associated with CoDel." CoDel is about dropping packets, so immediately I have to think how I could subvert a router running CoDel to drop other people's packets. Perhaps it is fine to say that there are no known attacks on CoDel and no steps necessary to mitigate such, but I think it's tempting fate and hackers to say that CoDel has no security exposures. From nobody Tue Mar 21 13:16:44 2017 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 EB78212E855 for ; Tue, 21 Mar 2017 13:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 v_7FJ31Ntm6v for ; Tue, 21 Mar 2017 13:16:34 -0700 (PDT) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A1F7129851 for ; Tue, 21 Mar 2017 13:16:34 -0700 (PDT) Received: by mail-pg0-x229.google.com with SMTP id n190so98608685pga.0 for ; Tue, 21 Mar 2017 13:16:34 -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=V0aWjIAURw2HZN3+c/Foa5W07FhCSrRwM/HetM6nksE=; b=X/Y9xcFyd+xiYNIWZ/q7JWyBvwK4pmTCgZZpQm8avj5y3yn7jasg00MPTiRF2lDzwp fqurR8Pd5SxmP+YUUpU2+VqFSAIdX8VQ34okj8B18O0/86jWcw5K6LL7gWgTCJ6qkpqr fpSDHx1AcUo3pCTkMTjJGttUIIcaX21tFeBKcloVKka9/Lx6Xq/EhvbelSLgk+C5J4RL SSKSyavZPMNubYRF5cR284jntOwCY1MzoIhuQ4fabVBY1feQhflIgEiS7+FoL6wCtNyg Uz3rjoz24H3U81XsP6YvcPTWMfWq6Cu1KN9Yhn0hEfzPnAAig0vc0l1RYsBVmqzNvode 1/+g== 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=V0aWjIAURw2HZN3+c/Foa5W07FhCSrRwM/HetM6nksE=; b=agJP3rqMd1ffPEaHl8O4ZitMdw/Q/fL1SOcSa6MckXixguft0PTS3xQpN1EXPXmUI+ O2dv7fYEpIyg7rhUiSD+nu+RbG2rLRxGpGsnI0FE0gw6syQXI1//HZsU73SpMs4MGOHr FbWBQDzzJ1Eh9zUryKTRXAyWMm0k4gZDM5j0X1l6BCx4ocQFLbo0KO5vDqQdqLcb6GYV taLiUVEwiMGoZforA4S0GoE+kcPvABmzcIt7VUq9lofIooEBNxW7nw+Fw/UgQinzggb8 rP10mSEtcXuNA50peXWDL6ncCIk0UsgL5G3ufSGAFmq6DdOZS8SMWrPiu2pXI8xIaMw2 dCBg== X-Gm-Message-State: AFeK/H1fLaRDtJNeNOjG4uraIeSiGF5528hxaMPSlnwhZWjXlGhe5HpSms3SIlxz+JYOwFDUjSG/PnMoud2fbQ== X-Received: by 10.99.116.10 with SMTP id p10mr39532502pgc.74.1490127394014; Tue, 21 Mar 2017 13:16:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.177.199 with HTTP; Tue, 21 Mar 2017 13:16:33 -0700 (PDT) From: Kathleen Moriarty Date: Tue, 21 Mar 2017 16:16:33 -0400 Message-ID: To: "secdir@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [secdir] SecDir Lunch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Mar 2017 20:16:36 -0000 Hi, The SecDir lunch on Tuesday of next week will take place in room: studio 3. We'll wait until 11:50 to start to give folks a chance to get food before the meeting. If you have any special topics to discuss, please let us know. Thanks in advance! -- Best regards, Kathleen From nobody Tue Mar 21 19:04:55 2017 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 EA398129431; Tue, 21 Mar 2017 19:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.222 X-Spam-Level: X-Spam-Status: No, score=-4.222 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 9C_m8rpmaEmZ; Tue, 21 Mar 2017 19:04:39 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A877126BF7; Tue, 21 Mar 2017 19:04:38 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml709-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DDF00375; Wed, 22 Mar 2017 02:04:36 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 22 Mar 2017 02:04:34 +0000 Received: from DGGEMA403-HUB.china.huawei.com (10.3.20.44) by nkgeml411-hub.china.huawei.com (10.98.56.70) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 22 Mar 2017 10:04:32 +0800 Received: from DGGEMA501-MBS.china.huawei.com ([169.254.4.56]) by DGGEMA403-HUB.china.huawei.com ([10.3.20.44]) with mapi id 14.03.0301.000; Wed, 22 Mar 2017 10:04:30 +0800 From: "Gengxuesong (Geng Xuesong)" To: Yoav Nir , "secdir@ietf.org" CC: "draft-ietf-aqm-codel.all@ietf.org" , "ietf@ietf.org" , "aqm@ietf.org" Thread-Topic: [aqm] Review of draft-ietf-aqm-codel-07 Thread-Index: AQHSohmrIModH2ljM06Ghh8sQcqdUqGgGhzw Date: Wed, 22 Mar 2017 02:04:30 +0000 Message-ID: References: <149008338604.24977.6083947817909590331@ietfa.amsl.com> In-Reply-To: <149008338604.24977.6083947817909590331@ietfa.amsl.com> Accept-Language: en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.169.123] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.58D1DBB4.01E4, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.56, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: d1de04b9f72ef8ec43a766f971f4a0f3 Archived-At: Subject: Re: [secdir] [aqm] Review of draft-ietf-aqm-codel-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 02:04:43 -0000 Hi,=20 I can not agree more on this. It is well written, but I really think I can get the point of the draft fas= ter if I can read the section 5 before section 3. Best Regards, Emma (Xuesong) -----Original Message----- From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Tuesday, March 21, 2017 4:03 PM To: secdir@ietf.org Cc: draft-ietf-aqm-codel.all@ietf.org; ietf@ietf.org; aqm@ietf.org Subject: [aqm] Review of draft-ietf-aqm-codel-07 Reviewer: Yoav Nir Review result: Has Nits Hi, I have reviewed this document as part of the security directorate's ongoing= effort to review all IETF documents being processed by the IESG. These co= mments were written primarily for the benefit of the security area director= s. Document editors and WG chairs should treat these comments just like an= y other last call comments. The document describes the CoDel (controlled delay) framework for reducing = bufferbloat. It does a good job of describing the problem, outlining the so= lution and providing both a description of the algorithm (including pseudo-= code) and linking to real world implementations.=20 Two nits: 1. A lot of terms are used long before they are explained, such as Estimato= r, Sojourn time, Interval (BTW: if this is a moving interval the spec shoul= d probably say so). When reading sections 3 I concluded that the document w= as aimed at peopel who already knew all these terms and didn't need definit= ions, but then reading section 5 gave me a lot of a-ha moments about what I= had read previously. 2. The security considerations section says "There are no specific security= exposures associated with CoDel." CoDel is about dropping packets, so imm= ediately I have to think how I could subvert a router running CoDel to drop= other people's packets. Perhaps it is fine to say that there are no known = attacks on CoDel and no steps necessary to mitigate such, but I think it's = tempting fate and hackers to say that CoDel has no security exposures. _______________________________________________ aqm mailing list aqm@ietf.org https://www.ietf.org/mailman/listinfo/aqm From nobody Tue Mar 21 22:10:33 2017 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 23FAA129464 for ; Tue, 21 Mar 2017 22:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=google.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 lPT1P7aJklu8 for ; Tue, 21 Mar 2017 22:10:18 -0700 (PDT) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (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 A962612943B for ; Tue, 21 Mar 2017 22:10:15 -0700 (PDT) Received: by mail-vk0-x235.google.com with SMTP id d188so115201634vka.0 for ; Tue, 21 Mar 2017 22:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5Gm2jlSTFBRw+QETQ1oGEA0bzyEcP/oREwyeO7z1t+8=; b=F6RYfmt29GLe7A+S6p/TrlVfpFhHPQXRBdVkmylwAhymusm9jgzEinFjv1+8rZCXTX lGakX67QZAWi+oCaaKnxZu2v/1lLzHHBS0D4JsL6Au8Vf9CYMy1poS9WaPCF8rwInnOu kl4KeEDOSjHDJX+IhCyZNOJ/EPo7iNKes2Ct02G3fONzFXUIvV8d3CYLiw3JfEuIPQrJ s4zROaP1myX+Mm3x1VcmxavW5IBtKbMg09g2oJHeDo1zE+Qzu3Qqh0zBD8BM6zaz4Ccu sBf07zI/pZOTez17jRWjHTGFHvEdzCfAk+NwFSvZpKAAwzWtZSI3BkqInb4jZviwAxj9 BGmw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5Gm2jlSTFBRw+QETQ1oGEA0bzyEcP/oREwyeO7z1t+8=; b=igOwHoUpzAxypF9C/YxRLuOI1KWKLby3WPnmRvchHov6BwOVXcepeOofYpM14B46XM ItXF7VGfcNnFLp7u1VGHmNWx/4rnaTCJ3VdJcFRmFy45CBBnOOjflo0zzzw5nTz2AmfW 6srFVPTRRvW/iPR14jAHyn1G2fYa1QOsLNDhcOfufhF3FcMfjsksYHOHxYigAxKg/p7c nOi8kKClK6776+zio0Q3bOFFcVdl6qBGy1ZLcrKIW/9xeJ2eqB0ddsyw62XLLmHKxBj0 UqClEuTYjx2BU954vjEfJlJlstbvuBkyyo837mHLkE+OKgw0kgxdQWMFuOpm6PJu2sNV nBAg== X-Gm-Message-State: AFeK/H2Mreq0prolt0MRUvseLV5tiDEuLAoq1HH60VXteuVMf35DeZrT9MsVuBkwROSogQZuGGGjU22Xvi60RF/P X-Received: by 10.176.74.155 with SMTP id s27mr14109789uae.143.1490159414417; Tue, 21 Mar 2017 22:10:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Tue, 21 Mar 2017 22:10:13 -0700 (PDT) In-Reply-To: References: <149008338604.24977.6083947817909590331@ietfa.amsl.com> From: Jana Iyengar Date: Tue, 21 Mar 2017 22:10:13 -0700 Message-ID: To: "Gengxuesong (Geng Xuesong)" Cc: Yoav Nir , "secdir@ietf.org" , "draft-ietf-aqm-codel.all@ietf.org" , "ietf@ietf.org" , "aqm@ietf.org" Content-Type: multipart/alternative; boundary=f403045ef6548e677b054b4ac607 Archived-At: Subject: Re: [secdir] [aqm] Review of draft-ietf-aqm-codel-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 05:10:20 -0000 --f403045ef6548e677b054b4ac607 Content-Type: text/plain; charset=UTF-8 Thanks Yoav, Emma. I can try to move Sec 5 before Sec 3, if that helps. Yoav: What do you suggest we add for security considerations? Thanks for the reviews! - jana On Tue, Mar 21, 2017 at 7:04 PM, Gengxuesong (Geng Xuesong) < gengxuesong@huawei.com> wrote: > Hi, > > I can not agree more on this. > It is well written, but I really think I can get the point of the draft > faster if I can read the section 5 before section 3. > > > Best Regards, > Emma (Xuesong) > > -----Original Message----- > From: aqm [mailto:aqm-bounces@ietf.org] On Behalf Of Yoav Nir > Sent: Tuesday, March 21, 2017 4:03 PM > To: secdir@ietf.org > Cc: draft-ietf-aqm-codel.all@ietf.org; ietf@ietf.org; aqm@ietf.org > Subject: [aqm] Review of draft-ietf-aqm-codel-07 > > Reviewer: Yoav Nir > Review result: Has Nits > > Hi, > > I have reviewed this document as part of the security directorate's > ongoing effort to review all IETF documents being processed by the IESG. > These comments were written primarily for the benefit of the security area > directors. Document editors and WG chairs should treat these comments just > like any other last call comments. > > The document describes the CoDel (controlled delay) framework for reducing > bufferbloat. It does a good job of describing the problem, outlining the > solution and providing both a description of the algorithm (including > pseudo-code) and linking to real world implementations. > > Two nits: > > 1. A lot of terms are used long before they are explained, such as > Estimator, Sojourn time, Interval (BTW: if this is a moving interval the > spec should probably say so). When reading sections 3 I concluded that the > document was aimed at peopel who already knew all these terms and didn't > need definitions, but then reading section 5 gave me a lot of a-ha moments > about what I had read previously. > > 2. The security considerations section says "There are no specific > security exposures associated with CoDel." CoDel is about dropping > packets, so immediately I have to think how I could subvert a router > running CoDel to drop other people's packets. Perhaps it is fine to say > that there are no known attacks on CoDel and no steps necessary to mitigate > such, but I think it's tempting fate and hackers to say that CoDel has no > security exposures. > > _______________________________________________ > aqm mailing list > aqm@ietf.org > https://www.ietf.org/mailman/listinfo/aqm > --f403045ef6548e677b054b4ac607 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks Yoav, Emma. I can try to move Sec 5 before Sec 3, i= f that helps.
Yoav: What do you suggest we add for security considerati= ons?

Thanks for the reviews!
- jana<= /div>


On Tue, Mar 21, 2017 at 7:04 PM, Gengxuesong (Geng Xuesong) <gengxuesong@huawei.com> wrote:
Hi,

I can not agree more on this.
It is well written, but I really think I can get the point of the draft fas= ter if I can read the section 5 before section 3.


Best Regards,
Emma (Xuesong)

-----Original Message-----
From: aqm [mailto:aqm-bounces@ietf.= org] On Behalf Of Yoav Nir
Sent: Tuesday, March 21, 2017 4:03 PM
To: secdir@ietf.org
Cc: draft-ietf-aqm-cod= el.all@ietf.org; ietf@ietf.org; aqm@ietf.org
Subject: [aqm] Review of draft-ietf-aqm-codel-07

Reviewer: Yoav Nir
Review result: Has Nits

Hi,

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

The document describes the CoDel (controlled delay) framework for reducing = bufferbloat. It does a good job of describing the problem, outlining the so= lution and providing both a description of the algorithm (including pseudo-= code) and linking to real world implementations.

Two nits:

1. A lot of terms are used long before they are explained, such as Estimato= r, Sojourn time, Interval (BTW: if this is a moving interval the spec shoul= d probably say so). When reading sections 3 I concluded that the document w= as aimed at peopel who already knew all these terms and didn't need def= initions, but then reading section 5 gave me a lot of a-ha moments about wh= at I had read previously.

2. The security considerations section says "There are no specific sec= urity exposures associated with CoDel."=C2=A0 CoDel is about dropping = packets, so immediately I have to think how I could subvert a router runnin= g CoDel to drop other people's packets. Perhaps it is fine to say that = there are no known attacks on CoDel and no steps necessary to mitigate such= , but I think it's tempting fate and hackers to say that CoDel has no s= ecurity exposures.

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

--f403045ef6548e677b054b4ac607-- From nobody Tue Mar 21 22:15:46 2017 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 43E45126B7F; Tue, 21 Mar 2017 22:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 PTrnNTS0L5OA; Tue, 21 Mar 2017 22:15:31 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AB7B1242F5; Tue, 21 Mar 2017 22:15:31 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id n11so26834026wma.0; Tue, 21 Mar 2017 22:15:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=lo9cWTZMulBLNJJsPrLhryDEhcoNvKm8b8lmD+hyHxg=; b=LcoMAD7nI9axHFd2bJmMgBoutPMxk+0BRW1SpQgMJ/tpA+JDd0fehwQ/O+mj4LVAhr imlbctRM8GZzP5Jsj4YOJx7YoFEGztLIbWqmL/AM7jtOjbckB4/xveSiyLKDUMjGy7IN eOQzO9SpYxvlQNI6FhKRZevyRMLtNuFm9TNjSMPQ0mEFzWFQoAZVtMsFEkaA1uPBDnB0 wWMRE42ls5pxrGNl5Jij3TAz9EzOs8ThkGogaLrHYU0rymaZ+Bk8IdbJOI7+6TEf5OQ8 SBQlCL0OHyAm4oiP48JENuNLY6r7DxXxX0P1Mn1gz+QsjiCIraerzgsLZ3auVQof5/27 6q0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=lo9cWTZMulBLNJJsPrLhryDEhcoNvKm8b8lmD+hyHxg=; b=snVewC/cZhygS8vUdjnjegbQojeiBdITGp5RTYJM4oO1GPWFchvI/FUSzvQdnfvDWf 5GdoN1I2zJbPtRlKMhZYRXy3YmbAQ11D2YhQxWqDp7v90Ll4VUKkuPTikrXdrZF/unc2 TzIZVIh3Ibqfv3beGehjB/2ey+J9Pfu56XEpPmEuS9yiTmFPv/zqEEJD8MM/V8fKxv67 FBdeiPL9RuamV2ws/AMC87OvyXefoHwCOA/LwqI1m3CjcIYs09aMKnoM/2uup1ZRphZy ClzHyEbg/tAF7mfqhLJFUlYLh17gLTWxd3pNs49gmJs/R2QwMbml1JG/RCDKHjn6e0r1 nHOw== X-Gm-Message-State: AFeK/H04eV41kUhy8RGzHGGkSLOziWkPZxq4sowndOsu6m2N/vd+JQtxzXGUSGS6aE0XsA== X-Received: by 10.28.55.138 with SMTP id e132mr5599740wma.6.1490159729938; Tue, 21 Mar 2017 22:15:29 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id u81sm328401wrb.67.2017.03.21.22.15.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Mar 2017 22:15:29 -0700 (PDT) From: Yoav Nir Message-Id: <3C9CECA3-D84E-4471-B4AF-EA1C5061CC90@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_A6D557CA-D55A-4A0A-8AE8-B5A59B241ECD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Wed, 22 Mar 2017 07:15:26 +0200 In-Reply-To: Cc: "Gengxuesong (Geng Xuesong)" , "secdir@ietf.org" , "draft-ietf-aqm-codel.all@ietf.org" , "ietf@ietf.org" , "aqm@ietf.org" To: Jana Iyengar References: <149008338604.24977.6083947817909590331@ietfa.amsl.com> X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [secdir] [aqm] Review of draft-ietf-aqm-codel-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 05:15:33 -0000 --Apple-Mail=_A6D557CA-D55A-4A0A-8AE8-B5A59B241ECD Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii > On 22 Mar 2017, at 7:10, Jana Iyengar wrote: > > Thanks Yoav, Emma. I can try to move Sec 5 before Sec 3, if that helps. Thanks. I think it will. > Yoav: What do you suggest we add for security considerations? How about: OLD: There are no specific security exposures associated with CoDel NEW: There are no known security exposures associated with CoDel at this time. Yoav --Apple-Mail=_A6D557CA-D55A-4A0A-8AE8-B5A59B241ECD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJY0ghvAAoJELhJCxUKWMyZ0qMIAMFaV/1VwjJx6+zZLL/Zr+Lq 1X1Mt70dc0cDK1/l/iHQvo0RFnLCD9sJUVoQzv0LBbvV5FNy6R96KwpoR4sRMjXD +z7YF7+LBCqAdAo/z1091bJ6h+LDwxbn8aZf7pqnxC6NkWEE1IR4B8BJbOOFy8yA 2lKP45G0tet6pvIrFM5qP4usPxmSzi0dw0+py/9R9jBQN2bTdtLAO2AqOm2WroHU UY7nVn9P/hZw5At5qH9dPMTACSE6gt+uuQVw9FLHw6SDwQb37M0+HPE6k1JLHPVI /ZVA0ni+1m6feOJtlyKTyp2vKwvdbHNqjV9QNSBizWDxJhEaDYJl5AodVBS8e5w= =+3oo -----END PGP SIGNATURE----- --Apple-Mail=_A6D557CA-D55A-4A0A-8AE8-B5A59B241ECD-- From nobody Tue Mar 21 22:21:00 2017 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 2651A1242F5 for ; Tue, 21 Mar 2017 22:20:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=google.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 F-CJIyWy253N for ; Tue, 21 Mar 2017 22:20:50 -0700 (PDT) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (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 71958127599 for ; Tue, 21 Mar 2017 22:20:47 -0700 (PDT) Received: by mail-vk0-x22a.google.com with SMTP id z204so58588936vkd.1 for ; Tue, 21 Mar 2017 22:20:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FEYvf2mRafRqOtc+czZVd9CIIrv/29TN0hWnEjVyAtw=; b=e8QvGkl1NvLOY1pZEzz64fc4Xxz936JCdYtsTScb0a3yWWtkX0no3PzXg9tJztfFLJ 8A/+JKPjyx3t5Sc4VKFegwIydDbf9fbYag2KOK4W4ATPeKMDE4QENb29u7mGh6WDlawA TQANsNEIl9jgzV6Z6U//4aFyXnkuod478UF4KihY+Ajfad7qOrZRc2Z6JBSiBGghSnku Wn3bFlWrAHdPte3FtJ3KCOLGbSX+lhin+hRPEMSbCSu6ccLZQS4CoCEnWAuG7D1Ju/Wy yjj26hnr5LlPIQDPrDO7p5gbBv4mJFTu+oIHinqmoZP1zqrJSojzASchyxbnQHU4+7pE bKIg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FEYvf2mRafRqOtc+czZVd9CIIrv/29TN0hWnEjVyAtw=; b=b88MVbrT2Dz3B6ly/Tg3q2n+ERKeHwh5yacueFoCWemucVgpIPIm+H8kQFrAGMYPdy hyGnRvtsu46W+YaoBxK9juZ3cltUIGemDSv4/Gd2S0kPf82RsoORuF3UK47Zs+4RGzNc G6GvnvdNmtO65OskkBJ9O+F+Y4iWaC1UWxDuiauhaOYTCsWtWUA2iSQsY1mcM/YS8hu8 c1t7GXOCr9UhBmRAyow4ylTwpNFnD3mT/N2Hokco9WMmR9BAq477H2Mjc331dDYzLL7A 7sdqAZC+GMMP5r5kGfrxdu8Ghydp8Fu6JxxSjG/xDRcgGE/O+pPdpPsvQ65XjKl9Jn2M g80Q== X-Gm-Message-State: AFeK/H08++H/Va8Zqtv/yM3Onbg3iw/SlZ1Tslozoj9aEko2QEIIpsk2Ia4DqRBzn6SILtkRyGg/zXXc3U7hzgFQ X-Received: by 10.176.16.5 with SMTP id f5mr13978324uab.13.1490160046244; Tue, 21 Mar 2017 22:20:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Tue, 21 Mar 2017 22:20:45 -0700 (PDT) In-Reply-To: <3C9CECA3-D84E-4471-B4AF-EA1C5061CC90@gmail.com> References: <149008338604.24977.6083947817909590331@ietfa.amsl.com> <3C9CECA3-D84E-4471-B4AF-EA1C5061CC90@gmail.com> From: Jana Iyengar Date: Tue, 21 Mar 2017 22:20:45 -0700 Message-ID: To: Yoav Nir Cc: "Gengxuesong (Geng Xuesong)" , "secdir@ietf.org" , "draft-ietf-aqm-codel.all@ietf.org" , "ietf@ietf.org" , "aqm@ietf.org" Content-Type: multipart/alternative; boundary=f403045e345e37540b054b4aec50 Archived-At: Subject: Re: [secdir] [aqm] Review of draft-ietf-aqm-codel-07 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 05:20:51 -0000 --f403045e345e37540b054b4aec50 Content-Type: text/plain; charset=UTF-8 SGTM. Thanks! On Tue, Mar 21, 2017 at 10:15 PM, Yoav Nir wrote: > > > On 22 Mar 2017, at 7:10, Jana Iyengar wrote: > > > > Thanks Yoav, Emma. I can try to move Sec 5 before Sec 3, if that helps. > > Thanks. I think it will. > > > Yoav: What do you suggest we add for security considerations? > > How about: > > OLD: > There are no specific security exposures associated with CoDel > > NEW: > There are no known security exposures associated with CoDel at this > time. > > Yoav > > --f403045e345e37540b054b4aec50 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
SGTM. Thanks!

On Tue, Mar 21, 2017 at 10:15 PM, Yoav Nir <ynir.ietf= @gmail.com> wrote:

> On 22 Mar 2017, at 7:10, Jana Iyengar <jri@google.com> wrote:
>
> Thanks Yoav, Emma. I can try to move Sec 5 before Sec 3, if that helps= .

Thanks. I think it will.

> Yoav: What do you suggest we add for security considerations?

How about:

OLD:
=C2=A0 =C2=A0There are no specific security exposures asso= ciated with CoDel

NEW:
=C2=A0 =C2=A0There are no known security exposures associated with CoDel at= this time.

Yoav


--f403045e345e37540b054b4aec50-- From nobody Wed Mar 22 09:46:21 2017 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 C2BF7129A90; Wed, 22 Mar 2017 09:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bv2xUzAZ35Sf; Wed, 22 Mar 2017 09:46:13 -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 7B7AC129AC6; Wed, 22 Mar 2017 09:46:02 -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 v2MGjqZU029458 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 22 Mar 2017 18:45:52 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id v2MGjpFK024608; Wed, 22 Mar 2017 18:45:51 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22738.43583.681785.129984@fireball.acr.fi> Date: Wed, 22 Mar 2017 18:45:51 +0200 From: Tero Kivinen To: Christian Huitema Cc: The IESG , secdir@ietf.org, draft-ietf-ipsecme-rfc7321bis.all@ietf.org In-Reply-To: <2927d78d-7293-ba53-4aa3-0351e0a6e7b2@huitema.net> References: <2927d78d-7293-ba53-4aa3-0351e0a6e7b2@huitema.net> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 9 min Archived-At: Subject: [secdir] secdir review of draft-ietf-ipsecme-rfc7321bis-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Mar 2017 16:46:15 -0000 Christian Huitema writes: > The second set of nits contains manual keying. According to the > draft, anyone using manual keying is punished for doing so, and will > only be able to use ENCR_AES_CBC. I assume that there is WG > consensus on that, but the justification that other algorithms > really require IKEv2 is a bit weak. If there is an API to configure > encryption with the results of an IKEv2 negotiation, it could just > as well be used with the results of a manual configuration. Not sure > that the definition of algorithms is the best place to deprecate > manual configuration, even if there are some pretty good reasons to > do that. Using API to configure keying material to the IPsec is not manual keying. There are two options in RFC4301 for key management, section 4.5.1 manual techniques, and 4.5.2 automated key management. Anything that creates keys on the fly (i.e., IKEv2, or API) is automated key management. When using manual techniques the "person manually configures each system with keying material and SA management data relevant to secure communication with other systems." (section 4.5.1 of RFC4301). As there might not be person manually configuring the next keys when the device is rebooted, and when the counters start again from zero, manual keying cannot be used with algorithms like CCM, GCM or CHACHA20 etc. -- kivinen@iki.fi From nobody Thu Mar 23 02:01:17 2017 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 73F20129673 for ; Thu, 23 Mar 2017 02:01:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.48.00 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secretary@mit.edu Message-ID: <149025967647.7592.17092856352856981375.idtracker@ietfa.amsl.com> Date: Thu, 23 Mar 2017 02:01:16 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Mar 2017 09:01:16 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-04-13 Reviewer LC end Draft Phillip Hallam-Baker 2017-02-24 draft-ietf-dmm-lma-controlled-mag-params-04 Tero Kivinen R2016-09-28 draft-ietf-ippm-6man-pdm-option-09 Russ Mundy None draft-ietf-ipsecme-tcp-encaps-09 Magnus Nystrom 2017-03-27 draft-ietf-alto-multi-cost-07 Hilarie Orman 2017-03-01 draft-ietf-6man-rfc2460bis-08 Radia Perlman 2017-04-10 draft-ietf-isis-auto-conf-04 Vincent Roca 2017-04-07 draft-ietf-rtgwg-yang-key-chain-15 Joseph Salowey 2017-04-07 draft-ietf-isis-mi-bis-02 Yaron Sheffer 2017-03-31 draft-ietf-pals-status-reduction-04 Last calls: Reviewer LC end Draft Derek Atkins 2017-03-22 draft-ietf-i2nsf-problem-and-use-cases-11 Ben Laurie 2017-03-02 draft-ietf-dprive-dtls-and-tls-profiles-08 Sandra Murphy 2017-03-27 draft-ietf-dnsop-nsec-aggressiveuse-08 Rich Salz 2017-04-06 draft-ietf-mmusic-dtls-sdp-22 Tom Yu 2017-02-20 draft-ietf-slim-negotiating-human-language-08 Early review requests: Reviewer Due Draft Daniel Gillmor 2016-02-01 draft-ietf-rtcweb-security-08 Brian Weis 2016-02-01 draft-ietf-cdni-uri-signing-10 Next in the reviewer rotation: Rifaat Shekh-Yusef Melinda Shore Robert Sparks Takeshi Takahashi Sean Turner Carl Wallace David Waltermire Sam Weiler Brian Weis Klaas Wierenga From nobody Sun Mar 26 20:50:47 2017 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 E43AC127241; Sun, 26 Mar 2017 20:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 Me90KVg1PTdL; Sun, 26 Mar 2017 20:50:43 -0700 (PDT) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DA1E1292D0; Sun, 26 Mar 2017 20:50:41 -0700 (PDT) Received: by mail-qt0-x229.google.com with SMTP id n21so27876999qta.1; Sun, 26 Mar 2017 20:50:41 -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=i6PbsDc2t8VOP/AZ1nXYb7oESlufxXSYAYIAsfqdG44=; b=Z0WjszP1tYQ18dfYOnbPk7trlQx9emfIBRwA/xIeVucYiaO2nAonI5Gc7SYJTxORUo DXfZPEODKppb7a6y+IJC0i1R3+gxW3kLbkTM56yYy1WZbmTT5L2JVf73fqgDuEPSx/yT sLidlBxE+tZgavzFjmA4Ep8WfU37G+1IDGWaOzh6ocZppYLFGmV3Ml8U/tG0jHWh1L+f 3mNDQ9uBjcH8vEFSbdPrgtmnGiv2ubIczdi6soj/jh1rBy3+Ou0VE+lNqCsNaW2mzGez wZl9sA5B3AXlgUsv5l32b81Z3D9bkQCQ3Uv4Rm06CXZdMfANXy5SByASaduJb/R4bJpI CkPg== 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=i6PbsDc2t8VOP/AZ1nXYb7oESlufxXSYAYIAsfqdG44=; b=pNeyr+CzkxbV3QxJBCk+s643QWlAMo/AV0I1sFw1NwYd7difoOZ/ISX+yTOSLFMPaI yqwKYCFOXuqhq59mCUfstHBf9uZ5bAiZDAqx9caB7XIx0z5VLkRoBIGuGA+ZCy/ykTOO iFFN3QpdUiXw8uzcX8LIBVDg4ATqaRU8gN1lDZ4FY4XjqZYm9v3H2y8QGDyVGRu9j8fg WEy5NemcXNeuAdsT+00bkvNK7esFfy56U3GxeRaCHu4PlNWlGC7l+AUKnWwul9GNS6ep nfA9zQQFozn7y++7Q1sHOuMfQVS0AUD+XEqaOZWSpjbshUpbJR7qpjGV3O9YiYr4vzab I8og== X-Gm-Message-State: AFeK/H0EQ1J+cxr2b522i7hG8KeMoF/FlCymSEF8jwplAkKLhGe7manW7ijRnqYl6uLPHjnkLljii9O9PA1i2Q== X-Received: by 10.200.40.42 with SMTP id 39mr18556184qtq.149.1490586640220; Sun, 26 Mar 2017 20:50:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.48.47 with HTTP; Sun, 26 Mar 2017 20:50:39 -0700 (PDT) From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= Date: Sun, 26 Mar 2017 20:50:39 -0700 Message-ID: To: "secdir@ietf.org" , draft-ietf-alto-multi-cost@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [secdir] Secdir review of draft-ietf-multi-cost X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 03:50:46 -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. This document describes extensions to the ALTO (Application Layer Traffic Optimization) protocol that allows for more efficient information exchanges between an ALTO client and an ALTO server. Specifically, it allows a client to query for multiple metrics in one request. The security considerations section correctly refers to the basic ALTO protocol I only have one additional consideration (and I don't even know if it applies ...): With the existing ALTO protocol, a server could defend against dDOS by not throttling requests. However, each accepted request is simple in that it only deals with one metric. With this document, a malicious client could send a highly complicated query to the server, which may cause significant resources to be used on the server end and without an ability to throttle. Is that a risk? Other than that, the document may benefit from a language/grammar review. Example: "Hence a legacy may send a request with a constraint test on any of the cost types listed in "cost-type-name" - should likely be "legacy client". There are more such examples. Thanks, -- Magnus From nobody Mon Mar 27 16:36:10 2017 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 6C9611296C1; Mon, 27 Mar 2017 16:36:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.697 X-Spam-Level: X-Spam-Status: No, score=-4.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.796, SPF_HELO_PASS=-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=nokia.onmicrosoft.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 1T4bKDouvmk2; Mon, 27 Mar 2017 16:36:07 -0700 (PDT) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0125.outbound.protection.outlook.com [104.47.1.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 64D5F1277BB; Mon, 27 Mar 2017 16:36:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector2-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PAHvFIc5TGhVtjSs6TLje0rjVjevPbl3a7OXQFqro20=; b=CHaOLt/U1rbkBC4VJA3gcl/eKsbMXE/yj0KMEkCxiA7Jl+R1hlYthdGL9NAvtDgGsWkdOQEFANT7aQJ0XLGTY9XfgvQau/6W2gDhUoD6NKBzGz0naXGnSIaDWwm2Cw1Cyj59JMz5Er7ayDqLkrm4Eq/Isrkcw+Dt05HSiabbpR4= Received: from DB6PR0701MB2454.eurprd07.prod.outlook.com (10.168.75.147) by DB6PR0701MB2454.eurprd07.prod.outlook.com (10.168.75.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1005.2; Mon, 27 Mar 2017 23:36:01 +0000 Received: from DB6PR0701MB2454.eurprd07.prod.outlook.com ([10.168.75.147]) by DB6PR0701MB2454.eurprd07.prod.outlook.com ([10.168.75.147]) with mapi id 15.01.1005.009; Mon, 27 Mar 2017 23:36:01 +0000 From: "Randriamasy, Sabine (Nokia - FR/Nozay)" To: =?utf-8?B?TWFnbnVzIE55c3Ryw7Zt?= , "secdir@ietf.org" , "draft-ietf-alto-multi-cost@ietf.org" Thread-Topic: Secdir review of draft-ietf-multi-cost Thread-Index: AQHSpq1SieTDKNg7/kiD8M84t6RrlqGo3KmA Date: Mon, 27 Mar 2017 23:36:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=nokia-bell-labs.com; x-originating-ip: [135.245.20.25] x-microsoft-exchange-diagnostics: 1; DB6PR0701MB2454; 7:PDKgmi6r0rFYBYo5oSJL5+RDw+0vu4IFtTBwvNRm3m/SjQbbw95rhTKE2f02oywdRLWN6u+OPwoI4GDejLrmbXWgoiicjPt3vssVlvAv3Tb+v7PFIctTfkduGYekpN3vMEjKZT+E0jftep55wi8Dn5T8P3/9GntigNvdaaiHSYI0vXHf2e9b1Y5YChFHfNJBnyTO8KUXW34Mqg76jPEDLO0FIzVSbL1za3KT8fpkXRH29YmkBwTyU0lsaEKXbEbfmRwEibTXfTnOKfx7z7ccjsgm8+yIg0/hnHs7TNIswxFBaclhdYuIjLbT4rSu+vaKnawUQFTuRr8xcpGdob9AeA== x-ms-office365-filtering-correlation-id: d621bd34-6282-4eb7-8c00-08d4756a0780 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081); SRVR:DB6PR0701MB2454; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123564025)(20161123562025)(20161123558025)(20161123555025)(6072148); SRVR:DB6PR0701MB2454; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2454; x-forefront-prvs: 02596AB7DA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(6009001)(39450400003)(39850400002)(39860400002)(39840400002)(39410400002)(45984002)(13464003)(229853002)(8676002)(74316002)(561944003)(66066001)(6436002)(3280700002)(2906002)(33656002)(3660700001)(53936002)(39060400002)(54356999)(5660300001)(81166006)(76176999)(81156014)(50986999)(122556002)(8936002)(305945005)(7696004)(77096006)(7736002)(189998001)(3846002)(6506006)(102836003)(6116002)(2950100002)(2201001)(2501003)(6246003)(38730400002)(55016002)(9686003)(99286003)(2900100001)(25786009)(230783001)(86362001)(90052001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2454; H:DB6PR0701MB2454.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: nokia-bell-labs.com X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Mar 2017 23:36:01.6728 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2454 Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-multi-cost X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Mar 2017 23:36:09 -0000 SGVsbG8gTWFnbnVzLA0KDQpUaGFuayB5b3UgdmVyeSBtdWNoIGZvciB5b3VyIHJldmlldyBhbmQg ZmVlZGJhY2suIFRvIGFuc3dlciB5b3VyIHF1ZXN0aW9uczoNCi0gd2UgYmVsaWV2ZSB0aGF0IHRo aXMgcHJvcG9zYWwgZG9lcyBub3QgY2F1c2UgYW55IGFkZGl0aW9uYWwgc2VjdXJpdHkgaXNzdWVz IGNvbXBhcmVkIHRvIHRoZSBiYXNlIHByb3RvY29sIHNwZWNpZmllZCBpbiBSRkM3Mjg1LiBUaGUg TXVsdGktQ29zdCBvcHRpbWl6YXRpb24gZXZlbiB0ZW5kcyB0byByZWR1Y2UgdGhlICBvbiB0aGUg d2lyZSBkYXRhIGV4Y2hhbmdlIHZvbHVtZSBjb21wYXJlZCB0byBtdWx0aXBsZSBzaW5nbGUgY29z dCBBTFRPIHRyYW5zYWN0aW9ucy4gTGlrZXdpc2UsIHRoZSByaXNrIHJlbGF0ZWQgdG8gbWFzc2l2 ZSBtdWx0aS1jb3N0IHJlcXVlc3QgaXMgbW9kZXJhdGVkIGJ5IHRoZSBmYWN0IHRoYXQgTXVsdGkt Q29zdCBjb25zdHJhaW50cyBmdXJ0aGVyIGZpbHRlcnMgQUxUTyBTZXJ2ZXIgcmVzcG9uc2VzIGFu ZCB0aHVzIHRoZWlyIHZvbHVtZS4gDQotIEluZGVlZCB0aGUgZm9ybXVsYXRpb24gImxlZ2FjeSIg bmVlZHMgYmUgdXBkYXRlZCBhcyB5b3Ugc3VnZ2VzdC4gV2Ugd2lsbCB0cmFjayBzaW1pbGFyIGV4 YW1wbGVzIGFuZCBwb3N0IGEgcmV2aXNpb24uIA0KDQpCZXN0IHJlZ2FyZHMsDQpTYWJpbmUNCg0K DQo+Pi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+PkZyb206IE1hZ251cyBOeXN0csO2bSBb bWFpbHRvOm1hZ251c25AZ21haWwuY29tXQ0KPj5TZW50OiBsdW5kaSAyNyBtYXJzIDIwMTcgMDU6 NTENCj4+VG86IHNlY2RpckBpZXRmLm9yZzsgZHJhZnQtaWV0Zi1hbHRvLW11bHRpLWNvc3RAaWV0 Zi5vcmcNCj4+U3ViamVjdDogU2VjZGlyIHJldmlldyBvZiBkcmFmdC1pZXRmLW11bHRpLWNvc3QN Cj4+DQo+PkkgaGF2ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3Vy aXR5IGRpcmVjdG9yYXRlJ3Mgb25nb2luZw0KPj5lZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRv Y3VtZW50cyBiZWluZyBwcm9jZXNzZWQgYnkgdGhlIElFU0cuIFRoZXNlDQo+PmNvbW1lbnRzIHdl cmUgd3JpdHRlbiBwcmltYXJpbHkgZm9yIHRoZSBiZW5lZml0IG9mIHRoZSBzZWN1cml0eSBhcmVh DQo+PmRpcmVjdG9ycy4gRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hhaXJzIHNob3VsZCB0cmVh dCB0aGVzZSBjb21tZW50cyBqdXN0DQo+Pmxpa2UgYW55IG90aGVyIGxhc3QgY2FsbCBjb21tZW50 cy4NCj4+DQo+PlRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGV4dGVuc2lvbnMgdG8gdGhlIEFMVE8g KEFwcGxpY2F0aW9uIExheWVyIFRyYWZmaWMNCj4+T3B0aW1pemF0aW9uKSBwcm90b2NvbCB0aGF0 IGFsbG93cyBmb3IgbW9yZSBlZmZpY2llbnQgaW5mb3JtYXRpb24gZXhjaGFuZ2VzDQo+PmJldHdl ZW4gYW4gQUxUTyBjbGllbnQgYW5kIGFuIEFMVE8gc2VydmVyLg0KPj5TcGVjaWZpY2FsbHksIGl0 IGFsbG93cyBhIGNsaWVudCB0byBxdWVyeSBmb3IgbXVsdGlwbGUgbWV0cmljcyBpbiBvbmUgcmVx dWVzdC4NCj4+DQo+PlRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uIGNvcnJlY3Rs eSByZWZlcnMgdG8gdGhlIGJhc2ljIEFMVE8NCj4+cHJvdG9jb2wgSSBvbmx5IGhhdmUgb25lIGFk ZGl0aW9uYWwgY29uc2lkZXJhdGlvbiAoYW5kIEkgZG9uJ3QgZXZlbiBrbm93IGlmIGl0DQo+PmFw cGxpZXMgLi4uKTogV2l0aCB0aGUgZXhpc3RpbmcgQUxUTyBwcm90b2NvbCwgYSBzZXJ2ZXIgY291 bGQgZGVmZW5kIGFnYWluc3QNCj4+ZERPUyBieSBub3QgdGhyb3R0bGluZyByZXF1ZXN0cy4gSG93 ZXZlciwgZWFjaCBhY2NlcHRlZCByZXF1ZXN0IGlzIHNpbXBsZQ0KPj5pbiB0aGF0IGl0IG9ubHkg ZGVhbHMgd2l0aCBvbmUgbWV0cmljLiBXaXRoIHRoaXMgZG9jdW1lbnQsIGEgbWFsaWNpb3VzIGNs aWVudA0KPj5jb3VsZCBzZW5kIGEgaGlnaGx5IGNvbXBsaWNhdGVkIHF1ZXJ5IHRvIHRoZSBzZXJ2 ZXIsIHdoaWNoIG1heSBjYXVzZQ0KPj5zaWduaWZpY2FudCByZXNvdXJjZXMgdG8gYmUgdXNlZCBv biB0aGUgc2VydmVyIGVuZCBhbmQgd2l0aG91dCBhbiBhYmlsaXR5IHRvDQo+PnRocm90dGxlLiBJ cyB0aGF0IGEgcmlzaz8NCj4+DQo+Pk90aGVyIHRoYW4gdGhhdCwgdGhlIGRvY3VtZW50IG1heSBi ZW5lZml0IGZyb20gYSBsYW5ndWFnZS9ncmFtbWFyDQo+PnJldmlldy4gRXhhbXBsZToNCj4+Ikhl bmNlIGEgbGVnYWN5IG1heSBzZW5kIGEgcmVxdWVzdCB3aXRoIGEgY29uc3RyYWludCB0ZXN0IG9u IGFueSBvZiB0aGUgY29zdA0KPj50eXBlcyBsaXN0ZWQgaW4gImNvc3QtdHlwZS1uYW1lIiAtIHNo b3VsZCBsaWtlbHkgYmUgImxlZ2FjeSBjbGllbnQiLiBUaGVyZSBhcmUNCj4+bW9yZSBzdWNoIGV4 YW1wbGVzLg0KPj4NCj4+VGhhbmtzLA0KPj4tLSBNYWdudXMNCg== From nobody Tue Mar 28 05:59:22 2017 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 482E4129485 for ; Tue, 28 Mar 2017 05:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.397 X-Spam-Level: X-Spam-Status: No, score=-5.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.796, 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 lquG2PiJFfLH for ; Tue, 28 Mar 2017 05:59:13 -0700 (PDT) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 F286B1297D6 for ; Tue, 28 Mar 2017 05:59:12 -0700 (PDT) Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1csqiM-0006Th-7W for secdir@ietf.org; Tue, 28 Mar 2017 14:59:11 +0200 Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1csqiJ-0005PL-V3 for secdir@ietf.org; Tue, 28 Mar 2017 08:59:08 -0400 Received: (qmail 16478 invoked from network); 28 Mar 2017 12:59:06 -0000 Received: from unknown (HELO [31.133.138.92]) (Authenticated-user:_huitema@huitema.net@[31.133.138.92]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 28 Mar 2017 12:59:06 -0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (14D27) In-Reply-To: Date: Tue, 28 Mar 2017 07:59:05 -0500 Cc: "secdir@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <4F30D2CD-1C40-4D36-95A3-F0196EEDCA27@huitema.net> References: To: Kathleen Moriarty X-Originating-IP: 168.144.250.245 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.04) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49EdlGitVsfXsrKty9N3esIJTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXp4mj+qNG2iDXGL1WWZbJ47RcOb18WfxGyg6Om6u4YYm2MTdluvJRrjaShI +YD0wrE5hjoyEb9Oq0NWpyO3vrfYy2h1mQR50Wwo5hSyeApVLD3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSB0ktSrwQbrgk6jfwMHIN4qnTFgIfDMShmlQFqCr5hA8xAXSGwpLGc/Znuh3MoIpK0HWMuAgJN trN0R8KpG/alc7bRF0J+AL6gRRwFcty0/RGJ+cv73CChOPjKA0/DVd83mzKXD5o/Ia+BqyQ7Q0nt IZ2PVtMHd8bHCmdzlxzVIEgwyGTHIAoNFX+jcW7DGmdE6eBVl9/A6GtGi+mfMSANmgQ9/T0zHbtC pLbhgZ6Z/Qhqxiuap5uKiBpffUsHYsfmkrboF55pyqAvfOP9PRiFk64VFGHGL6a4Aiv0Hpn+svlW gWWsfzmdEBxk/w4+z2XWJKyg1OJH8aak+/hDMnS4uzLQQGIH13szEQZ25LjADnMNMt/iVpWAgKap 6cHjipcLcqiSoo7BxyxRryqmiHuCdUetTZ/25DKDZC7RirBgbePcy8BFh+JufJrwsKmKW6bHd9QD sMspn/O/edVkHySM+ALd1qpS3WRnmoTWbUrkZhjGyf0aq+d/9I/bGpNg5cA+ X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: Re: [secdir] SecDir Lunch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 12:59:20 -0000 I don't see a Studio room in the hotel location map. Where is it? -- Christian Huitema=20 > On Mar 21, 2017, at 3:16 PM, Kathleen Moriarty wrote: >=20 > Hi, >=20 > The SecDir lunch on Tuesday of next week will take place in room: > studio 3. We'll wait until 11:50 to start to give folks a chance to > get food before the meeting. If you have any special topics to > discuss, please let us know. >=20 > Thanks in advance! >=20 > --=20 >=20 > Best regards, > Kathleen >=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 Mar 28 06:50:13 2017 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 DF4B21299E1 for ; Tue, 28 Mar 2017 06:50:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sunet-se.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 erWLwPKHAqGo for ; Tue, 28 Mar 2017 06:50:09 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (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 C23F41201F8 for ; Tue, 28 Mar 2017 06:50:09 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id e75so56666161itd.1 for ; Tue, 28 Mar 2017 06:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sunet-se.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=2NsCxB9KR+3AxTI1pVPRqJTv3UZZguXEMaHlP78/dj8=; b=nr4suevxp6C7L5QJH0W7bKUEOdwgt0auuPpMOG+LT1YZUAeXzj7cV6uBeXqUuJb01Y lZ57n5A/FPV8ElpOtzqWlieZuvM1cQe0hMGg57sl4HppFT6pUTkHAF3WYkvcoepyQpoV o2w5vJ4pabv+yCK+wgpi0g+YBGLduOAN/B2aCQwKWJI0CJnKcGmSAgFCDxkzF7AFdr6M vsn0gF6k4OTwbm4KDQx6Xzcb0enIEG/C9KoN+7Kwu9cbkHoVqB8iXkxhg57yux3G7nz7 G6F0V1GOYHMNJUr/j4aG9caQtLiyvyC1ehCvY3pYuiRrFeVVQm6VkwdleYywzo1gEnBv mFJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=2NsCxB9KR+3AxTI1pVPRqJTv3UZZguXEMaHlP78/dj8=; b=CEBJ8sigsKN1I1MsmVc1aQgGxEnwLO7zLdK63nOX1o1ztdacDr66fpzjgtaKmAO0rt FzWHXJeGnqFI9PZAr3a2STPKBKWK71BrFQGgjCSHFPdrgo7Kfso0vc3HZM3ptCJHKjHT zdmHeHiCcH4Zob6pPpaINUEJATvfY0MxAwdnEUsj3N/vFyPyfyk7MI110UPSieWVICsE QsRByDeiiXP4t05EWWXZgpvNwPfbEcPzJvyKhY/4sXk8Uq5D6Kvj4TpJjjqLNTmG/iyl n2iZkRB34vHIEVEoIVpCTlwAvFC4KU0MVWWLUgT9/v+zHktvqB0zmiO8vAqIkrTVCau3 wWOQ== X-Gm-Message-State: AFeK/H1wAVgJjhMefBxj0HOJSKSYN6mlWojnllqWk/dbjOR8vFSJ21K7FYz66aKrCNeoAw== X-Received: by 10.107.185.135 with SMTP id j129mr25038735iof.3.1490709002986; Tue, 28 Mar 2017 06:50:02 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:5bd:2276:a75e:7a76? (t2001067c0370012805bd2276a75e7a76.v6.meeting.ietf.org. [2001:67c:370:128:5bd:2276:a75e:7a76]) by smtp.gmail.com with ESMTPSA id 17sm1923573ioq.45.2017.03.28.06.50.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 28 Mar 2017 06:50:02 -0700 (PDT) To: secdir@ietf.org References: <4F30D2CD-1C40-4D36-95A3-F0196EEDCA27@huitema.net> From: Leif Johansson Message-ID: <73986826-ebe3-b61f-8099-5a4e67d952ba@sunet.se> Date: Tue, 28 Mar 2017 15:50:02 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <4F30D2CD-1C40-4D36-95A3-F0196EEDCA27@huitema.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [secdir] SecDir Lunch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 13:50:12 -0000 On 2017-03-28 14:59, Christian Huitema wrote: > I don't see a Studio room in the hotel location map. Where is it? > can't find it either... From nobody Tue Mar 28 07:33:51 2017 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 0661112955D for ; Tue, 28 Mar 2017 07:33:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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_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 xAo6ha3sLfYI for ; Tue, 28 Mar 2017 07:33:46 -0700 (PDT) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (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 4277C12954C for ; Tue, 28 Mar 2017 07:33:44 -0700 (PDT) Received: by mail-pg0-x235.google.com with SMTP id g2so73860082pge.3 for ; Tue, 28 Mar 2017 07:33:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iHd/kU4PTNp/YDXKgA8QUjwVgLDfBEhsVU4eelgMPMA=; b=Z8QTuVWPh9bZFgKAUENxq4L/kRZm52VmcW86aGg8a2Anask7CPedbKNT388hi/0csq J3ednYGOR4s/+N2fP/ybSOdxGuI4srcpewNMODkPcIFLeHqv5F08gr0Jj/lN4Bw5cgYE 9K9AhpRIrB5jkoOVAwbvGwq+3eMwh5uZz4c7YHwHSB/FXTBqwWkQm0zN46phn6j4Uts2 Z6nO2Bcu19OKEo4KXvCr0V+jtIiNycVCWrWpv8bO/hHAoaPA0FRoNsrYLOGmffDjnp+b TNVHMcn2nh5UlN4tATfCkX3aotvOth705Z36nUiB9cJIzyPtANnPn5kLsa9Menk+APyf 25fQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iHd/kU4PTNp/YDXKgA8QUjwVgLDfBEhsVU4eelgMPMA=; b=RFVjFMuqirgbbwWXe0yTUx9jkTfVCqZfBijvljK5M5cEptvFRCudvplv4irqGF8MwI BsX7c0pgz3pg2SPPosTTsQAuTXB1Q40XSkNJWlFscXM3eBtpaZI00/vGaF0d28/UbAfU 2OIk6PcssIgXybSOwqqH7ybygpR8o9Lp3fCVW1ktPdmYBUtQcolR8E1eRkZlCclPXvQS +w0jADrbC+432QKSeg3+oJg+FieRxqwM32+VwYP3EfU/q90AXVfTDW4H10teLRUQ29l0 RWXr4O5NM9lMJNZl57ojFiWO+a4HAgXgqgsFp+RTBYhV1e4kHO8BRzIjHuUtDCGVw0NZ qLXA== X-Gm-Message-State: AFeK/H1tOD3Q7SlZ+AxZsJnqLsotgsQMeSSU/GOuI3yzEdrYuztZ7pRC5pnK5cQSvpUY5z031xXPzhw8INNOzg== X-Received: by 10.99.62.4 with SMTP id l4mr30378718pga.172.1490711623923; Tue, 28 Mar 2017 07:33:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.183.98 with HTTP; Tue, 28 Mar 2017 07:33:43 -0700 (PDT) In-Reply-To: <4F30D2CD-1C40-4D36-95A3-F0196EEDCA27@huitema.net> References: <4F30D2CD-1C40-4D36-95A3-F0196EEDCA27@huitema.net> From: Kathleen Moriarty Date: Tue, 28 Mar 2017 10:33:43 -0400 Message-ID: To: Christian Huitema Cc: "secdir@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [secdir] SecDir Lunch X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 14:33:49 -0000 New room: Bianco 3rd floor, IESG sign in front of the door If you have a hot topic, please send it to the list and we'll discuss them in our usual agenda. Thank you, Kathleen On Tue, Mar 28, 2017 at 8:59 AM, Christian Huitema wrote: > I don't see a Studio room in the hotel location map. Where is it? Turns out, it's in Seoul. > > -- Christian Huitema > >> On Mar 21, 2017, at 3:16 PM, Kathleen Moriarty wrote: >> >> Hi, >> >> The SecDir lunch on Tuesday of next week will take place in room: >> studio 3. We'll wait until 11:50 to start to give folks a chance to >> get food before the meeting. If you have any special topics to >> discuss, please let us know. >> >> Thanks in advance! >> >> -- >> >> Best regards, >> Kathleen >> >> _______________________________________________ >> secdir mailing list >> secdir@ietf.org >> https://www.ietf.org/mailman/listinfo/secdir >> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > -- Best regards, Kathleen From nobody Tue Mar 28 09:34:48 2017 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 C2637120724; Tue, 28 Mar 2017 09:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 VP3qpkn_TIXJ; Tue, 28 Mar 2017 09:34:38 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 679E2126DFB; Tue, 28 Mar 2017 09:34:35 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id C36FB28B0041; Tue, 28 Mar 2017 12:34:33 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 2AE6A1F8036; Tue, 28 Mar 2017 12:34:33 -0400 (EDT) From: Sandra Murphy X-Pgp-Agent: GPGMail Content-Type: multipart/signed; boundary="Apple-Mail=_FC2E29DD-1191-43F4-99A0-C3D82E427BCC"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Tue, 28 Mar 2017 12:34:32 -0400 Message-Id: To: secdir@ietf.org, draft-ietf-dnsop-nsec-aggressiveuse@ietf.org, dnsops-chairs@ietf.org, The IETF Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [secdir] secdir review of draft-ietf-dnsop-nsec-aggressiveuse X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Mar 2017 16:34:41 -0000 --Apple-Mail=_FC2E29DD-1191-43F4-99A0-C3D82E427BCC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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 suggests that resolvers should use NSEC/NSEC3 proof of = non-existence for a domain name in a received query to generate a = negative reply, rather than relying on the current spec of an exact = match to the domain name. Generating positive replies from wildcard = answers is also suggested. The motivation is improvements in latency for queriers and improvements = in bandwidth and CPU load on recursive resolvers and validation servers. I have no serious objections about the draft. I am curious about my thought that an attacker might find this of = benefit, as they can learn of non-existence in just one query, rather = than every name in a NSEC denied range. I know zone walking is a concern = to some, but I do not know if ease of determining non-existence is also = a concern. Section 7 explicitly spells out the changes to RFC4035 are explicitly = spelled out as to what is removed and what replaces it. Section 5 is not so = clearly delineated. The last paragraph of 5., nothing in 5.1 or 5.2, and the last paragraph = of 5.3 use SHOUD/MUST/MAY kinds of language. For the paragraphs that don=E2=80=99= t - should they? For the paragraphs that do, is this additional behavior or a replacement for existing spec (i.e. like the section 7 update to = RFC4035). If a replacement, a replacement of what? If not, where do the new = paragraphs fit? The following is a sequential set of comments, not in importance order. page 3 This document updates RFC 4035 to allow recursive resolvers to use NSEC/NSEC3 resource records to synthesize negative answers from the information they have in the cache. re: recursive resolvers - is the technique not applicable to stub = resolvers? (I do see references to stub resolver caches in a web search, but you = can=E2=80=99t trust the web.) [RFC8020], and [I-D.vixie-dnsext-resimprove] proposes first steps to using NXDOMAIN information for more effective caching. This takes this technique further. Unless rfc8020 and the vixie draft are the same thing (don=E2=80=99t = think so), should be =E2=80=9Cpropose=E2=80=9D. Too many uses of =E2=80=9Cthis=E2=80=9D in that last sentence - I = presume you mean This draft takes those previous techniques further. page 4 If a validating resolver receives a query for cat.example.com, it contacts its resolver (which may be itself) Maybe If a validating resolver receives a query for cat.example.com, it contacts its recursive resolver (which may be itself) About: and also has privacy implications (e.g: typos leak out further than necessary). Does it also make certain explorations easier, where someone can find = out a range that does not exist by doing just one query rather than query every name = in the range? Or is that sort of exploration already prevented by other = techniques? If a query is received for leek.example.org, it contacts its resolver (which may be itself) I suggest =E2=80=9Cthe resolver contacts its resolver=E2=80=9D= - the query is not doing the contacting. page 6 section 5.1 and 5.2 say =E2=80=9Cresolver can immediately return=E2=80=9D = - is this meant to specify new behavior, should they have SHOULD/MAY/MUST kinds of = words? page 7 Section 5 of [RFC2308] states that the maximum number of negative cache TTL value is 3 hours (10800). I don=E2=80=99t find a maximum in RFC2308. I do find: Values of one to three hours have been found to work = well and would make sensible a default. Did I miss something? =E2=80=9Cthe maximum number of negative cache TTL value is=E2=80=9D - a = bit twisty. Did you mean something like: Section 5 of [RFC2308] states that the maximum negative cache TTL value = is=E2=80=9D otherwise, I=E2=80=99d think =E2=80=9Cnumber of =E2=80=A6 values=E2=80=9D,= but even so I don=E2=80=99t think there are multiple values here. Are there? page 9 The text says Thanks to Mark Andrews for providing the helpful notes for implementors provided in Appendix B. The authors would like to specifically thank =E2=80=A6 Mark Andrews also provided the helpful notes for implementors (https://www.ietf.org/mail- archive/web/dnsop/current/msg18332.html) which we made into Appendix B. Perhaps you intended to thank him twice? No problem, just wondering. =E2=80=94Sandy --Apple-Mail=_FC2E29DD-1191-43F4-99A0-C3D82E427BCC Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY2pCZAAoJEHplpQeet0IZo3gP/3t/CE2rDgrsON3Amp1fM9w8 0nbnNufy6WSlNKLDy7RSnM9Ej4sThhW15mJxQ5KJSypv3lkxuZ8/4eGrOGwUQswi c/IsSjaRUQhuvJ6UTK7KT/s2RH6rfaBLWFCPrx6H7Xmm3UZhWcNOV1WPR+omCP5f n7qSCmNIGKFWEXSM1Db5Ty6SUbE/sk6M4mVQHs6q0eNxPp8xFfneN9OoVDIyPcUO S4Ql4UE/fV+uiRHIdhgfjf8GX9uQ0JkTZnBoZpAJM7/ByLqs3Z/TPZhKNwemv0D/ /LD5SyilX2M7twpcbIUx/dOKss3oli0DtfRaGCdfb6MmTt01m+2VmAWgbHEJKHTO UbCJ/nLkFpbvMWLVzkW6X38Y3qNlKLtPxmQT9eVku5dqo+xQLTCQoWopI+bx4DRA fgB/+NKX/uQjMrXa19ZXWjQjLKY5Mj/HD4dYCD4Tuvgp24DRf7dJf1q+lpDHQRo3 AxqXE9qKvJ6bHnurxsGZG6O5x5TQ4xEYwLpXe+WNSvz78fRWVbdmlh3s5+mFl97f vozqqSxwtvRQZIZeYM24kXDGiw5jQlT2rFLH4SNXDDbu43kNveYKbsw4WXQqfVVJ d4H6f48r2G91OdEd2MHTc0EjU1uDesGHEMUhIjxStlE7BZmFcadKTU48bxe9yrFU QF/fKyHRoAMMSynlqs4K =6ryT -----END PGP SIGNATURE----- --Apple-Mail=_FC2E29DD-1191-43F4-99A0-C3D82E427BCC-- From nobody Tue Mar 28 21:50:23 2017 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 AFC12129432; Tue, 28 Mar 2017 21:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 3Sqb0hp8jPak; Tue, 28 Mar 2017 21:50:20 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::235]) (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 8FD2D127B31; Tue, 28 Mar 2017 21:50:20 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id o67so2322683oib.1; Tue, 28 Mar 2017 21:50:20 -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=IgzGD9vXh/9qt5I7ls7R/4SdfS1fXigU0FVS1KZd/qo=; b=j/02zG3UBWIdc/aV8XwLAoWLlYu6GJOSn+Yl/slKIo71JylwDLnwNvBfk/Ua1faTzr ODjNjVg9S+3PPnq+L0Uxi/geMcsTiRX7SAqWKndysjS5WU+E7hGv/DiHNGZMubtxwlRx wanKSdDf/Tl+LZfFv9wkiCDE7IkqL42lP8fE/Edwvd08tV0NLr1iQVKEgrM1INAVLA2z qR2oSwpHfeWhKXJf4GbOowra5xlirRzNKzlJaTbI2IUDLCfPX9TfUTaL4Jjlq00Om8Q+ KcJEJd5v6UAB5vr+VwKtcJldEBDXhb9YsyUHOVF2mLbDGLd+klCpCL149S2EiNbM03cO kGzw== 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=IgzGD9vXh/9qt5I7ls7R/4SdfS1fXigU0FVS1KZd/qo=; b=Q/xdqCMmepezhtNlbMz7T3jnAjYxaP0USNi69cuwEOqKlRg2ehVnaQ7FwemdRsDlr8 GzIZgg0l+aiO1z5M3G6IYtLGLse71gLuFmPRADU+twxRZtCQzKDGHEsRud0uPs+qFDHU LznoEUMTo3qzOGANSinNtLvuSn3697OgbWmT/71gI2Y/DyhaSHcRsJ6titATSVTX5VjF NQj0Hrrm5kk44kSVbCjj220nlMyQQitoZwuPLqB8NH9Xlqc9vNM5C92T6JPqzQUocvw+ sHnCt5X+hesMXYS0qftoo5Jo5CBiVJCJvyeqmLNZDffXbx1GAatKSZuMnT/xTC+OORBm RpzQ== X-Gm-Message-State: AFeK/H2jrxBsPfqG0IXjAWt4cDWTr1WP+L+8iOpQQBM/Q2kKofBIH9EvSSldTTQ6BzsBE/mMdnW5Zgu7D0ELjQ== X-Received: by 10.202.72.7 with SMTP id v7mr2214721oia.175.1490763019755; Tue, 28 Mar 2017 21:50:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.146.74 with HTTP; Tue, 28 Mar 2017 21:50:19 -0700 (PDT) From: Radia Perlman Date: Tue, 28 Mar 2017 21:50:19 -0700 Message-ID: To: The IESG , "secdir@ietf.org" , draft-ietf-isis-auto-conf.all@tools.ietf.org Content-Type: multipart/alternative; boundary=001a113db20c3ca83e054bd75025 Archived-At: Subject: [secdir] SECDIR review of draft-ietf-isis-auto-conf-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 04:50:22 -0000 --001a113db20c3ca83e054bd75025 Content-Type: text/plain; charset=UTF-8 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 describes a touchless (autoconfiguring) implementation of IS-IS. I don't have any security comments, but I have some other comments. They use the term "Double-Duplication". I don't know what that is. I think they mean "both the system ID and router fingerprint are duplicated". To me "double duplicate" would be that there were 3 or more systems with the same information. The terminology "NET" and "NSAP" have always been very confusing to most IETF'ers (including me!). Might it be possible to stop using those terms? Of course, it's not fair to pick on this document to start doing that. In the early days of IS-IS, some implementations decided that NET should be the NSAP minus the last byte. Others thought it should be a full size NSAP, but with the last byte 0. The formal ISO definition in CLNP did not clarify this sort of thing, at least to me. Anyway, is there an IETF IS-IS document that explains what NET and NSAPs are, as opposed to saying (as in this document) that "an NET is a type of NSAP", which I find very confusing. In section 3.4.2, it says " Routers operating in auto-configuration mode MUST NOT form adjacencies with routers which are NOT operating in auto-configuration mode. " Why is that? I'd think it would be easier to deploy if you could gradually introduce autoconfiguring routers in with existing implementations that don't know about the A bit. Are you concerned about an actual area 0? Other than those (mostly) editorial comments, which are only suggestions anyway, this is ready for publication. I haven't been following IS-IS recently, and I'm actually surprised that there hasn't been totally autoconfiguring implementations up until now. Radia --001a113db20c3ca83e054bd75025 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have reviewed this docu= ment as part of the security directorate's ongoing effort to review all= IETF documents being processed by the IESG. These comments were written pr= imarily for the benefit of the security area directors. Document editors an= d WG chairs should treat these comments just like any other last call comme= nts.=C2=A0

This docu= ment describes a touchless (autoconfiguring) implementation of IS-IS.=C2=A0= I don't have any security comments, but I have some other comments.

They use the term "Double-Duplication". I don'= t know what that is. I think they mean "both the system ID and router= fingerprint are duplicated". To me "double duplicate" woul= d be that there were 3 or more systems with the same information.

The terminol= ogy "NET" and "NSAP" have always been very confusing to= most IETF'ers (including me!). Might it be possible to stop using thos= e terms? Of course, it's not fair to pick on this document to start do= ing that. In the early days of IS-IS, some implementations decided that NE= T should be the NSAP minus the last byte. Others thought it should be a fu= ll size NSAP, but with the last byte 0. The formal ISO definition in CLNP = did not clarify this sort of thing, at least to me. Anyway, is there an IE= TF IS-IS document that explains what NET and NSAPs are, as opposed to sayin= g (as in this document) that "an NET is a type of NSAP", which I = find very confusing.

In section 3.4.2, it says " Routers operating in auto-configurati= on mode MUST NOT form adjacencies with routers which are NOT operating in auto-configuration mode. &quo= t;
<= br>
= Why is that? I'd think it would be easier to deploy if you could gradu= ally introduce autoconfiguring routers in with existing implementations tha= t don't know about the A bit. Are you concerned about an actual area 0= ?
O= ther than those (mostly) editorial comments, which are only suggestions any= way, this is ready for publication. I haven't been following IS-IS rec= ently, and I'm actually surprised that there hasn't been totally au= toconfiguring implementations up until now.

Radia


--001a113db20c3ca83e054bd75025-- From nobody Wed Mar 29 05:18:25 2017 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 5C5371296CE; Wed, 29 Mar 2017 05:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.521 X-Spam-Level: X-Spam-Status: No, score=-14.521 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, 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 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 zQhG5kMGM5iF; Wed, 29 Mar 2017 05:18:11 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 111761296C8; Wed, 29 Mar 2017 05:18:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=23058; q=dns/txt; s=iport; t=1490789889; x=1491999489; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=fWsppe/+qtxTuNk4yxMGtZlQ+SXJuoK93UmSKMNiCIw=; b=YEZ/VRlDPLe+yh+yEmHp6hMGnsc3oUl8qbBkVP0R5POhSU5PtufKQyJf 9GIHAe0jL2SptoJzVHvyH/krDKc+WReb36w0s2b46LUQ/R37QyFXR4Idc UeM5XZrQQMwCQGqKL+mSGzWlUh2zBnmUsH1UO8Rqb6H3+GY4Fv/Ha59Z4 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DPAQBVpdtY/5tdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm48K2GBCweDW4oRkVCIGIsngg+CDoYiAhqDGz8YAQIBAQEBAQE?= =?us-ascii?q?BayiFFQEBAQEDIwpcAgEIEQQBASgDAgICHxEUCQgCBAESCIgPA4FYAxWtdIImh?= =?us-ascii?q?ysNgxEBAQEBAQEBAQEBAQEBAQEBAQEBAQEdhk6Eb4JRgjmCUIJfBZYQhhY6AY4?= =?us-ascii?q?XhC+RPIpviHoBHziBBFkVhRkdgWN1AYgogQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.36,241,1486425600"; d="scan'208,217";a="401663662" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Mar 2017 12:18:07 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v2TCI7wr025656 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 29 Mar 2017 12:18:07 GMT Received: from xch-aln-001.cisco.com (173.36.7.11) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 29 Mar 2017 07:18:07 -0500 Received: from xch-aln-001.cisco.com ([173.36.7.11]) by XCH-ALN-001.cisco.com ([173.36.7.11]) with mapi id 15.00.1210.000; Wed, 29 Mar 2017 07:18:07 -0500 From: "Les Ginsberg (ginsberg)" To: Radia Perlman , The IESG , "secdir@ietf.org" , "draft-ietf-isis-auto-conf.all@tools.ietf.org" Thread-Topic: SECDIR review of draft-ietf-isis-auto-conf-04 Thread-Index: AQHSqEf+b5kJ8TGx5UCZKC9F5w0LG6GruBzg Date: Wed, 29 Mar 2017 12:18:06 +0000 Message-ID: <12e61a2f6e194bc1822ce377172ddff2@XCH-ALN-001.cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.106.147] Content-Type: multipart/alternative; boundary="_000_12e61a2f6e194bc1822ce377172ddff2XCHALN001ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-isis-auto-conf-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 12:18:14 -0000 --_000_12e61a2f6e194bc1822ce377172ddff2XCHALN001ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmFkaWEg4oCTDQoNClRoYW54IGZvciB0aGUgcmV2aWV3Lg0KUmVzcG9uc2VzIGlubGluZS4NCg0K RnJvbTogUmFkaWEgUGVybG1hbiBbbWFpbHRvOnJhZGlhcGVybG1hbkBnbWFpbC5jb21dDQpTZW50 OiBUdWVzZGF5LCBNYXJjaCAyOCwgMjAxNyA5OjUwIFBNDQpUbzogVGhlIElFU0c7IHNlY2RpckBp ZXRmLm9yZzsgZHJhZnQtaWV0Zi1pc2lzLWF1dG8tY29uZi5hbGxAdG9vbHMuaWV0Zi5vcmcNClN1 YmplY3Q6IFNFQ0RJUiByZXZpZXcgb2YgZHJhZnQtaWV0Zi1pc2lzLWF1dG8tY29uZi0wNA0KDQpJ IGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJl Y3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVp bmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJp bWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuIERv Y3VtZW50IGVkaXRvcnMgYW5kIFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMg anVzdCBsaWtlIGFueSBvdGhlciBsYXN0IGNhbGwgY29tbWVudHMuDQoNClRoaXMgZG9jdW1lbnQg ZGVzY3JpYmVzIGEgdG91Y2hsZXNzIChhdXRvY29uZmlndXJpbmcpIGltcGxlbWVudGF0aW9uIG9m IElTLUlTLiAgSSBkb24ndCBoYXZlIGFueSBzZWN1cml0eSBjb21tZW50cywgYnV0IEkgaGF2ZSBz b21lIG90aGVyIGNvbW1lbnRzLg0KDQpUaGV5IHVzZSB0aGUgdGVybSAiRG91YmxlLUR1cGxpY2F0 aW9uIi4gSSBkb24ndCBrbm93IHdoYXQgdGhhdCBpcy4gSSB0aGluayB0aGV5IG1lYW4gImJvdGgg dGhlIHN5c3RlbSBJRCBhbmQgcm91dGVyIGZpbmdlcnByaW50IGFyZSBkdXBsaWNhdGVkIi4gVG8g bWUgImRvdWJsZSBkdXBsaWNhdGUiIHdvdWxkIGJlIHRoYXQgdGhlcmUgd2VyZSAzIG9yIG1vcmUg c3lzdGVtcyB3aXRoIHRoZSBzYW1lIGluZm9ybWF0aW9uLg0KDQpbTGVzOl0gWW91IGFyZSBjb3Jy ZWN0ICAtIHRoZSB0ZXJtIOKAnGRvdWJsZS1kdXBsaWNhdGlvbuKAnSBtZWFucyBkdXBsaWNhdGUg c3lzdGVtIGlkIEFORCBmaW5nZXJwcmludC4NCkkgd291bGQgYmUgaGFwcHkgdG8gcmVtb3ZlIHRo ZSB0ZXJtIOKAnGRvdWJsZS1kdXBsaWNhdGlvbuKAnSBhbmQgc2ltcGx5IHNheSDigJxkdXBsaWNh dGlvbiBvZiBzeXN0ZW0taWQgYW5kIGZpbmdlcnByaW504oCdLiBJIHRoaW5rIHRoaXMgd291bGQg YmUgY2xhcmlmeWluZy4NCklmIHRoaXMgc2F0aXNmaWVzIHlvdSBhbmQgbXkgY28tYXV0aG9ycyBh Z3JlZSB3ZSBjYW4gbWFrZSB0aGlzIGNoYW5nZS4NCg0KVGhlIHRlcm1pbm9sb2d5ICJORVQiIGFu ZCAiTlNBUCIgaGF2ZSBhbHdheXMgYmVlbiB2ZXJ5IGNvbmZ1c2luZyB0byBtb3N0IElFVEYnZXJz IChpbmNsdWRpbmcgbWUhKS4gTWlnaHQgaXQgYmUgcG9zc2libGUgdG8gc3RvcCB1c2luZyB0aG9z ZSB0ZXJtcz8gT2YgY291cnNlLCBpdCdzIG5vdCBmYWlyIHRvIHBpY2sgb24gdGhpcyBkb2N1bWVu dCB0byBzdGFydCBkb2luZyB0aGF0LiBJbiB0aGUgZWFybHkgZGF5cyBvZiBJUy1JUywgc29tZSBp bXBsZW1lbnRhdGlvbnMgZGVjaWRlZCB0aGF0IE5FVCBzaG91bGQgYmUgdGhlIE5TQVAgbWludXMg dGhlIGxhc3QgYnl0ZS4gT3RoZXJzIHRob3VnaHQgaXQgc2hvdWxkIGJlIGEgZnVsbCBzaXplIE5T QVAsIGJ1dCB3aXRoIHRoZSBsYXN0IGJ5dGUgMC4gVGhlIGZvcm1hbCBJU08gZGVmaW5pdGlvbiBp biBDTE5QIGRpZCBub3QgY2xhcmlmeSB0aGlzIHNvcnQgb2YgdGhpbmcsIGF0IGxlYXN0IHRvIG1l LiBBbnl3YXksIGlzIHRoZXJlIGFuIElFVEYgSVMtSVMgZG9jdW1lbnQgdGhhdCBleHBsYWlucyB3 aGF0IE5FVCBhbmQgTlNBUHMgYXJlLCBhcyBvcHBvc2VkIHRvIHNheWluZyAoYXMgaW4gdGhpcyBk b2N1bWVudCkgdGhhdCAiYW4gTkVUIGlzIGEgdHlwZSBvZiBOU0FQIiwgd2hpY2ggSSBmaW5kIHZl cnkgY29uZnVzaW5nLg0KDQpbTGVzOl0gVGhlIHRlcm1zIGFyZSB1c2VkIGluIElTTyAxMDU4OS4g SSB0aGluayB0aGUgbW9zdCBwcmVjaXNlIHJlZmVyZW5jZSBpcyBJU08gMTA1ODkgU2VjdGlvbiA3 LjEuNToNCg0K4oCcQWxsIG9mIHRoZSBJU+KAmXMgbWFudWFsQXJlYUFkZHJlc3Nlcywgd2hlbiBj b21iaW5lZCB3aXRoIHRoZSBJU+KAmXMgc3lzdGVtSUQsIGFyZSB2YWxpZCBuZXR3b3JrIGVudGl0 eSB0aXRsZXMgZm9yIHRoZSBJUy7igJ0NCg0KSSB0aGluayB0aGUgZHJhZnTigJlzIHVzZSBvZiB0 aGUgdGVybSBpcyBjb25zaXN0ZW50IHdpdGggSVNPIDEwNTg5IGFuZCBJIGFtIG5vdCBpbmNsaW5l ZCB0byBjaGFuZ2UgaXQuDQoNCk9mIGNvdXJzZSB0aGVyZSBpcyBubyBJRVRGIGRvY3VtZW50IHJl Z2FyZGluZyBORVRzL05TQVBzLiBXaHkgd291bGQgd2Ugd2FudCB0byBkZWx2ZSBpbnRvIHN1Y2gg ZGFyayB3YXRlcnM/IOKYug0KDQpJbiBzZWN0aW9uIDMuNC4yLCBpdCBzYXlzICIgUm91dGVycyBv cGVyYXRpbmcgaW4gYXV0by1jb25maWd1cmF0aW9uIG1vZGUgTVVTVCBOT1QgZm9ybSBhZGphY2Vu Y2llcyB3aXRoIHJvdXRlcnMgd2hpY2ggYXJlIE5PVCBvcGVyYXRpbmcgaW4gYXV0by1jb25maWd1 cmF0aW9uIG1vZGUuICINCg0KV2h5IGlzIHRoYXQ/IEknZCB0aGluayBpdCB3b3VsZCBiZSBlYXNp ZXIgdG8gZGVwbG95IGlmIHlvdSBjb3VsZCBncmFkdWFsbHkgaW50cm9kdWNlIGF1dG9jb25maWd1 cmluZyByb3V0ZXJzIGluIHdpdGggZXhpc3RpbmcgaW1wbGVtZW50YXRpb25zIHRoYXQgZG9uJ3Qg a25vdyBhYm91dCB0aGUgQSBiaXQuIEFyZSB5b3UgY29uY2VybmVkIGFib3V0IGFuIGFjdHVhbCBh cmVhIDA/DQoNCltMZXM6XSBUaGUgdGFyZ2V0IGZvciB0aGVzZSBleHRlbnNpb25zIGlzIGRlZmlu ZWQgaW4gU2VjdGlvbiAyOg0KDQrigJxJUy1JUyBhdXRvLWNvbmZpZ3VyYXRpb24gaXMgcHJpbWFy aWx5IGludGVuZGVkIGZvciB1c2UgaW4gc21hbGwgKGkuZS4NCiAgIDEwcyBvZiBkZXZpY2VzKSBh bmQgdW5tYW5hZ2VkIGRlcGxveW1lbnRzLiAgSXQgYWxsb3dzIElTLUlTIHRvIGJlDQogICB1c2Vk IHdpdGhvdXQgdGhlIG5lZWQgZm9yIGFueSBjb25maWd1cmF0aW9uIGJ5IHRoZSB1c2VyLiAgSXQg aXMgbm90DQogICByZWNvbW1lbmRlZCBmb3IgbGFyZ2VyIGRlcGxveW1lbnRzLuKAnQ0KDQpJIHRo aW5rIHRoZXJlIGFyZSBtYW55IGdvb2QgcmVhc29ucyBmb3IgdGhhdCDigJMgdGhlIHByaW1hcnkg b25lIGJlaW5nIHRoYXQgd2hlbiBvbmUgc3RhcnRzIGRlcGxveWluZyBtb3JlIHRoYW4gYSBtaW5p bXVtIHNldCBvZiBmZWF0dXJlcyB0aGVyZSBhcmUgbWFueSBtb3JlIG9wdGlvbnMgYW5kIGl0IGJl Y29tZXMgcHJvYmxlbWF0aWNhbCB0byBzZWxlY3QgYSBkZWZhdWx0IHNldHRpbmcgdGhhbiB3aWxs IGJlIHNhdGlzZmFjdG9yeSBpbiBhbGwgZGVwbG95bWVudHMuIERldGVybWluaW5nIGxldmVsIGlz IG9uZSBlYXN5IGV4YW1wbGUg4oCTIGFzc3VtaW5nIEwxIGlzbuKAmXQgYXBwcm9wcmlhdGUgZm9y IGxhcmdlciBkZXBsb3ltZW50cy4gQXV0b2NvbmZpZyBvZiBhcmVhIGFkZHJlc3MgaXMgYW5vdGhl ci4NCg0KU28gdGhpcyByZXN0cmljdGlvbiBpcyBpbnRlbnRpb25hbC4NCg0KICAgTGVzDQoNCk90 aGVyIHRoYW4gdGhvc2UgKG1vc3RseSkgZWRpdG9yaWFsIGNvbW1lbnRzLCB3aGljaCBhcmUgb25s eSBzdWdnZXN0aW9ucyBhbnl3YXksIHRoaXMgaXMgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLiBJIGhh dmVuJ3QgYmVlbiBmb2xsb3dpbmcgSVMtSVMgcmVjZW50bHksIGFuZCBJJ20gYWN0dWFsbHkgc3Vy cHJpc2VkIHRoYXQgdGhlcmUgaGFzbid0IGJlZW4gdG90YWxseSBhdXRvY29uZmlndXJpbmcgaW1w bGVtZW50YXRpb25zIHVwIHVudGlsIG5vdy4NCg0KUmFkaWENCg0KDQo= --_000_12e61a2f6e194bc1822ce377172ddff2XCHALN001ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIg Lz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVs YXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJF Ti1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlJhZGlhIOKAkzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbnggZm9yIHRoZSByZXZpZXcuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlc3BvbnNlcyBpbmxpbmUuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4g MGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFJhZGlhIFBlcmxtYW4gW21haWx0bzpy YWRpYXBlcmxtYW5AZ21haWwuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE1hcmNo IDI4LCAyMDE3IDk6NTAgUE08YnI+DQo8Yj5Ubzo8L2I+IFRoZSBJRVNHOyBzZWNkaXJAaWV0Zi5v cmc7IGRyYWZ0LWlldGYtaXNpcy1hdXRvLWNvbmYuYWxsQHRvb2xzLmlldGYub3JnPGJyPg0KPGI+ U3ViamVjdDo8L2I+IFNFQ0RJUiByZXZpZXcgb2YgZHJhZnQtaWV0Zi1pc2lzLWF1dG8tY29uZi0w NDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij5JIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVu dCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcgZWZmb3J0IHRv IHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiBU aGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0 aGUgc2VjdXJpdHkNCiBhcmVhIGRpcmVjdG9ycy4gRG9jdW1lbnQgZWRpdG9ycyBhbmQgV0cgY2hh aXJzIHNob3VsZCB0cmVhdCB0aGVzZSBjb21tZW50cyBqdXN0IGxpa2UgYW55IG90aGVyIGxhc3Qg Y2FsbCBjb21tZW50cy4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuNXB0Ij5UaGlzIGRvY3Vt ZW50IGRlc2NyaWJlcyBhIHRvdWNobGVzcyAoYXV0b2NvbmZpZ3VyaW5nKSBpbXBsZW1lbnRhdGlv biBvZiBJUy1JUy4mbmJzcDsgSSBkb24ndCBoYXZlIGFueSBzZWN1cml0eSBjb21tZW50cywgYnV0 IEkgaGF2ZSBzb21lIG90aGVyIGNvbW1lbnRzLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5 LjVwdCI+VGhleSB1c2UgdGhlIHRlcm0gJnF1b3Q7PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+RG91YmxlLUR1cGxpY2F0aW9uJnF1b3Q7LiBJIGRvbid0IGtub3cgd2hhdCB0aGF0IGlz LiBJIHRoaW5rIHRoZXkgbWVhbiAmcXVvdDtib3RoIHRoZSBzeXN0ZW0gSUQgYW5kIHJvdXRlciBm aW5nZXJwcmludCBhcmUgZHVwbGljYXRlZCZxdW90Oy4gVG8gbWUgJnF1b3Q7ZG91YmxlIGR1cGxp Y2F0ZSZxdW90OyB3b3VsZA0KIGJlIHRoYXQgdGhlcmUgd2VyZSAzIG9yIG1vcmUgc3lzdGVtcyB3 aXRoIHRoZSBzYW1lIGluZm9ybWF0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5b TGVzOl0gWW91IGFyZSBjb3JyZWN0ICZuYnNwOy0gdGhlIHRlcm0g4oCcZG91YmxlLWR1cGxpY2F0 aW9u4oCdIG1lYW5zIGR1cGxpY2F0ZSBzeXN0ZW0gaWQgQU5EIGZpbmdlcnByaW50LjxvOnA+PC9v OnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgd291bGQgYmUgaGFwcHkgdG8g cmVtb3ZlIHRoZSB0ZXJtIOKAnGRvdWJsZS1kdXBsaWNhdGlvbuKAnSBhbmQgc2ltcGx5IHNheSDi gJxkdXBsaWNhdGlvbiBvZiBzeXN0ZW0taWQgYW5kIGZpbmdlcnByaW504oCdLiBJIHRoaW5rIHRo aXMgd291bGQgYmUgY2xhcmlmeWluZy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPklmIHRoaXMgc2F0aXNmaWVzIHlvdSBhbmQgbXkgY28tYXV0aG9ycyBhZ3Jl ZSB3ZSBjYW4gbWFrZSB0aGlzIGNoYW5nZS48L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PlRoZSB0ZXJtaW5vbG9neSAmcXVvdDtORVQmcXVvdDsgYW5kICZxdW90O05TQVAmcXVvdDsgaGF2 ZSBhbHdheXMgYmVlbiB2ZXJ5IGNvbmZ1c2luZyB0byBtb3N0IElFVEYnZXJzIChpbmNsdWRpbmcg bWUhKS4gTWlnaHQgaXQgYmUgcG9zc2libGUgdG8gc3RvcCB1c2luZyB0aG9zZSB0ZXJtcz8gT2Yg Y291cnNlLCBpdCdzIG5vdCBmYWlyIHRvIHBpY2sgb24gdGhpcyBkb2N1bWVudCB0byBzdGFydCBk b2luZw0KIHRoYXQuIEluIHRoZSBlYXJseSBkYXlzIG9mIElTLUlTLCBzb21lIGltcGxlbWVudGF0 aW9ucyBkZWNpZGVkIHRoYXQgTkVUIHNob3VsZCBiZSB0aGUgTlNBUCBtaW51cyB0aGUgbGFzdCBi eXRlLiBPdGhlcnMgdGhvdWdodCBpdCBzaG91bGQgYmUgYSBmdWxsIHNpemUgTlNBUCwgYnV0IHdp dGggdGhlIGxhc3QgYnl0ZSAwLiBUaGUgZm9ybWFsIElTTyBkZWZpbml0aW9uIGluIENMTlAgZGlk IG5vdCBjbGFyaWZ5IHRoaXMgc29ydCBvZiB0aGluZywgYXQNCiBsZWFzdCB0byBtZS4gQW55d2F5 LCBpcyB0aGVyZSBhbiBJRVRGIElTLUlTIGRvY3VtZW50IHRoYXQgZXhwbGFpbnMgd2hhdCBORVQg YW5kIE5TQVBzIGFyZSwgYXMgb3Bwb3NlZCB0byBzYXlpbmcgKGFzIGluIHRoaXMgZG9jdW1lbnQp IHRoYXQgJnF1b3Q7YW4gTkVUIGlzIGEgdHlwZSBvZiBOU0FQJnF1b3Q7LCB3aGljaCBJIGZpbmQg dmVyeSBjb25mdXNpbmcuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltMZXM6XSBUaGUgdGVybXMgYXJlIHVz ZWQgaW4gSVNPIDEwNTg5LiBJIHRoaW5rIHRoZSBtb3N0IHByZWNpc2UgcmVmZXJlbmNlIGlzIElT TyAxMDU4OSBTZWN0aW9uIDcuMS41OjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPuKAnEFsbCBvZiB0aGUgSVPigJlzIG1hbnVhbEFyZWFBZGRyZXNzZXMsIHdoZW4gY29tYmlu ZWQgd2l0aCB0aGUgSVPigJlzIHN5c3RlbUlELCBhcmUgdmFsaWQgbmV0d29yayBlbnRpdHkgdGl0 bGVzIGZvciB0aGUgSVMu4oCdPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ SSB0aGluayB0aGUgZHJhZnTigJlzIHVzZSBvZiB0aGUgdGVybSBpcyBjb25zaXN0ZW50IHdpdGgg SVNPIDEwNTg5IGFuZCBJIGFtIG5vdCBpbmNsaW5lZCB0byBjaGFuZ2UgaXQuPG86cD48L286cD48 L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+T2YgY291cnNlIHRoZXJlIGlzIG5vIElFVEYgZG9j dW1lbnQgcmVnYXJkaW5nIE5FVHMvTlNBUHMuIFdoeSB3b3VsZCB3ZSB3YW50IHRvIGRlbHZlIGlu dG8gc3VjaCBkYXJrIHdhdGVycz8NCjwvc3Bhbj48L2k+PC9iPjxiPjxpPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj5KPC9z cGFuPjwvaT48L2I+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+SW4gc2VjdGlvbiAzLjQuMiwgaXQgc2F5cyAmcXVvdDsgUm91 dGVycyBvcGVyYXRpbmcgaW4gYXV0by1jb25maWd1cmF0aW9uIG1vZGUgTVVTVCBOT1QgZm9ybSBh ZGphY2VuY2llcyB3aXRoIHJvdXRlcnMgd2hpY2ggYXJlIE5PVCBvcGVyYXRpbmcgaW4gYXV0by1j b25maWd1cmF0aW9uIG1vZGUuICZxdW90Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5X aHkgaXMgdGhhdD8gSSdkIHRoaW5rIGl0IHdvdWxkIGJlIGVhc2llciB0byBkZXBsb3kgaWYgeW91 IGNvdWxkIGdyYWR1YWxseSBpbnRyb2R1Y2UgYXV0b2NvbmZpZ3VyaW5nIHJvdXRlcnMgaW4gd2l0 aCBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgdGhhdCBkb24ndCBrbm93IGFib3V0IHRoZSBBIGJp dC4gQXJlIHlvdSBjb25jZXJuZWQgYWJvdXQgYW4gYWN0dWFsIGFyZWENCiAwPzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+W0xlczpdIFRoZSB0YXJnZXQgZm9yIHRoZXNlIGV4dGVuc2lvbnMgaXMgZGVmaW5lZCBp biBTZWN0aW9uIDI6PG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS4yNXB0Ij48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+4oCcSVMtSVMgYXV0by1jb25maWd1cmF0aW9uIGlzIHByaW1h cmlseSBpbnRlbmRlZCBmb3IgdXNlIGluIHNtYWxsIChpLmUuPG86cD48L286cD48L3NwYW4+PC9p PjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NS4yNXB0 Ij48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7IDEwcyBvZiBkZXZpY2VzKSBhbmQgdW5tYW5hZ2VkIGRlcGxveW1lbnRzLiZuYnNwOyBJ dCBhbGxvd3MgSVMtSVMgdG8gYmU8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1LjI1cHQiPjxiPjxpPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgdXNlZCB3aXRo b3V0IHRoZSBuZWVkIGZvciBhbnkgY29uZmlndXJhdGlvbiBieSB0aGUgdXNlci4mbmJzcDsgSXQg aXMgbm90PG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7 Jm5ic3A7IHJlY29tbWVuZGVkIGZvciBsYXJnZXIgZGVwbG95bWVudHMu4oCdPG86cD48L286cD48 L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayB0aGVyZSBhcmUgbWFueSBnb29kIHJl YXNvbnMgZm9yIHRoYXQg4oCTIHRoZSBwcmltYXJ5IG9uZSBiZWluZyB0aGF0IHdoZW4gb25lIHN0 YXJ0cyBkZXBsb3lpbmcgbW9yZSB0aGFuIGEgbWluaW11bSBzZXQgb2YgZmVhdHVyZXMgdGhlcmUg YXJlIG1hbnkNCiBtb3JlIG9wdGlvbnMgYW5kIGl0IGJlY29tZXMgcHJvYmxlbWF0aWNhbCB0byBz ZWxlY3QgYSBkZWZhdWx0IHNldHRpbmcgdGhhbiB3aWxsIGJlIHNhdGlzZmFjdG9yeSBpbiBhbGwg ZGVwbG95bWVudHMuIERldGVybWluaW5nIGxldmVsIGlzIG9uZSBlYXN5IGV4YW1wbGUg4oCTIGFz c3VtaW5nIEwxIGlzbuKAmXQgYXBwcm9wcmlhdGUgZm9yIGxhcmdlciBkZXBsb3ltZW50cy4gQXV0 b2NvbmZpZyBvZiBhcmVhIGFkZHJlc3MgaXMgYW5vdGhlci48bzpwPjwvbzpwPjwvc3Bhbj48L2k+ PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5TbyB0aGlzIHJlc3RyaWN0aW9uIGlzIGludGVudGlvbmFsLjxvOnA+ PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBMZXM8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5PdGhl ciB0aGFuIHRob3NlIChtb3N0bHkpIGVkaXRvcmlhbCBjb21tZW50cywgd2hpY2ggYXJlIG9ubHkg c3VnZ2VzdGlvbnMgYW55d2F5LCB0aGlzIGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbi4gSSBoYXZl bid0IGJlZW4gZm9sbG93aW5nIElTLUlTIHJlY2VudGx5LCBhbmQgSSdtIGFjdHVhbGx5IHN1cnBy aXNlZCB0aGF0IHRoZXJlIGhhc24ndCBiZWVuIHRvdGFsbHkNCiBhdXRvY29uZmlndXJpbmcgaW1w bGVtZW50YXRpb25zIHVwIHVudGlsIG5vdy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ UmFkaWE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_12e61a2f6e194bc1822ce377172ddff2XCHALN001ciscocom_-- From nobody Wed Mar 29 08:34:18 2017 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 B1176128D19; Wed, 29 Mar 2017 08:34:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 sPahGK596_re; Wed, 29 Mar 2017 08:34:11 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E5D741296DF; Wed, 29 Mar 2017 08:33:52 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJX40253; Wed, 29 Mar 2017 15:33:51 +0000 (GMT) Received: from NKGEML414-HUB.china.huawei.com (10.98.56.75) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 29 Mar 2017 16:33:49 +0100 Received: from NKGEML514-MBS.china.huawei.com ([169.254.3.121]) by nkgeml414-hub.china.huawei.com ([10.98.56.75]) with mapi id 14.03.0235.001; Wed, 29 Mar 2017 23:33:43 +0800 From: "Liubing (Leo)" To: "Les Ginsberg (ginsberg)" , Radia Perlman , The IESG , "secdir@ietf.org" , "draft-ietf-isis-auto-conf.all@tools.ietf.org" Thread-Topic: SECDIR review of draft-ietf-isis-auto-conf-04 Thread-Index: AQHSqEgBchmj9rhmrk6XlusEIpAsTKGrNl4AgACzaPA= Date: Wed, 29 Mar 2017 15:33:41 +0000 Message-ID: <8AE0F17B87264D4CAC7DE0AA6C406F45C2ED09C5@nkgeml514-mbs.china.huawei.com> References: <12e61a2f6e194bc1822ce377172ddff2@XCH-ALN-001.cisco.com> In-Reply-To: <12e61a2f6e194bc1822ce377172ddff2@XCH-ALN-001.cisco.com> Accept-Language: en-US, zh-CN Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.151.156] Content-Type: multipart/alternative; boundary="_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2ED09C5nkgeml514mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.58DBD3DF.0230, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.121, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 076e1e6c0b7201eaf94880c6f192ae9f Archived-At: Subject: Re: [secdir] SECDIR review of draft-ietf-isis-auto-conf-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Mar 2017 15:34:15 -0000 --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2ED09C5nkgeml514mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIGZvciBSYWRpYeKAmXMgcmV2aWV3IGFuZCBjb21tZW50cyBhZ2Fpbi4NCkZldyBtaW5v ciBjb21tZW50cyBpbmxpbmUsIHN0YXJ0aW5nIHdpdGgg4oCcW0Jpbmdd4oCdLg0KDQpGcm9tOiBM ZXMgR2luc2JlcmcgKGdpbnNiZXJnKSBbbWFpbHRvOmdpbnNiZXJnQGNpc2NvLmNvbV0NClNlbnQ6 IFdlZG5lc2RheSwgTWFyY2ggMjksIDIwMTcgNzoxOCBBTQ0KVG86IFJhZGlhIFBlcmxtYW47IFRo ZSBJRVNHOyBzZWNkaXJAaWV0Zi5vcmc7IGRyYWZ0LWlldGYtaXNpcy1hdXRvLWNvbmYuYWxsQHRv b2xzLmlldGYub3JnDQpTdWJqZWN0OiBSRTogU0VDRElSIHJldmlldyBvZiBkcmFmdC1pZXRmLWlz aXMtYXV0by1jb25mLTA0DQoNClJhZGlhIOKAkw0KDQpUaGFueCBmb3IgdGhlIHJldmlldy4NClJl c3BvbnNlcyBpbmxpbmUuDQoNCkZyb206IFJhZGlhIFBlcmxtYW4gW21haWx0bzpyYWRpYXBlcmxt YW5AZ21haWwuY29tXQ0KU2VudDogVHVlc2RheSwgTWFyY2ggMjgsIDIwMTcgOTo1MCBQTQ0KVG86 IFRoZSBJRVNHOyBzZWNkaXJAaWV0Zi5vcmc8bWFpbHRvOnNlY2RpckBpZXRmLm9yZz47IGRyYWZ0 LWlldGYtaXNpcy1hdXRvLWNvbmYuYWxsQHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRm LWlzaXMtYXV0by1jb25mLmFsbEB0b29scy5pZXRmLm9yZz4NClN1YmplY3Q6IFNFQ0RJUiByZXZp ZXcgb2YgZHJhZnQtaWV0Zi1pc2lzLWF1dG8tY29uZi0wNA0KDQpJIGhhdmUgcmV2aWV3ZWQgdGhp cyBkb2N1bWVudCBhcyBwYXJ0IG9mIHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZSdzIG9uZ29pbmcg ZWZmb3J0IHRvIHJldmlldyBhbGwgSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRo ZSBJRVNHLiBUaGVzZSBjb21tZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVu ZWZpdCBvZiB0aGUgc2VjdXJpdHkgYXJlYSBkaXJlY3RvcnMuIERvY3VtZW50IGVkaXRvcnMgYW5k IFdHIGNoYWlycyBzaG91bGQgdHJlYXQgdGhlc2UgY29tbWVudHMganVzdCBsaWtlIGFueSBvdGhl ciBsYXN0IGNhbGwgY29tbWVudHMuDQoNClRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIGEgdG91Y2hs ZXNzIChhdXRvY29uZmlndXJpbmcpIGltcGxlbWVudGF0aW9uIG9mIElTLUlTLiAgSSBkb24ndCBo YXZlIGFueSBzZWN1cml0eSBjb21tZW50cywgYnV0IEkgaGF2ZSBzb21lIG90aGVyIGNvbW1lbnRz Lg0KDQpUaGV5IHVzZSB0aGUgdGVybSAiRG91YmxlLUR1cGxpY2F0aW9uIi4gSSBkb24ndCBrbm93 IHdoYXQgdGhhdCBpcy4gSSB0aGluayB0aGV5IG1lYW4gImJvdGggdGhlIHN5c3RlbSBJRCBhbmQg cm91dGVyIGZpbmdlcnByaW50IGFyZSBkdXBsaWNhdGVkIi4gVG8gbWUgImRvdWJsZSBkdXBsaWNh dGUiIHdvdWxkIGJlIHRoYXQgdGhlcmUgd2VyZSAzIG9yIG1vcmUgc3lzdGVtcyB3aXRoIHRoZSBz YW1lIGluZm9ybWF0aW9uLg0KDQpbTGVzOl0gWW91IGFyZSBjb3JyZWN0ICAtIHRoZSB0ZXJtIOKA nGRvdWJsZS1kdXBsaWNhdGlvbuKAnSBtZWFucyBkdXBsaWNhdGUgc3lzdGVtIGlkIEFORCBmaW5n ZXJwcmludC4NCkkgd291bGQgYmUgaGFwcHkgdG8gcmVtb3ZlIHRoZSB0ZXJtIOKAnGRvdWJsZS1k dXBsaWNhdGlvbuKAnSBhbmQgc2ltcGx5IHNheSDigJxkdXBsaWNhdGlvbiBvZiBzeXN0ZW0taWQg YW5kIGZpbmdlcnByaW504oCdLiBJIHRoaW5rIHRoaXMgd291bGQgYmUgY2xhcmlmeWluZy4NCklm IHRoaXMgc2F0aXNmaWVzIHlvdSBhbmQgbXkgY28tYXV0aG9ycyBhZ3JlZSB3ZSBjYW4gbWFrZSB0 aGlzIGNoYW5nZS4NCg0KW0JpbmddIEFzIGEgY28tYXV0aG9yLCBJIGFsc28gYWdyZWUgdG8gY2hh bmdlIGl0IHRvIOKAnGR1cGxpY2F0aW9uIG9mIHN5c3RlbS1pZCBhbmQgZmluZ2VycHJpbnTigJ0s IHdoaWNoIGNvdWxkIGVsaW1pbmF0ZSBjb25mdXNpb24uDQoNClRoZSB0ZXJtaW5vbG9neSAiTkVU IiBhbmQgIk5TQVAiIGhhdmUgYWx3YXlzIGJlZW4gdmVyeSBjb25mdXNpbmcgdG8gbW9zdCBJRVRG J2VycyAoaW5jbHVkaW5nIG1lISkuIE1pZ2h0IGl0IGJlIHBvc3NpYmxlIHRvIHN0b3AgdXNpbmcg dGhvc2UgdGVybXM/IE9mIGNvdXJzZSwgaXQncyBub3QgZmFpciB0byBwaWNrIG9uIHRoaXMgZG9j dW1lbnQgdG8gc3RhcnQgZG9pbmcgdGhhdC4gSW4gdGhlIGVhcmx5IGRheXMgb2YgSVMtSVMsIHNv bWUgaW1wbGVtZW50YXRpb25zIGRlY2lkZWQgdGhhdCBORVQgc2hvdWxkIGJlIHRoZSBOU0FQIG1p bnVzIHRoZSBsYXN0IGJ5dGUuIE90aGVycyB0aG91Z2h0IGl0IHNob3VsZCBiZSBhIGZ1bGwgc2l6 ZSBOU0FQLCBidXQgd2l0aCB0aGUgbGFzdCBieXRlIDAuIFRoZSBmb3JtYWwgSVNPIGRlZmluaXRp b24gaW4gQ0xOUCBkaWQgbm90IGNsYXJpZnkgdGhpcyBzb3J0IG9mIHRoaW5nLCBhdCBsZWFzdCB0 byBtZS4gQW55d2F5LCBpcyB0aGVyZSBhbiBJRVRGIElTLUlTIGRvY3VtZW50IHRoYXQgZXhwbGFp bnMgd2hhdCBORVQgYW5kIE5TQVBzIGFyZSwgYXMgb3Bwb3NlZCB0byBzYXlpbmcgKGFzIGluIHRo aXMgZG9jdW1lbnQpIHRoYXQgImFuIE5FVCBpcyBhIHR5cGUgb2YgTlNBUCIsIHdoaWNoIEkgZmlu ZCB2ZXJ5IGNvbmZ1c2luZy4NCg0KW0xlczpdIFRoZSB0ZXJtcyBhcmUgdXNlZCBpbiBJU08gMTA1 ODkuIEkgdGhpbmsgdGhlIG1vc3QgcHJlY2lzZSByZWZlcmVuY2UgaXMgSVNPIDEwNTg5IFNlY3Rp b24gNy4xLjU6DQoNCuKAnEFsbCBvZiB0aGUgSVPigJlzIG1hbnVhbEFyZWFBZGRyZXNzZXMsIHdo ZW4gY29tYmluZWQgd2l0aCB0aGUgSVPigJlzIHN5c3RlbUlELCBhcmUgdmFsaWQgbmV0d29yayBl bnRpdHkgdGl0bGVzIGZvciB0aGUgSVMu4oCdDQoNCkkgdGhpbmsgdGhlIGRyYWZ04oCZcyB1c2Ug b2YgdGhlIHRlcm0gaXMgY29uc2lzdGVudCB3aXRoIElTTyAxMDU4OSBhbmQgSSBhbSBub3QgaW5j bGluZWQgdG8gY2hhbmdlIGl0Lg0KDQpPZiBjb3Vyc2UgdGhlcmUgaXMgbm8gSUVURiBkb2N1bWVu dCByZWdhcmRpbmcgTkVUcy9OU0FQcy4gV2h5IHdvdWxkIHdlIHdhbnQgdG8gZGVsdmUgaW50byBz dWNoIGRhcmsgd2F0ZXJzPyDimLoNCg0KSW4gc2VjdGlvbiAzLjQuMiwgaXQgc2F5cyAiIFJvdXRl cnMgb3BlcmF0aW5nIGluIGF1dG8tY29uZmlndXJhdGlvbiBtb2RlIE1VU1QgTk9UIGZvcm0gYWRq YWNlbmNpZXMgd2l0aCByb3V0ZXJzIHdoaWNoIGFyZSBOT1Qgb3BlcmF0aW5nIGluIGF1dG8tY29u ZmlndXJhdGlvbiBtb2RlLiAiDQoNCldoeSBpcyB0aGF0PyBJJ2QgdGhpbmsgaXQgd291bGQgYmUg ZWFzaWVyIHRvIGRlcGxveSBpZiB5b3UgY291bGQgZ3JhZHVhbGx5IGludHJvZHVjZSBhdXRvY29u ZmlndXJpbmcgcm91dGVycyBpbiB3aXRoIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyB0aGF0IGRv bid0IGtub3cgYWJvdXQgdGhlIEEgYml0LiBBcmUgeW91IGNvbmNlcm5lZCBhYm91dCBhbiBhY3R1 YWwgYXJlYSAwPw0KDQpbTGVzOl0gVGhlIHRhcmdldCBmb3IgdGhlc2UgZXh0ZW5zaW9ucyBpcyBk ZWZpbmVkIGluIFNlY3Rpb24gMjoNCg0K4oCcSVMtSVMgYXV0by1jb25maWd1cmF0aW9uIGlzIHBy aW1hcmlseSBpbnRlbmRlZCBmb3IgdXNlIGluIHNtYWxsIChpLmUuDQogICAxMHMgb2YgZGV2aWNl cykgYW5kIHVubWFuYWdlZCBkZXBsb3ltZW50cy4gIEl0IGFsbG93cyBJUy1JUyB0byBiZQ0KICAg dXNlZCB3aXRob3V0IHRoZSBuZWVkIGZvciBhbnkgY29uZmlndXJhdGlvbiBieSB0aGUgdXNlci4g IEl0IGlzIG5vdA0KICAgcmVjb21tZW5kZWQgZm9yIGxhcmdlciBkZXBsb3ltZW50cy7igJ0NCg0K SSB0aGluayB0aGVyZSBhcmUgbWFueSBnb29kIHJlYXNvbnMgZm9yIHRoYXQg4oCTIHRoZSBwcmlt YXJ5IG9uZSBiZWluZyB0aGF0IHdoZW4gb25lIHN0YXJ0cyBkZXBsb3lpbmcgbW9yZSB0aGFuIGEg bWluaW11bSBzZXQgb2YgZmVhdHVyZXMgdGhlcmUgYXJlIG1hbnkgbW9yZSBvcHRpb25zIGFuZCBp dCBiZWNvbWVzIHByb2JsZW1hdGljYWwgdG8gc2VsZWN0IGEgZGVmYXVsdCBzZXR0aW5nIHRoYW4g d2lsbCBiZSBzYXRpc2ZhY3RvcnkgaW4gYWxsIGRlcGxveW1lbnRzLiBEZXRlcm1pbmluZyBsZXZl bCBpcyBvbmUgZWFzeSBleGFtcGxlIOKAkyBhc3N1bWluZyBMMSBpc27igJl0IGFwcHJvcHJpYXRl IGZvciBsYXJnZXIgZGVwbG95bWVudHMuIEF1dG9jb25maWcgb2YgYXJlYSBhZGRyZXNzIGlzIGFu b3RoZXIuDQoNClNvIHRoaXMgcmVzdHJpY3Rpb24gaXMgaW50ZW50aW9uYWwuDQoNCltCaW5nXSBB cyBMZXMgc2FpZCwgdGhpcyByZXN0cmljdGlvbiBpcyBpbnRlbnRpb25hbC4gQXQgdGhlIGJlZ2lu bmluZywgd2UgYWN0dWFsbHkgdGhvdWdodCBhYm91dCB0aGUgcG9zc2liaWxpdGllcyBvZiB1c2lu ZyB0aGUgYXV0by1jb25mIG1lY2hhbmlzbSBub3Qgb25seSBpbiBzbWFsbCBuZXR3b3Jrcy4gQnV0 IGxhdGVyIHdlIGFncmVlZCB0aGF0IGl0IG1pZ2h0IGJlIGJldHRlciB0byBiZSBsZXNzIGFtYml0 aW91cyB0aGF0IHRvIGd1YXJhbnRlZSBpdCBjYW4gZG8gdGhlIGpvYiB3ZWxsIGZvciBzbWFsbCBu ZXR3b3JrcyBmaXJzdC4gIEZvciBpbmNyZW1lbnRhbCBkZXBsb3ltZW50IGFuZCBsYXJnZXIgZGVw bG95bWVudCwgdGhlc2UgYXJlIGRlZmluaXRlbHkgc29tZSBpbnRlcmVzdGluZyBwcm9ibGVtcyB0 byBiZSBzb2x2ZWQuIElmIHdlIGNvdWxkIGZpZ3VyZSBvdXQgc29tZSBnb29kIGlkZWFzIGluIHRo ZSBmdXR1cmUsIHdlIGNhbiBjb25zaWRlciB0byBpbml0aWF0ZSBzb21lIG5ldyB3b3JrLg0KDQog ICBMZXMNCg0KT3RoZXIgdGhhbiB0aG9zZSAobW9zdGx5KSBlZGl0b3JpYWwgY29tbWVudHMsIHdo aWNoIGFyZSBvbmx5IHN1Z2dlc3Rpb25zIGFueXdheSwgdGhpcyBpcyByZWFkeSBmb3IgcHVibGlj YXRpb24uIEkgaGF2ZW4ndCBiZWVuIGZvbGxvd2luZyBJUy1JUyByZWNlbnRseSwgYW5kIEknbSBh Y3R1YWxseSBzdXJwcmlzZWQgdGhhdCB0aGVyZSBoYXNuJ3QgYmVlbiB0b3RhbGx5IGF1dG9jb25m aWd1cmluZyBpbXBsZW1lbnRhdGlvbnMgdXAgdW50aWwgbm93Lg0KW0JpbmddIFRoZXJlIGlzIGFu IG9wZW4gc291cmNlIGltcGxlbWVudGF0aW9uLCB3aGljaCBpcyBiYXNlZCBvbiBhbiBlYXJsaWVy IHZlcnNpb24gb2YgdGhpcyBkb2N1bWVudCwgYW5kIGludGVncmF0aW5nIHNvdXJjZSByb3V0aW5n IGZ1bmN0aW9uIGZvciBob21lIG5ldHdvcmsgc2NlbmFyaW9zLiBMaW5rOiBodHRwczovL2dpdC11 cy5uZXRkZWYub3JnL3Byb2plY3RzL09TUi9yZXBvcy9vcGVud3J0LWlzaXMtaG5ldC9jb21taXRz IC4NCg0KQmVzdCByZWdhcmRzLA0KQmluZw0KDQpSYWRpYQ0KDQoNCg== --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2ED09C5nkgeml514mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 VGFob21hOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7 Zm9udC1mYW1pbHk6IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0Fj ZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5 bGUtbGluazoi5om55rOo5qGG5paH5pysIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo5LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFw aCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdp bjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCXRleHQtaW5kZW50OjIxLjBwdDsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkNoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IuaJueazqOahhuaWh+acrCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms65om55rOo5qGG5paH5pysOw0KCWZvbnQtZmFtaWx5OuWu i+S9kzt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzky LjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2Vj dGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxp c3QgbDANCgl7bXNvLWxpc3QtaWQ6NTgwNjc2MDI1Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0K CW1zby1saXN0LXRlbXBsYXRlLWlkczoxODkyMDA3NjYgLTQ4MDA3MDk0MiA2NzY5ODY5MSA2NzY5 ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5 Mzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJbWFyZ2lu LWxlZnQ6MTguMHB0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjVwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1p bHk65a6L5L2TOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iOw0KCWNv bG9yOiMxRjQ5N0Q7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJv dHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl ZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0t LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1s PjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iWkgtQ04iIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+VGhhbmtzIGZvciBSYWRpYeKAmXMgcmV2aWV3IGFuZCBjb21tZW50cyBhZ2Fpbi4NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+RmV3IG1pbm9yIGNvbW1l bnRzIGlubGluZSwgc3RhcnRpbmcgd2l0aCDigJxbQmluZ13igJ0uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTGVzIEdpbnNiZXJnIChn aW5zYmVyZykgW21haWx0bzpnaW5zYmVyZ0BjaXNjby5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4g V2VkbmVzZGF5LCBNYXJjaCAyOSwgMjAxNyA3OjE4IEFNPGJyPg0KPGI+VG86PC9iPiBSYWRpYSBQ ZXJsbWFuOyBUaGUgSUVTRzsgc2VjZGlyQGlldGYub3JnOyBkcmFmdC1pZXRmLWlzaXMtYXV0by1j b25mLmFsbEB0b29scy5pZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogU0VDRElSIHJl dmlldyBvZiBkcmFmdC1pZXRmLWlzaXMtYXV0by1jb25mLTA0PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJhZGlh IOKAkzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFueCBmb3IgdGhlIHJl dmlldy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJlc3BvbnNl cyBpbmxpbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFJhZGlhIFBlcmxtYW4gWzxhIGhy ZWY9Im1haWx0bzpyYWRpYXBlcmxtYW5AZ21haWwuY29tIj5tYWlsdG86cmFkaWFwZXJsbWFuQGdt YWlsLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTWFyY2ggMjgsIDIwMTcg OTo1MCBQTTxicj4NCjxiPlRvOjwvYj4gVGhlIElFU0c7IDxhIGhyZWY9Im1haWx0bzpzZWNkaXJA aWV0Zi5vcmciPnNlY2RpckBpZXRmLm9yZzwvYT47IDxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRm LWlzaXMtYXV0by1jb25mLmFsbEB0b29scy5pZXRmLm9yZyI+DQpkcmFmdC1pZXRmLWlzaXMtYXV0 by1jb25mLmFsbEB0b29scy5pZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gU0VDRElS IHJldmlldyBvZiBkcmFmdC1pZXRmLWlzaXMtYXV0by1jb25mLTA0PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6OS41cHQiPkkgaGF2ZSBy ZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFzIHBhcnQgb2YgdGhlIHNlY3VyaXR5IGRpcmVjdG9yYXRl J3Mgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFsbCBJRVRGIGRvY3VtZW50cyBiZWluZyBwcm9j ZXNzZWQgYnkgdGhlIElFU0cuIFRoZXNlIGNvbW1lbnRzIHdlcmUgd3JpdHRlbiBwcmltYXJpbHkg Zm9yIHRoZSBiZW5lZml0DQogb2YgdGhlIHNlY3VyaXR5IGFyZWEgZGlyZWN0b3JzLiBEb2N1bWVu dCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxkIHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3Qg bGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1lbnRzLiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZTo5LjVwdCI+VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSB0b3VjaGxlc3MgKGF1 dG9jb25maWd1cmluZykgaW1wbGVtZW50YXRpb24gb2YgSVMtSVMuJm5ic3A7IEkgZG9uJ3QgaGF2 ZSBhbnkgc2VjdXJpdHkgY29tbWVudHMsIGJ1dCBJIGhhdmUgc29tZSBvdGhlciBjb21tZW50cy48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjVwdCI+VGhleSB1c2UgdGhlIHRl cm0gJnF1b3Q7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6YmxhY2siPkRv dWJsZS1EdXBsaWNhdGlvbiZxdW90Oy4gSSBkb24ndCBrbm93IHdoYXQgdGhhdCBpcy4gSSB0aGlu ayB0aGV5IG1lYW4gJnF1b3Q7Ym90aCB0aGUgc3lzdGVtIElEIGFuZCByb3V0ZXIgZmluZ2VycHJp bnQgYXJlIGR1cGxpY2F0ZWQmcXVvdDsuIFRvDQogbWUgJnF1b3Q7ZG91YmxlIGR1cGxpY2F0ZSZx dW90OyB3b3VsZCBiZSB0aGF0IHRoZXJlIHdlcmUgMyBvciBtb3JlIHN5c3RlbXMgd2l0aCB0aGUg c2FtZSBpbmZvcm1hdGlvbi48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltMZXM6XSBZb3UgYXJl IGNvcnJlY3QgJm5ic3A7LSB0aGUgdGVybSDigJxkb3VibGUtZHVwbGljYXRpb27igJ0gbWVhbnMg ZHVwbGljYXRlIHN5c3RlbSBpZCBBTkQgZmluZ2VycHJpbnQuPG86cD48L286cD48L3NwYW4+PC9p PjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgd291bGQgYmUgaGFwcHkgdG8g cmVtb3ZlIHRoZSB0ZXJtIOKAnGRvdWJsZS1kdXBsaWNhdGlvbuKAnSBhbmQgc2ltcGx5IHNheSDi gJxkdXBsaWNhdGlvbiBvZiBzeXN0ZW0taWQgYW5kIGZpbmdlcnByaW504oCdLiBJIHRoaW5rIHRo aXMgd291bGQgYmUNCiBjbGFyaWZ5aW5nLiA8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYgdGhpcyBzYXRpc2ZpZXMgeW91IGFuZCBteSBj by1hdXRob3JzIGFncmVlIHdlIGNhbiBtYWtlIHRoaXMgY2hhbmdlLjxvOnA+PC9vOnA+PC9zcGFu PjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPltCaW5nXSBBcyBhIGNvLWF1dGhvciwgSSBhbHNv IGFncmVlIHRvIGNoYW5nZSBpdCB0byDigJxkdXBsaWNhdGlvbiBvZiBzeXN0ZW0taWQgYW5kIGZp bmdlcnByaW504oCdLCB3aGljaCBjb3VsZCBlbGltaW5hdGUgY29uZnVzaW9uLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNr Ij5UaGUgdGVybWlub2xvZ3kgJnF1b3Q7TkVUJnF1b3Q7IGFuZCAmcXVvdDtOU0FQJnF1b3Q7IGhh dmUgYWx3YXlzIGJlZW4gdmVyeSBjb25mdXNpbmcgdG8gbW9zdCBJRVRGJ2VycyAoaW5jbHVkaW5n IG1lISkuIE1pZ2h0IGl0IGJlIHBvc3NpYmxlIHRvIHN0b3AgdXNpbmcgdGhvc2UgdGVybXM/IE9m IGNvdXJzZSwgaXQncyBub3QgZmFpciB0byBwaWNrIG9uIHRoaXMgZG9jdW1lbnQNCiB0byBzdGFy dCBkb2luZyB0aGF0LiBJbiB0aGUgZWFybHkgZGF5cyBvZiBJUy1JUywgc29tZSBpbXBsZW1lbnRh dGlvbnMgZGVjaWRlZCB0aGF0IE5FVCBzaG91bGQgYmUgdGhlIE5TQVAgbWludXMgdGhlIGxhc3Qg Ynl0ZS4gT3RoZXJzIHRob3VnaHQgaXQgc2hvdWxkIGJlIGEgZnVsbCBzaXplIE5TQVAsIGJ1dCB3 aXRoIHRoZSBsYXN0IGJ5dGUgMC4gVGhlIGZvcm1hbCBJU08gZGVmaW5pdGlvbiBpbiBDTE5QIGRp ZCBub3QgY2xhcmlmeSB0aGlzIHNvcnQNCiBvZiB0aGluZywgYXQgbGVhc3QgdG8gbWUuIEFueXdh eSwgaXMgdGhlcmUgYW4gSUVURiBJUy1JUyBkb2N1bWVudCB0aGF0IGV4cGxhaW5zIHdoYXQgTkVU IGFuZCBOU0FQcyBhcmUsIGFzIG9wcG9zZWQgdG8gc2F5aW5nIChhcyBpbiB0aGlzIGRvY3VtZW50 KSB0aGF0ICZxdW90O2FuIE5FVCBpcyBhIHR5cGUgb2YgTlNBUCZxdW90Oywgd2hpY2ggSSBmaW5k IHZlcnkgY29uZnVzaW5nLg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0xlczpdIFRoZSB0ZXJtcyBhcmUgdXNlZCBp biBJU08gMTA1ODkuIEkgdGhpbmsgdGhlIG1vc3QgcHJlY2lzZSByZWZlcmVuY2UgaXMgSVNPIDEw NTg5IFNlY3Rpb24gNy4xLjU6PG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj7igJxBbGwgb2YgdGhlIElT4oCZcyBtYW51YWxBcmVh QWRkcmVzc2VzLCB3aGVuIGNvbWJpbmVkIHdpdGggdGhlIElT4oCZcyBzeXN0ZW1JRCwgYXJlIHZh bGlkIG5ldHdvcmsgZW50aXR5IHRpdGxlcyBmb3IgdGhlIElTLuKAnTxvOnA+PC9vOnA+PC9zcGFu PjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB0aGluayB0 aGUgZHJhZnTigJlzIHVzZSBvZiB0aGUgdGVybSBpcyBjb25zaXN0ZW50IHdpdGggSVNPIDEwNTg5 IGFuZCBJIGFtIG5vdCBpbmNsaW5lZCB0byBjaGFuZ2UgaXQuPG86cD48L286cD48L3NwYW4+PC9p PjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5PZiBjb3Vyc2UgdGhl cmUgaXMgbm8gSUVURiBkb2N1bWVudCByZWdhcmRpbmcgTkVUcy9OU0FQcy4gV2h5IHdvdWxkIHdl IHdhbnQgdG8gZGVsdmUgaW50byBzdWNoIGRhcmsgd2F0ZXJzPw0KPC9zcGFuPjwvaT48L2I+PGI+ PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj5KPC9zcGFuPjwvaT48L2I+PGI+PGk+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpw Pjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjpibGFjayI+SW4gc2VjdGlvbiAzLjQuMiwgaXQgc2F5 cyAmcXVvdDsgUm91dGVycyBvcGVyYXRpbmcgaW4gYXV0by1jb25maWd1cmF0aW9uIG1vZGUgTVVT VCBOT1QgZm9ybSBhZGphY2VuY2llcyB3aXRoIHJvdXRlcnMgd2hpY2ggYXJlIE5PVCBvcGVyYXRp bmcgaW4gYXV0by1jb25maWd1cmF0aW9uIG1vZGUuICZxdW90Ozwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iY29sb3I6YmxhY2siPldoeSBpcyB0aGF0PyBJJ2QgdGhpbmsgaXQgd291bGQgYmUgZWFz aWVyIHRvIGRlcGxveSBpZiB5b3UgY291bGQgZ3JhZHVhbGx5IGludHJvZHVjZSBhdXRvY29uZmln dXJpbmcgcm91dGVycyBpbiB3aXRoIGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyB0aGF0IGRvbid0 IGtub3cgYWJvdXQgdGhlIEEgYml0LiBBcmUgeW91IGNvbmNlcm5lZCBhYm91dA0KIGFuIGFjdHVh bCBhcmVhIDA/PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+W0xlczpdIFRoZSB0YXJnZXQgZm9yIHRoZXNlIGV4dGVuc2lv bnMgaXMgZGVmaW5lZCBpbiBTZWN0aW9uIDI6PG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48 L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjUuMjVwdCI+ PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj7igJxJUy1JUyBhdXRvLWNvbmZpZ3VyYXRpb24gaXMgcHJpbWFyaWx5IGludGVuZGVkIGZv ciB1c2UgaW4gc21hbGwgKGkuZS48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1LjI1cHQiPjxiPjxpPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5i c3A7IDEwcyBvZiBkZXZpY2VzKSBhbmQgdW5tYW5hZ2VkIGRlcGxveW1lbnRzLiZuYnNwOyBJdCBh bGxvd3MgSVMtSVMgdG8gYmU8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo1LjI1cHQiPjxiPjxpPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7 IHVzZWQgd2l0aG91dCB0aGUgbmVlZCBmb3IgYW55IGNvbmZpZ3VyYXRpb24gYnkgdGhlIHVzZXIu Jm5ic3A7IEl0IGlzIG5vdDxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgcmVjb21tZW5kZWQgZm9yIGxhcmdlciBkZXBs b3ltZW50cy7igJ08bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxpPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgdGhlcmUgYXJlIG1hbnkgZ29vZCByZWFzb25zIGZv ciB0aGF0IOKAkyB0aGUgcHJpbWFyeSBvbmUgYmVpbmcgdGhhdCB3aGVuIG9uZSBzdGFydHMgZGVw bG95aW5nIG1vcmUgdGhhbiBhIG1pbmltdW0gc2V0IG9mIGZlYXR1cmVzIHRoZXJlDQogYXJlIG1h bnkgbW9yZSBvcHRpb25zIGFuZCBpdCBiZWNvbWVzIHByb2JsZW1hdGljYWwgdG8gc2VsZWN0IGEg ZGVmYXVsdCBzZXR0aW5nIHRoYW4gd2lsbCBiZSBzYXRpc2ZhY3RvcnkgaW4gYWxsIGRlcGxveW1l bnRzLiBEZXRlcm1pbmluZyBsZXZlbCBpcyBvbmUgZWFzeSBleGFtcGxlIOKAkyBhc3N1bWluZyBM MSBpc27igJl0IGFwcHJvcHJpYXRlIGZvciBsYXJnZXIgZGVwbG95bWVudHMuIEF1dG9jb25maWcg b2YgYXJlYSBhZGRyZXNzIGlzIGFub3RoZXIuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48 L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbyB0aGlzIHJlc3RyaWN0aW9uIGlz IGludGVudGlvbmFsLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+W0JpbmddIEFzIExlcyBzYWlkLCB0aGlzIHJlc3RyaWN0aW9uIGlzIGlu dGVudGlvbmFsLiBBdCB0aGUgYmVnaW5uaW5nLCB3ZSBhY3R1YWxseSB0aG91Z2h0IGFib3V0IHRo ZSBwb3NzaWJpbGl0aWVzIG9mIHVzaW5nIHRoZSBhdXRvLWNvbmYgbWVjaGFuaXNtDQogbm90IG9u bHkgaW4gc21hbGwgbmV0d29ya3MuIEJ1dCBsYXRlciB3ZSBhZ3JlZWQgdGhhdCBpdCBtaWdodCBi ZSBiZXR0ZXIgdG8gYmUgbGVzcyBhbWJpdGlvdXMgdGhhdCB0byBndWFyYW50ZWUgaXQgY2FuIGRv IHRoZSBqb2Igd2VsbCBmb3Igc21hbGwgbmV0d29ya3MgZmlyc3QuICZuYnNwO0ZvciBpbmNyZW1l bnRhbCBkZXBsb3ltZW50IGFuZCBsYXJnZXIgZGVwbG95bWVudCwgdGhlc2UgYXJlIGRlZmluaXRl bHkgc29tZSBpbnRlcmVzdGluZyBwcm9ibGVtcw0KIHRvIGJlIHNvbHZlZC4gSWYgd2UgY291bGQg ZmlndXJlIG91dCBzb21lIGdvb2QgaWRlYXMgaW4gdGhlIGZ1dHVyZSwgd2UgY2FuIGNvbnNpZGVy IHRvIGluaXRpYXRlIHNvbWUgbmV3IHdvcmsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IExlczxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjpibGFjayI+T3RoZXIgdGhhbiB0aG9zZSAobW9zdGx5KSBlZGl0b3JpYWwgY29tbWVu dHMsIHdoaWNoIGFyZSBvbmx5IHN1Z2dlc3Rpb25zIGFueXdheSwgdGhpcyBpcyByZWFkeSBmb3Ig cHVibGljYXRpb24uIEkgaGF2ZW4ndCBiZWVuIGZvbGxvd2luZyBJUy1JUyByZWNlbnRseSwgYW5k IEknbSBhY3R1YWxseSBzdXJwcmlzZWQgdGhhdCB0aGVyZSBoYXNuJ3QNCiBiZWVuIHRvdGFsbHkg YXV0b2NvbmZpZ3VyaW5nIGltcGxlbWVudGF0aW9ucyB1cCB1bnRpbCBub3cuPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PltCaW5nXSBUaGVyZSBpcyBhbiBvcGVuIHNvdXJjZSBpbXBsZW1lbnRhdGlvbiwgd2hpY2ggaXMg YmFzZWQgb24gYW4gZWFybGllciB2ZXJzaW9uIG9mIHRoaXMgZG9jdW1lbnQsIGFuZCBpbnRlZ3Jh dGluZyBzb3VyY2Ugcm91dGluZyBmdW5jdGlvbiBmb3INCiBob21lIG5ldHdvcmsgc2NlbmFyaW9z LiBMaW5rOiA8YSBocmVmPSJodHRwczovL2dpdC11cy5uZXRkZWYub3JnL3Byb2plY3RzL09TUi9y ZXBvcy9vcGVud3J0LWlzaXMtaG5ldC9jb21taXRzIj4NCmh0dHBzOi8vZ2l0LXVzLm5ldGRlZi5v cmcvcHJvamVjdHMvT1NSL3JlcG9zL29wZW53cnQtaXNpcy1obmV0L2NvbW1pdHM8L2E+IC48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QmluZzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOmJsYWNrIj5SYWRpYTwv c3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_8AE0F17B87264D4CAC7DE0AA6C406F45C2ED09C5nkgeml514mbschi_-- From nobody Thu Mar 30 07:18:27 2017 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 330A8126C26 for ; Thu, 30 Mar 2017 07:18:25 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen To: X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Reply-to: secdir-secretary@mit.edu Message-ID: <149088350520.15503.12463527357933201092.idtracker@ietfa.amsl.com> Date: Thu, 30 Mar 2017 07:18:25 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 14:18:25 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2017-04-13 Reviewer LC end Draft Derek Atkins 2017-03-22 draft-ietf-i2nsf-problem-and-use-cases-11 Phillip Hallam-Baker 2017-02-24 draft-ietf-dmm-lma-controlled-mag-params-04 Tero Kivinen R2016-09-28 draft-ietf-ippm-6man-pdm-option-09 Hilarie Orman 2017-03-01 draft-ietf-6man-rfc2460bis-09 Vincent Roca 2017-04-07 draft-ietf-rtgwg-yang-key-chain-17 Joseph Salowey 2017-04-07 draft-ietf-isis-mi-bis-02 Yaron Sheffer 2017-03-31 draft-ietf-pals-status-reduction-04 Rifaat Shekh-Yusef 2017-03-13 draft-mm-wg-effect-encrypt-09 For telechat 2017-04-27 Reviewer LC end Draft Russ Mundy 2017-04-18 draft-ietf-ipsecme-tcp-encaps-09 Last calls: Reviewer LC end Draft Ben Laurie 2017-03-02 draft-ietf-dprive-dtls-and-tls-profiles-08 Rich Salz 2017-04-06 draft-ietf-mmusic-dtls-sdp-22 Melinda Shore 2017-04-09 draft-ietf-core-coap-tcp-tls-07 Robert Sparks 2017-04-06 draft-ietf-httpbis-encryption-encoding-08 Tom Yu 2017-02-20 draft-ietf-slim-negotiating-human-language-08 Early review requests: Reviewer Due Draft Daniel Gillmor 2016-02-01 draft-ietf-rtcweb-security-08 Next in the reviewer rotation: Takeshi Takahashi Sean Turner Carl Wallace David Waltermire Sam Weiler Brian Weis Klaas Wierenga Paul Wouters Liang Xia Tom Yu From nobody Thu Mar 30 07:53:03 2017 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 700F3129517; Thu, 30 Mar 2017 07:53:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yaron Sheffer To: Cc: draft-ietf-pals-status-reduction.all@ietf.org, ietf@ietf.org, pals@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.49.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149088558240.15511.14051374750329617951@ietfa.amsl.com> Date: Thu, 30 Mar 2017 07:53:02 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-pals-status-reduction-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 14:53:03 -0000 Reviewer: Yaron Sheffer Review result: Ready This document proposes a way to aggregate status messages of multiple pseudowires carried on the same MPLS-network LSP. The Security Considerations simply refer to an earlier RFC, and this makes sense in this case. However from a broader perspective, I think the community should consider another look at its security assumptions. After what we've seen in recent years, maybe it's not a good idea to refer back to a 2006 document that contains this sentence: "To prevent unwanted packet insertion, it is also important to prevent unauthorized physical access to the PSN," We have all learned the hard way that this advice is not practical - bad actors WILL get physical access to your network. From nobody Thu Mar 30 12:00:44 2017 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 31C0A129A4E for ; Thu, 30 Mar 2017 12:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.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 k4aFjDP0ZF-c for ; Thu, 30 Mar 2017 12:00:33 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 A17DF129AA3 for ; Thu, 30 Mar 2017 12:00:26 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id x35so47563531qtc.2 for ; Thu, 30 Mar 2017 12:00:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=JRkJ5QbawCMIc+J4++k3hfs1cVfiLkKfiuRk0Mrv7ic=; b=dmvPS1slNT2cfCNJNYyWh0bBWWYUjurZahWQqhJtahv+GdRjES6AhFF4puMc+jtPPr 6pq4QEa1NG/BBfL97Dl4sEMU9U6I5ijY+cMAm7NhDrIqMltm32aTTqgQUJx/jBE00JrU OyPTosGpsblkCPrKla8S4J914vOoM9vysakoR4cULcMkHU42lAfeyj17Dq05FwcDOaTm RYcez0xNtFl9bzdWPSfqLIvT3PXlIp421TusJwQ+n/j5kAXLMPbZ7+OtORKYRqGPJKuk ns89EoR4N5A3fTyO5cMj8WqrfYcYRptop0sVH+v/dxI6Mkl/nmFwjq3ZUZD4otZL+p4B DWMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=JRkJ5QbawCMIc+J4++k3hfs1cVfiLkKfiuRk0Mrv7ic=; b=WAP4WEgqRkHNdM6YfoPD3NQ41Telxr03qu7bpl7Bl4QoIsnRVydwz2PuHZLdDx18sb /FYggh5LbpdYtMmC2QO/rJJPCfcAVOAtNYKtFQLd7ej8QysBpfRNaA8D92Lhf9S2F3z6 jz1eR3XyDAfOgIklaHgeqd7Hp7gDnMm2I5LqJvfLjJrHTABNyEzZmj7Bxy8EKQll9nyV 2O7NYEHKMNfr7aWLDvfcORpjGfoESNQCSY19Fqp4IONfFh1xkCYaIPnL+oRimfgAuaTs 8eDXHen4Z49406Eoh4cmJFSGSKYhP6K3kp4h/VmApjEOhf8AxBYt9hJ5tNP889gRWmQB ZScA== X-Gm-Message-State: AFeK/H1YYp7mv+I61wigG/rumdnmSx2K3UWDRaQXj8QwdPinQlyuY9E+ObxSvsxbMVQ4eOsUsaTfcbHPjMrdeR6N X-Received: by 10.200.43.185 with SMTP id m54mr1354179qtm.122.1490900423848; Thu, 30 Mar 2017 12:00:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.177.11 with HTTP; Thu, 30 Mar 2017 11:59:43 -0700 (PDT) In-Reply-To: References: From: Warren Kumari Date: Thu, 30 Mar 2017 13:59:43 -0500 Message-ID: To: Sandra Murphy Cc: IETF Security Directorate , draft-ietf-dnsop-nsec-aggressiveuse@ietf.org, dnsops-chairs@ietf.org, The IETF Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-dnsop-nsec-aggressiveuse X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 19:00:42 -0000 On Tue, Mar 28, 2017 at 11:34 AM, Sandra Murphy wrote: > 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. Thank you very much for your review, and getting it in early, it makes addressing them much easier. > > This document suggests that resolvers should use NSEC/NSEC3 proof of non-= existence for a domain name in a received query to generate a negative repl= y, rather than relying on the current spec of an exact match to the domain = name. Generating positive replies from wildcard answers is also suggested. > > The motivation is improvements in latency for queriers and improvements i= n bandwidth and CPU load on recursive resolvers and validation servers. > > I have no serious objections about the draft. > > I am curious about my thought that an attacker might find this of benefit= , as they can learn of non-existence in just one query, rather than every n= ame in a NSEC denied range. I know zone walking is a concern to some, but I= do not know if ease of determining non-existence is also a concern. I may have missed something, but I do not see the concern -- an attacker can already learn of non-existence in just one query; that is exactly what NSEC (already) provides. If an attacker queries e.g the root for .belkin they get back (trimmed): $ dig +dnssec belkin beer. 44025 IN NSEC bentley. NS DS RRSIG NSEC This tells the attacker that nothing exists between beer and bentley (in one query). All that this document does is optimize the recursive server so that, if the attacker tries to instead do e.g a dictionary attack and ask many names between beer and bentley the recursive (and auths) have less work to do. The attacker only advantage to the attacker is that they have to wait slightly less time doing a dictionary attack -- but, they would be much better off asking for the (existing) NSEC info directly. > > Section 7 explicitly spells out the changes to RFC4035 are explicitly spe= lled > out as to what is removed and what replaces it. Section 5 is not so clea= rly > delineated. Yup. At one point we had the changes explicitly spelled out in both, the WG felt that this was overly long and duplicating the text was confusing. > > The last paragraph of 5., nothing in 5.1 or 5.2, and the last paragraph o= f 5.3 > use SHOUD/MUST/MAY kinds of language. For the paragraphs that don=E2=80= =99t - should > they? For the paragraphs that do, is this additional behavior or a > replacement for existing spec (i.e. like the section 7 update to RFC4035)= . > If a replacement, a replacement of what? If not, where do the new paragr= aphs > fit? > I don't think that these bits to need the 2119 language - they are more explanatory, and providing explanation / justification for the change baing made to RFC4035 (which is updated in Section 7). > The following is a sequential set of comments, not in importance order. > > page 3 > > This document updates RFC 4035 to allow recursive resolvers to use > NSEC/NSEC3 resource records to synthesize negative answers from the > information they have in the cache. > > re: recursive resolvers - is the technique not applicable to stub resolve= rs? > (I do see references to stub resolver caches in a web search, but you can= =E2=80=99t > trust the web.) Good catch -- we fixed a similar issue in the Abstract, but missed it here. > > [RFC8020], and [I-D.vixie-dnsext-resimprove] proposes first steps to > using NXDOMAIN information for more effective caching. This takes > this technique further. > > Unless rfc8020 and the vixie draft are the same thing (don=E2=80=99t thin= k so), > should be =E2=80=9Cpropose=E2=80=9D. > > > Too many uses of =E2=80=9Cthis=E2=80=9D in that last sentence - I presume= you mean > This draft takes those previous techniques further. Thank you. I changed these to: [RFC8020] and [I-D.vixie-dnsext-resimprove propose steps to using NXDOMAIN information for more effective caching. This document takes this technique further. > > > page 4 > > If a validating resolver receives a query for cat.example.com, it > contacts its resolver (which may be itself) > > Maybe > > If a validating resolver receives a query for cat.example.com, it > contacts its recursive resolver (which may be itself) Thank you -- I believe that the current is more correct; in most cases the validating resolver will be a recursive resolver and will be contacting a authoritative server. In a few cases (currently, in the future this may change as validating stubs become common) it will be a stub contacting a recursive, so the text in the draft covers both cases. > > About: > > and also has > privacy implications (e.g: typos leak out further than necessary). > > Does it also make certain explorations easier, where someone can find out= a range > that does not exist by doing just one query rather than query every name = in the > range? Or is that sort of exploration already prevented by other techniq= ues? Nope; as above. Attackers already have the capability to find ranges which do not exist (querying for the NSEC record). > > If a query is received for leek.example.org, it contacts its resolver > (which may be itself) > > I suggest =E2=80=9Cthe resolver contacts its resolver=E2=80= =9D - the query is not > doing the contacting. Thank you. I changed it to: "If a query is received for leek.example.org, the system contacts its resolver (which may be itself) to query..." I think that this addresses your comment in a more general manner. > > > page 6 > > section 5.1 and 5.2 say =E2=80=9Cresolver can immediately return=E2=80=9D= - is this meant > to specify new behavior, should they have SHOULD/MAY/MUST kinds of words? I don't *think* so -- it means that is has the ability to; other text suggests what it actually should to. > > page 7 > > Section 5 of [RFC2308] states that the maximum number of negative > cache TTL value is 3 hours (10800). > > I don=E2=80=99t find a maximum in RFC2308. I do find: > Values of one to three hours have been found to work w= ell > and would make sensible a default. > Did I miss something? > See below. > > =E2=80=9Cthe maximum number of negative cache TTL value is=E2=80=9D - a b= it twisty. Did you > mean something like: > > Section 5 of [RFC2308] states that the maximum negative cache TTL value = is=E2=80=9D > > otherwise, I=E2=80=99d think =E2=80=9Cnumber of =E2=80=A6 values=E2=80=9D= , but even so I don=E2=80=99t think there are > multiple values here. Are there? Nope, you did not miss anything, and yes, yes that was twisty - 'twas an artifact of poor editing. I changed this to be: Section 5 of [RFC2308 suggests a maximum default negative cache TTL value of 3 hours (10800). It is RECOMMENDED that validating resolvers limit the maximum effective TTL value of negative responses (NSEC/NSEC3 RRs) to this same value. > > page 9 > > > > The text says > > Thanks to Mark Andrews for providing the helpful notes for > implementors provided in Appendix B. > > The authors would like to specifically thank > =E2=80=A6 > Mark Andrews also provided the > helpful notes for implementors (https://www.ietf.org/mail- > archive/web/dnsop/current/msg18332.html) which we made into > Appendix B. > > Perhaps you intended to thank him twice? No problem, just wondering. Nope, edit fail. Fixed. Thank you again for your comments. I've posted / am just about to post a new version with them addressed / incorporated. W > > =E2=80=94Sandy > > > > > > --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Thu Mar 30 13:49:40 2017 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 CF2A8129552; Thu, 30 Mar 2017 13:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-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 WQaG43sGcSip; Thu, 30 Mar 2017 13:49:36 -0700 (PDT) Received: from walnut.tislabs.com (walnut.tislabs.com [192.94.214.200]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 366AB12951B; Thu, 30 Mar 2017 13:49:26 -0700 (PDT) Received: from nova.tislabs.com (unknown [10.66.1.77]) by walnut.tislabs.com (Postfix) with ESMTP id 7E49628B003B; Thu, 30 Mar 2017 16:49:25 -0400 (EDT) Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by nova.tislabs.com (Postfix) with ESMTP id 787831F8036; Thu, 30 Mar 2017 16:49:14 -0400 (EDT) Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Content-Type: multipart/signed; boundary="Apple-Mail=_271850B6-8E28-403F-8932-A8747B257FB4"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: Sandra Murphy In-Reply-To: Date: Thu, 30 Mar 2017 16:47:00 -0400 Cc: Sandra Murphy , IETF Security Directorate , draft-ietf-dnsop-nsec-aggressiveuse@ietf.org, dnsop-chairs@ietf.org, The IETF Message-Id: References: To: Warren Kumari X-Mailer: Apple Mail (2.2104) Archived-At: Subject: Re: [secdir] secdir review of draft-ietf-dnsop-nsec-aggressiveuse X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 20:49:39 -0000 --Apple-Mail=_271850B6-8E28-403F-8932-A8747B257FB4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Top note: My original message misspelled the dnsop-chairs alias. Warren replied = to everyone, so I=E2=80=99m guessing that he got a bounce from my error. Anyone responding to Warren=E2=80=99s message, please note. > On Mar 30, 2017, at 2:59 PM, Warren Kumari wrote: >=20 > On Tue, Mar 28, 2017 at 11:34 AM, Sandra Murphy = wrote: >>=20 >> I am curious about my thought that an attacker might find this of = benefit, as they can learn of non-existence in just one query, rather = than every name in a NSEC denied range. I know zone walking is a concern = to some, but I do not know if ease of determining non-existence is also = a concern. >=20 >=20 > I may have missed something, but I do not see the concern -- an > attacker can already learn of non-existence in just one query; that is > exactly what NSEC (already) provides. > If an attacker queries e.g the root for .belkin they get back = (trimmed): > $ dig +dnssec belkin > beer. 44025 IN NSEC bentley. NS DS RRSIG NSEC >=20 > This tells the attacker that nothing exists between beer and bentley > (in one query). All that this document does is optimize the recursive > server so that, if the attacker tries to instead do e.g a dictionary > attack and ask many names between beer and bentley the recursive (and > auths) have less work to do. The attacker only advantage to the > attacker is that they have to wait slightly less time doing a > dictionary attack -- but, they would be much better off asking for the > (existing) NSEC info directly. Yes, silly of me, sorry, (Ill) thought retracted. >>=20 >> The last paragraph of 5., nothing in 5.1 or 5.2, and the last = paragraph of 5.3 >> use SHOUD/MUST/MAY kinds of language. For the paragraphs that = don=E2=80=99t - should >> they? For the paragraphs that do, is this additional behavior or a >> replacement for existing spec (i.e. like the section 7 update to = RFC4035). >> If a replacement, a replacement of what? If not, where do the new = paragraphs >> fit? >>=20 >=20 > I don't think that these bits to need the 2119 language - they are > more explanatory, and providing explanation / justification for the > change baing made to RFC4035 (which is updated in Section 7). So you are going to take out the normative language? Otherwise, well, = it confused me. >=20 >>=20 >> page 7 >>=20 >> Section 5 of [RFC2308] states that the maximum number of negative >> cache TTL value is 3 hours (10800). >>=20 >> I don=E2=80=99t find a maximum in RFC2308. I do find: >> Values of one to three hours have been found to = work well >> and would make sensible a default. >> Did I miss something? >>=20 >=20 > I changed this to be: > Section 5 of [RFC2308 suggests a maximum default negative cache TTL > value of 3 hours (10800). It is RECOMMENDED that validating resolvers > limit the maximum effective TTL value of negative responses > (NSEC/NSEC3 RRs) to this same value. Quibble: I still don=E2=80=99t see that RC2308 sets 3 as a maximum, just =E2=80=9Ch= ave been found to work well=E2=80=9D. Could be elsewhere in RFC2308, and I missed it. =E2=80=94Sandy --Apple-Mail=_271850B6-8E28-403F-8932-A8747B257FB4 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJY3W7RAAoJEHplpQeet0IZn/wP/RrQPR2KbX7WtmkWyT+VS4Za TUB8GcwFndDp57pHXQKSxKLlO7jDwU/KEqrb9XsNu9/5yYtTh6RThh1G7KdgBAUB ivrnknHsQADtGUle1KMbUbKKm1ozazAeufX2lDdRbDL7Ri8IuoBqzZem6DjccFiA bs8Ks5NJNpHCi18cYq7JQCWwHAmpsWHPy5HCBaz5vOb4de1CIMYEZiG3KmFbM9Aj Q7AeRP2SiLjifqDFxxjZ/RhiGyx0xvmoKapLUDlXvSBn27BOXpYulPmyj3wnh6I2 YSVDT1GbpuYkFBTyvCgVXOb/S2XkIW5N6my6UkQewOSyPElUfgFs5MLIXyB/pPk2 6FrQoIjVIqaoqlh6aH5vbmg+N3DANZcHhxBzsOImTYOT1vpcaFiadcwqbeO7u0cb Fv+x/lWyO/pWkPYCYfilzGvqULzlEk3KyWO4Gr44JkyrqJ8MnIjfhsJSy2OoPJPb LsBzrMcBRg6F18KlNuS1TrB5BjI6JmWwwiUtZ0gmFayySAvs2gvx3YyQzIc9UCNq Ic42jHnXHndtfK8qdLJ8FRYLuzVAnzEF6UKOTBPkJpd0QcqidzoXE0V3z2NAUgzZ nxcaDW+lGOO8++0h1DXVSxGo1/D7bb8+Jc557oLqvZFGkRbB4HVumMxuMhJdjBa7 a3fSZmSAY8nynCE6pdJd =BxAe -----END PGP SIGNATURE----- --Apple-Mail=_271850B6-8E28-403F-8932-A8747B257FB4-- From nobody Fri Mar 31 08:47:47 2017 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 8FCDD1294AC; Thu, 30 Mar 2017 01:45:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1490863531; bh=CM8Vq2O3kfW7OyLoHzFLfQzZjKzJCbgA858/g79vhFs=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=lWqFGYKkYXbl36jx/m3g1be8EQ+aj/SD9GQgrFgjMcx/MlAtjE8e2iosLjBZzzjd0 cbVCLV6BoU3JulEqeVsZzV7sAa2IFZQYOqTUrHdSSkSuS1OTXCnBIFovxBRDT7uJY2 e2v4ywQcc5Xn5wpizE+4L0xLxbYLcSBm7EdshwDY= 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 3B9A31293E9 for ; Thu, 30 Mar 2017 01:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0I4uc6JCXLN for ; Thu, 30 Mar 2017 01:45:28 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [IPv6:2001:470:8b2d:804:52:12:128:0]) (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 818C4128B4E for ; Thu, 30 Mar 2017 01:45:28 -0700 (PDT) Received: from [2001:da8:203:80:c95d:260a:b071:c107] by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1ctVhu-0004tQ-TY for new-work@ietf.org; Thu, 30 Mar 2017 08:45:27 +0000 To: new-work@ietf.org From: Xueyuan Jia Message-ID: <72a628ef-a936-8544-fe55-8be3093cfaaf@w3.org> Date: Thu, 30 Mar 2017 16:47:52 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.22 Precedence: list Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 31 Mar 2017 08:47:46 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Dataset Exchange Working Group (until 2017-04-30) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Mar 2017 08:45:32 -0000 Hello, Today W3C Advisory Committee Representatives received a Proposal to review a draft charter for the Dataset Exchange Working Group: https://www.w3.org/2017/dxwg/charter 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 2017-04-30 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 Phil Archer, Data Strategist and Team Contact . Thank you, Xueyuan Jia, W3C Marketing & Communications [1] http://www.w3.org/Consortium/Member/List _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work