From nobody Tue Apr 2 10:17:15 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4435120155; Tue, 2 Apr 2019 10:17:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 bKWeQXuAiryf; Tue, 2 Apr 2019 10:17:05 -0700 (PDT) Received: from Mail1.Yoyodyne.COM (mail1.yoyodyne.com [IPv6:2604:4ec0:3::7]) by ietfa.amsl.com (Postfix) with SMTP id 86C561200FB; Tue, 2 Apr 2019 10:17:05 -0700 (PDT) Received: from [10.0.4.54] ([24.5.60.91]) by Mail1.Yoyodyne.COM via Internet for (and others); Tue, 2 Apr 2019 10:17:04 PDT From: Derrell Piper Content-Type: multipart/alternative; boundary="Apple-Mail=_389DB6DB-CAE9-4AE0-8F64-A41F5AC7B530" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Message-Id: <4C94645D-B024-4FDD-B4F5-1B769232E9ED@electric-loft.org> Date: Tue, 2 Apr 2019 10:17:04 -0700 To: secdir@ietf.org, ietf@ietf.org, draft-ietf-manet-dlep-multi-hop-extension.all@ietf.org X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: [secdir] Secdir review of draft-ietf-manet-dlep-multi-hop-extension-06.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 17:17:07 -0000 --Apple-Mail=_389DB6DB-CAE9-4AE0-8F64-A41F5AC7B530 Content-Transfer-Encoding: 7bit Content-Type: text/plain; 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. The summary is READY This document defines a new DLEP Extension Type and three new DLEP Data Items to allow modems which implement multi-hop forwarding to change multi-hop forwarding behavior through a new hop-control mechanism defined by these extensions. The Security Considerations section was updated to explicitly note this addition of a hop-control mechanism which can be used to terminate and reset connections, affecting reacheability. As this new extension is defined under the existing RFC 8175 framework, the Security Considerations stated there also apply. --Apple-Mail=_389DB6DB-CAE9-4AE0-8F64-A41F5AC7B530 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.

The summary is READY

This = document defines a new DLEP Extension Type and three new
DLEP Data Items to allow modems which implement multi-hop
forwarding to change multi-hop forwarding behavior through a = new
hop-control mechanism defined by these extensions.

The Security Considerations section was = updated to explicitly
note this addition of a hop-control = mechanism which can be used
to terminate and reset = connections, affecting reacheability.  As
this new = extension is defined under the existing RFC 8175
framework, = the Security Considerations stated there also apply.

= --Apple-Mail=_389DB6DB-CAE9-4AE0-8F64-A41F5AC7B530-- From nobody Tue Apr 2 12:29:22 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C03A0120248 for ; Tue, 2 Apr 2019 12:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 SC6VoZ_imcYp for ; Tue, 2 Apr 2019 12:29:13 -0700 (PDT) Received: from mail-wm1-x32b.google.com (mail-wm1-x32b.google.com [IPv6:2a00:1450:4864:20::32b]) (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 8210712020A for ; Tue, 2 Apr 2019 12:29:13 -0700 (PDT) Received: by mail-wm1-x32b.google.com with SMTP id y197so5212163wmd.0 for ; Tue, 02 Apr 2019 12:29:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=pw3DzNyeaNbH3T9dswd9vqo6emT63GUf47TWaa62+WI=; b=pGIRpcHQg8XSfLr3rAi+hNxhiB+VY5+cb4rN/0wmQ+sw8+GDX7s8+yz6KBT1IigN17 JkddUxXXhW6VBQ+KMfihqIDTJSlnCGUqzQKmMuYzeeRuSjhYX0BojEnvJC4eOQkmUYWK ebPeacXnkg+/ZYfNF+LPXM2vKEPWjM9HSaMt88bPKwAMIxnr6ZpAUm0TToiu2u4C3ASW 2tjraSsMLzrSxOGCxUJvc+xvt7DpHCdYBlZvsUiKxHZVNcarLpXXECEB8pcs1JKmGGC3 b5OjxqN77ViFF56DmrRPQq7qRy1O2V6dAcOI2U9Q9+G/HGADVEpfFN9QkDsrS9mGsE3s 479g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=pw3DzNyeaNbH3T9dswd9vqo6emT63GUf47TWaa62+WI=; b=RMv1ywKunsWTlPGbEduaBO/O6HrI3EH7x8JDWRLdwNz+cySUnK4L+cgmUnUcYabS4Q lUWCku2ayyDIrg0JDIQY2N65XzgNr+pUZEkoHzma+1iP6q8z6DRCflC09MXvLBIAp89h UOyoIbzFuvYUyQUHX2ZZ441rPRnZOj1m3THhENmUewjDBqVHaHbGbhCwMyPEvuVR55x6 yGryxxRr+Pk8Ml64wVqcKeRinREpV58m1ylLjSlgOMH/Wo8QRpxWIAFBI+Lor5MX7tN4 hN1Y2QVwySTlO1uy6xrLgu0dadpR3bjVJjoVj8+rLcrFhVv1I8yZB9ObHalHbXe61jXs UaMA== X-Gm-Message-State: APjAAAVhl80zPxjgJrDc5U30wzriKNO8HcxO5cG6wZF8hzcij7v0Ok9w TlM9Kdnfke3Pjoxde13UtzD3oF5Kk7A= X-Google-Smtp-Source: APXvYqzb2No3fTzYJI7K3I/hgyLZ9gl439k2GJJWdf8hIOIuC1gUqrGfVMiHs30hHamvwHbhVDlcGQ== X-Received: by 2002:a1c:1a46:: with SMTP id a67mr4925751wma.21.1554233351798; Tue, 02 Apr 2019 12:29:11 -0700 (PDT) Received: from [192.168.1.13] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id x205sm10391695wmg.9.2019.04.02.12.29.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Apr 2019 12:29:10 -0700 (PDT) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_1867CA16-C91B-4116-B23E-B658F330FB58" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Message-Id: <766097F3-A70F-439D-9F20-AEA8F47DCE02@gmail.com> Date: Tue, 2 Apr 2019 22:29:01 +0300 To: secdir X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: [secdir] Rough outline of a Security Considerations Sunday Tutorial X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2019 19:29:19 -0000 --Apple-Mail=_1867CA16-C91B-4116-B23E-B658F330FB58 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 [ NOTE: This is cross-posted to SAAG and SecDir. The discussion should = happen on the SAAG list as the SecDir list has a special purpose that is = not general discussion ] Hi. As I mentioned at the SAAG meeting, we are planning to have a Security = Considerations tutorial on the Sunday of an upcoming meeting. I=E2=80=99ve put a very rough initial draft of an outline on github: https://github.com/IETF-SAAG/SecurityConsiderationsTutorial = Please read and comment (either on the SAAG list = or in github), and send = PRs. Your input is very much needed, as it is you who do the SecDir = reviews. Yoav --Apple-Mail=_1867CA16-C91B-4116-B23E-B658F330FB58 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
[ NOTE: This is cross-posted to SAAG and SecDir. The = discussion should happen on the SAAG list as the SecDir list has a = special purpose that is not general discussion ]

Hi.

As I mentioned at the SAAG meeting, we are planning to have a = Security Considerations tutorial on the Sunday of an upcoming = meeting.

I=E2=80= =99ve put a very rough initial draft of an outline on github:

https://github.com/IETF-SAAG/SecurityConsiderationsTutorial=

Please read = and comment (either on the SAAG = list or in github), and send PRs.  Your input is very much = needed, as it is you who do the SecDir reviews.

Yoav

= --Apple-Mail=_1867CA16-C91B-4116-B23E-B658F330FB58-- From nobody Wed Apr 3 01:01:12 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D16D120174; Wed, 3 Apr 2019 01:01:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 2ozBbGwhJCbE; Wed, 3 Apr 2019 01:01:05 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E5DC120164; Wed, 3 Apr 2019 01:01:04 -0700 (PDT) Received: from lhreml709-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 426FB9D3143BD6472E07; Wed, 3 Apr 2019 08:57:58 +0100 (IST) Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by lhreml709-cah.china.huawei.com (10.201.108.32) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 3 Apr 2019 08:57:57 +0100 Received: from DGGEMM528-MBX.china.huawei.com ([169.254.8.72]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0415.000; Wed, 3 Apr 2019 15:57:54 +0800 From: "Yemin (Amy)" To: tom petch , Sandra Murphy CC: "ccamp@ietf.org" , "secdir@ietf.org" , "draft-ietf-ccamp-rsvp-te-bandwidth-availability.all@ietf.org" , Sandra Murphy Thread-Topic: [CCAMP] Secdir last call review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-13 Thread-Index: AQHUuqwWHpLws/0qnkGGhYcJXbfKyaYqZyww Date: Wed, 3 Apr 2019 07:57:54 +0000 Message-ID: <9C5FD3EFA72E1740A3D41BADDE0B461FCFBC7AE8@DGGEMM528-MBX.china.huawei.com> References: <154908012600.28521.5714645741731093529@ietfa.amsl.com> <9C5FD3EFA72E1740A3D41BADDE0B461FCFB598CD@DGGEMM528-MBX.china.huawei.com> <3DCE5D1E-DBF1-4293-8FA1-FD6E975E24FC@tislabs.com> <02db01d4e623$51e9aee0$4001a8c0@gateway.2wire.net> In-Reply-To: <02db01d4e623$51e9aee0$4001a8c0@gateway.2wire.net> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.169.30.234] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [secdir] [CCAMP] Secdir last call review of draft-ietf-ccamp-rsvp-te-bandwidth-availability-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 08:01:10 -0000 RGVhciBhbGwsIA0KDQpJIGFncmVlZCB0aGF0IElFRUU3NTQgc2hvdWxkIGJlIHJlZmVyZW5jZWQu ICBJIGFsc28gdGFsa2VkIHRvIFJGQyBlZGl0b3JzIGFib3V0IHRoZSBwcmVmZXJyZWQgZm9ybWF0 LCB0aGV5IHJlY29tbWVuZCB0aGUgZm9sbG93aW5nIGZvcm1hdDogICAgDQogICBbSUVFRTc1NF0g IElFRUUsICJJRUVFIFN0YW5kYXJkIGZvciBGbG9hdGluZy1Qb2ludCBBcml0aG1ldGljIiwNCiAg ICAgICAgICAgICAgSUVFRSA3NTQtMjAwOCwgRE9JIDEwLjExMDkvSUVFRVNURC4yMDA4LjQ2MTA5 MzUsIDIwMDgsDQogICAgICAgICAgICAgIDxodHRwOi8vc3RhbmRhcmRzLmllZWUub3JnL2ZpbmRz dGRzLw0KICAgICAgICAgICAgICBzdGFuZGFyZC83NTQtMjAwOC5odG1sPi4NCg0KUmVnYXJkaW5n IHRoZSBhcHBlbmRpeCwgU2FuZHkgYW5kIEkgaGFkIGEgdGFsayBkdXJpbmcgdGhlIElFVEYgbWVl dGluZy4gSXQncyBhZ3JlZWQgdGhhdCB0aGUgdGV4dCBpbiB0aGUgYXBwZW5kaXggd2lsbCBiZSB1 cGRhdGVkIHRvIGF2b2lkIGFtYmlndW91cy4gDQpBbHNvIHRoZSBuaXRzIHdpbGwgYmUgZml4ZWQu DQoNClRoYW5rIGFnYWluIGZvciBTYW5keSBhbmQgVG9tJ3MgY29tbWVudHMuIA0KDQpCUiwNCkFt eQ0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IHRvbSBwZXRjaCBbbWFpbHRvOmll dGZjQGJ0Y29ubmVjdC5jb21dIA0KU2VudDogRnJpZGF5LCBNYXJjaCAyOSwgMjAxOSA3OjM3IFBN DQpUbzogU2FuZHJhIE11cnBoeSA8c2FuZHlAdGlzbGFicy5jb20+OyBZZW1pbiAoQW15KSA8YW15 LnllbWluQGh1YXdlaS5jb20+DQpDYzogY2NhbXBAaWV0Zi5vcmc7IHNlY2RpckBpZXRmLm9yZzsg ZHJhZnQtaWV0Zi1jY2FtcC1yc3ZwLXRlLWJhbmR3aWR0aC1hdmFpbGFiaWxpdHkuYWxsQGlldGYu b3JnOyBTYW5kcmEgTXVycGh5IDxzYW5keUB0aXNsYWJzLmNvbT4NClN1YmplY3Q6IFJlOiBbQ0NB TVBdIFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY2NhbXAtcnN2cC10ZS1i YW5kd2lkdGgtYXZhaWxhYmlsaXR5LTEzDQoNClNhbmRyYQ0KDQpPbiBqdXN0IHRoZSBxdWVzdGlv biBvZiB0aGUgcmVmZXJlbmNlIGZvciBmbG9hdGluZyBwb2ludCwgSSB3b3VsZCBkcmF3IHlvdXIg YXR0dGVudGlvbiB0byBZQU5HLCBSRkM3OTUwLHdoaWNoIGhhcw0KICAgW0lFRUU3NTQtMjAwOF0N CiAgICAgICAgICAgICAgSUVFRSwgIklFRUUgU3RhbmRhcmQgZm9yIEZsb2F0aW5nLVBvaW50IEFy aXRobWV0aWMiLA0KICAgICAgICAgICAgICBJRUVFIDc1NC0yMDA4LCBET0kgMTAuMTEwOS9JRUVF U1RELjIwMDguNDYxMDkzNSwgMjAwOCwNCiAgICAgICAgICAgICAgPGh0dHA6Ly9zdGFuZGFyZHMu aWVlZS5vcmcvZmluZHN0ZHMvDQogICAgICAgICAgICAgIHN0YW5kYXJkLzc1NC0yMDA4Lmh0bWw+ Lg0KVGhlcmUgaGFzIGJlZW4gYSBsb3Qgb2YgZGlzY3Vzc2lvbiBpbiB0aGUgSUVURiBPQU0gYXJl bmEgYXJvdW5kIHRoaXMgdG9waWMgYW5kIEkgd291bGQgcmVnYXJkIHRoYXQgcmVmZXJlbmNlIGFz IHRoZSBiZXN0IGNvbnNpZGVyZWQgYW5kIHBlcmhhcHMgdGhlIG1vc3QgaW5mbHVlbnRpYWwuLg0K DQpUb20gUGV0Y2gNCg0KLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIlNhbmRy YSBNdXJwaHkiIDxzYW5keUB0aXNsYWJzLmNvbT4NClRvOiAiWWVtaW4gKEFteSkiIDxhbXkueWVt aW5AaHVhd2VpLmNvbT4NCkNjOiA8Y2NhbXBAaWV0Zi5vcmc+OyA8c2VjZGlyQGlldGYub3JnPjsg PGRyYWZ0LWlldGYtY2NhbXAtcnN2cC10ZS1iYW5kd2lkdGgtYXZhaWxhYmlsaXR5LmFsbEBpZXRm Lm9yZz47ICJTYW5kcmEgTXVycGh5IiA8c2FuZHlAdGlzbGFicy5jb20+DQpTZW50OiBUaHVyc2Rh eSwgTWFyY2ggMjgsIDIwMTkgMTE6MzIgQU0NClN1YmplY3Q6IFJlOiBbQ0NBTVBdIFNlY2RpciBs YXN0IGNhbGwgcmV2aWV3IG9mDQpkcmFmdC1pZXRmLWNjYW1wLXJzdnAtdGUtYmFuZHdpZHRoLWF2 YWlsYWJpbGl0eS0xMw0KDQoNCj4gSSBzZWUgdGhhdCBhIG5ldyB2ZXJzaW9uIHdhcyBwb3N0ZWQg b24gTWFyIDYuICBJIHRoYW5rIHRoZSBhdXRob3JzIGZvcg0KdGhlaXIgYXR0ZW50aW9uIHRvIG15 IGNvbW1lbnRzIGFuZCBmb3IgdGhlIGV4cGxhbmF0aW9ucyBmb3IgY2FzZXMgd2hlcmUgSSB3YXMg Y29uZnVzZWQuDQo+DQo+IEkgaGF2ZSBvbmUgc3VnZ2VzdGlvbi4gIFRoZSBhdXRob3JzIGNoYW5n ZWQgdGhlIHRleHQgdG8gc2F5IOKAnGZsb2F0aW5nDQpwb2ludOKAnSwgYnV0IEkgZGlkIG5vdCBt YWtlIGNsZWFyIHRoYXQgSSB0aGluayBhIHJlZmVyZW5jZSB0byBJRUVFIDc1NCBpcyBuZWVkZWQu DQo+DQo+IEkgZm91bmQgb25lIHJlZmVyZW5jZSB0byBhbiBJRVNHIGNvbW1lbnQgZHVyaW5nIHRo ZSByZXZpZXcgb2YNCmRyYWZ0LWlldGYtaXNpcy1wY3INCj4NCj4g4oCiIEphcmkgQXJra286IENv bW1lbnQgWzIwMTYtMDEtMDcgMDQ6NTEgUFNUXToNCj4gVGhpcyBjb21tZW50IGZyb20gU3VyZXNo IEtyaXNobmFuJ3MgR2VuLUFSVCByZXZpZXcgc2VlbXMgcmVsZXZhbnQ6DQpUaGVyZSBpcyBubyBy ZWZlcmVuY2UgZm9yIHRoZSBmb3JtYXQgb2YgdGhlIEJhbmR3aWR0aCBmaWVsZHMgaW4gU2VjdGlv bnMNCjYuMyBhbmQgNi40LiBJIGFtIGFzc3VtaW5nIHRoaXMgcmVmZXJzIHRvIHRoZSBTaW5nbGUg UHJlY2lzaW9uIGZvcm1hdA0KKGJpbmFyeTMyKSBmcm9tIElFRUUgNzU0LiBJZiBzbywgcGxlYXNl IGFkZCBhbiBleHBsaWNpdCByZWZlcmVuY2UgdG8gdGhpcy4NCj4NCj4gU28gdGhlIHJlZmVyZW5j ZSB0byB0aGUgSUVFRSBzdGFuZGFyZCBoYXMgYmVlbiBjb25zaWRlcmVkIGEgZ29vZCBpZGVhDQpp biBwYXN0IGRyYWZ0IElFU0cgcmV2aWV3cy4NCj4NCj4gSSBmb3VuZCB0aHJlZSBSRkNzIHRoYXQg Y29udGFpbmVkIGEgcmVmZXJlbmNlIHRvIHRoZSBJRUVFIDc1NA0Kc3RhbmRhcmQuICBUaGUgZmly c3QgaXMgdGhlIFJGQyB0aGF0IHJlc3VsdGVkIGZyb20gZHJhZnQtaWV0Zi1pc2lzLXBjcg0KPg0K PiBSRkMgNzgxMyAgICAgICAgICAgICAgICAgICAgICAgIElTLUlTIFBDUiAgICAgICAgICAgICAg ICAgICAgICBKdW5lDQoyMDE2DQo+DQo+IDExLjIuICBJbmZvcm1hdGl2ZSBSZWZlcmVuY2VzDQo+ DQo+ICAgIFtJRUVFNzU0XSAgSUVFRSwgIklFRUUgU3RhbmRhcmQgZm9yIEZsb2F0aW5nLVBvaW50 IEFyaXRobWV0aWMiLA0KPiAgICAgICAgICAgICAgIElFRUUgNzU0LTIwMDgsIERPSSAxMC4xMTA5 L0lFRUVTVEQuMjAwOC40NjEwOTM1LCAyMDA4LA0KPiAgICAgICAgICAgICAgIDxodHRwOi8vc3Rh bmRhcmRzLmllZWUub3JnL2ZpbmRzdGRzLw0KPiAgICAgICAgICAgICAgIHN0YW5kYXJkLzc1NC0y MDA4Lmh0bWw+Lg0KPg0KPiB0aGUgc2Vjb25kIGlzIGFuIE9TUEYgUkZDDQo+DQo+IFJGQyA3NDcx ICAgICAgICAgICAgICAgIE9TUEYgVEUgTWV0cmljIEV4dGVuc2lvbnMgICAgICAgICAgICAgTWFy Y2gNCjIwMTUNCj4NCj4gMTMuMS4gIE5vcm1hdGl2ZSBSZWZlcmVuY2VzDQo+DQo+ICAgIFtJRUVF NzU0XSAgSW5zdGl0dXRlIG9mIEVsZWN0cmljYWwgYW5kIEVsZWN0cm9uaWNzIEVuZ2luZWVycywN Cj4gICAgICAgICAgICAgICAiU3RhbmRhcmQgZm9yIEZsb2F0aW5nLVBvaW50IEFyaXRobWV0aWMi LCBJRUVFIFN0YW5kYXJkDQo+ICAgICAgICAgICAgICAgNzU0LCBBdWd1c3QgMjAwOC4NCj4NCj4g YW5kIHRoZSB0aGlyZCBpcyBhIENDQU1QIFJGQzoNCj4NCj4NCj4gUkZDIDgzMzAgICAgICAgICAg ICBBdmFpbGFiaWxpdHkgRXh0ZW5zaW9uIHRvIE9TUEYtVEUgICAgICBGZWJydWFyeQ0KMjAxOA0K Pg0KPiA3LjEuICBOb3JtYXRpdmUgUmVmZXJlbmNlcw0KPg0KPiAgICBbSUVFRTc1NC0yMDA4XQ0K PiAgICAgICAgICAgICAgIElFRUUsICJJRUVFIFN0YW5kYXJkIGZvciBGbG9hdGluZy1Qb2ludCBB cml0aG1ldGljIiwNCj4gICAgICAgICAgICAgICBJRUVFIDc1NC0yMDA4LCBET0kgMTAuMTEwOS9J RUVFU1RELjIwMDguNDYxMDkzNS4NCj4NCj4NCj4gTm90ZSB0aGF0IG9uZSByZWZlcmVuY2UgaXMg aW5mb3JtYXRpdmUsIHR3byBhcmUgbm9ybWF0aXZlLiAgVGhlDQphdXRob3JzIHNob3VsZCBkZWNp ZGUgd2hldGhlciB0aGUgZm9ybWF0IGlzIGEgcmVxdWlyZW1lbnQgYW5kIHRoZXJlZm9yZSB0aGUg cmVmZXJlbmNlIHNob3VsZCBiZSBub3JtYXRpdmUuDQo+DQo+IEluIGNvbnZlcnNhdGlvbiB3aXRo IHRoZSBSRkMtRWRpdG9yLCB0aGVyZSBhcmUgc29tZSBJRUVFIHJlcXVlc3RzIGFzDQp0byBob3cg dGhlIHJlZmVyZW5jZSBzaG91bGQgYmUgcGhyYXNlZC4gIFRoZSBhdXRob3JzIG1heSB3aXNoIHRv IGNvbnN1bHQgdGhlIFJGQy1FZGl0b3IgdG8gZGVjaWRlIGhvdyB0aGlzIHJlZmVyZW5jZSBzaG91 bGQgYmUgcGhyYXNlZC4gIFRoZXJlIGFyZSBldmlkZW50bHkgY29uc2lkZXJhdGlvbnMgb2Ygd2hl dGhlciB5b3Ugd2lzaCB0aGlzIGRvY3VtZW50IHRvIGZvbGxvdyB0aGUgSUVFRSBzdGFuZGFyZCBh cyBpdCBjaGFuZ2VzLCBvciB3aGV0aGVyIHlvdSB3YW50IHRvIHBvaW50IHRvIHRoZSBjdXJyZW50 IHZlcnNpb24gZXhwbGljaXRseS4NCj4NCj4gU29tZXRoaW5nIEkgZGlkIG5vdCBub3RpY2UgYmVm b3JlOg0KPg0KPiBQYWdlIDY6DQo+DQo+ICAgICAgICAgT3B0aW9uYWxseSwgYSBoaWdoZXIgYXZh aWxhYmlsaXR5IGJhbmR3aWR0aCBjYW4gYmUNCj4gICAgICAgICBhbGxvY2F0ZWQgdG8gbG93ZXIg YXZhaWxhYmlsaXR5IHJlcXVlc3Qgd2hlbiB0aGUgbG93ZXINCj4gICAgICAgICBhdmFpbGFiaWxp dHkgYmFuZHdpZHRoIGNhbm5vdCBzYXRpc2Z5IHRoZSByZXF1ZXN0Lg0KPg0KPg0KPiBEb2VzIHRo aXMgbWFrZSB0aGUgb3JkZXIgb2YgbG9va2luZyBhdCBhdmFpbGFiaWxpdHkgYmFuZHdpZHRoIHJl cXVlc3RzDQppbXBvcnRhbnQ/ICBJZiBhIGxvd2VyIGF2YWlsYWJpbGl0eSByZXF1aXJlbWVudCBi YW5kd2lkdGggcmVxdWVzdCBpcyBhbGxvY2F0ZWQgZnJvbSB0aGUgaGlnaGVyIGF2YWlsYWJpbGl0 eSBiYW5kd2lkdGggYmVmb3JlIGFsbCBoaWdoZXIgYXZhaWxhYmlsaXR5IGJhbmR3aWR0aCByZXF1 ZXN0cyBhcmUgc2F0aXNmaWVkLCBtaWdodCB0aGF0IHByZXZlbnQgYSBoaWdoZXIgYXZhaWxhYmls aXR5IGJhbmR3aWR0aCByZXF1ZXN0IGZyb20gYmVpbmcgc2F0aXNmaWVkPw0KPg0KPiBBcHBlbmRp eCBQYWdlIDkgYW5kIDEwDQo+DQo+IEkgYW0gYWZyYWlkIHRoYXQgZXZlbiBhZnRlciByZXZpZXcg b2YgdGhlIGF1dGhvcnMnIGNvbW1lbnRzIGFuZA0KYW5vdGhlciB0aW1lIG92ZXIgdGhlIEFwcGVu ZGl4LCBJIHN0aWxsIGRvIG5vdCB1bmRlcnN0YW5kIHRoZSB0YWJsZSBpbiB0aGUgQXBwZW5kaXgu ICBUbyBteSByZWFkaW5nIG9mIHBhZ2UgOSBhbmQgMTA6DQo+DQo+IDQwME1icHMgKGxldmVsIDMg bW9kdWxhdGlvbikgaXMgYXZhaWxhYmxlIGV4Y2VwdCBmb3IgdGhlIDUyIG1pbnV0ZXMgYQ0KeWVh ciB3aGVuIHRoZSBtb2R1bGF0aW9uIGRyb3BzIHRvIGxldmVsIDIgPT0+ICg1MjU2MDAtNTIpLzUy NTYwMCA9IDk5Ljk5JSBvZiB0aGUgdGltZSA0MDBNYnBzIGlzIGF2YWlsYWJsZQ0KPg0KPiAyMDBN YnBzIChsZXZlbCAyIG1vZHVsYXRpb24pIGlzIGF2YWlsYWJsZSBleGNlcHQgZm9yIHRoZSAyNiBt aW51dGVzIGENCnllYXIgd2hlbiB0aGUgbW9kdWxhdGlvbiBkcm9wcyB0byBsZXZlbCAxID09PiAo NTI1NjAwLTI2KS81MjU2MDAgPSA5OS45OTUlIG9mIHRoZSB0aW1lIDIwME1icHMgaXMgYXZhaWxh YmxlDQo+DQo+IDEwME1icHMgKGxldmVsIDEgbW9kdWxhdGlvbikgaXMgYXZhaWxhYmxlIGV4Y2Vw dCBmb3IgdGhlIDUgbWludXRlcyBhDQp5ZWFyIHdoZW4gdGhlIHdob2xlIHN5c3RlbSBpcyB1bmF2 YWlsYWJsZSA9PT4gKDUyNTYwMC01KS8yNTI2MDAgPSA5OS45OTklIG9mIHRoZSB0aW1lIDEwME1i cHMgaXMgYXZhaWxhYmxlLg0KPg0KPiAoVGhlcmXigJlzIGFub3RoZXIgaW50ZXJwcmV0YXRpb24g b2YgeW91ciBleGFtcGxlIHRleHQgLSB0aGF0IHRoZQ0KNDAwTWJncCBpcyBub3QgYXZhaWxhYmxl IGluIHRoZSBsaWdodCByYWluIHRoYXQgZHJvcHMgdGhlIG1vZHVsYXRpb24gdG8NCmxldmVsMiAt b3ItICB0aGUgMjYgbWludXRlcyBvZiBoZWF2eSByYWluIHRoYXQgZHJvcHMgdGhlIG1vZHVsYXRp b24gdG8gbGV2ZWwgMSAtb3ItIHdoZW4gdGhlIHdob2xlIHN5c3RlbSBpcyB1bmF2YWlsYWJsZSwg c28gNDAwTWJwcyBpcyB1bmF2YWlsYWJsZSA1MisyNis1IG1pbnV0ZXMgZWFjaCB5ZWFyLCB3aGlj aCBpcyBtb3JlIGxpa2UgOTkuOTglLikNCj4NCj4gVGhhdCB3b3VsZCBtYWtlIHRoZSB0YWJsZSBz YXk6DQo+DQo+IFN1Yi1iYW5kd2lkdGggKE1icHMpICAgQXZhaWxhYmlsaXR5DQo+DQo+ICAgIC0t LS0tLS0tLS0tLS0tLS0tLSAgICAgLS0tLS0tLS0tLS0tDQo+DQo+ICAgIDQwMCAgICAgICAgICAg ICAgICAgICAgOTkuOTklDQo+DQo+ICAgIDIwMCAgICAgICAgICAgICAgICAgICAgOTkuOTk1JQ0K Pg0KPiAgICAxMDAgICAgICAgICAgICAgICAgICAgIDk5Ljk5OSUNCj4NCj4gRXZlbiBpZiBJIGFt IHN0aWxsIGFtIGludGVycHJldGluZyB0aGlzIGluY29ycmVjdGx5LCBJIHdvdWxkIGxpa2UgdG8N CnBvaW50IG91dCB0aGF0IHRoZSB0ZXh0IGhhcyB0d28gc3RhdGVtZW50cyBvbiBwYWdlIDEwIHRo YXQgc2VlbSB0bw0KY29uZmxpY3Q6DQo+DQo+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgVGhlbiB0aGUgZHJvcHBlZCAxMDAgTWJwcw0KPiAgICBiYW5kd2lkdGggaGFzIDk5 Ljk5NSUgYXZhaWxhYmlsaXR5Lg0KPg0KPiBhbmQNCj4NCj4gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBTbyB0aGUgMTAwIE1icHMNCj4gICAgYmFuZHdpZHRo IG9mIHRoZSBtb2R1bGF0aW9uIGxldmVsIDEgb3ducyB0aGUgYXZhaWxhYmlsaXR5IG9mDQo+ICAg IDk5Ljk5OSUuDQo+DQo+IFlvdSBtaWdodCB3YW50IHRvIGRvIHRoZSByZWFkZXJzIGEgZmF2b3Ig YW5kIGNsZWFyIHVwIHRoZSBjb25mbGljdC4NCj4NCj4NCj4gU29tZSBuaXRzIGFyZSBiZWxvdy4N Cj4NCj4g4oCUU2FuZHkNCj4NCj4gSW4gbGlnaHQgb2YgdGhlIFJGQy1FZGl0b3IgcmVxdWVzdCBk dXJpbmcgdGhlIElFVEYxMDQgcGxlbmFyeSBvbg0KV2VkbmVzZGF5LCBoZXJlIGFyZSBzb21lIG5p dHMgdGhlIFJGQy1FZGl0b3Igd291bGQgcHJvYmFibHkgY2F0Y2gsIGJ1dCB0byBtYWtlIHRoZWly IHRhc2sgZWFzaWVyLCBJIG5vdGUgdGhlbSBoZXJlLg0KPg0KPiBQYWdlIDM6DQo+DQo+ICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBXaGVuIGEgdmlkZW8gYXBwbGljYXRpb24g cmVxdWVzdHMNCj4gICAgZm9yIDEyMCBNYnBzIHdpdGhvdXQgYmFuZHdpZHRoIGF2YWlsYWJpbGl0 eSByZXF1aXJlbWVudA0KPg0KPiByZXF1ZXN0cyBmb3IgMTIwIE1icHMg4oCUPiDigJxtYWtlcyBh IHJlcXVlc3QgZm9yIDEyME1icHPigJ0gb3Ig4oCccmVxdWVzdHMNCjEyME1icHPigJ0NCj4gd2l0 aG91dCBiYW5kd2lkdGgg4oCUPiB3aXRob3V0IGEgYmFuZHdpZHRoDQo+DQo+IFBhZ2UgNToNCj4N Cj4gICAgICAgQXZhaWxhYmlsaXR5ICg0IG9jdGV0cyk6IGEgMzItYml0IGZsb2F0aW5nIHBvaW50 IG51bWJlcg0KZGVzY3JpYmVzDQo+DQo+IFRoaXMgd291bGQgYmUgYSBnb29kIHBsYWNlIHRvIHB1 dCBhIGNpdGUgdG8gdGhlIElFRUUgNzU0IHJlZmVyZW5jZS4NCj4NCj4gICAgICAgdGhlIGRlY2lt YWwgdmFsdWUgb2YgYXZhaWxhYmlsaXR5IHJlcXVpcmVtZW50IGZvciB0aGlzIGJhbmR3aWR0aA0K PiAgICAgICByZXF1ZXN0LiBUaGUgdmFsdWUgTVVTVCBiZSBsZXNzIHRoYW4gMWFuZCBpcyB1c3Vh bGx5IGV4cHJlc3NlZA0KaW4NCj4NCj4gb2YgYXZhaWxhYmlsaXR5IHJlcXVpcmVtZW50IOKAlD4g 4oCcb2YgdGhlIGF2YWlsYWJpbGl0eSByZXF1aXJlbWVudOKAnQ0KPiAxYW5kIOKAlD4g4oCcMSBh bmTigJ0NCj4NCj4gUGFnZSA2Og0KPg0KPiAgICAgICAgIGFsbG9jYXRlZCB0byBsb3dlciBhdmFp bGFiaWxpdHkgcmVxdWVzdCB3aGVuIHRoZSBsb3dlcg0KPg0KPiB0byBsb3dlciBhdmFpbGFiaWxp dHkgcmVxdWVzdCDigJQ+IHRvIGEgbG93ZXIgYXZhaWxhYmlsaXR5IHJlcXVlc3QNCj4NCj4gICAg V2hlbiBhIG5vZGUgcmVjZWl2ZXMgQXZhaWxhYmlsaXR5IFRMVnMgd2hpY2ggbWl4ZWQgb2YgemVy byBpbmRleA0KYW5kDQo+DQo+IOKAnHdoaWNoIG1peGVkIG9m4oCdIOKAlD4g4oCcd2hpY2ggYXJl IGEgbWl4IG9mIg0KPg0KPiAgICBzZXZlcmFsIDxiYW5kd2lkdGgsIGF2YWlsYWJpbGl0eT4gcGFp cnMsIGJ1dCB0aGVyZSdyZSBhcmUgZXh0cmENCj4NCj4g4oCcdGhlcmXigJlyZSBhcmXigJ0g4oCU PiDigJx0aGVyZSBhcmXigJ0NCj4NCj4gICAgYmFuZHdpZHRoLVRMVnMgd2l0aG91dCBtYXRjaGlu ZyBpbmRleCBBdmFpbGFiaWxpdHktVExWLCB0aGUgZXh0cmENCj4NCj4gY291bGQgYmUg4oCcd2l0 aG91dCBtYXRjaGluZyB0aGUgaW5kZXggb2YgYW55IEF2YWlsYWJpbGl0eS1UTFbigJ0gb3INCuKA nHdpdGhvdXQgYW55IEF2YWlsYWJpbGl0eS1UTFYgd2l0aCBhIG1hdGNoaW5nIGluZGV44oCdDQo+ DQo+IFBhZ2UgNzoNCj4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIFJTVlAtVEUgc2lnbmFsaW5nIHVzZWQNCj4gICAgaW4gR01QTFMgbmV0d29yay4NCj4N Cj4gaW4gR01QTFMgbmV0d29yayDigJQ+IOKAnGluIGEgR01QTFMgbmV0d29ya+KAnSBvciDigJxp biBHTVBMUyBuZXR3b3JrcyINCj4NCj4NCj4gPiBPbiBGZWIgMjIsIDIwMTksIGF0IDQ6NTggQU0s IFllbWluIChBbXkpIDxhbXkueWVtaW5AaHVhd2VpLmNvbT4NCndyb3RlOg0KPiA+DQo+ID4gSGkg U2FuZHJhLA0KPiA+DQo+ID4gTWFueSB0aGFua3MgZm9yIHRoZSBkZXRhaWwgcmV2aWV3IGNvbW1l bnRzLCBwbGVhc2Ugc2VlIHJlcGx5IGlubGluZQ0KYmVsb3cuDQo+ID4gQW5kIEnigJltIHZlcnkg c29ycnkgZm9yIHRoZSBsYXRlIHJlcGx5Lg0KPiA+DQo+ID4gQlIsDQo+ID4gQW15DQo+ID4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBTYW5kcmEgTXVycGh5IFttYWlsdG86 c2FuZHlAdGlzbGFicy5jb21dDQo+ID4gU2VudDogU2F0dXJkYXksIEZlYnJ1YXJ5IDAyLCAyMDE5 IDEyOjAyIFBNDQo+ID4gVG86IHNlY2RpckBpZXRmLm9yZw0KPiA+IENjOiBjY2FtcEBpZXRmLm9y ZzsgaWV0ZkBpZXRmLm9yZzsNCmRyYWZ0LWlldGYtY2NhbXAtcnN2cC10ZS1iYW5kd2lkdGgtYXZh aWxhYmlsaXR5LmFsbEBpZXRmLm9yZw0KPiA+IFN1YmplY3Q6IFNlY2RpciBsYXN0IGNhbGwgcmV2 aWV3IG9mDQpkcmFmdC1pZXRmLWNjYW1wLXJzdnAtdGUtYmFuZHdpZHRoLWF2YWlsYWJpbGl0eS0x Mw0KPiA+DQo+ID4gUmV2aWV3ZXI6IFNhbmRyYSBNdXJwaHkNCj4gPiBSZXZpZXcgcmVzdWx0OiBI YXMgSXNzdWVzDQo+ID4NCj4gPiBJIGhhdmUgcmV2aWV3ZWQgdGhpcyBkb2N1bWVudA0KZHJhZnQt aWV0Zi1jY2FtcC1yc3ZwLXRlLWJhbmR3aWR0aC1hdmFpbGFiaWxpdHkNCj4gPiBhcyBwYXJ0IG9m IHRoZSBzZWN1cml0eSBkaXJlY3RvcmF0ZeKAmXMgb25nb2luZyBlZmZvcnQgdG8gcmV2aWV3IGFs bA0KSUVURiBkb2N1bWVudHMgYmVpbmcgcHJvY2Vzc2VkIGJ5IHRoZSBJRVNHLiBUaGVzZSBjb21t ZW50cyB3ZXJlIHdyaXR0ZW4gcHJpbWFyaWx5IGZvciB0aGUgYmVuZWZpdCBvZiB0aGUgc2VjdXJp dHkgYXJlYSBkaXJlY3RvcnMuICBEb2N1bWVudCBlZGl0b3JzIGFuZCBXRyBjaGFpcnMgc2hvdWxk IHRyZWF0IHRoZXNlIGNvbW1lbnRzIGp1c3QgbGlrZSBhbnkgb3RoZXIgbGFzdCBjYWxsIGNvbW1l bnRzLg0KPiA+DQo+ID4gVGhpcyBkcmFmdCBwcm92aWRlcyBhIG5ldyBUTFYgZm9yIHRoZSBFdGhl cm5ldCBTRU5ERVJfVFNQRUMgb2JqZWN0DQp0aGF0IHdpbGwgY2FycnkgYXZhaWxhYmlsaXR5IHJl cXVpcmVtZW50cyBmb3IgUlNWUC1URSBzaWduYWxpbmcgb2YgR01QTFMgTFNQcy4NCj4gPg0KPiA+ IFRoZSBkcmFmdCBpcyB0aG9yb3VnaC4gIEkgZG8gaGF2ZSBzb21lIGNvbW1lbnRzLiAgSSByZXZp ZXdlZCB0aGUNCm5vcm1hdGl2ZSByZWZlcmVuY2VzIFJGQ3MgMjIwNSwgMzIwOSwgMzQ3MywgNjAw MywgYXMgd2VsbCBhcyBSRkMzOTQ1IGFuZCBSRkM1OTIwLiAgSSBjYW7igJl0IGNsYWltIHRoYXQg SSB1bmRlcnN0b29kIGV2ZXJ5dGhpbmcgaW4gdGhhdCBzdGFjaywgc28gdGhlIGZvbGxvd2luZyBj b3VsZCBlYXNpbHkgYmUgd3JvbmcuDQo+ID4NCj4gPiBDb21wdXRpbmcgdGhlIExTUCBwYXRoOg0K PiA+DQo+ID4gUGFnZSA0LCBzZWN0aW9uIDIgZGlzY3Vzc2VzIG9idGFpbmluZyBuZXR3b3JrIHRv cG9sb2d5LCBjYWxjdWxhdGluZw0KdGhlIExTUCByb3V0ZSwgUkZDODMzMOKAmXMgZXh0ZW5zaW9u cyBmb3IgYXZhaWxhYmlsaXR5IGluIE9TUEYgVEUgTFNBIG1lc3NhZ2VzLiAgRG9lcyB0aGlzIGRy YWZ0IGFzc3VtZSB0aGF0IHRoaXMgZXh0ZW5zaW9uIHdpbGwgYWx3YXlzIGJlIHVzZWQgd2l0aCBh biBFWFBMSUNJVF9ST1VURSBvYmplY3Q/ICBJcyB0aGlzIGRyYWZ0IG5vdCBhcHBsaWNhYmxlIHdp dGhvdXQgdGhhdCBleHBsaWNpdCBMU1Agcm91dGUgY2FsY3VsYXRpb24/DQo+ID4gW0FteV0gTm8s IHRoZXJlJ3Mgbm8gYXNzdW1wdGlvbiB0aGF0IHRoZSBleHRlbnNpb24gY2FuIGJlIG9ubHkgdXNl ZA0Kd2l0aCBhbiBFWFBMSUNJVF9ST1VURSBvYmplY3QuICBUaGUgbm9kZSB3aG8gb2J0YWlucyBu ZXR3b3JrIHRvcG9sb2d5LCBjYWxjdWxhdGVzIHRoZSBMU1Agcm91dGUsIGNvdWxkIGJlIGEgc291 cmNlIG5vZGUgYW5kIGludGVybWVkaWF0ZSBub2Rlcy4NCj4gPiBBdmFpbGFiaWxpdHkgVExWIHZz IENMQVNTVFlQRSBvYmplY3RzOg0KPiA+DQo+ID4gVGhlIGRlZmluaXRpb24gaW4gUkZDNjAwMyBv ZiB0aGUgQmFuZHdpZHRoIFByb2ZpbGUgVExWIGhhcyBjZXJ0YWluDQpjb25zdHJhaW50cyBvbiB0 aGUgdmFsdWVzIG9mIHRoZSBJbmRleDoNCj4gPiAgICAgICAgICAgICAgICAgICAgICAgICAgVGhl IEluZGV4IGZpZWxkIHZhbHVlIE1VU1QgY29ycmVzcG9uZCB0byBhdA0KbGVhc3Qgb25lDQo+ID4g ICAgICAgb2YgdGhlIENsYXNzLVR5cGUgdmFsdWVzIGluY2x1ZGVkIGVpdGhlciBpbiB0aGUgQ0xB U1NUWVBFDQpvYmplY3QNCj4gPiAgICAgICBbUkZDNDEyNF0gb3IgaW4gdGhlIEVYVEVOREVEX0NM QVNTVFlQRSBvYmplY3QgW01DT1NdLg0KPiA+DQo+ID4gSSBhbSBub3QgY2VydGFpbiBpZiB0aGlz IG1lYW5zIHRoYXQgdGhlIHByZXNlbmNlIG9mIGFuIEV0aGVybmV0DQpTRU5ERVJfVFNQRUMgT2Jq ZWN0IHdpdGggYSBCYW5kd2lkdGggUHJvZmlsZSBUTFYgbWVhbnMgdGhlcmUgbXVzdCBiZSBhIENM QVNTVFlQRSBvYmplY3QgaW4gdGhlIFJTVlAtVEUgbWVzc2FnZSBhcyB3ZWxsLCBvciB0aGF0IHRo ZSBJbmRleCBmaWVsZCB2YWx1ZXMgYXJlIHRha2VuIGZyb20gdGhlIHNldCBvZiBkZWZpbmVkIENs YXNzLVR5cGUgdmFsdWVzLg0KPiA+DQo+ID4gQnV0IGlmIHRoZSBmaXJzdCwgZG9lcyB0aGlzIGlu ZHVjZSByZXF1aXJlbWVudHMgYnkgaW5jbHVzaW9uIG9mIHRoZQ0KQXZhaWxhYmlsaXR5IFRMViB0 aGF0IHRoZXNlIG90aGVyIENMQVNTVFlQRSBvYmplY3RzIG11c3QgYmUgaW5jbHVkZWQgYXMgd2Vs bD8NCj4gPiBPciBhcmUgeW91IGludGVuZGluZyB0byB1cGRhdGUgUkZDNjAwMyB0byBlbGltaW5h dGUgdGhhdCBjb25zdHJhaW50Pw0KSWYgdGhlIHNlY29uZCwgZG9lcyB0aGUgUkZDNjAwMyBjb25z dHJhaW50IGFsc28gY29uc3RyYWluIHRoZSBpbmRleCB2YWx1ZXMgdXNlZCBpbiB0aGUgQXZhaWxh YmlsaXR5IFRMVj8gIFNob3VsZCB0aGF0IGJlIG1lbnRpb25lZD8gIChPciBhbSBJIGp1c3QgY29u ZnVzZWQ/KQ0KPiA+IFtBbXldIEl04oCZcyB0aGUgc2Vjb25kIGNhc2UuIFRoZSBSRkM2MDAzIGNv bnN0cmFpbnQgc2hvdWxkIGFsc28gYXBwbHkNCnRvIHRoZSBpbmRleCB2YWx1ZXMgdXNlZCBpbiB0 aGUgQXZhaWxhYmlsaXR5IFRMVi4gVGhlIGN1cnJlbnQgdGV4dCBzdGF0ZXMgdGhhdCDigJxoYXZp bmcgdGhlIHNhbWUgdmFsdWUgb2YgSW5kZXggZmllbGTigJ0sIHdoaWNoIGltcGxpZXMgdGhlIHNh bWUgY29uc3RyYWludC4NCj4gPg0KPiA+IEJhbmR3aWR0aCBUTFYgdG8gQXZhaWxhYmlsaXR5IFRM ViBhc3NvY2lhdGlvbjoNCj4gPg0KPiA+IFBhZ2UgNCwgU2VjdGlvbiAzLjEgc2F5cw0KPiA+DQo+ ID4gICAgICAgV2hlbiB0aGUgQXZhaWxhYmlsaXR5IFRMViBpcyBpbmNsdWRlZCwgaXQgTVVTVCBi ZSBwcmVzZW50DQphbG9uZw0KPiA+ICAgICAgIHdpdGggdGhlIEV0aGVybmV0IEJhbmR3aWR0aCBQ cm9maWxlIFRMVi4gSWYgdGhlIGJhbmR3aWR0aA0KPiA+ICAgICAgIHJlcXVpcmVtZW50cyBpbiB0 aGUgbXVsdGlwbGUgRXRoZXJuZXQgQmFuZHdpZHRoIFByb2ZpbGUgVExWcw0KaGF2ZQ0KPiA+ICAg ICAgIGRpZmZlcmVudCBBdmFpbGFiaWxpdHkgcmVxdWlyZW1lbnRzLCBtdWx0aXBsZSBBdmFpbGFi aWxpdHkNClRMVnMNCj4gPiAgICAgICBTSE9VTEQgYmUgY2FycmllZC4gSW4gc3VjaCBhIGNhc2Us IHRoZSBBdmFpbGFiaWxpdHkgVExWIGhhcyBhDQpvbmUNCj4gPiAgICAgICB0byBvbmUgY29ycmVz cG9uZGVuY2Ugd2l0aCB0aGUgRXRoZXJuZXQgQmFuZHdpZHRoIFByb2ZpbGUgVExWDQpieQ0KPiA+ ICAgICAgIGhhdmluZyB0aGUgc2FtZSB2YWx1ZSBvZiBJbmRleCBmaWVsZC4gSWYgYWxsIHRoZSBi YW5kd2lkdGgNCj4gPiAgICAgICByZXF1aXJlbWVudHMgaW4gdGhlIEV0aGVybmV0IEJhbmR3aWR0 aCBQcm9maWxlIGhhdmUgdGhlIHNhbWUNCj4gPiAgICAgICBBdmFpbGFiaWxpdHkgcmVxdWlyZW1l bnQsIG9uZSBBdmFpbGFiaWxpdHkgVExWIFNIT1VMRCBiZQ0KY2FycmllZC4NCj4gPiAgICAgICBJ biB0aGlzIGNhc2UsIHRoZSBJbmRleCBmaWVsZCBpcyBzZXQgdG8gMC4NCj4gPg0KPiA+IEkgZmlu ZCB0aGF0IHRoZSBkZXNjcmlwdGlvbiBpcyBub3QgY2xlYXIgaW4gYWxsIGNhc2VzLiAgSSBmb3Vu ZCBhDQptZXNzYWdlIGluIHRoZSB3b3JraW5nIGdyb3VwIGRpc2N1c3Npb24gb2YgdGhpcyBhc3Nv Y2lhdGlvbiB0aGF0IHRoZSBhc3NvY2lhdGlvbiBpcyBlaXRoZXIg4oCcbjpu4oCdIG9yIOKAnG46 MeKAnS4gIEkgdGhpbmsgdGhpcyBkZXNjcmlwdGlvbiBzb3VuZHMgbW9yZSBsaWtlIG4gMToxIGFz c29jaWF0aW9ucw0KPiA+IG9yIGEgIG46MSBhc3NvY2lhdGlvbi4gICBJcyB0aGF0IHdoYXQgaXMg aW50ZW5kZWQ/ICBDYW4gdGhlDQphc3NvY2lhdGlvbnMgYmUNCj4gPiBtaXhlZCBpbiB0aGUgc2Ft ZSBtZXNzYWdlPyAgU3VwcG9zZSB0aGVyZSB3ZXJlIDMgQmFuZHdpZHRoIFRMVnMgdGhhdA0KbmVl ZGVkIHRoZSBzYW1lIGF2YWlsYWJpbGl0eSBhbmQgb25lIHRoYXQgaGFkIGEgZGlmZmVyZW50IGF2 YWlsYWJpbGl0eSBuZWVkLCBjb3VsZCB0aGVyZSBiZSAzIEJhbmR3aWR0aCBUTFZzIHdpdGggaW5k ZXggMCBhbmQgb25lIEF2YWlsYWJpbGl0eS1UTFYgd2l0aCBpbmRleCAwIGFuZCBhbHNvIGEgQmFu ZHdpZHRoIFRMVnMgLSBBdmFpbGFiaWxpdHkgVExWIHBhaXIgd2l0aCBtYXRjaGluZyBpbmRleCB2 YWx1ZXM/DQo+ID4gW0FteV0gVGhhbmtzIGZvciBsb29raW5nIGludG8gdGhlIHBhc3QgZGlzY3Vz c2lvbi4gVGhlIGludGVuc2lvbiB3YXMNCm4qKDE6MSkgYXNzb2NpYXRpb24gb3IgbjoxIGFzc29j aWF0aW9uLiBJdCB3YXMgbm90IHNvIGFjY3VyYXRlIGJ5IHVzaW5nIOKAnG46buKAnSBhc3NvY2lh dGlvbiBpbiB0aGUgcGFzdC4NCj4gPiBSZWdhcmRpbmcgdGhlIGV4YW1wbGUgeW91IGxpc3QsIGlm IHRoZSBmb3VyIEJhbmR3aWR0aCBUTFZzIGFyZSBzZW50DQppbiB0aGUgc2FtZSBtZXNzYWdlLCBp dOKAmXMgYmV0dGVyIHRvIHVzZSBmb3VyIGRpZmZlcmVudCBpbmRleCB2YWx1ZXMgYXMgdGhleSBh cmUg4oCcbXVsdGlwbGUgRXRoZXJuZXQgQmFuZHdpZHRoIFByb2ZpbGUgVExWcyBoYXZlIGRpZmZl cmVudCBBdmFpbGFiaWxpdHkgcmVxdWlyZW1lbnRz4oCdLg0KPiA+IE9mIGNvdXJzZSB3aGF0IHlv dSBwcm9wb3NlZCBjb3VsZCBhbHNvIHdvcmsgdGVjaG5pY2FsbHkuDQo+ID4NCj4gPiBlcnJvciBj aGVja2luZzoNCj4gPg0KPiA+IE90aGVyIGRvY3VtZW50cyBpbiB0aGUgcmVmZXJlbmNlcyAoUkZD MjIwNSwgMzIwOSwgMzQ3MywgNjAwMywgZXRjKQ0KaGF2ZSBtYWRlIGEgcG9pbnQgb2YgZXhwbGlj aXRseSBkZXNjcmliaW5nIHRoZSBlcnJvciBoYW5kbGluZyAtIHdoZW4gUGF0aEVyciBhbmQgUmVz dkVyciBhbmQgTm90aWZ5IG1lc3NhZ2VzIGFyZSBzZW50LCB0byB3aG9tLCB0aGUgZXJyb3IgY29k ZXMsIHRoZSBlcnJvciB2YWx1ZSBzdWItY29kZXMsIGV0Yy4gIEkgZG9u4oCZdCBzZWUgdGhhdCBo ZXJlIGZvciB0aGUgYmFuZHdpZHRoLXRsdi10by1hdmFpbGFiaWxpdHktdGx2IGFzc29jaWF0aW9u cy4NCj4gPiBbQW15XSBUaGFua3MgZm9yIHRoZSBjb21tZW50LCBJIGFncmVlIHRoZSBlcnJvciBw cm9jZXNzIHNob3VsZCBiZQ0KY2xlYXJlci4NCj4gPiBJcyBhIG1peCBvZiBpbmRleC16ZXJvIGFu ZCBpbmRleC1ub24temVybw0KYmFuZHdpZHRoLXRsdi10by1hdmFpbGFiaWxpdHktdGx2IGFzc29j aWF0aW9ucyAobGlrZSBhYm92ZSkgYW4gZXJyb3I/IGlzIHRoZSBtZXNzYWdlIGRyb3BwZWQ/ICBp cyBhbiBlcnJvciBzZW50Pw0KPiA+IGlmIHRoZSBtZXNzYWdlIGlzIG5vdCBkcm9wcGVkLCBhcmUg YW55IG9mIHRoZSBiYW5kd2lkdGgtdGx2LA0KYXZhaWxhYmlsaXR5LXRsdiBhc3NvY2lhdGlvbnMg cmV0YWluZWQ/DQo+ID4gW0FteV0gVGhlIG1lc3NhZ2UgTUFZIGJlIGlnbm9yZWQgYW5kIFNIT1VM RCBOT1QgYmUgcHJvcGFnYXRlZC4NCj4gPiBJZiB0aGVyZSBhcmUgYXZhaWxhYmlsaXR5LXRsdnMg d2l0aCBub24temVybyBpbmRleGVzIHdpdGggbm8NCm1hdGNoaW5nIGluZGV4IHZhbHVlIGFtb25n IHRoZSBiYW5kd2lkdGgtdGx2cywgdGhhdCBzdXJlbHkgaXMgYW4gZXJyb3I/DQpJcyB0aGUgbWVz c2FnZSBkcm9wcGVkPyAgT3IgaXMgdGhlIGF2YWlsYWJpbGl0eSB0bHYgZHJvcHBlZD8gIElzIGEg UGF0aEVyci9SZXN2RXJyIG1lc3NhZ2Ugc2VudD8NCj4gPiBbQW15XSB5ZXMsIHRoaXMgaXMgYW4g ZXJyb3IuIEl04oCZcyBwcmVmZXJyZWQgdG8gZHJvcCB0aGUgYXZhaWxhYmlsaXR5DQp0bHYuDQo+ ID4gU3VwcG9zZSBhbGwgYXZhaWxhYmlsaXR5LXRsdnMgaGF2ZSBhIG1hdGNoaW5nICh6ZXJvIG9y IG5vbi16ZXJvKQ0KaW5kZXggdmFsdWUgYW1vbmcgdGhlIGJhbmR3aWR0aC10bHZzLCBidXQgdGhl cmUgYXJlIGV4dHJhIGJhbmR3aWR0aC10bHZzIChubyBhdmFpbGFiaWxpdHktdGx2IHdpdGggYSBt YXRjaGluZyBpbmRleCB2YWx1ZSkuICBJcyB0aGF0IGFuIGVycm9yPw0KQXJlIHRoZSBleHRyYSBi YW5kd2lkdGgtdGx2cyBkcm9wcGVkPyBpZ25vcmVkPyBwcm9wYWdhdGVkPw0KPiA+IFtBbXldVGhl IGV4dHJhIGJhbmR3aWR0aC10bHZzIE1BWSBiZSBpZ25vcmVkIGFuZCBTSE9VTEQgTk9UIGJlDQpw cm9wYWdhdGVkLg0KPiA+IChSRkMzMjA5IGhhcyBzZXZlcmFsIGNhc2VzIHdoZXJlIHRoZXJlIG1p Z2h0IGJlIGV4dHJhIG9iamVjdHMgb3INCnN1Yi1vYmplY3RzIGFuZCB0aGUgbGFuZ3VhZ2UgaXMg 4oCcY2FuIGJlL01BWSBiZS9TSE9VTEQgYmUvYXJlIGlnbm9yZWQgYW5kIFNIT1VMRCBOT1QgYmUg L2FyZSBub3QvbmVlZCBub3QgYmUgcHJvcGFnYXRlZOKAnSApDQo+ID4NCj4gPg0KPiA+IG11bHRp cGxpY2l0eToNCj4gPg0KPiA+IFJGQzMyMDkgc2F5cyBpdCBkb2VzIG5vdCBhcHBseSB0byBtdWx0 aWNhc3QsIGJ1dCBpdCBkb2VzIHRhbGsgYWJvdXQNCm11bHRpcGxlIHBhcmFsbGVsIExTUCB0dW5u ZWxzIGJldHdlZW4gdHdvIG5vZGVzLCBhbmQgYWJvdXQgbXVsdGlwb2ludC10by1wb2ludCBMU1Bz IGZvciBXRiBhbmQgU0Ugc3R5bGUgcmVzZXJ2YXRpb25zIHdoZW4gdGhlcmUgYXJlIG11bHRpcGxl IHNlbmRlcnMsIGFuZCBhYm91dCB0aGUgbWVyZ2luZyBydWxlcyBvZiBXRiByZXNlcnZhdGlvbnMu ICBEb2VzIGF2YWlsYWJpbGl0eSB3b3JrIGluIHRob3NlIHN0eWxlIHJlc2VydmF0aW9ucz8NCj4g PiBbQW15XSBDb25zaWRlcmluZyB0aGF0IHRoZSB0cmFmZmljIGZyb20gc2VuZGVycyBpcyBtb3Jl IGxpa2VseSB0byBiZQ0KY29uY3VycmVudCBhbmQgaW5kZXBlbmRlbnQsIHRoZSBhdmFpbGFiaWxp dHkgVExWIGNhbiBiZSBsaW1pdGVkIHRvIEZpeGVkIEZpbHRlciAoRkYpIFN0eWxlIG9ubHkuDQo+ ID4gYXZhaWxhYmlsaXR5IHZzIOKAnHZhcmlhYmxlIGRpc2NyZXRlIGJhbmR3aWR0aOKAnToNCj4g Pg0KPiA+IEkgYmVsaWV2ZSBJIHVuZGVyc3Rvb2QgdGhlIGRpc2N1c3Npb24gb2YgdGhlIG5lZWQg dG8gc2lnbmFsDQphdmFpbGFiaWxpdHkgcmVxdWlyZW1lbnRzIGluIG9yZGVyIGZvciB0aGUgc3lz dGVtIHRvIGRldGVybWluZSB3aGVuIGFuIExTUCB3YXMgZmVhc2libGUuICBJIGNhbiBkaW1seSB1 bmRlcnN0YW5kIHRoYXQgdGhlcmUgbWlnaHQgYmUgbGlua3MgaGF2ZSDigJx2YXJpYWJsZSBkaXNj cmV0ZSBiYW5kd2lkdGjigJ0uICBTZWN0aW9uIDIgc2F5cyDigJxUaGUgQXZhaWxhYmlsaXR5IFRM ViBjYW4gYmUgYXBwbGljYWJsZSB0byBhbnkga2luZCBvZiBwaHlzaWNhbCBsaW5rcyB3aXRoIHZh cmlhYmxlIGRpc2NyZXRlIGJhbmR3aWR0aCwgc3VjaCBhcyBtaWNyb3dhdmUgb3IgRFNMLuKAnQ0K PiA+IFdoeSBub3Qgb3RoZXIgbGluayB0eXBlcz8gRG8gb25seSDigJx2YXJpYWJsZSBkaXNjcmV0 ZSBiYW5kd2lkdGjigJ0NCmxpbmtzIHN1cHBvcnQgYXZhaWxhYmlsaXR5Pw0KPiA+IFtBbXldIFRv IG91ciBjdXJyZW50IGtub3dsZWRnZSwgb25seeKAnHZhcmlhYmxlIGRpc2NyZXRlIGJhbmR3aWR0 aOKAnQ0KbGlua3Mgc3VwcG9ydCBhdmFpbGFiaWxpdHkuDQo+ID4NCj4gPiBjYWxjdWxhdGluZyBh dmFpbGFiaWxpdHk6DQo+ID4NCj4gPiBJbiBwYWdlIDksIEFwcGVuZGl4IEE6DQo+ID4NCj4gPiBQ ZXJoYXBzIEkgZG9u4oCZdCB1bmRlcnN0YW5kIGhvdyB0aGUgYXZhaWxhYmlsaXR5IG1ldHJpYyBp cyB1c2VkLiAgSW4NCnRoZQ0KPiA+IGZvbGxvd2luZzoNCj4gPg0KPiA+ICAgIE9uIGEgc3Vubnkg ZGF5LCB0aGUgbW9kdWxhdGlvbiBsZXZlbCAzIGNhbiBiZSB1c2VkIHRvIGFjaGlldmUgNDAwDQo+ ID4gICAgTWJwcyBsaW5rIGJhbmR3aWR0aC4NCj4gPg0KPiA+ICAgIEEgbGlnaHQgcmFpbiB3aXRo IFggbW0vaCByYXRlIHRyaWdnZXJzIHRoZSBzeXN0ZW0gdG8gY2hhbmdlIHRoZQ0KPiA+ICAgIG1v ZHVsYXRpb24gbGV2ZWwgZnJvbSBsZXZlbCAzIHRvIGxldmVsIDIsIHdpdGggYmFuZHdpZHRoIGNo YW5naW5nDQo+ID4gICAgZnJvbSA0MDAgTWJwcyB0byAyMDAgTWJwcy4gVGhlIHByb2JhYmlsaXR5 IG9mIFggbW0vaCByYWluIGluIHRoZQ0KPiA+ICAgIGxvY2FsIGFyZWEgaXMgNTIgbWludXRlcyBp biBhIHllYXIuIFRoZW4gdGhlIGRyb3BwZWQgMjAwIE1icHMNCj4gPiAgICBiYW5kd2lkdGggaGFz IDk5Ljk5JSBhdmFpbGFiaWxpdHkuDQo+ID4NCj4gPiBJIHdvdWxkIHNheSB0aGF0IHRoZSA0MDBN YnBzIGJhbmR3aWR0aCBpcyBhdmFpbGFibGUgd2hlbmV2ZXIgaXQgaXMNCm5vdCByYWluaW5nLg0K PiA+IEl0IGxpZ2h0bHkgcmFpbnMgNTIgbWluIHllYXIsIHdoaWNoIG1lYW5zIGl0IGlzIG5vdCBy YWluaW5nIDk5Ljk5JQ0Kb2YgdGhlIHRpbWUsIHNvIHRoZSA0MDBNYnBzIGF2YWlsYWJpbGl0eSBp cyA5OS45OSUuICBUaGUgMjAwTWJwcyBpcyBhdmFpbGFibGUgZHVyaW5nIHRoYXQgNTIgbWluLCBz byA5OS45OSUgaXMgbm90IHRoZSAyMDBNYnBzIGF2YWlsYWJpbGl0eS4NClJpZ2h0Pw0KPiA+DQo+ ID4gVGhlIGFuYWxvZ291cyBjb21tZW50IGFwcGxpZXMgdG8gdGhlIG5leHQgdHdvIHBhcmFncmFw aHMuDQo+ID4NCj4gPiBEb2VzIHRoYXQgZXhwbGFpbiB3aHkgdGhlIHRhYmxlIHNob3dzIHRoZSAx MDBNYnBzIGJhbmR3aWR0aCBoYXZpbmcNCnR3byBkaWZmZXJlbnQgYXZhaWxhYmlsaXRpZXM/DQo+ ID4gW0FteV1Zb3VyIHVuZGVyc3RhbmRpbmcgaXMgYWxzbyBjb3JyZWN0LiBUaGF0IGlzIGp1c3Qg YSBkaWZmZXJlbnQNCndheSB0byBwcmVzZW50IHRoZSByZXN1bHQuIFRha2UgdGhlIHZhbHVlcyBm cm9tIHRoZSB0YWJsZSwgMTAwTWJwcyB3aXRoIDk5Ljk5NSUgYW5kIDEwME1icHMgd2l0aCA5OS45 OTklIGNhbiBiZSBhbHNvIGNvbnNpZGVyZWQgYXMgYmFuZHdpZHRoIHdpdGggOTkuOTklIGF2YWls YWJpbGl0eS4NCj4gPiBUaHVzIGl0IHdpbGwgcmVzdWx0IHRoZSB0b3RhbCBidyB3aXRoIDk5Ljk5 JSBhdmFpbGFiaWxpdHkgPQ0KMjAwKzEwMCsxMDA9NDAwTWJwcw0KPiA+DQo+ID4NCj4gPiBzZWN1 cml0eToNCj4gPg0KPiA+IFRoZSBkcmFmdCAoKikgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBwb2lu dHMgdG8gUlNWUC1URSwgYnV0IHdpdGhvdXQNCmFuIFJGQyByZWZlcmVuY2UsIGFuZCB0byBSRkM1 OTIwLiAgQmVjYXVzZSB0aGlzIGlzIGEgR01QTFMgcmVsYXRlZCBmZWF0dXJlLCBpdCBzaG91bGQg cmVmZXIgdG8gdGhlIEdNUExTIGV4dGVuc2lvbnMgdG8gUlNWUC1URSBpbiBSRkMzNDczLg0KQXMg YW4gZXh0ZW5zaW9uIHRvIFJGQzYwMDMsIGl0IGNvdWxkIHJlZmVyIHRvIHRoYXQgUkZD4oCZcyBz ZWN1cml0eSBjb25zaWRlcmF0aW9ucyBzZWN0aW9uLCBidXQgdGhhdCBvbmx5IGdldHMgdGhlIHJl YWRlciB0byBSRkMzNDczLCBSRkMzMjA5LCBhbmQgUkZDNTkyMC4NCj4gPg0KPiA+IFRoZSBzZWN1 cml0eSBjb25zaWRlcmF0aW9ucyBmb3IgUlNWUC1URSBpdHNlbGYgKFJGQzMyMDkpIHBvaW50cyB0 bw0KUkZDMjIwNS4NCj4gPiBSRkMyMjA1IGRlZmluZXMgYW4gSW50ZWdyaXR5IG9iamVjdCAoZGVm aW5lZCBpbiBSRkMyNzQ3KSB0aGF0DQpjYXJyaWVzIGEga2V5ZWQgY3J5cHRvZ3JhcGhpYyBkaWdl c3QgYmFzZWQgb24gYSBzaGFyZWQga2V5LCBwcm92aWRpbmcgaG9wLWJ5LWhvcCBwcm90ZWN0aW9u IGJldHdlZW4gdHdvIFJTVlAgbm9kZXMuICBIb3dldmVyLCBQQVRIIG1lc3NhZ2VzIGFyZSBkaXJl Y3RlZCB0b3dhcmQgdGhlIHRyYWZmaWMgZGVzdGluYXRpb24gYWRkcmVzcywgbm90IHRoZSBuZXh0 IFJTVlAgbm9kZS4gIFRoZXJlIGNvdWxkIGJlIGNsb3VkcyBvZiBub24tUlNWUCBub2RlcyBiZXR3 ZWVuIHR3byBSU1ZQIG5vZGVzIHRoYXQgdGhlIFBBVEggZW5jb3VudGVycy4gIFRoaXMgbWFrZXMg aXQgZGlmZmljdWx0IHRvIHNoYXJlIGEga2V5IGJldHdlZW4gaW5kaXZpZHVhbCBwYWlycyBvZiBS U1ZQIG5vZGVzLCBhbmQgY291bGQgbW90aXZhdGUgb3BlcmF0b3JzIHRvIGNvbmZpZ3VyZSB0aGUg c2FtZSBrZXkgaW4gbGFyZ2UgbnVtYmVycyBvZiBSU1ZQIG5vZGVzLg0KPiA+DQo+ID4gUkZDMzQ3 MyBwb2ludHMgdG8gUkZDMjc0N+KAmXMgcHJvdGVjdGlvbiBvZiBSU1ZQIG1lc3NhZ2VzLiAgSXQg YWxzbw0Kbm90ZXMgdGhhdCBpdCBpbnRyb2R1Y2VzIGEgTm90aWZ5IG1lc3NhZ2UgdGhhdCBpcyBu b3Qgc2VudCB0byB0aGUgdHJhZmZpYyBkZXN0aW5hdGlvbiBhZGRyZXNzIGJ1dCBpbnN0ZWFkIHRv IGEgbm9kZSB0aGF0IHJlcXVlc3RlZCBub3RpZmljYXRpb24uICBPbmUgdHJhbnNtaXNzaW9uIG9w dGlvbiBpcyB0aGF0IHRoZSBOT1RJRlkgaXMgZW5jYXBzdWxhdGVkIGluIGFuIElQIHBhY2tldCBh bmQgZm9yd2FyZGVkIGRpcmVjdGx5IHRvIHRoZSByZXF1ZXN0aW5nIG5vZGUuICBUaGF0IGNvbXBs aWNhdGVzIHRoZSBJbnRlZ3JpdHkgb2JqZWN0IHByb3RlY3Rpb24sIHVubGVzcyB0aGUgc2hhcmVk IGtleSBpcyB3aWRlbHkgc2hhcmVkLg0KPiA+DQo+ID4gUkZDMzk0NSBub3RlcyB0aGF0IGF1dGhl bnRpY2F0aW9uIGluIEdNUExTIHN5c3RlbXMgbWF5IHVzZSB0aGUNCmF1dGhlbnRpY2F0aW9uIG1l Y2hhbmlzbXMgb2YgdGhlIGNvbXBvbmVudCBwcm90b2NvbHMsIHBvaW50aW5nIHRvDQpSRkMyNzQ3 IChhcyB3ZWxsIGFzIG90aGVycyBmb3IgTERQLCBMTVAsIGV0YyB0aGF0IGRvbuKAmXQgYXBwbHkg aGVyZSkuDQo+ID4NCj4gPiBSRkM1OTIwIGRpc2N1c3NlcyB0aHJlYXRzLCBhdHRhY2tzLCBhbmQg cHJvdGVjdGlvbnMgZm9yIE1QTFMvR01QTFMNCmRhdGEgYW5kIGNvbnRyb2wgcGxhbmVzLiAgU2Vj dGlvbiA3LjEuMiBpbiBwYXJ0aWN1bGFyIHRhbGtzIGFib3V0IOKAnENvbnRyb2wtUGxhbmUgUHJv dGVjdGlvbiB3aXRoIFJTVlAtVEXigJ0sIGFuZCBjb3VsZCBiZSBtZW50aW9uZWQgaGVyZSBleHBs aWNpdGx5LiAgSXQgdGFsa3MgYWJvdXQgbmV0d29yayBib3JkZXIgY29uZmlndXJhdGlvbiB0byBs aW1pdCBleHRlcm5hbCBhdHRhY2tzLCBhbmQgbWVudGlvbnMNCj4gPiBSRkMyNzQ3IGF1dGhlbnRp Y2F0aW9uIHByb3RlY3Rpb25zLCBtYWtpbmcgc29tZSBvZiB0aGUgc2FtZSBwb2ludHMNCmFib3V0 IG5vbi1SU1ZQIGNsb3VkcyBhbmQgc2hhcmVkIGtleXMgY29uZmlndXJhdGlvbi4gIEl0IGFsc28g cG9pbnRzIHRvIFJGQzQyMzAsIHdoaWNoIGlzIGEgdmVyeSBkZXRhaWxlZCBsb29rIGF0IFJTVlAg c2VjdXJpdHksIGFuZCBwcm9iYWJseSBkZXNlcnZlcyB0byBiZSBtZW50aW9uZWQgaGVyZS4NCj4g Pg0KPiA+IFNvIGFsbCB0b2xkLCBhdCB0aGUgZW5kIG9mIGFsbCB0aGUgcmVmZXJlbmNlIGNoYWlu cywgdGhlIG9ubHkNCmRlZmluZWQgYXV0aGVudGljYXRpb24gYW5kIGludGVncml0eSBwcm90ZWN0 aW9uIGluIDIyMDUsIDMyMDksIGFuZCAzNDczIGlzIGJhc2VkIG9uIHNoYXJlZCBrZXlzIHRoYXQg YXJlIHZlcnkgZGlmZmljdWx0IHRvIGNvbmZpZ3VyZSB3aXRoIGZpbmUgZ3JhbnVsYXJpdHkuDQo+ ID4NCj4gPiBIb3dldmVyLCBhcyB3YXMgc2FpZCBpbiByZXBseSB0byBhIGRpZmZlcmVudCBNUExT IHJlbGF0ZWQgZHJhZnQNCnJldmlldw0KPiA+IHllc3RlcmRheToNCj4gPg0KPiA+ICAgICBUaGUg TVBMUyBuZXR3b3JrIGlzIG9mdGVuIGNvbnNpZGVyZWQgdG8gYmUgYSBjbG9zZWQgbmV0d29yayBz dWNoDQp0aGF0DQo+ID4gICAgIGluc2VydGlvbiwgbW9kaWZpY2F0aW9uLCBvciBpbnNwZWN0aW9u IG9mIHBhY2tldHMgYnkgYW4gb3V0c2lkZQ0KcGFydHkgaXMNCj4gPiAgICAgbm90IHBvc3NpYmxl Lg0KPiA+DQo+ID4gU28gbWF5YmUgdGhhdCBpcyBhY2NlcHRlZCBhcyBzdWZmaWNpZW50IGluIGRl cGxveW1lbnQuDQo+ID4NCj4gPiBNUExTIGRvY3VtZW50cyBhcmUgYWxzbyB0eXBpY2FsbHkgZ3Jh bnRlZCBhbiBleGNlcHRpb24gZnJvbSBtb3JlDQpyaWdvcm91cyBzZWN1cml0eSByZXF1aXJlbWVu dHMgYmVjYXVzZSBNUExTIGlzIHVzZWQgb25seSB3aXRoaW4gb25lIHJvdXRpbmcgZG9tYWluIC8g SVNQIC8gcHJvdmlkZXIgLyBldGMsIHVuZGVyIGEgc2luZ2xlIGFkbWluaXN0cmF0aXZlIGNvbnRy b2wsIHNvIGVycm9ycyBtYWRlIHdvdWxkIG5vdCBiZSBnbG9iYWwgaW4gaW1wYWN0LiAgSW4gcGFy dGljdWxhciwgZXJyb3JzIHRoYXQgbWlnaHQgcmVzdWx0IGZyb20gb25lIGxlZ2l0aW1hdGUgYnV0 IGZhdWx0eS9taXMtY29uZmlndXJlZC9zdWJ2ZXJ0ZWQvbWFsaWNpb3VzIE1QTFMgbm9kZSBzaG91 bGQgbm90IHByb3BhZ2F0ZSBvdXQgdG8gdGhlIGdlbmVyYWwgSW50ZXJuZXQuICAoKiopDQo+ID4g W0FteV0gVGhhbmtzIGZvciB0aGUgZGV0YWlsIGV4cGxhbmF0aW9uIG9uIHRoZSBzZWN1cml0eQ0K Y29uc2lkZXJhdGlvbiwgaXTigJlzIHF1aWV0IGVkdWNhdGlvbmFsLiBBcyB0aGUgb3BlcmF0aW5n IGVudmlyb25tZW50IG9mIEdNUExTIGlzIHNpbWlsYXIgdG8gTVBMUyBuZXR3b3JrLCB3ZSB3aWxs IGFkb3B0IHRoZSBzaW1pbGFyIHRleHQuDQo+ID4NCj4gPiBOaXRzOg0KPiA+DQo+ID4gZmxvYXRp bmcgbnVtYmVycw0KPiA+DQo+ID4gUGFnZSA1LCBTZWN0aW9uIDMuMSwgc2F5cyDigJxhIDMyLWJp dCBmbG9hdGluZyBudW1iZXLigJ0uICBJIGJlbGlldmUgeW91DQptZWFuIGEgZmxvYXRpbmctcG9p bnQgbnVtYmVyLiAgSSBjaGVja2VkIG90aGVyIElFVEYgUkZDcyAoZS5nLiwgUkZDODMzMCksIGFu ZCBpdCBpcyBjb21tb24gdG8gbWVudGlvbiB0aGUgSUVFRSA3NTQtMjAwOCBzdGFuZGFyZCB3aGVu IGluY2x1ZGluZyBhIGZsb2F0aW5nIHBvaW50IHZhbHVlIGluIHRoZSBzcGVjLg0KPiA+DQo+ID4g QnV0IGlzIGEgZmxvYXRpbmcgcG9pbnQgdmFsdWUgbmVlZGVkPyAgVGhlIGRyYWZ0IHNheXMgdGhh dCB0aGUNCnZhbHVlcyBhcmUgdHlwaWNhbGx5IGluIGEgc21hbGwgc2V0IG9mIGtub3duIHZhbHVl cy4gIFRoZSBpbnRybyBzb3VuZHMgbGlrZSBhIHNtYWxsIHNldCBvZiBjbGFzc2VzIGFyZSB1c2Vk IGZvciDigJxlZmZpY2llbnQgcGxhbm5pbmfigJ0uICBKdXN0IGN1cmlvdXMuICBPVE9ILCBSRkM4 MzMwIHVzZXMgZmxvYXRpbmcgcG9pbnQsIGFuZCB0aGUgSVRVIGRvY3VtZW50c+KAmQ0KY2FsY3Vs YXRpb24gb2YgYXZhaWxhYmlsaXR5IG1ha2UgaXQgc2VlbSBsaWtlIGZ1bGwgZmxvYXRpbmcgcG9p bnQgaXMgbmVlZGVkLg0KPiA+IFtBbXldIHdpbGwgdXBkYXRlIHRvIOKAnGZsb2F0aW5nLXBvaW50 IG51bWJlcuKAnS4NCj4gPg0KPiA+IHRoZSBBdmFpbGFiaWxpdHkgVExWIGZvcm1hdDoNCj4gPg0K PiA+IHBhZ2UgNSwgc2VjdGlvbiAzLjEgc2F5czoNCj4gPg0KPiA+ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgVGhlIEF2YWlsYWJpbGl0eSBUTFYNCmhhcw0K PiA+ICAgIHRoZSBmb2xsb3dpbmcgZm9ybWF0Og0KPiA+DQo+ID4gICAgICAgIDAgICAgICAgICAg ICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCj4gPiAg ICAgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1 IDYgNyA4IDkgMA0KMQ0KPiA+DQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiA+ICAgICAgIHwgICAgSW5kZXggICAgICB8 ICAgICAgICAgICAgICAgICBSZXNlcnZlZA0KfA0KPiA+DQorLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiA+ICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgIEF2YWlsYWJpbGl0eQ0KfA0KPiA+DQorLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0K PiA+DQo+ID4gICAgICAgICAgICAgICAgICAgICAgICAgICBGaWd1cmUgMTogQXZhaWxhYmlsaXR5 IFRMVg0KPiA+DQo+ID4gSSBwcmVzdW1lIHRoYXQgdGhpcyBpcyBqdXN0IHRoZSBWYWx1ZSBwb3J0 aW9uIG9mIHRoZSBUTFYgZm9ybWF0IHRoYXQNCmlzIGRlZmluZWQgZm9yIHRoZSBFdGhlcm5ldCBT RU5ERVJfVFNQRUMgT2JqZWN0IGluIFNlY3Rpb24gNCBvZiBSRkM2MDAzLg0KPiA+IFtBbXldIFll cywgaXQgaXMuDQo+ID4NCj4gPiBQYWdlIDEsIEFic3RyYWN0Og0KPiA+DQo+ID4gICAgdHlwaWNh bGx5IHVzZWQgZm9yIGRlc2NyaWJpbmcgdGhlc2UgbGlua3Mgd2hlbiBkdXJpbmcgbmV0d29yaw0K PiA+ICAgIHBsYW5uaW5nDQo+ID4NCj4gPiDigJx3aGVuIGR1cmluZ+KAnSAtIGlzIHRoYXQgZGVs aWJlcmF0ZT8gIEl0IHNvdW5kcyByZWR1bmRhbnQsIG1heWJlIGR1ZQ0KdG8gZWRpdGluZy4NCj4g PiBPciBtYXliZSBpdCB3YXMgc3VwcG9zZWQgdG8gYmUg4oCcd2hlbiBkb2luZ+KAnT8NCj4gPiBb QW15XSBXaWxsIHVwZGF0ZSB0byDigJx3aGVuIGRvaW5n4oCdLg0KPiA+DQo+ID4gICAgc2lnbmFs aW5nLiBUaGlzIGV4dGVuc2lvbiBjYW4gYmUgdXNlZCB0byBzZXQgdXAgYSBHZW5lcmFsaXplZA0K TXVsdGktDQo+ID4gICAgUHJvdG9jb2wgTGFiZWwgU3dpdGNoaW5nIChHTVBMUykgTGFiZWwgU3dp dGNoZWQgUGF0aCAoTFNQKSB1c2luZw0KdGhlDQo+ID4gICAgRXRoZXJuZXQgU0VOREVSX1RTUEVD IG9iamVjdC4NCj4gPg0KPiA+IG5vdCBzdXJlIC0gd2hhdCBpcyB1c2luZyB0aGUgU0VOREVSX1RT UEVDIC0gdGhlIExTUCBvciB0aGlzDQpleHRlbnNpb24/DQo+ID4gW0FteV0gSG93IGFib3V0IGNo YW5nZSB0byDigJxpbiBjb25qdW5jdGlvbiB3aXRoIFNFTkRFUl9UU1BFQ+KAnS4NCj4gPg0KPiA+ IFBhZ2UgMywgU2VjdGlvbiAxOg0KPiA+DQo+ID4gICAgYmFuZHdpZHRoIGF2YWlsYWJpbGl0eS4g Rm9yIGV4YW1wbGUsIHRoZSBiYW5kd2lkdGggd2l0aCA5OS45OTklDQo+ID4gICAgYXZhaWxhYmls aXR5IG9mIGEgbGluayBpcyAxMDAgTWJwczsgdGhlIGJhbmR3aWR0aCB3aXRoIDk5Ljk5JQ0KPiA+ ICAgIGF2YWlsYWJpbGl0eSBpcyAyMDAgTWJwcy4NCj4gPg0KPiA+IG1heWJlOg0KPiA+DQo+ID4g ICAgYmFuZHdpZHRoIGF2YWlsYWJpbGl0eS4gU3VwcG9zZSwgZm9yIGV4YW1wbGUsIHRoZSBiYW5k d2lkdGggd2l0aA0KOTkuOTk5JQ0KPiA+IFtBbXldIHdpbGwgdXBkYXRlIHRoZSB0ZXh0Lg0KPiA+ DQo+ID4gUGFnZSA1LCBzZWN0aW9uIDMuMjoNCj4gPg0KPiA+ICAgIFRMVnMgYW5kIG9uZSBvciBt b3JlIEF2YWlsYWJpbGl0eSBUTFZzLiBFYWNoIEV0aGVybmV0IEJhbmR3aWR0aA0KPiA+ICAgIFBy b2ZpbGUgVExWIGNvcnJlc3BvbmRzIHRvIGFuIGF2YWlsYWJpbGl0eSBwYXJhbWV0ZXIgaW4gdGhl DQo+ID4gICAgQXZhaWxhYmlsaXR5IFRMVi4NCj4gPg0KPiA+IOKApiDigJxpbiBhbiBBdmFpbGFi aWxpdHkgVExW4oCdPyBvciDigJxpbiB0aGUgYXNzb2NpYXRlZCBBdmFpbGFiaWxpdHkgVExW4oCd Pw0KVGhlcmXigJlzIG1vcmUgdGhhbiBvbmUuDQo+ID4gW0FteV0gd2lsbCB1cGRhdGUgdG8g4oCc aW4gdGhlIGFzc29jaWF0ZWQgQXZhaWxhYmlsaXR5IFRMVuKAnS4NCj4gPg0KPiA+IFBhZ2UgNiwg c2VjdGlvbiAzLjINCj4gPg0KPiA+ICAgICAgICAgbGluayksIGl0IFNIT1VMRCByZXNlcnZlIHRo ZSBiYW5kd2lkdGggcmVzb3VyY2UgZnJvbSBlYWNoDQo+ID4NCj4gPiDigJxpdOKAnSAtPiDigJx0 aGUgbm9kZeKAnQ0KPiA+DQo+ID4gICAgICAgIHRoaXMgTFNQLiBPcHRpb25hbGx5LCB0aGUgaGln aGVyIGF2YWlsYWJpbGl0eSBiYW5kd2lkdGggY2FuDQpiZQ0KPiA+DQo+ID4g4oCcdGhlIGhpZ2hl cuKAnSAtPiDigJxhIGhpZ2hlcuKAnSAgKHRoZXJl4oCZcyBtb3JlIHRoYW4gb25lLCByaWdodD8p DQo+ID4NCj4gPiAgICAgICAgIHJlcXVlc3QgY2Fubm90IGJlIHNhdGlzZmllZCwgaXQgU0hPVUxE IGdlbmVyYXRlIFBhdGhFcnINCm1lc3NhZ2UNCj4gPg0KPiA+IOKAnGl04oCdIC0+IOKAnHRoZSBu b2Rl4oCdDQo+ID4NCj4gPiAgICBnZW5lcmF0ZSBQYXRoRXJyIG1lc3NhZ2Ugd2l0aCB0aGUgZXJy b3IgY29kZSAiRXh0ZW5kZWQgQ2xhc3MtVHlwZQ0KPiA+DQo+ID4g4oCcUGF0aEVycuKAnSAtPiDi gJxhIFBhdGhFcnLigJ0gb3Ig4oCcUGF0aEVyciBtZXNzYWdlc+KAnQ0KPiA+IFtBbXldIHdpbGwg dXBkYXRlIHRoZSBkcmFmdCBhY2NvcmRpbmdseS4NCj4gPiBwb3N0c2NyaXB0czoNCj4gPg0KPiA+ ICgqKikgW1tbIEkgd2lsbCBub3RlIHRoYXQgUkZDMzIwOSBpbmNsdWRlcyBhbiBBUyBudW1iZXIg c3ViamVjdA0KYW1vbmcgdGhlIHN1Ym9iamVjdHMgb2YgdGhlIEVYUExJQ0lUX1JPVVRFIG9iamVj dC4gIFdpdGggdGhlIGlkZWEgdGhhdCB5b3UgbWlnaHQgc2V0IHVwIGV4cGxpY2l0IHJvdXRlcyB0 aGF0IGdvIHRocm91Z2ggbXVsdGlwbGUgQVNOcy4gIE91Y2guDQpJIGtub3cgdGhlcmUgYXJlIHBy b3ZpZGVycyB3aG8gaGF2ZSBkaWZmZXJlbnQgQVNOcyB1bmRlciBzaW5nbGUgYWRtaW5pc3RyYXRp dmUgY29udHJvbCwgZnJvbSBhY3F1aXNpdGlvbnMgb3IgYnVzaW5lc3MgdXNlIGNhc2VzLCBidXQg dGhpcyBqdXN0IG1ha2VzIGl0IHBvc3NpYmxlIGZvciBhbiBleHBsaWNpdCByb3V0ZSBmb3IgYW4g TFNQIHRvIGJlIG1pc2NvbmZpZ3VyZWQgdG8gaW5jbHVkZSB5b3VyIChleHRlcm5hbCkgbmVpZ2hi b3IgQVNOLiAgQW5kIFJGQzU5MjAgdGFsa3MgYWJvdXQg4oCcQVNCUi1BU0JSIGNvbW11bmljYXRp b24gZm9yIGludGVyLUFTIExTUHPigJ0uICBCZXR0ZXIgaGF2ZSBnb29kIG91dGJvdW5kIGZpbHRl cnMgb24geW91ciBib3JkZXIgcm91dGVycy4gXV1dDQo+ID4NCj4gPiAoKilBcyBpcyB0eXBpY2Fs IGZvciBzcGVjaWZpY2F0aW9ucyB0aGF0IGV4dGVuZCBvdGhlciBwdWJsaXNoZWQNClJGQ3MsIHRo aXMgZHJhZnQgc2F5cyBpdCDigJxkb2VzIG5vdCBpbnRyb2R1Y2UgYW55IG5ldyBzZWN1cml0eSBj b25zaWRlcmF0aW9uc+KAnS4NCj4gPg0KPiA+IDxiZWdpbiBzb2FwYm94PiBJbiBnZW5lcmFsLCBJ IGFtIHNrZXB0aWNhbCBvZiBleHRlbnNpb24gZHJhZnRzIHRoYXQNCm1ha2Ugc3VjaCBjbGFpbXMu ICBTdXJlbHkgdGhlIGV4aXN0aW5nIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHNob3VsZCBiZSBl eGFtaW5lZCB0byBzZWUgaG93IHRoZXkgYXBwbHkgdG8gdGhpcyBuZXcgZmVhdHVyZSBvciBvYmpl Y3QgYmVpbmcgaW50cm9kdWNlZD8gIERvIGN1cnJlbnQgcHJvdGVjdGlvbnMgYWRlcXVhdGVseSBw cm90ZWN0IHRoZSBuZXcgZmVhdHVyZS9vYmplY3Q/ICBEb2VzIHRoZSBuZXcgZmVhdHVyZS9vYmpl Y3QgY2FycnkgbmV3IGluZm9ybWF0aW9uLCBwcm9kdWNlIG5ldyBiZWhhdmlvcnM/ICBldGMuIEJ1 dCB0aGlzIGlzIHNvIHZlcnkgY29tbW9uIEkgY291bGQgaGFyZGx5IHJlcXVlc3QgdGhhdCBtb3Jl IGJlIHNhaWQgaGVyZS4gSnVzdCBzYXlpbmcuIDxlbmQNCj4gPiBzb2FwYm94Pg0KPiA+IFtBbXld IFRoYW5rcyBhZ2FpbiBmb3IgdGhlIGRldGFpbCByZXZpZXcuDQo+DQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IENDQU1QIG1haWxpbmcgbGlzdA0K PiBDQ0FNUEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2NjYW1wDQo+DQoNCg== From nobody Wed Apr 3 15:07:10 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473E61202A6 for ; Wed, 3 Apr 2019 15:07:05 -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=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zeibDU5dCKz2 for ; Wed, 3 Apr 2019 15:07:04 -0700 (PDT) Received: from outbound-ss-879.bluehost.com (outbound-ss-879.bluehost.com [69.89.30.202]) (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 C3CAA120161 for ; Wed, 3 Apr 2019 15:07:03 -0700 (PDT) Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 20ED31E0AA8 for ; Wed, 3 Apr 2019 16:06:59 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id Bo26hjhbJVLCbBo26hE78Q; Wed, 03 Apr 2019 16:06:59 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: $(_cmae_reason DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=EVFLSlff3169fHxVIx7BmZdbAN+X+HYRKuKOIht76G0=; b=w4hXRXVkZeAnSc7HaPU8kFhPcM TY5NDh+EUzt2RqHnMG9zEWByk/Hee7zoc9IjIKat8hdy2b2p2a2N5q2xFgz2S6txEFAZv1n50MJul GFV+Kk9rMGqx25U6sknVoP2Qp; Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:47382 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hBo26-000ow6-On; Wed, 03 Apr 2019 16:06:58 -0600 To: Stephen Kent , secdir@ietf.org Cc: draft-ietf-manet-dlep-pause-extension.all@ietf.org, manet@ietf.org, ietf@ietf.org References: <155309526492.14741.18141095676597911076@ietfa.amsl.com> From: Lou Berger Message-ID: <6dddf23c-806a-d8ab-7f65-ac7b0855deac@labn.net> Date: Wed, 3 Apr 2019 18:06:57 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <155309526492.14741.18141095676597911076@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 72.66.11.201 X-Source-L: No X-Exim-ID: 1hBo26-000ow6-On X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([IPv6:::1]) [72.66.11.201]:47382 X-Source-Auth: lberger@labn.net X-Email-Count: 2 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-manet-dlep-pause-extension-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 22:07:08 -0000 Hi Steve, Thanks for the comments! On 3/20/2019 11:21 AM, Stephen Kent via Datatracker wrote: > Reviewer: Stephen Kent > Review result: Has Nits > > I have reviewed this document as part of the security directorate's ongoing > effort to review all IETF documents being processed by the IESG. These > comments were written with the intent of improving security requirements and > considerations in IETF drafts. Comments not addressed in last call may be > included in AD reviews during the IESG review. Document editors and WG chairs > should treat these comments just like any other last call comments. > > Review Summary: Ready with nits > > This brief document defines and extension to DLEP That enables a modem to use > DLEP to pause and resume inbound traffic from a specific peer. DLEP (RFC 8175) > cites GTSM as a security mechanism, which is rather weak, but it says that > implementations SHOULD use TLS (1.2), which is fine. > > The text states that “An example of when a modem might send this data item is > when an internal queue length exceeds a particular threshold.” However, all of > details of this data item seem to focus exclusively on queues. Thus it seems > likely that this is not just an example, but, rather, the primary motivation > for introducing the pause extension. A slight rewording of the text here seems > appropriate, or the authors could describe other (not-queue-based) examples. fair point, how about: OLD:   An example of when a modem might send   this data item is when an internal queue length exceeds a particular   threshold. NEW: The motivating use case is for this data item is when a modem's internal queue length exceeds a particular threshold.  Other use cases are possible, e.g., when there a non queue related congestion points within a modem, but such are not explicitly described in this document. > The Security Considerations section of 8175 addresses a reasonable range of > concerns. Thus it is appropriate that this document’s Security Considerations > section is very brief, as it cites the corresponding section in 8175. I suggest > a couple of minor change to the wording here: > > “The extension does not inherently introduce any additional threats … > -> > “The extension does not inherently introduce any additional vulnerabilities …” > > “ … but this is not a substantively different threat by …” > -> > “ … but this is not a substantively different attack by …” > > There are numerous examples of awkward/poor phrasing throughout the document, > which I hope the RFC Editor will correct, e.g., > > Abstract: > “…to the DLEP protocol …” -> “… to DLEP …” Hopefully these have already been corrected, if not I'm sure the editor will help us out. > page 7: > > “A modem can indicate that traffic is to be suppressed on a device wide or > destination specific basis.” > > “A modem can indicate that traffic is to be suppressed on a device- wide or > destination-specific basis.” Thanks. > “This includes that to indicate that transmission can resume to all > destinations …” > > “Thus, to indicate that transmission can resume to all destinations, …” I'm not sure thus is quite right, but will revise! Thanks again!, Lou > > From nobody Wed Apr 3 16:02:33 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE671202C9; Wed, 3 Apr 2019 16:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=open-xchange.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 j0A_3lbhmSJX; Wed, 3 Apr 2019 16:02:15 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 363CA1202C3; Wed, 3 Apr 2019 16:02:11 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 5A4CE6A23E; Thu, 4 Apr 2019 01:02:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1554332529; bh=g6+yXZ7MDPLLd5tx4QFAlN/fO641wK1AKjG2k78K3M4=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=7JBBhIcBddzRbIEOHVZYV684VJ4hGUuloY8X6Q4j8x6c3lMRBMJEun9932bngHhEV bjGXMbbUwqNim7mUxvB+Lm/Lfj1hx6+B2vFohHEG/cAuCcIinz7xeU36+tmaHB83jI xv9N2SIXVGk+2YtyS+M4ixZOaVpe9SjvXS/2NrOiC2EAQ2PCtMOpmMB56dDkymVvfY DyrdfnbQnsq4ZcHwNLmENHYmxqKTsE6VepeL/r4VTBrtCpVJyHsbQ97LICE1ql80ch tgGZqiaHXwKQ7lhjyYcOxLa6Tw1LTZcoLRi9lCN5zS6RtdbyaIx9VkPEYey2uhsNwb NuXtzDMdRmXcg== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id 4CF3C3C0399; Thu, 4 Apr 2019 01:02:09 +0200 (CEST) Date: Wed, 3 Apr 2019 17:02:09 -0600 (MDT) From: Michael Slusarz To: Stefan Santesson , Stefan Santesson via Datatracker , secdir@ietf.org Cc: extra@ietf.org, ietf@ietf.org, draft-ietf-extra-imap-fetch-preview.all@ietf.org Message-ID: <400432883.3939.1554332529253@appsuite.open-xchange.com> In-Reply-To: <155325148211.23112.1549884159837912898@ietfa.amsl.com> References: <155325148211.23112.1549884159837912898@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.1-Rev10 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-extra-imap-fetch-preview-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2019 23:02:18 -0000 Hello Stefan, Thanks for your review. Comments below. > On March 22, 2019 at 4:44 AM Stefan Santesson via Datatracker wrote: > > However the security consideration section seems to lack relevant information. > The current security considerations section raise the threat of DOS attacks. > It is, however, not clear to me how the risk of DOS is affected or mitigated by > the fact that request for preview data is restricted to authenticated clients. > A discussion of this seems at least to be relevant for the context. Background: the security consideration section is adapted from similar text in the CONVERT (RFC 5259) security considerations section. Denial of server attacks here are exclusively due to authenticated users issuing PREVIEW generation commands. DOS would occur by exhausting local server resources. This kind of DOS attack is similar to DOS attacks that can be done with core IMAP commands available for authenticated users (e.g. excessive FETCHs, APPEND floods). To that extent, we could add additional language from 5259 to this document along the lines of: "In order to mitigate such attacks, servers SHOULD log the client authentication identity on FETCH operations in order to facilitate tracking of abusive clients." ...although, this is not exclusive to PREVIEW extension so maybe this is something that can/should be added more generally to imap4rev2 (in draft) Security Considerations. The only algorithm defined in this document is a text-parsing algorithm, so theoretically there are security considerations involved in this text parsing. However, IMAP servers are required to do all sorts of text parsing in order to return FETCH data so this extension is not adding a different security risk that already doesn't exist with base RFC 3501 functionality. I would be fine with adding a line stating that all security risks associated with base IMAP spec are applicable to this document also. michael From nobody Wed Apr 3 19:08:50 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 883FD120392 for ; Wed, 3 Apr 2019 19:08:43 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SylQhmj1UdK8 for ; Wed, 3 Apr 2019 19:08:42 -0700 (PDT) Received: from gproxy4-pub.mail.unifiedlayer.com (gproxy4-pub.mail.unifiedlayer.com [69.89.23.142]) (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 EC1AB12039D for ; Wed, 3 Apr 2019 19:08:37 -0700 (PDT) Received: from cmgw10.unifiedlayer.com (unknown [10.9.0.10]) by gproxy4.mail.unifiedlayer.com (Postfix) with ESMTP id 8F600175D09 for ; Wed, 3 Apr 2019 20:08:35 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id BrnvhyfjNuj2oBrnvhvdRv; Wed, 03 Apr 2019 20:08:35 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: $(_cmae_reason DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:MIME-Version:Subject:References:In-Reply-To: Message-ID:Date:To:From:Sender:Reply-To:Cc:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=ssLnqCeYwisy7k1KjE+Ey8OLCJTmMRXdESbK3h9Bgm8=; b=Twxnmz6CR6X1jj8ctCTLDtgloT 7E7VSZ1gpvGkjlnt6hwKtFsWFAm/q+zYTYUcdxIJpR2xGeByoAEZAY1sdfpAlRyZ2GjAilHQIDV4N HIjL3bOAC9TdGBQBRBywjDS4f; Received: from [172.56.35.109] (port=63648 helo=[IPV6:2607:fb90:78d:1a53:0:25:1809:9b01]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1hBrnv-001vqs-8f; Wed, 03 Apr 2019 20:08:35 -0600 From: Lou Berger To: Derrell Piper , , , Date: Wed, 03 Apr 2019 22:08:34 -0400 Message-ID: <169e618f870.27ce.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <4C94645D-B024-4FDD-B4F5-1B769232E9ED@electric-loft.org> References: <4C94645D-B024-4FDD-B4F5-1B769232E9ED@electric-loft.org> User-Agent: AquaMail/1.18.2-1413 (build: 101800200) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----------169e61add1420fd27ceb59c9d7" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 172.56.35.109 X-Source-L: No X-Exim-ID: 1hBrnv-001vqs-8f X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([IPV6:2607:fb90:78d:1a53:0:25:1809:9b01]) [172.56.35.109]:63648 X-Source-Auth: lberger@labn.net X-Email-Count: 14 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-manet-dlep-multi-hop-extension-06.txt X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 02:08:43 -0000 This is a multi-part message in MIME format. ------------169e61add1420fd27ceb59c9d7 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit Hi, Thanks for the review! Lou ---------- On April 2, 2019 1:17:42 PM Derrell Piper 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 summary is READY > > This document defines a new DLEP Extension Type and three new > DLEP Data Items to allow modems which implement multi-hop > forwarding to change multi-hop forwarding behavior through a new > hop-control mechanism defined by these extensions. > > The Security Considerations section was updated to explicitly > note this addition of a hop-control mechanism which can be used > to terminate and reset connections, affecting reacheability. As > this new extension is defined under the existing RFC 8175 > framework, the Security Considerations stated there also apply. ------------169e61add1420fd27ceb59c9d7 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Thanks for the review!

Lou

On April 2, 2019 1:17:42 PM Derrell Piper <ddp@electric-loft.or= g> 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<= br class=3D"">the benefit of the security area directors. Document editors = and
WG chairs should treat these comments just like any other= last
call comments.

The summary= is READY

This document defines a new DLEP Ext= ension Type and three new
DLEP Data Items to allow modems whi= ch implement multi-hop
forwarding to change multi-hop forward= ing behavior through a new
hop-control mechanism defined by t= hese extensions.

The Security Considerations s= ection was updated to explicitly
note this addition of a hop-= control mechanism which can be used
to terminate and reset co= nnections, affecting reacheability.  As
this new extensi= on is defined under the existing RFC 8175
framework, the Secu= rity Considerations stated there also apply.

------------169e61add1420fd27ceb59c9d7-- From nobody Thu Apr 4 06:01:52 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 47FD71204B2 for ; Thu, 4 Apr 2019 06:01:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <155438291129.30874.6417438246862659291.idtracker@ietfa.amsl.com> Date: Thu, 04 Apr 2019 06:01:51 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 13:01:51 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-04-11 Reviewer LC end Draft Daniel Franke 2019-03-18 draft-ietf-sidrops-https-tal-07 Phillip Hallam-Baker 2019-03-18 draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04 Sandra Murphy R2019-01-31 draft-ietf-ccamp-rsvp-te-bandwidth-availability-14 Vincent Roca R2018-10-29 draft-ietf-pce-gmpls-pcep-extensions-13 For telechat 2019-05-02 Reviewer LC end Draft Shaun Cooley 2019-03-13 draft-ietf-dots-data-channel-28 Stephen Farrell R2019-03-19 draft-ietf-dots-signal-channel-31 Last calls: Reviewer LC end Draft Derek Atkins 2019-03-03 draft-ietf-netmod-module-tags-07 Nancy Cam-Winget 2019-02-15 draft-ietf-rtcweb-security-11 Daniel Gillmor 2018-03-19 draft-gutmann-scep-13 Charlie Kaufman 2019-03-14 draft-ietf-trans-rfc6962-bis-31 Aanchal Malhotra 2019-04-12 draft-ietf-netconf-restconf-notif-13 Catherine Meadows 2019-04-12 draft-ietf-mmusic-rfc4566bis-34 Alexey Melnikov 2019-04-11 draft-ietf-sidrops-lta-use-cases-05 Daniel Migault 2019-04-11 draft-ietf-roll-useofrplinfo-25 Matthew Miller 2019-04-08 draft-ietf-core-multipart-ct-03 Russ Mundy 2019-04-22 draft-housley-hkdf-oids-01 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-08 Hilarie Orman 2019-04-10 draft-ietf-acme-caa-06 Tim Polk 2019-04-17 draft-ietf-isis-segment-routing-extensions-23 Vincent Roca R2019-02-13 draft-ietf-perc-private-media-framework-09 Kyle Rose 2019-04-15 draft-ietf-pce-hierarchy-extensions-10 Takeshi Takahashi R2019-04-12 draft-ietf-netconf-yang-push-22 Takeshi Takahashi R2018-08-31 draft-ietf-lisp-rfc6833bis-24 David Waltermire 2019-02-15 draft-ietf-rtcweb-ip-handling-11 Klaas Wierenga 2019-02-26 draft-ietf-mpls-sr-over-ip-03 Taylor Yu 2019-02-15 draft-ietf-rtcweb-security-arch-18 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-11 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Scott Kelly 2019-03-22 draft-ietf-rift-rift-04 Kathleen Moriarty 2019-04-08 draft-ietf-bmwg-ngfw-performance-00 Next in the reviewer rotation: Kyle Rose Joseph Salowey Rich Salz Stefan Santesson Yaron Sheffer Rifaat Shekh-Yusef Melinda Shore Valery Smyslov Robert Sparks Takeshi Takahashi From nobody Thu Apr 4 09:29:18 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BB014120696; Thu, 4 Apr 2019 09:27:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1554395250; bh=up2qj9qxxy8MoaM5502Md215s3MbyA5SosLA5xDDicA=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=rILfvC2eiEjE5VPVjhDaxXB+/Lwmok9g7vn682sJXbJ4ReJLHeOIGLvS+rqFCxO/M Z3i6f3VtfLeondiVfMKOkHtzr31ib2AyYJ9uSgPYoqjyI3t5Zv1VhrccTXH1Kg43Tl tdOKMj8HIfsowbzFd42AjDX+pjZGCZKwpC2BSkt8= X-Mailbox-Line: From new-work-bounces@ietf.org Thu Apr 4 09:27:27 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA381206B8; Thu, 4 Apr 2019 09:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1554395244; bh=up2qj9qxxy8MoaM5502Md215s3MbyA5SosLA5xDDicA=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=faFf4X9yZrClC7rHUj47qhDFFi20Phmcm5bsBwOIiTEhKf00tT3Y3ZwRoGZdAE1kE pRaTxVnqYRnioQhB1KMoNytYDh9uJDbeFBJKa6B7m+5SeuJJXz9qOgBSDAbCeVJwPG gZQ0BmTlRKSgX2/bgdaudRi9PBNC/R69NMi4efOI= 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 109E21206E0 for ; Thu, 4 Apr 2019 09:27:17 -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, HK_RANDOM_ENVFROM=0.001, 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 FDWWbSMG3tUo for ; Thu, 4 Apr 2019 09:27:15 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC67B1206C8 for ; Thu, 4 Apr 2019 09:27:14 -0700 (PDT) Received: from [42.100.4.38] (helo=jiaxueyuandeMacBook-Pro.local) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1hC5Cq-0004F5-Fq for new-work@ietf.org; Thu, 04 Apr 2019 16:27:13 +0000 To: new-work@ietf.org From: xueyuan Message-ID: <1058e548-5129-e277-a2b3-a9ec2e4ea5f0@w3.org> Date: Fri, 5 Apr 2019 00:27:03 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Thu, 04 Apr 2019 09:29:17 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Media Working Group (until 2019-05-03) 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, 04 Apr 2019 16:27:32 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgTWVkaWEg V29ya2luZyBHcm91cDoKIMKgIGh0dHBzOi8vd3d3LnczLm9yZy8yMDE5LzA0L21lZGlhLWNoYXJ0 ZXItZHJhZnQuaHRtbAoKQXMgcGFydCBvZiBlbnN1cmluZyB0aGF0IHRoZSBjb21tdW5pdHkgaXMg YXdhcmUgb2YgcHJvcG9zZWQgd29yawphdCBXM0MsIHRoaXMgZHJhZnQgY2hhcnRlciBpcyBwdWJs aWMgZHVyaW5nIHRoZSBBZHZpc29yeQpDb21taXR0ZWUgcmV2aWV3IHBlcmlvZC4KClczQyBpbnZp dGVzIHB1YmxpYyBjb21tZW50cyB0aHJvdWdoIDIwMTktMDUtMDMgb24gdGhlCnByb3Bvc2VkIGNo YXJ0ZXIuIFBsZWFzZSBzZW5kIGNvbW1lbnRzIHRvCnB1YmxpYy1uZXctd29ya0B3My5vcmcsIHdo aWNoIGhhcyBhIHB1YmxpYyBhcmNoaXZlOgogwqAgaHR0cDovL2xpc3RzLnczLm9yZy9BcmNoaXZl cy9QdWJsaWMvcHVibGljLW5ldy13b3JrLwoKT3RoZXIgdGhhbiBjb21tZW50cyBzZW50IGluIGZv cm1hbCByZXNwb25zZXMgYnkgVzNDIEFkdmlzb3J5CkNvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMs IFczQyBjYW5ub3QgZ3VhcmFudGVlIGEgcmVzcG9uc2UgdG8KY29tbWVudHMuIElmIHlvdSB3b3Jr IGZvciBhIFczQyBNZW1iZXIgWzFdLCBwbGVhc2UgY29vcmRpbmF0ZQp5b3VyIGNvbW1lbnRzIHdp dGggeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRpdmUuIEZvcgpleGFtcGxlLCB5 b3UgbWF5IHdpc2ggdG8gbWFrZSBwdWJsaWMgY29tbWVudHMgdmlhIHRoaXMgbGlzdCBhbmQKaGF2 ZSB5b3VyIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZSByZWZlciB0byBpdCBmcm9t IGhpcwpvciBoZXIgZm9ybWFsIHJldmlldyBjb21tZW50cy4KCklmIHlvdSBzaG91bGQgaGF2ZSBh bnkgcXVlc3Rpb25zIG9yIG5lZWQgZnVydGhlciBpbmZvcm1hdGlvbiwgcGxlYXNlCmNvbnRhY3Qg RnJhbsOnb2lzIERhb3VzdCwgVzNDIFN0YWZmIENvbnRhY3QgPGZkQHczLm9yZz4uCgpUaGFuayB5 b3UsClh1ZXl1YW4gSmlhLCBXM0MgTWFya2V0aW5nICYgQ29tbXVuaWNhdGlvbnMKClsxXSBodHRw Oi8vd3d3LnczLm9yZy9Db25zb3J0aXVtL01lbWJlci9MaXN0CgpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXwpuZXctd29yayBtYWlsaW5nIGxpc3QKbmV3LXdv cmtAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXctd29y awo= From nobody Thu Apr 4 15:38:36 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8B7312022A for ; Thu, 4 Apr 2019 15:38:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verizon.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id haZmKt6N6vHc for ; Thu, 4 Apr 2019 15:38:32 -0700 (PDT) Received: from sonic315-14.consmr.mail.bf2.yahoo.com (sonic315-14.consmr.mail.bf2.yahoo.com [74.6.134.124]) (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 5E55E120185 for ; Thu, 4 Apr 2019 15:38:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=verizon.net; s=a2048; t=1554417511; bh=TmRiOX1o/uQV709xKtrGLJC88mrYETublN77xx0V6i4=; h=From:Subject:To:Cc:References:Date:In-Reply-To:From:Subject; b=dPf+TiOJJh2Yy29SCpEYn9O/r3v2xVmbqczqXptlqQ86lPfe+7wZ4j5tFUH/jvEHpNGsUBZdNnboddS6YyQU0rDJBJs7VqZ+WJoHMgahtvv1qi8aDmjbUb5Z/G52iAJjLnRXnHob5Lf7GbVtQBo1IMJ6ea+WOXWcsu9ZlrIBjgtG0DZ9naGtLFVjsdBS1t4n3mF/gQlyQvo65vPhVCfJAsUji3Tq/aQRHIjtajU1YqPnpgfuwq5S2r/Z3gqcUCvoto3r4CA/J1UL8QUfC+RtrfMNtUnJAu0CYRw9PUUG4HthrArhtjHTf9oQmy9B0xM75S8vl4dru5yQL2qeyW1fvw== X-YMail-OSG: MBxwPmcVM1nQRhYlomroMvXNOd53BfmCv7B7FmqdDili0BzKN8.fKTI1lWqJBSQ _AmYGrd2p.izlcrzonNjziVCZi0Dqz.0yNJMh6ET55cd5iEfAy3SobvxnISbWzoBGoPkWfPU3zh_ 5wl09sfkKoxWA10rR6IvGxKrmQV0juc2Xa..Jq8OwdXs3Ik.KMHB_cbO8rK6uY7Oz.2cvWBsWQMc snJPLfl1YUiD007naU.NLreizu5dOt9XnQwFj4kKLKdHN1PemZZGBkdn8jH2SIDgi_np3hO4jl2F s7SRD.u1kd7hAorxhgQ0zfsoNKCLnrOwL_DYACcM_9IkbfV3TkyVrzj2XffP7HEc0vFgrXrERrP4 y9WH9puXJon5p7RG2kwxcqZDd685.mEiYDTZwDSFWm8N3q_au7SHsz3BOn.EXLaPqlFfA8Zojuce cIqSV5hAiED6h6Xm1RKcA.kzeydPIl2B36xo6IipHaosPRp9nGx06C4bOoz6WljIc9ZjtbJSccLU 9O_FOOlYFjNtWTVrGN0Kl9gjG.185.U4aR9WzeIlFHT0GSqPfot5yrQr9HokUUblxvCjR6jYH96h XgMu7qlwoVk8ZxMWF6Wrj9_TvVuBzoO2UdbbmXSD8qn5.NzoB8ML.vp7rbTVQlbB1NCswKlHWOBP XkiPctnFPoPqO9EJsXjeyUr79D610DVOPTkRRjdC0UN3yQ16v1jQenTD4Y3DuWesWTDiCOUkaabW Xn9hQc5hZHzGNZ9D1CCaLOAM_pQFQ9ATVicjOvCm0NSLL11tfb4cc2In6pfYuevwSBFmiekHk6UB FsCo5djXVDcVijMt_GnwC1N_zFyxyi_q.vncgVUJNCiJTwkj1Qp69ny2pifmS2IdPUpBuzB3u0_h I70XAkLtDlRcK8BzzvbvQbRzsMQIvES3cMjoKiXQjaHFnfOefbs01QWjEDVt1aaLENCtQpspvHF1 MwLJnSbKjSkL.TZ_0GPwrL_v1pxoPE6ZDFC4uvR5Qq0WuLJ_LbqAJHGCwkikYPFe0pf4oleUB7tS mrjxAKJrltip6H9as57Erj1lGVvwPvzF11muPGDuovxX_Ywbf8GVh.8AFa.u8tHTQEJ6zO_tLP7z Src1P8wuA9gGfzY5CMl_u Received: from sonic.gate.mail.ne1.yahoo.com by sonic315.consmr.mail.bf2.yahoo.com with HTTP; Thu, 4 Apr 2019 22:38:31 +0000 Received: from 192.40.225.130 (EHLO Steves-MacBook-Pro.local) ([192.40.225.130]) by smtp413.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ef3da3371e5c72119df3c3879322e470; Thu, 04 Apr 2019 22:28:29 +0000 (UTC) From: Stephen Kent To: Lou Berger , Stephen Kent , secdir@ietf.org Cc: draft-ietf-manet-dlep-pause-extension.all@ietf.org, manet@ietf.org, ietf@ietf.org References: <155309526492.14741.18141095676597911076@ietfa.amsl.com> <6dddf23c-806a-d8ab-7f65-ac7b0855deac@labn.net> Message-ID: Date: Thu, 4 Apr 2019 15:28:12 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <6dddf23c-806a-d8ab-7f65-ac7b0855deac@labn.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-manet-dlep-pause-extension-05 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2019 22:38:34 -0000 Lou, Thanks for the quick reply. Your proposed edits look fine. Steve > Hi Steve, > > Thanks for the comments! > > On 3/20/2019 11:21 AM, Stephen Kent via Datatracker wrote: >> Reviewer: Stephen Kent >> Review result: Has Nits >> >> I have reviewed this document as part of the security directorate's >> ongoing >> effort to review all IETF documents being processed by the IESG.  These >> comments were written with the intent of improving security >> requirements and >> considerations in IETF drafts.  Comments not addressed in last call >> may be >> included in AD reviews during the IESG review.  Document editors and >> WG chairs >> should treat these comments just like any other last call comments. >> >> Review Summary: Ready with nits >> >> This brief document defines and extension to DLEP That enables a >> modem to use >> DLEP to pause and resume inbound traffic from a specific peer. DLEP >> (RFC 8175) >> cites GTSM as a security mechanism, which is rather weak, but it says >> that >> implementations SHOULD use TLS (1.2), which is fine. >> >> The text states that “An example of when a modem might send this data >> item is >> when an internal queue length exceeds a particular threshold.” >> However, all of >> details of this data item seem to focus exclusively on queues. Thus >> it seems >> likely that this is not just an example, but, rather, the primary >> motivation >> for introducing the pause extension. A slight rewording of the text >> here seems >> appropriate, or the authors could describe other (not-queue-based) >> examples. > > fair point, how about: > > OLD: > >   An example of when a modem might send >   this data item is when an internal queue length exceeds a particular >   threshold. > > NEW: > > The motivating use case is for this data item is when a modem's > internal queue length exceeds a particular threshold.  Other use cases > are possible, e.g., when there a non queue related congestion points > within a modem, but such are not explicitly described in this document. > > >> The Security Considerations section of 8175 addresses a reasonable >> range of >> concerns. Thus it is appropriate that this document’s Security >> Considerations >> section is very brief, as it cites the corresponding section in 8175. >> I suggest >> a couple of minor change to the wording here: >> >> “The extension does not inherently introduce any additional threats … >> -> >> “The extension does not inherently introduce any additional >> vulnerabilities …” >> >> “ …  but this is not a substantively different threat by …” >> -> >> “ …  but this is not a substantively different attack by …” >> >> There are numerous examples of awkward/poor phrasing throughout the >> document, >> which I hope the RFC Editor will correct, e.g., >> >> Abstract: >>          “…to the DLEP protocol …” -> “… to DLEP …” > > Hopefully these have already been corrected, if not I'm sure the > editor will help us out. > > >> page 7: >> >> “A modem can indicate that traffic is to be suppressed on a device    >> wide or >> destination specific basis.” >> >> “A modem can indicate that traffic is to be suppressed on a device-   >> wide or >> destination-specific basis.” > > Thanks. > >> “This includes that to indicate that transmission can resume to all >> destinations  …” >> >> “Thus, to indicate that transmission can resume to all destinations,  …” > > I'm not sure thus is quite right, but will revise! > > Thanks again!, > > Lou > >> >> > From nobody Thu Apr 4 23:25:42 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 363EC12031F; Thu, 4 Apr 2019 23:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-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 9yVJvhXKPsct; Thu, 4 Apr 2019 23:25:32 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEE2F120361; Thu, 4 Apr 2019 23:25:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.60,310,1549926000"; d="scan'208,217";a="377297880" Received: from dom38-1-82-236-155-50.fbx.proxad.net (HELO [192.168.1.100]) ([82.236.155.50]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Apr 2019 08:25:08 +0200 From: Vincent Roca Content-Type: multipart/alternative; boundary="Apple-Mail=_640E2EED-E03C-4CA1-80A1-E886899E5E13" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Message-Id: Date: Fri, 5 Apr 2019 08:25:07 +0200 To: The IESG , draft-ietf-pce-gmpls-pcep-extensions.all@ietf.org, secdir@ietf.org X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: [secdir] Secdir review of draft-ietf-pce-gmpls-pcep-extensions-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 06:25:35 -0000 --Apple-Mail=_640E2EED-E03C-4CA1-80A1-E886899E5E13 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, I have reviewed this document as part of the security directorate=E2=80=99= s ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments = just like any other last call comments. Summary: Ready Since my previous secdir review of the -12 version, the comments have = all been addressed in a satisfying manner. Typo:=20 ** Remove one =C2=AB against =C2=BB in sentence: "In order to protect against against=E2=80=A6"=20 Regards, Vincent= --Apple-Mail=_640E2EED-E03C-4CA1-80A1-E886899E5E13 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello,

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

Summary: Ready

Since my previous secdir review of the -12 version, = the comments have all been
addressed in a satisfying manner.


Typo: 
** Remove one = =C2=AB against =C2=BB in sentence:
"In order to protect = against against=E2=80=A6" 


Regards,

  = Vincent
= --Apple-Mail=_640E2EED-E03C-4CA1-80A1-E886899E5E13-- From nobody Fri Apr 5 07:39:20 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49138120453; Fri, 5 Apr 2019 07:39:18 -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 qukQ0gRfPLIl; Fri, 5 Apr 2019 07:39:16 -0700 (PDT) Received: from dash.upc.es (dash.upc.es [147.83.2.50]) (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 551ED12044F; Fri, 5 Apr 2019 07:39:16 -0700 (PDT) Received: from entelserver.upc.edu (entelserver.upc.es [147.83.39.4]) by dash.upc.es (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id x35EdATh040340; Fri, 5 Apr 2019 16:39:10 +0200 Received: from webmail.entel.upc.edu (webmail.entel.upc.edu [147.83.39.6]) by entelserver.upc.edu (Postfix) with ESMTP id D3E401D53C1; Fri, 5 Apr 2019 16:39:09 +0200 (CEST) Received: from 131.111.5.141 by webmail.entel.upc.edu with HTTP; Fri, 5 Apr 2019 16:39:10 +0200 Message-ID: In-Reply-To: <96b8684a-1319-7f89-8e1e-28e8bc154e55@earthlink.net> References: <96b8684a-1319-7f89-8e1e-28e8bc154e55@earthlink.net> Date: Fri, 5 Apr 2019 16:39:10 +0200 From: "Carles Gomez Montenegro" To: "Charlie Kaufman" Cc: "secdir@ietf.org" , "draft-ietf-6lo-deadline-time.all@ietf.org" , "Charlie Perkins" User-Agent: SquirrelMail/1.4.21-1.fc14 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.100.2 at dash X-Virus-Status: Clean X-Greylist: Delayed for 00:04:02 by milter-greylist-4.3.9 (dash.upc.es [147.83.2.50]); Fri, 05 Apr 2019 16:39:11 +0200 (CEST) Archived-At: Subject: Re: [secdir] Secdir review of draft-ietf-6lo-deadline-time-03 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Apr 2019 14:39:18 -0000 Dear Charlie Kaufman, Thanks for reviewing draft-ietf-6lo-deadline-time-03. Authors of draft-ietf-6lo-deadline-time recently produced revision -04 of the draft, based on a number of comments received, including yours: https://datatracker.ietf.org/doc/draft-ietf-6lo-deadline-time/ Do you think -04 satisfies your previous concerns? Thanks, Shwetha and Carles (6lo co-chairs) > Hello Charlie K., > > > Thanks for your review and comments. I have made some follow-up > interspersed with your comments below. > > > On 12/23/2018 8:08 PM, Charlie Kaufman wrote: >> >> ... >> >> One of the challenges facing this design is maintaining tight clock >> synchronization between packet forwarding devices. The design assumes >> that sets of such devices are held in tight synchronization through >> unspecified mechanisms. These groupings are called "time zones". It >> also calls for the origination time and delivery deadline fields be >> updated when a packet transitions between "time zones" (which assumes >> that packet forwarding devices on separating two time zones be aware >> of the time difference between them so that it can update those fields). >> > > I think the intention was to obey transitions between time zones as we > usually think of them (Pacific, Central European, etc.). The border > routers could be expected to have the timezone information configured. > > >> >> >> Section 6 specifies that when one of these packets is encapsulated and >> sent through an IPv6 in IPv6 tunnel, and tunnel exit the time fields >> must be copied from the outer header to the inner header before the >> packet is forwarded on. This would be true of any form of >> encapsulation, in particular including IPsec tunnelling. >> > > Would it be O.K. if we simply deleted "IPv6-in-IPv6" from that sentence? > > >> >> Many time synchronization protocols - particularly those that target >> subsecond synchronization - assume they are running on a secure >> network (or that attackers would not be motivated to mess up time >> synchronization). If the time synchronization between the packet >> forwarding devices were to be broken such that there was substantial >> drift between the devices, that could be used as a denial of service >> attack if that could be used to cause most or all data packets to be >> discarded as expired. >> > > I think that a lot of things go wrong if the synchronization between the > networks is broken. As mentioned in the document > draft-ietf-ntp-packet-timestamps, we need to consider whether or not to > include a new subsection about "Synchronization Aspects". > > >> >> >> ... I eventually concluded that only the DT field was intended to be >> used for this purpose and the OT field was intended to be used to >> track delivery performance and is not used in the calculation of >> packet lifetime. Assuming I have that right, it would be good if it >> were more explicit in the document. >> > > Thanks for this feedback; we will find a way to make the distinction > more explicit. > > >> >> The bit bummer in me was offended by the fact that the TU and EXP >> fields had two different ways of representing 1 second time >> granularity (TU=00/EXP=110 and TU=01/EXP=000). Given that time >> granularity greater than 10 seconds is never likely to be needed, the >> need for the TU=01 code point is questionable, but at the least >> perhaps the spec should say which is the preferred encoding. >> > > We are going to rework the time representation to be in accordance with > the abovementioned document draft-ietf-ntp-packet-timestamps. I think > this will resolve the concern you have raised. > > > >> I also could not tell whether the encoding was expected to be constant >> within a Time Zone (in which case the fields would not be necessary in >> every packet) or whether packet relay nodes were expected to >> canonicalize the time representation whenever it parses a packet. But >> this is only a matter of taste. >> > > I have always thought that the encoding would be constant from end to > end. We should have also made that explicit. Do you think there is a > good reason to allow the encoding to be chosen on a hop-by-hop basis? > > > Thanks again! > > > Regards, > Charlie P. > > From nobody Sat Apr 6 06:40:13 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D9E0120005 for ; Sat, 6 Apr 2019 06:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 gzGXaaC2Di8I for ; Sat, 6 Apr 2019 06:40:01 -0700 (PDT) Received: from smtp114.iad3a.emailsrvr.com (smtp114.iad3a.emailsrvr.com [173.203.187.114]) (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 389F112009A for ; Sat, 6 Apr 2019 06:40:01 -0700 (PDT) Received: from smtp23.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp23.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 29C9623A1B; Sat, 6 Apr 2019 09:40:00 -0400 (EDT) Received: from app45.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by smtp23.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 0F4DD23A11; Sat, 6 Apr 2019 09:40:00 -0400 (EDT) X-Sender-Id: scott@hyperthought.com Received: from app45.wa-webapps.iad3a (relay-webapps.rsapps.net [172.27.255.140]) by 0.0.0.0:25 (trex/5.7.12); Sat, 06 Apr 2019 09:40:00 -0400 Received: from hyperthought.com (localhost.localdomain [127.0.0.1]) by app45.wa-webapps.iad3a (Postfix) with ESMTP id F07C46004B; Sat, 6 Apr 2019 09:39:59 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: scott@hyperthought.com, from: scott@hyperthought.com) with HTTP; Sat, 6 Apr 2019 06:39:59 -0700 (PDT) X-Auth-ID: scott@hyperthought.com Date: Sat, 6 Apr 2019 06:39:59 -0700 (PDT) From: "Scott G. Kelly" To: draft-ietf-rift-rift.all@tools.ietf.org, "secdir@ietf.org" , "iesg@ietf.org" MIME-Version: 1.0 Content-Type: text/plain;charset=UTF-8 Content-Transfer-Encoding: quoted-printable Importance: Normal X-Priority: 3 (Normal) X-Type: plain Message-ID: <1554557999.98244880@apps.rackspace.com> X-Mailer: webmail/16.3.0-RC Archived-At: Subject: [secdir] secdir review of draft-ietf-rift-rift-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Apr 2019 13:40:04 -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=0AThe summary of the review is ready with is= sues=0A=0AFrom the abstract, this document outlines a specialized, dynamic = routing protocol for Clos and fat-tree network topologies.=0A=0A(should tha= t read CLOS?)=0A=0AFollowing is a brief summary of comments and questions b= y section.=0A=0A5.4.1 includes this sentence:=0A=0A The most security con= scious operators will want to have full control=0A over which port on whi= ch router/switch is connected to the respective=0A port on the "other sid= e", which we will call the "port-association=0A model" (PAM) achievable e= .g. by pairwise-key PKI.=0A=0AWhat is "pairwise-key PKI"?=0A=0ASecion 5.4.2= says "Low processing overhead and efficiency messaging are also a goal."= =0A=0AI suggest replacing efficiency with efficient=0A=0AIt also says "Mess= age privacy achieved through full encryption is a non-goal"=0A=0AI suggest = saying "Message confidentiality is a non-goal" instead.=0A=0A=0ASection 5.4= .3=0A"Length of Fingerprint: 8 bits. Length in 32-bit multiples of the=0A= following fingerprint not including lifetime or nonces. It allows=0A= to navigate the structure when an unknown key type is present. To=0A= clarify a common cornercase a fingerprint with length of 0 bits is=0A= presenting this field with value of 0."=0A=0ADoes length 0 mean no fi= ngerprint is present (i.e. fingerprints are not provided)? I don't understa= nd that last sentence.=0A=0AThe definition for "Security Fingerprint" inclu= des this=09sentence:=0A=0A"If the fingerprint is shorter than the significa= nt bits are left aligned and remaining bits are set to 0."=0A=0AI don't=09u= nderstand this=09sentence. I think you mean that=09if the fingerprint bit l= ength is not an even multiple of 32, then it is left-aligned, and the right= most unused bits are set to 0. But that's just a guess.=0A=0A5.4.4=0A"Any i= mplementation including RIFT security MUST generate and wrap around local n= onces properly"=0A=0AI see the term "nonce" used elsewhere, but because it = can wrap (and therefore repeat with regularity), I think this is a poor cho= ice for naming this field. It seems to be more of a counter. I think most s= ecurity folks would agree that a nonce used for security purposes should, b= y definition, repeat only with negligible probability.=0A=0AOn a related no= te, does this really provide anti-replay protection? Elsewhere in the docum= ent (e.g. section 5.4.4) it says that implementations could go up to 5 minu= tes without incrementing nonces. Can they send multiple packets with the sa= me nonce during this interval? If so, what prevents replay of a captured pa= cket within that interval?=0A=0AAlso, because wrapping (of this 16 bit valu= e) is supported, it's also possible that an earlier packet could be replaye= d (assuming the peer nonce also aligned), right? The odds of this seem low,= but could the protocol/endpoint states be manipulated to improve the odds?= Not sure. But if you are assuming this can't happen, this security-relevan= t assumption should be called out.=0A=0A5.4.7 says=0A=0A "If an implement= ation supports disabling the security envelope=0A requirements while send= ing a security envelope an implementation=0A could shut down the security= envelope procedures while maintaining an=0A adjacency and make changes t= o the algorithms on both sides then re=0A enable the security envelope pr= ocedures but that introduces security=0A holes during the disabled period= ."=0A=0AAside from the fact that this needs word-smithing, should this be c= alled out in the security considerations section? This eeems to be saying t= hat it's not a good idea to temporarily maintain adjacency while disabling = security, so is this a SHOULD NOT?=0A=0Asection 8.4=0Aflodding -> flooding= =0A=0Asection 8.4 also says=0A=0A It is expected that an=0A implementat= ion detecting too many fake losses or misorderings due to=0A the attack o= n the number would simply suppress its further processing.=0A=0Awhat are "f= ake losses"?=0A=0AI am not a routing expert, so there may be additional con= cerns that someone better versed in routing would raise.=0A From nobody Mon Apr 8 05:20:12 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD13C1202D7 for ; Mon, 8 Apr 2019 05:20:10 -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, DKIMWL_WL_MED=-0.001, 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=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6vl5eSG_3fk for ; Mon, 8 Apr 2019 05:20:08 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 4712B120033 for ; Mon, 8 Apr 2019 05:20:08 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id h18so884016lfj.11 for ; Mon, 08 Apr 2019 05:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=PNkwDcERFxt44FMDtXN+eYCa7IP7tiuUlxnLCJrI+eg=; b=rmz4EF73puf8TTuu88jN0Gz1AIR9ywv8tqAXP+M1P7pcPPsN6amicFMQvsnH6qKfCJ ieXQ0/LLJkRQgkupb1P3YKjPIFXxTxeauy3KpTO1VEtmKuVUFUQo7MOfJKdmiF0iTTU3 G1/1hq+hedqMtAGP8HSTk0MCapCNl6bbrUbo8FF714NYnhU/pms8/UjQufsCDkkU+Z7P Bl7ntcSY02r38xwnkOOG/ZEgGEB+E8u2CT4RsoDgYhgCS3Wt/dmIXHbFUtdE6ZHW7piR G6QDoA4ytApB6kGOxtZ/Tjo0b9Vb11Vmzgd58qN5+8CPSIatFDqfJDyXAGaI3VOyEXJm bw6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=PNkwDcERFxt44FMDtXN+eYCa7IP7tiuUlxnLCJrI+eg=; b=KU47JMdKWdXnPLBioUHF/Zb23nDteHFpolF/1SCmchUHG4mE0k8gUUEnFSAWo+Bfuz qg4ynzWPzEHBmb52a85NUnb+Q8jJWnDXsodj/IQg+PfkacFyajxDMRnUe1k+630IpZpw 5Z8VIYS/WoIa9smyp3mRLYCkjGV+LksgurI/VTMfBCenYmRxSXkuGcp7W85AlTAf6yk4 baEsOEeCSStQqbNZ2aKBHH1Irk23BLGViNH9cl2yjRNwILCVHx9RNxqJHSL6l3CF0EJy iTbTNH/fpkUbXzVZp20Y60VPpNs4a/PwK6g1H2mSN+MRfa8EP046KxFbKoOymhvhiXAO k+rg== X-Gm-Message-State: APjAAAWhhjQYcNBlXgVMHRZav+dDAaYFnd4VQnPXPNse4M4zDRad7qJ4 9F4uN7Jdkk7pG6aWQ5Ofh62X9l5Ev5gI/hPfY8xcB9Uk X-Google-Smtp-Source: APXvYqy235sGYKGxqa4LaLEZFt/cdxk8EYjRGwUbRfyI0T2wy9hJGRVUAG3CFG+PFQ4GaIM9Co+zR7smChU8FbdOVhw= X-Received: by 2002:ac2:4421:: with SMTP id w1mr15943296lfl.97.1554726006348; Mon, 08 Apr 2019 05:20:06 -0700 (PDT) MIME-Version: 1.0 References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> In-Reply-To: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> From: Eric Rescorla Date: Mon, 8 Apr 2019 05:19:29 -0700 Message-ID: To: Nevil Brownlee Cc: cfrg , secdir@ietf.org, "" Content-Type: multipart/alternative; boundary="00000000000054effe058603db19" Archived-At: Subject: Re: [secdir] ISE seeks help with some crypto drafts X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 12:20:11 -0000 --00000000000054effe058603db19 Content-Type: text/plain; charset="UTF-8" These drafts seem quite low value to publish: The existing OCB document [RFC 7253] is cited by exactly zero RFCs ( https://datatracker.ietf.org/doc/rfc7253/referencedby/), so having a specification for ciphers with block size != 128 seems of particularly low value. The existing RC5 document [RFC 2040] has 6 RFC-level citations, but as far as I know, RC5 has practically no usage in IETF protocols. AFAICT, RC6 isn't even specified in an RFC. Thus, test vectors for these algorithms don't seem that interesting. -Ekr On Fri, Mar 8, 2019 at 9:20 AM RFC ISE (Adrian Farrel) < rfc-ise@rfc-editor.org> wrote: > Hi CFRG and SecDir, > > Ted Krovetz has asked for publication of ... > > https://datatracker.ietf.org/doc/draft-krovetz-ocb-wideblock/ > ...and... > https://datatracker.ietf.org/doc/draft-krovetz-rc6-rc5-vectors/ > > ...in the Independent Stream. > > These are both currently in expired state, but available in the archive. > > At this stage I am looking to know whether anyone feels that publication > would be a bad thing: > - at this stage > - ever > > Please send me your opinions direct (I am not subscribed to this list, but > will check the archives). > > Please also let me know if you would be willing to be a detailed reviewer > of this work. > > Thanks, > Adrian > -- > Adrian Farrel (ISE), > rfc-ise@rfc-editor.org > > --00000000000054effe058603db19 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
These drafts seem quite low value to= publish:

The existing OCB document [RFC 7253] is = cited by exactly zero RFCs (https://datatracker.ietf.org/doc/rfc7= 253/referencedby/), so having a specification for ciphers with block si= ze !=3D 128 seems of particularly low value.

= The existing RC5 document [RFC 2040] has 6 RFC-level citations, but as far = as I know, RC5 has practically no usage in IETF protocols. AFAICT, RC6 isn&= #39;t even specified in an RFC. Thus, test vectors for these algorithms don= 't seem that interesting.

-Ekr

<= /div>




On Fri, Mar 8, 2019= at 9:20 AM RFC ISE (Adrian Farrel) <rfc-ise@rfc-editor.org> wrote:
Hi CFRG and SecDir,

Ted Krovetz has asked for publication of ...

https://datatracker.ietf.org/doc/draft-= krovetz-ocb-wideblock/
...and...
https://datatracker.ietf.org/doc/draf= t-krovetz-rc6-rc5-vectors/

...in the Independent Stream.

These are both currently in expired state, but available in the archive.
At this stage I am looking to know whether anyone feels that publication would be a bad thing:
- at this stage
- ever

Please send me your opinions direct (I am not subscribed to this list, but<= br> will check the archives).

Please also let me know if you would be willing to be a detailed reviewer of this work.

Thanks,
Adrian
--
Adrian Farrel (ISE),
rfc-ise@rfc-edi= tor.org

--00000000000054effe058603db19-- From nobody Mon Apr 8 05:30:25 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFAF21202D7; Mon, 8 Apr 2019 05:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=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 s-NOO2UVw77d; Mon, 8 Apr 2019 05:30:20 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 76B7A1201EB; Mon, 8 Apr 2019 05:30:20 -0700 (PDT) Received: from LLE2K16-MBX02.mitll.ad.local (LLE2K16-MBX02.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id x38CUIdU042402; Mon, 8 Apr 2019 08:30:18 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Eric Rescorla CC: Nevil Brownlee , "" , cfrg , "secdir@ietf.org" Thread-Topic: [Cfrg] ISE seeks help with some crypto drafts Thread-Index: AQHU1dNTVBBNlvC7XkWW3z1y4bZa2qYyogiAgAADAoA= Date: Mon, 8 Apr 2019 12:30:17 +0000 Message-ID: <35FC8AD5-BF45-4C3E-A0A8-0EA426970DEA@ll.mit.edu> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 Content-Type: multipart/signed; boundary="Apple-Mail-F62F13B3-64BD-4482-A46F-E9C79A383C01"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-08_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904080106 Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 12:30:23 -0000 --Apple-Mail-F62F13B3-64BD-4482-A46F-E9C79A383C01 Content-Type: multipart/alternative; boundary=Apple-Mail-381AE348-9FA0-4090-8878-AEDB3051CB16 Content-Transfer-Encoding: 7bit --Apple-Mail-381AE348-9FA0-4090-8878-AEDB3051CB16 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Well, we *are* interested in OCB and ciphers with block size !=3D 128 bits, e= ven if we won't necessarily document our use in another RFC. Thus, I see your point but disagree with it's apparent conclusion. IMHO the O= CB draft should be published.=20 Not sure about RC{5,6} - not my cup of tea. Regards, Uri Sent from my iPhone > On Apr 8, 2019, at 08:21, Eric Rescorla wrote: >=20 > These drafts seem quite low value to publish: >=20 > The existing OCB document [RFC 7253] is cited by exactly zero RFCs (https:= //datatracker.ietf.org/doc/rfc7253/referencedby/), so having a specification= for ciphers with block size !=3D 128 seems of particularly low value.=20 >=20 > The existing RC5 document [RFC 2040] has 6 RFC-level citations, but as far= as I know, RC5 has practically no usage in IETF protocols. AFAICT, RC6 isn'= t even specified in an RFC. Thus, test vectors for these algorithms don't se= em that interesting. >=20 > -Ekr >=20 >=20 >=20 >=20 >=20 >> On Fri, Mar 8, 2019 at 9:20 AM RFC ISE (Adrian Farrel) wrote: >> Hi CFRG and SecDir, >>=20 >> Ted Krovetz has asked for publication of ... >>=20 >> https://datatracker.ietf.org/doc/draft-krovetz-ocb-wideblock/ >> ....and... >> https://datatracker.ietf.org/doc/draft-krovetz-rc6-rc5-vectors/ >>=20 >> ....in the Independent Stream. >>=20 >> These are both currently in expired state, but available in the archive. >>=20 >> At this stage I am looking to know whether anyone feels that publication >> would be a bad thing: >> - at this stage >> - ever >>=20 >> Please send me your opinions direct (I am not subscribed to this list, bu= t >> will check the archives). >>=20 >> Please also let me know if you would be willing to be a detailed reviewer= >> of this work. >>=20 >> Thanks, >> Adrian >> --=20 >> Adrian Farrel (ISE), >> rfc-ise@rfc-editor.org >>=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg --Apple-Mail-381AE348-9FA0-4090-8878-AEDB3051CB16 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPldlbGwsIHdlICph cmUqIGludGVyZXN0ZWQgaW4gT0NCIGFuZCBjaXBoZXJzIHdpdGggYmxvY2sgc2l6ZSAhPSAxMjgg Yml0cywgZXZlbiBpZiB3ZSB3b24ndCBuZWNlc3NhcmlseSBkb2N1bWVudCBvdXIgdXNlIGluIGFu b3RoZXIgUkZDLjxkaXY+PGJyPjwvZGl2PjxkaXY+VGh1cywgSSBzZWUgeW91ciBwb2ludCBidXQg ZGlzYWdyZWUgd2l0aCBpdCdzIGFwcGFyZW50IGNvbmNsdXNpb24uIElNSE8gdGhlIE9DQiBkcmFm dCBzaG91bGQgYmUgcHVibGlzaGVkLiZuYnNwOzwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+Tm90 IHN1cmUgYWJvdXQgUkN7NSw2fSAtIG5vdCBteSBjdXAgb2YgdGVhLjxicj48YnI+PGRpdiBkaXI9 Imx0ciIgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+UmVnYXJkcyw8ZGl2PlVyaTwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxkaXY+U2VudCBmcm9tIG15IGlQaG9uZTwvZGl2PjwvZGl2PjxkaXYgZGlyPSJs dHIiPjxicj5PbiBBcHIgOCwgMjAxOSwgYXQgMDg6MjEsIEVyaWMgUmVzY29ybGEgJmx0OzxhIGhy ZWY9Im1haWx0bzpla3JAcnRmbS5jb20iPmVrckBydGZtLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj48 YnI+PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdiBkaXI9Imx0ciI+PG1ldGEgaHR0 cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgi PjxkaXYgZGlyPSJsdHIiPjxkaXYgZGlyPSJsdHIiPjxkaXY+VGhlc2UgZHJhZnRzIHNlZW0gcXVp dGUgbG93IHZhbHVlIHRvIHB1Ymxpc2g6PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGUgZXhp c3RpbmcgT0NCIGRvY3VtZW50IFtSRkMgNzI1M10gaXMgY2l0ZWQgYnkgZXhhY3RseSB6ZXJvIFJG Q3MgKDxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3JmYzcyNTMvcmVm ZXJlbmNlZGJ5LyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL3JmYzcyNTMvcmVmZXJlbmNlZGJ5LzwvYT4pLCBzbyBoYXZpbmcgYSBzcGVjaWZpY2F0aW9u IGZvciBjaXBoZXJzIHdpdGggYmxvY2sgc2l6ZSAhPSAxMjggc2VlbXMgb2YgcGFydGljdWxhcmx5 IGxvdyB2YWx1ZS4gPGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+VGhlIGV4aXN0aW5nIFJD NSBkb2N1bWVudCBbUkZDIDIwNDBdIGhhcyA2IFJGQy1sZXZlbCBjaXRhdGlvbnMsIGJ1dCBhcyBm YXIgYXMgSSBrbm93LCBSQzUgaGFzIHByYWN0aWNhbGx5IG5vIHVzYWdlIGluIElFVEYgcHJvdG9j b2xzLiBBRkFJQ1QsIFJDNiBpc24ndCBldmVuIHNwZWNpZmllZCBpbiBhbiBSRkMuIFRodXMsIHRl c3QgdmVjdG9ycyBmb3IgdGhlc2UgYWxnb3JpdGhtcyBkb24ndCBzZWVtIHRoYXQgaW50ZXJlc3Rp bmcuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj4tRWtyPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PC9kaXY+PC9kaXY+PGJy PjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj48ZGl2IGRpcj0ibHRyIiBjbGFzcz0iZ21haWxfYXR0 ciI+T24gRnJpLCBNYXIgOCwgMjAxOSBhdCA5OjIwIEFNIFJGQyBJU0UgKEFkcmlhbiBGYXJyZWwp ICZsdDs8YSBocmVmPSJtYWlsdG86cmZjLWlzZUByZmMtZWRpdG9yLm9yZyIgdGFyZ2V0PSJfYmxh bmsiPnJmYy1pc2VAcmZjLWVkaXRvci5vcmc8L2E+Jmd0OyB3cm90ZTo8YnI+PC9kaXY+PGJsb2Nr cXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHggMHB4IDAuOGV4 O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmctbGVmdDoxZXgi PkhpIENGUkcgYW5kIFNlY0Rpciw8YnI+DQo8YnI+DQpUZWQgS3JvdmV0eiBoYXMgYXNrZWQgZm9y IHB1YmxpY2F0aW9uIG9mIC4uLjxicj4NCjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWtyb3ZldHotb2NiLXdpZGVibG9jay8iIHJlbD0ibm9yZWZl cnJlciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWtyb3ZldHotb2NiLXdpZGVibG9jay88L2E+PGJyPg0KLi4uLmFuZC4uLjxicj4NCjxhIGhy ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWtyb3ZldHotcmM2LXJj NS12ZWN0b3JzLyIgcmVsPSJub3JlZmVycmVyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQta3JvdmV0ei1yYzYtcmM1LXZlY3RvcnMvPC9hPjxi cj4NCjxicj4NCi4uLi5pbiB0aGUgSW5kZXBlbmRlbnQgU3RyZWFtLjxicj4NCjxicj4NClRoZXNl IGFyZSBib3RoIGN1cnJlbnRseSBpbiBleHBpcmVkIHN0YXRlLCBidXQgYXZhaWxhYmxlIGluIHRo ZSBhcmNoaXZlLjxicj4NCjxicj4NCkF0IHRoaXMgc3RhZ2UgSSBhbSBsb29raW5nIHRvIGtub3cg d2hldGhlciBhbnlvbmUgZmVlbHMgdGhhdCBwdWJsaWNhdGlvbjxicj4NCndvdWxkIGJlIGEgYmFk IHRoaW5nOjxicj4NCi0gYXQgdGhpcyBzdGFnZTxicj4NCi0gZXZlcjxicj4NCjxicj4NClBsZWFz ZSBzZW5kIG1lIHlvdXIgb3BpbmlvbnMgZGlyZWN0IChJIGFtIG5vdCBzdWJzY3JpYmVkIHRvIHRo aXMgbGlzdCwgYnV0PGJyPg0Kd2lsbCBjaGVjayB0aGUgYXJjaGl2ZXMpLjxicj4NCjxicj4NClBs ZWFzZSBhbHNvIGxldCBtZSBrbm93IGlmIHlvdSB3b3VsZCBiZSB3aWxsaW5nIHRvIGJlIGEgZGV0 YWlsZWQgcmV2aWV3ZXI8YnI+DQpvZiB0aGlzIHdvcmsuPGJyPg0KPGJyPg0KVGhhbmtzLDxicj4N CkFkcmlhbjxicj4NCi0tIDxicj4NCkFkcmlhbiBGYXJyZWwgKElTRSksPGJyPg0KPGEgaHJlZj0i bWFpbHRvOnJmYy1pc2VAcmZjLWVkaXRvci5vcmciIHRhcmdldD0iX2JsYW5rIj5yZmMtaXNlQHJm Yy1lZGl0b3Iub3JnPC9hPjxicj4NCjxicj4NCjwvYmxvY2txdW90ZT48L2Rpdj4NCjwvZGl2Pjwv YmxvY2txdW90ZT48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2IGRpcj0ibHRyIj48c3Bhbj5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bhbj48YnI+ PHNwYW4+Q2ZyZyBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPjxzcGFuPjxhIGhyZWY9Im1haWx0bzpD ZnJnQGlydGYub3JnIj5DZnJnQGlydGYub3JnPC9hPjwvc3Bhbj48YnI+PHNwYW4+PGEgaHJlZj0i aHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZnJnIj5odHRwczovL3d3dy5p cnRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Nmcmc8L2E+PC9zcGFuPjxicj48L2Rpdj48L2Jsb2Nr cXVvdGU+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --Apple-Mail-381AE348-9FA0-4090-8878-AEDB3051CB16-- --Apple-Mail-F62F13B3-64BD-4482-A46F-E9C79A383C01 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE6Iw ggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3Qg Q0EwHhcNMTMxMjE3MDAwMDAwWhcNMjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBD QS0zMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQ AAtoHCkvUpUEX6jFvBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDc LBFIn0nppOu9RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKag vm9zTybP6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXS GoCAmhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12BmDntJ jXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYDVR0PAQH/ BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1 L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQuZWR1L29jc3AwMwYD VR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybD9MTFJDQTCBkgYDVR0g BIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0GCyqGSIb3EgIBAwEHMA0GCyqG SIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0GCyqGSIb3EgIBAwEOMA0G CyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBBQUAA4IBAQAsf9HBn72qU7UT gkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/LTCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZ OFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZcEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAc MS77E5H62yyxK1WPPgcBipGVnu1xSHbTiHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F 4snAoqQMI98MzDYeLOkjlzKRs77r/aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvR J/g22r1MV8RR1PktjMsNOsPfMIIEvDCCA6SgAwIBAgIBKTANBgkqhkiG9w0BAQUFADBUMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYw FAYDVQQDEw1NSVRMTCBSb290IENBMB4XDTEzMTIxNzAwMDAwMFoXDTIwMTIzMTIzNTk1OVowUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STETMBEGA1UEAxMKTUlUTEwgQ0EtMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANow UnVtfLbltbTcRuofAdJKnJBWUAALaBwpL1KVBF+oxbwXfJkCOdxsi2EbgKOB1iaXu/4sxVzn0iQ7 OlDOaL7wjn14NmyYA2JQQvSQ3CwRSJ9J6aTrvUb6Y1kosbQuenK8CeVLOUD3bcbSnXpOSyV5dqCs N8PJYoVIsXj28VmndZu2TCimoL5vc08mz+hbpikcXmCY0qQdvnAGI6BhhG0lR8sfLsx5usQKATB8 WvG8vsg8/Cc5OrD/YopYD94l0hqAgJocgc75UEOUDTVj/hJqPY8/7pCoWFQf1cHcbaKrjwKp+Inw wCGjPXbW9OXMtYFwBUj92f4lJMcgWWVDkX8CAwEAAaOCAZowggGWMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFNdgZg57SY11TA39z0beyMcSh8q/MB8GA1UdIwQYMBaAFGeqes/0Cqa5crWK oNKd8hDDQ+0pMA4GA1UdDwEB/wQEAwIBhjBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0 dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0bz9MTFJDQTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Au bGwubWl0LmVkdS9vY3NwMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9n ZXRjcmw/TExSQ0EwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsqhkiG9xICAQMBCDAN BgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMBCjANBgsqhkiG9xICAQMB CzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG9xICAQMBEDANBgkqhkiG9w0B AQUFAAOCAQEALH/RwZ+9qlO1E4JMWq4wHO4sp4XAxIFsHs2CrXf0ixkkNA4bcyFfy0wsalC4znfh /h06jCVwfPpx584cqkON0bJxmThU+UX8z4feHW/2Sd6pduOA8JSSO8lwQNg5GXBBIDlgvWx3KxJc 1OjZ4oGoUluaHVSa4Zh/14UAHDEu+xOR+tsssStVjz4HAYqRlZ7tcUh204h3uw6n1kNrVTC1H9t1 2ISLmveJCbEHeI0oe9TVQ9HuxeLJwKKkDCPfDMw2HizpI5cykbO+6/2jLDwCsepzGjr0S+wstD46 edYtqhZGxpl/KH54dpHq40070Sf4Ntq9TFfEUdT5LYzLDTrD3zCCBO0wggPVoAMCAQICCjM4lI8A AAAAbpYwDQYJKoZIhvcNAQELBQAwUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xu IExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0EtMzAeFw0xNjAxMTQx NzMwMzlaFw0xOTAxMTMxNzMwMzlaMGExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29s biBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQZW9wbGUxIDAeBgNVBAMTF0JsdW1lbnRoYWwuVXJpLjUw MDEwNTg0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4xQ2hom9O5hwXTWlTDaY/fuI iWvivQHEzd8volNcoLbxxuHKLXgwX++2TdbsHbfpaHVtAvF8huN7Lkn6Taf6MCzlBJRWoAJz6hwL wFCMLJeQI853KST/u/FIuLt+GjDbHXT/kGbvRyNkIPj+njA9uY5I8m0/XUDMV2aTtqEwc55Vo2CC LXWYStQ1maiEdGre59mIwkkLGTV9JSeCcK7Yx2Ba2D552QtH9QdjO1eeCEvOtwhMn7uV6LaGcfGL h8GKSkhavNEhIenDAy3U3tWQI1sbJ28iguuK63krciNj1TfbgVnfjpXhqCAI1aIKTCiotKUkR3Ar sA8BnpKUFbmyvQIDAQABo4IBtTCCAbEwHQYDVR0OBBYEFPFPxYiZomy2ZdvinDW1VhNj2YqbMA4G A1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAWgBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFow WDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUF BzABhhtodHRwOi8vb2NzcC5sbC5taXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGC NxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQUwJQYDVR0lBB4wHAYEVR0lAAYI KwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQ gQ51cmlAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIEGh4YAEwATABVAHMAZQByAEUAbgBjAC0AUwBX MA0GCSqGSIb3DQEBCwUAA4IBAQAW7r7PZtIEuVPCSblXPqrbVdgVkNIw3qV6WHz/8TfK1UnETx3t kjFGhR+TjEYYXhiZHaIFlTZzK4x8UH6X3NM/MqLZQ98cFxDVlGOTKEJqRBgdpLBaoDHddtW6s0d1 mPOC3KLH6MNDKKZV7PJrzu056M8DPj7RmbNJqadj8wZL1nTW7Nq/+8FyT+v6S3ecz78sETYU4KFX tWjeIryJFPLL5CjIIL+WWjrKJ2lvCUunVGJr75NELwyUSEDUUdM6UKTiqfuFf14TGUYcUCdw41U4 4fUP6RypuwERYRa90ACeqHAo8syxeYrLGtVbIcexJQSJNHF4XqepizC6hjV92swJMIIFLTCCBBWg AwIBAgIKGnTEIAAAAACtAzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMW TUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z MB4XDTE3MDMwMTE4MjUwNloXDTIwMTIzMTIzNTk1OVowbDELMAkGA1UEBhMCVVMxHzAdBgNVBAoT Fk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTErMCkGA1UEAxMiQmx1bWVu dGhhbC5VcmkuNTAwMTA1ODQgKE1vYmlsaXR5KTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAIPvGwQfo8knxsqsf3y/Wufeqk3qvXxn2FyNsiRGai8yWs81dbuqC06DJyUOqYQiJEBqZT7D PvT6cyHMOZzfBmoRz1OhV109wUq+v258uIX7RrtOcv5/w1lpT5KLOj4UjQAfFhty/umt5h3KfcmL pj5HbTNtPtPKIlPUujoRa+gaBRaHhYyhHBYb76L5vRnEc0N4NXFx6K3uaerpgQixsWYtHBoQSP+2 ciZiVFKOdGwDynaVEamErIFO6ehsQoKSHGQVJU8QkpYjzv9E6ogTGfOezBeDnHoaRuy7sbnw9Kfo NNrl+2dGiH2Jxh5ZJt2OzYLxepVtlsQj5JaimpG9n7sCAwEAAaOCAeowggHmMB0GA1UdDgQWBBT2 4hQz+9byQZkS4cbSlPwlhEq/rTAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAU12BmDntJjXVM Df3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVk dS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0G CSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYWB4ECG18ZNAgFk AgEJMCwGA1UdJQEB/wQiMCAGCCsGAQUFBwMEBgorBgEEAYI3CgMMBggrBgEFBQcDAjAYBgNVHSAE ETAPMA0GCyqGSIb3EgIBAwEIMEEGA1UdEQQ6MDiBDnVyaUBsbC5taXQuZWR1oCYGCisGAQQBgjcU AgOgGAwWVVIyMDk4MEBtaXRsbC5hZC5sb2NhbDAtBgkrBgEEAYI3FAIEIB4eAEwATABNAG8AYgBp AGwAZQBTAGkAZwBBAHUAdABoMA0GCSqGSIb3DQEBCwUAA4IBAQA24maNQ5H6oQQOC2JJQfouPZOn Yey/pwxIN1nXmfwkWQKJ/Rt4T7FFneWCLLn0aaGFFSQAXFaLPO5F2ZpBdUYx/LyzRThFfGVXDcW1 guQ4gOnU7MCBIVzEhxbsqd7REb7ts+vn/RQuI72bbWMi8oqwSQuCsD/wDi5uNhp+JS3ja2OBMfJ6 tgId8YwfkKr6cQ9pNWmqEdH1mg8b9ma3WhUeN8djE5InnvsEdXYmexgOxvx8iYPTFLpCqtt6pumL NFSUHCbClNUNv0yy/fRUUWtfKLqwbxcCc3JZS4U3Kp722sFrenGBLxiCfQ7M8c+y0BAlyNCqz6TO 8d9krpTCY7dWMYIC2TCCAtUCAQEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNv bG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgoadMQgAAAA AK0DMA0GCWCGSAFlAwQCAQUAoIIBSzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xOTA0MDgxMjMwMTVaMC8GCSqGSIb3DQEJBDEiBCAipIVcGvJ/PIGG4cmr3WrZLaKe tOlN1PKeu8/HzmFPjDBuBgkrBgEEAYI3EAQxYTBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMC CjM4lI8AAAAAbpYwcAYLKoZIhvcNAQkQAgsxYaBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMC CjM4lI8AAAAAbpYwDQYJKoZIhvcNAQEBBQAEggEAW/zlEEYJwnk9UvkcXvDF1vX+dTvaOeCtdtcv 3AEo3Vlnnn3zRE2Bd1WXiuIDVbIyXkq03GU7h/MTCip/DIBMswE6HzsfLVaiUUw41Qfc1pxjYpPw ZSgqRZ+Rs/jVd2JlxBgFTVR9Mn7sfWjVFnic1fxXwjznBTj01nYFZ2zIUG2HcCQfuXHkDSekBC+p c1pC5J72F7y7X9vsMrryjCt/VE2SpnIfuApi0VrGgwpENm4glqhRC/2GFHOsw6v+01G+BIZRWmdX sw385m1SQTfRVlq1SCImykquy5oMTK9TY/iZcPnJaPs1vPu+QAn/qhsVhavEvBIQIQTRCIjYeg2N nwAAAAAAAA== --Apple-Mail-F62F13B3-64BD-4482-A46F-E9C79A383C01-- From nobody Mon Apr 8 05:37:03 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 233261202D7; Mon, 8 Apr 2019 05:37:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=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 PEX2LUBHSsGh; Mon, 8 Apr 2019 05:36:58 -0700 (PDT) Received: from llmx2.ll.mit.edu (LLMX2.LL.MIT.EDU [129.55.12.48]) by ietfa.amsl.com (Postfix) with ESMTP id 95CB0120086; Mon, 8 Apr 2019 05:36:58 -0700 (PDT) Received: from LLE2K16-MBX03.mitll.ad.local (LLE2K16-MBX03.mitll.ad.local) by llmx2.ll.mit.edu (unknown) with ESMTP id x38Cau41046875; Mon, 8 Apr 2019 08:36:57 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: Eric Rescorla CC: Nevil Brownlee , "" , cfrg , "secdir@ietf.org" Thread-Topic: [Cfrg] ISE seeks help with some crypto drafts Thread-Index: AQHU1dNTVBBNlvC7XkWW3z1y4bZa2qYyogiAgAAE2wA= Date: Mon, 8 Apr 2019 12:36:55 +0000 Message-ID: <884BADB1-BCC6-44A5-89D0-92EEDCB8FB21@ll.mit.edu> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 Content-Type: multipart/signed; boundary="Apple-Mail-4D490D3F-4FEF-4935-8E1E-CC325E0FD9FF"; protocol="application/pkcs7-signature"; micalg=sha-256 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-08_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904080106 Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 12:37:01 -0000 --Apple-Mail-4D490D3F-4FEF-4935-8E1E-CC325E0FD9FF Content-Type: multipart/alternative; boundary=Apple-Mail-6AF96301-550F-41AF-AD27-EFC493C5D892 Content-Transfer-Encoding: 7bit --Apple-Mail-6AF96301-550F-41AF-AD27-EFC493C5D892 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable P.S. Regardless, the Value/Cost of publishing approaches infinity. ;-) Regards, Uri Sent from my iPhone > On Apr 8, 2019, at 08:21, Eric Rescorla wrote: >=20 > These drafts seem quite low value to publish: >=20 > The existing OCB document [RFC 7253] is cited by exactly zero RFCs (https:= //datatracker.ietf.org/doc/rfc7253/referencedby/), so having a specification= for ciphers with block size !=3D 128 seems of particularly low value.=20 >=20 > The existing RC5 document [RFC 2040] has 6 RFC-level citations, but as far= as I know, RC5 has practically no usage in IETF protocols. AFAICT, RC6 isn'= t even specified in an RFC. Thus, test vectors for these algorithms don't se= em that interesting. >=20 > -Ekr >=20 >=20 >=20 >=20 >=20 >> On Fri, Mar 8, 2019 at 9:20 AM RFC ISE (Adrian Farrel) wrote: >> Hi CFRG and SecDir, >>=20 >> Ted Krovetz has asked for publication of ... >>=20 >> https://datatracker.ietf.org/doc/draft-krovetz-ocb-wideblock/ >> ....and... >> https://datatracker.ietf.org/doc/draft-krovetz-rc6-rc5-vectors/ >>=20 >> ....in the Independent Stream. >>=20 >> These are both currently in expired state, but available in the archive. >>=20 >> At this stage I am looking to know whether anyone feels that publication >> would be a bad thing: >> - at this stage >> - ever >>=20 >> Please send me your opinions direct (I am not subscribed to this list, bu= t >> will check the archives). >>=20 >> Please also let me know if you would be willing to be a detailed reviewer= >> of this work. >>=20 >> Thanks, >> Adrian >> --=20 >> Adrian Farrel (ISE), >> rfc-ise@rfc-editor.org >>=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg --Apple-Mail-6AF96301-550F-41AF-AD27-EFC493C5D892 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPlAuUy4gUmVnYXJk bGVzcywgdGhlIFZhbHVlL0Nvc3Qgb2YgcHVibGlzaGluZyBhcHByb2FjaGVzIGluZmluaXR5LiA7 LSk8YnI+PGJyPjxkaXYgZGlyPSJsdHIiIGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPlJlZ2FyZHMs PGRpdj5Vcmk8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlNlbnQgZnJvbSBteSBpUGhvbmU8L2Rp dj48L2Rpdj48ZGl2IGRpcj0ibHRyIj48YnI+T24gQXByIDgsIDIwMTksIGF0IDA4OjIxLCBFcmlj IFJlc2NvcmxhICZsdDs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIj5la3JAcnRmbS5jb208 L2E+Jmd0OyB3cm90ZTo8YnI+PGJyPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXYg ZGlyPSJsdHIiPjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9o dG1sOyBjaGFyc2V0PXV0Zi04Ij48ZGl2IGRpcj0ibHRyIj48ZGl2IGRpcj0ibHRyIj48ZGl2PlRo ZXNlIGRyYWZ0cyBzZWVtIHF1aXRlIGxvdyB2YWx1ZSB0byBwdWJsaXNoOjwvZGl2PjxkaXY+PGJy PjwvZGl2PjxkaXY+VGhlIGV4aXN0aW5nIE9DQiBkb2N1bWVudCBbUkZDIDcyNTNdIGlzIGNpdGVk IGJ5IGV4YWN0bHkgemVybyBSRkNzICg8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9yZmM3MjUzL3JlZmVyZW5jZWRieS8iIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9yZmM3MjUzL3JlZmVyZW5jZWRieS88L2E+KSwgc28gaGF2 aW5nIGEgc3BlY2lmaWNhdGlvbiBmb3IgY2lwaGVycyB3aXRoIGJsb2NrIHNpemUgIT0gMTI4IHNl ZW1zIG9mIHBhcnRpY3VsYXJseSBsb3cgdmFsdWUuIDxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48 ZGl2PlRoZSBleGlzdGluZyBSQzUgZG9jdW1lbnQgW1JGQyAyMDQwXSBoYXMgNiBSRkMtbGV2ZWwg Y2l0YXRpb25zLCBidXQgYXMgZmFyIGFzIEkga25vdywgUkM1IGhhcyBwcmFjdGljYWxseSBubyB1 c2FnZSBpbiBJRVRGIHByb3RvY29scy4gQUZBSUNULCBSQzYgaXNuJ3QgZXZlbiBzcGVjaWZpZWQg aW4gYW4gUkZDLiBUaHVzLCB0ZXN0IHZlY3RvcnMgZm9yIHRoZXNlIGFsZ29yaXRobXMgZG9uJ3Qg c2VlbSB0aGF0IGludGVyZXN0aW5nLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+LUVrcjwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJyPjwv ZGl2PjwvZGl2PjwvZGl2Pjxicj48ZGl2IGNsYXNzPSJnbWFpbF9xdW90ZSI+PGRpdiBkaXI9Imx0 ciIgY2xhc3M9ImdtYWlsX2F0dHIiPk9uIEZyaSwgTWFyIDgsIDIwMTkgYXQgOToyMCBBTSBSRkMg SVNFIChBZHJpYW4gRmFycmVsKSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJmYy1pc2VAcmZjLWVkaXRv ci5vcmciIHRhcmdldD0iX2JsYW5rIj5yZmMtaXNlQHJmYy1lZGl0b3Iub3JnPC9hPiZndDsgd3Jv dGU6PGJyPjwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdp bjowcHggMHB4IDBweCAwLjhleDtib3JkZXItbGVmdDoxcHggc29saWQgcmdiKDIwNCwyMDQsMjA0 KTtwYWRkaW5nLWxlZnQ6MWV4Ij5IaSBDRlJHIGFuZCBTZWNEaXIsPGJyPg0KPGJyPg0KVGVkIEty b3ZldHogaGFzIGFza2VkIGZvciBwdWJsaWNhdGlvbiBvZiAuLi48YnI+DQo8YnI+DQo8YSBocmVm PSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1rcm92ZXR6LW9jYi13aWRl YmxvY2svIiByZWw9Im5vcmVmZXJyZXIiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1rcm92ZXR6LW9jYi13aWRlYmxvY2svPC9hPjxicj4NCi4u Li5hbmQuLi48YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9k cmFmdC1rcm92ZXR6LXJjNi1yYzUtdmVjdG9ycy8iIHJlbD0ibm9yZWZlcnJlciIgdGFyZ2V0PSJf YmxhbmsiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWtyb3ZldHotcmM2 LXJjNS12ZWN0b3JzLzwvYT48YnI+DQo8YnI+DQouLi4uaW4gdGhlIEluZGVwZW5kZW50IFN0cmVh bS48YnI+DQo8YnI+DQpUaGVzZSBhcmUgYm90aCBjdXJyZW50bHkgaW4gZXhwaXJlZCBzdGF0ZSwg YnV0IGF2YWlsYWJsZSBpbiB0aGUgYXJjaGl2ZS48YnI+DQo8YnI+DQpBdCB0aGlzIHN0YWdlIEkg YW0gbG9va2luZyB0byBrbm93IHdoZXRoZXIgYW55b25lIGZlZWxzIHRoYXQgcHVibGljYXRpb248 YnI+DQp3b3VsZCBiZSBhIGJhZCB0aGluZzo8YnI+DQotIGF0IHRoaXMgc3RhZ2U8YnI+DQotIGV2 ZXI8YnI+DQo8YnI+DQpQbGVhc2Ugc2VuZCBtZSB5b3VyIG9waW5pb25zIGRpcmVjdCAoSSBhbSBu b3Qgc3Vic2NyaWJlZCB0byB0aGlzIGxpc3QsIGJ1dDxicj4NCndpbGwgY2hlY2sgdGhlIGFyY2hp dmVzKS48YnI+DQo8YnI+DQpQbGVhc2UgYWxzbyBsZXQgbWUga25vdyBpZiB5b3Ugd291bGQgYmUg d2lsbGluZyB0byBiZSBhIGRldGFpbGVkIHJldmlld2VyPGJyPg0Kb2YgdGhpcyB3b3JrLjxicj4N Cjxicj4NClRoYW5rcyw8YnI+DQpBZHJpYW48YnI+DQotLSA8YnI+DQpBZHJpYW4gRmFycmVsIChJ U0UpLDxicj4NCjxhIGhyZWY9Im1haWx0bzpyZmMtaXNlQHJmYy1lZGl0b3Iub3JnIiB0YXJnZXQ9 Il9ibGFuayI+cmZjLWlzZUByZmMtZWRpdG9yLm9yZzwvYT48YnI+DQo8YnI+DQo8L2Jsb2NrcXVv dGU+PC9kaXY+DQo8L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRp diBkaXI9Imx0ciI+PHNwYW4+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188L3NwYW4+PGJyPjxzcGFuPkNmcmcgbWFpbGluZyBsaXN0PC9zcGFuPjxicj48c3Bh bj48YSBocmVmPSJtYWlsdG86Q2ZyZ0BpcnRmLm9yZyI+Q2ZyZ0BpcnRmLm9yZzwvYT48L3NwYW4+ PGJyPjxzcGFuPjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlydGYub3JnL21haWxtYW4vbGlzdGluZm8v Y2ZyZyI+aHR0cHM6Ly93d3cuaXJ0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jZnJnPC9hPjwvc3Bh bj48YnI+PC9kaXY+PC9ibG9ja3F1b3RlPjwvYm9keT48L2h0bWw+ --Apple-Mail-6AF96301-550F-41AF-AD27-EFC493C5D892-- --Apple-Mail-4D490D3F-4FEF-4935-8E1E-CC325E0FD9FF Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCE6Iw ggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3Qg Q0EwHhcNMTMxMjE3MDAwMDAwWhcNMjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBD QS0zMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQ AAtoHCkvUpUEX6jFvBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDc LBFIn0nppOu9RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKag vm9zTybP6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXS GoCAmhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12BmDntJ jXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYDVR0PAQH/ BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1 L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQuZWR1L29jc3AwMwYD VR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybD9MTFJDQTCBkgYDVR0g BIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0GCyqGSIb3EgIBAwEHMA0GCyqG SIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0GCyqGSIb3EgIBAwEOMA0G CyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBBQUAA4IBAQAsf9HBn72qU7UT gkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/LTCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZ OFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZcEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAc MS77E5H62yyxK1WPPgcBipGVnu1xSHbTiHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F 4snAoqQMI98MzDYeLOkjlzKRs77r/aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvR J/g22r1MV8RR1PktjMsNOsPfMIIEvDCCA6SgAwIBAgIBKTANBgkqhkiG9w0BAQUFADBUMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYw FAYDVQQDEw1NSVRMTCBSb290IENBMB4XDTEzMTIxNzAwMDAwMFoXDTIwMTIzMTIzNTk1OVowUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BL STETMBEGA1UEAxMKTUlUTEwgQ0EtMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANow UnVtfLbltbTcRuofAdJKnJBWUAALaBwpL1KVBF+oxbwXfJkCOdxsi2EbgKOB1iaXu/4sxVzn0iQ7 OlDOaL7wjn14NmyYA2JQQvSQ3CwRSJ9J6aTrvUb6Y1kosbQuenK8CeVLOUD3bcbSnXpOSyV5dqCs N8PJYoVIsXj28VmndZu2TCimoL5vc08mz+hbpikcXmCY0qQdvnAGI6BhhG0lR8sfLsx5usQKATB8 WvG8vsg8/Cc5OrD/YopYD94l0hqAgJocgc75UEOUDTVj/hJqPY8/7pCoWFQf1cHcbaKrjwKp+Inw wCGjPXbW9OXMtYFwBUj92f4lJMcgWWVDkX8CAwEAAaOCAZowggGWMBIGA1UdEwEB/wQIMAYBAf8C AQAwHQYDVR0OBBYEFNdgZg57SY11TA39z0beyMcSh8q/MB8GA1UdIwQYMBaAFGeqes/0Cqa5crWK oNKd8hDDQ+0pMA4GA1UdDwEB/wQEAwIBhjBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0 dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0bz9MTFJDQTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Au bGwubWl0LmVkdS9vY3NwMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9n ZXRjcmw/TExSQ0EwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsqhkiG9xICAQMBCDAN BgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMBCjANBgsqhkiG9xICAQMB CzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG9xICAQMBEDANBgkqhkiG9w0B AQUFAAOCAQEALH/RwZ+9qlO1E4JMWq4wHO4sp4XAxIFsHs2CrXf0ixkkNA4bcyFfy0wsalC4znfh /h06jCVwfPpx584cqkON0bJxmThU+UX8z4feHW/2Sd6pduOA8JSSO8lwQNg5GXBBIDlgvWx3KxJc 1OjZ4oGoUluaHVSa4Zh/14UAHDEu+xOR+tsssStVjz4HAYqRlZ7tcUh204h3uw6n1kNrVTC1H9t1 2ISLmveJCbEHeI0oe9TVQ9HuxeLJwKKkDCPfDMw2HizpI5cykbO+6/2jLDwCsepzGjr0S+wstD46 edYtqhZGxpl/KH54dpHq40070Sf4Ntq9TFfEUdT5LYzLDTrD3zCCBO0wggPVoAMCAQICCjM4lI8A AAAAbpYwDQYJKoZIhvcNAQELBQAwUTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xu IExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlUTEwgQ0EtMzAeFw0xNjAxMTQx NzMwMzlaFw0xOTAxMTMxNzMwMzlaMGExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29s biBMYWJvcmF0b3J5MQ8wDQYDVQQLEwZQZW9wbGUxIDAeBgNVBAMTF0JsdW1lbnRoYWwuVXJpLjUw MDEwNTg0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA4xQ2hom9O5hwXTWlTDaY/fuI iWvivQHEzd8volNcoLbxxuHKLXgwX++2TdbsHbfpaHVtAvF8huN7Lkn6Taf6MCzlBJRWoAJz6hwL wFCMLJeQI853KST/u/FIuLt+GjDbHXT/kGbvRyNkIPj+njA9uY5I8m0/XUDMV2aTtqEwc55Vo2CC LXWYStQ1maiEdGre59mIwkkLGTV9JSeCcK7Yx2Ba2D552QtH9QdjO1eeCEvOtwhMn7uV6LaGcfGL h8GKSkhavNEhIenDAy3U3tWQI1sbJ28iguuK63krciNj1TfbgVnfjpXhqCAI1aIKTCiotKUkR3Ar sA8BnpKUFbmyvQIDAQABo4IBtTCCAbEwHQYDVR0OBBYEFPFPxYiZomy2ZdvinDW1VhNj2YqbMA4G A1UdDwEB/wQEAwIFIDAfBgNVHSMEGDAWgBTXYGYOe0mNdUwN/c9G3sjHEofKvzAzBgNVHR8ELDAq MCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsL0xMQ0EzMGYGCCsGAQUFBwEBBFow WDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5sbC5taXQuZWR1L2dldHRvL0xMQ0EzMCcGCCsGAQUF BzABhhtodHRwOi8vb2NzcC5sbC5taXQuZWR1L29jc3AwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGC NxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQUwJQYDVR0lBB4wHAYEVR0lAAYI KwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQ gQ51cmlAbGwubWl0LmVkdTAnBgkrBgEEAYI3FAIEGh4YAEwATABVAHMAZQByAEUAbgBjAC0AUwBX MA0GCSqGSIb3DQEBCwUAA4IBAQAW7r7PZtIEuVPCSblXPqrbVdgVkNIw3qV6WHz/8TfK1UnETx3t kjFGhR+TjEYYXhiZHaIFlTZzK4x8UH6X3NM/MqLZQ98cFxDVlGOTKEJqRBgdpLBaoDHddtW6s0d1 mPOC3KLH6MNDKKZV7PJrzu056M8DPj7RmbNJqadj8wZL1nTW7Nq/+8FyT+v6S3ecz78sETYU4KFX tWjeIryJFPLL5CjIIL+WWjrKJ2lvCUunVGJr75NELwyUSEDUUdM6UKTiqfuFf14TGUYcUCdw41U4 4fUP6RypuwERYRa90ACeqHAo8syxeYrLGtVbIcexJQSJNHF4XqepizC6hjV92swJMIIFLTCCBBWg AwIBAgIKGnTEIAAAAACtAzANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMW TUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0z MB4XDTE3MDMwMTE4MjUwNloXDTIwMTIzMTIzNTk1OVowbDELMAkGA1UEBhMCVVMxHzAdBgNVBAoT Fk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTErMCkGA1UEAxMiQmx1bWVu dGhhbC5VcmkuNTAwMTA1ODQgKE1vYmlsaXR5KTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAIPvGwQfo8knxsqsf3y/Wufeqk3qvXxn2FyNsiRGai8yWs81dbuqC06DJyUOqYQiJEBqZT7D PvT6cyHMOZzfBmoRz1OhV109wUq+v258uIX7RrtOcv5/w1lpT5KLOj4UjQAfFhty/umt5h3KfcmL pj5HbTNtPtPKIlPUujoRa+gaBRaHhYyhHBYb76L5vRnEc0N4NXFx6K3uaerpgQixsWYtHBoQSP+2 ciZiVFKOdGwDynaVEamErIFO6ehsQoKSHGQVJU8QkpYjzv9E6ogTGfOezBeDnHoaRuy7sbnw9Kfo NNrl+2dGiH2Jxh5ZJt2OzYLxepVtlsQj5JaimpG9n7sCAwEAAaOCAeowggHmMB0GA1UdDgQWBBT2 4hQz+9byQZkS4cbSlPwlhEq/rTAOBgNVHQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAU12BmDntJjXVM Df3PRt7IxxKHyr8wMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bC9MTENBMzBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVk dS9nZXR0by9MTENBMzAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0G CSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYWB4ECG18ZNAgFk AgEJMCwGA1UdJQEB/wQiMCAGCCsGAQUFBwMEBgorBgEEAYI3CgMMBggrBgEFBQcDAjAYBgNVHSAE ETAPMA0GCyqGSIb3EgIBAwEIMEEGA1UdEQQ6MDiBDnVyaUBsbC5taXQuZWR1oCYGCisGAQQBgjcU AgOgGAwWVVIyMDk4MEBtaXRsbC5hZC5sb2NhbDAtBgkrBgEEAYI3FAIEIB4eAEwATABNAG8AYgBp AGwAZQBTAGkAZwBBAHUAdABoMA0GCSqGSIb3DQEBCwUAA4IBAQA24maNQ5H6oQQOC2JJQfouPZOn Yey/pwxIN1nXmfwkWQKJ/Rt4T7FFneWCLLn0aaGFFSQAXFaLPO5F2ZpBdUYx/LyzRThFfGVXDcW1 guQ4gOnU7MCBIVzEhxbsqd7REb7ts+vn/RQuI72bbWMi8oqwSQuCsD/wDi5uNhp+JS3ja2OBMfJ6 tgId8YwfkKr6cQ9pNWmqEdH1mg8b9ma3WhUeN8djE5InnvsEdXYmexgOxvx8iYPTFLpCqtt6pumL NFSUHCbClNUNv0yy/fRUUWtfKLqwbxcCc3JZS4U3Kp722sFrenGBLxiCfQ7M8c+y0BAlyNCqz6TO 8d9krpTCY7dWMYIC2TCCAtUCAQEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNv bG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zAgoadMQgAAAA AK0DMA0GCWCGSAFlAwQCAQUAoIIBSzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3 DQEJBTEPFw0xOTA0MDgxMjM2NTJaMC8GCSqGSIb3DQEJBDEiBCCxPKjXk1AAtio+jQotIM7JdcCw HLLr89QrRO5QVNqjSzBuBgkrBgEEAYI3EAQxYTBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMC CjM4lI8AAAAAbpYwcAYLKoZIhvcNAQkQAgsxYaBfMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTMC CjM4lI8AAAAAbpYwDQYJKoZIhvcNAQEBBQAEggEAYkKk8neqLL2c8yioLmvi1dmZGUIyxGPozmzx CAZJkZMyb1TdvF19DUJyf9ZxATpNzunkEw3sPD8rM/4LcyCB3eTorshZmNidz/hXe1VbaQnCVCei LW00LwCeDiHiWhQTkeIMU1OTETWq4PlD9xXUUG0krzIMwNWZszERQvZuK2wfVmnGm5rZlwmiNVX5 A6hKbEWAN86GnXI4bj7oRrQRnE6Hnvl8jY66T+CErYKLEso600GfvP5oOzwC8mq/E2nTKzvHmC3j Y5DM1TK+lB8gQlOL3mc3nQXj3Vu4f10sgw2l3w2HpSRDmJ5GjMjv5fi0TkA4nEn37InKFIs21Ojy rwAAAAAAAA== --Apple-Mail-4D490D3F-4FEF-4935-8E1E-CC325E0FD9FF-- From nobody Mon Apr 8 05:40:47 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B83F120303 for ; Mon, 8 Apr 2019 05:40:33 -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, DKIMWL_WL_MED=-0.001, 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=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCOOt7ZaXRXJ for ; Mon, 8 Apr 2019 05:40:31 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::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 1266F1203D5 for ; Mon, 8 Apr 2019 05:40:28 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id h16so11055636ljg.11 for ; Mon, 08 Apr 2019 05:40:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZRdWkNm2gx8jSB+mk63gm3Kxzhj0L+PN6zg53c1iv6I=; b=olB69Qh/QY7KBESG3c/Pc/WqFDqCoxZYlw8zBA6RAJqAMtZG/cneFR0SubpmOdzfP6 edAgkewevrhXzTOwhcxygImBH5GClmwtsoVkQExjKRXHrJSmjDKf7cfsC5imA0FZI+CY Jsb4fTjAKrxl8lEglMgmfq8ii/lDIfy9L9WTJM6UOjg46OCMxda6fDhmWKIvz/dZ5gUy G2MA41OcU8MLlz+f0J+0obcIgeOco1RUm6TBUB5bIDfcmXXZxtDt/rmMAT83SFQ6E4lV oQ9Lat/PqdVn2wWwYngXaYeZDQ+wDV+zoc2wruVFECUm+FekUgnyxm71Wmft/dCYERqM sBzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZRdWkNm2gx8jSB+mk63gm3Kxzhj0L+PN6zg53c1iv6I=; b=iohlktF+LgAHQVvPODi+ihj/Bkz5K/OriFqcKR/M5/hGazHOslI0xlNUgcZtQNhWKG 36PanqrPvBa/gC1ad0QdFlQiTERLLdGDp4OrgHIwFRO78mXVHUoULHncXyEm9aSMG/PU 5GMxQi2e5aldRyQEJ6eDZc6pa+nn/Fl/nxy6e4B/4FB6zU45C0bH8gOyEdXYLhTP/ww4 3ViZz/KfEh9jeTkuqZKVPuw01UGsja0Iv6+tLZcx8KkkiKaXFrKWU/sChmNkshm1Lsa8 STEgo4pTuaGcWNfXrFtjYr8C/pP9Z06AxYvuF1j7pzBADS5ms1SnloB52O8L9/1X3Vk9 D2EA== X-Gm-Message-State: APjAAAVNVuWWKbrUF8ugO4SMHDbcrX7vPQaytQtq6qvGYQEbVwJbeMS1 jCZdPFN/erNaYb2OvpZULq1thEqvtbyITTKuesorHA== X-Google-Smtp-Source: APXvYqxFlRSOu3pfcZsdPplMhXQ5IpYxSOJBkyCqil8a+aO4QRXPNmYegcvYf4yu1H0uYqCwpROI9xYqLOLz7Vc04Fc= X-Received: by 2002:a2e:9a49:: with SMTP id k9mr16487566ljj.84.1554727226316; Mon, 08 Apr 2019 05:40:26 -0700 (PDT) MIME-Version: 1.0 References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <35FC8AD5-BF45-4C3E-A0A8-0EA426970DEA@ll.mit.edu> In-Reply-To: <35FC8AD5-BF45-4C3E-A0A8-0EA426970DEA@ll.mit.edu> From: Eric Rescorla Date: Mon, 8 Apr 2019 05:39:49 -0700 Message-ID: To: "Blumenthal, Uri - 0553 - MITLL" Cc: Nevil Brownlee , "" , cfrg , "secdir@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000c2bf90586042462" Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 12:40:38 -0000 --0000000000000c2bf90586042462 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 8, 2019 at 5:30 AM Blumenthal, Uri - 0553 - MITLL < uri@ll.mit.edu> wrote: > Well, we *are* interested in OCB and ciphers with block size != 128 bits, > even if we won't necessarily document our use in another RFC. > > Thus, I see your point but disagree with it's apparent conclusion. IMHO > the OCB draft should be published. > Why does having it documented in an RFC assist that? It's not difficult to find a description of OCB. -Ekr > Not sure about RC{5,6} - not my cup of tea. > > Regards, > Uri > > Sent from my iPhone > > On Apr 8, 2019, at 08:21, Eric Rescorla wrote: > > These drafts seem quite low value to publish: > > The existing OCB document [RFC 7253] is cited by exactly zero RFCs ( > https://datatracker.ietf.org/doc/rfc7253/referencedby/), so having a > specification for ciphers with block size != 128 seems of particularly low > value. > > The existing RC5 document [RFC 2040] has 6 RFC-level citations, but as far > as I know, RC5 has practically no usage in IETF protocols. AFAICT, RC6 > isn't even specified in an RFC. Thus, test vectors for these algorithms > don't seem that interesting. > > -Ekr > > > > > > On Fri, Mar 8, 2019 at 9:20 AM RFC ISE (Adrian Farrel) < > rfc-ise@rfc-editor.org> wrote: > >> Hi CFRG and SecDir, >> >> Ted Krovetz has asked for publication of ... >> >> https://datatracker.ietf.org/doc/draft-krovetz-ocb-wideblock/ >> ....and... >> https://datatracker.ietf.org/doc/draft-krovetz-rc6-rc5-vectors/ >> >> ....in the Independent Stream. >> >> These are both currently in expired state, but available in the archive. >> >> At this stage I am looking to know whether anyone feels that publication >> would be a bad thing: >> - at this stage >> - ever >> >> Please send me your opinions direct (I am not subscribed to this list, but >> will check the archives). >> >> Please also let me know if you would be willing to be a detailed reviewer >> of this work. >> >> Thanks, >> Adrian >> -- >> Adrian Farrel (ISE), >> rfc-ise@rfc-editor.org >> >> _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > > --0000000000000c2bf90586042462 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Apr 8, 2019 at 5:30 AM Blumen= thal, Uri - 0553 - MITLL <uri@ll.mit.e= du> wrote:
Well, we *are* interested in OCB and ciphers with block= size !=3D 128 bits, even if we won't necessarily document our use in a= nother RFC.

Thus, I see your point but disagree with it&= #39;s apparent conclusion. IMHO the OCB draft should be published.=C2=A0

Why does having it documented in = an RFC assist that? It's not difficult to find a description of OCB.

-Ekr


Not sure a= bout RC{5,6} - not my cup of tea.

Regards,
Uri

Sent from my iPhone

On Apr 8, 2019, at 0= 8:21, Eric Rescorla <e= kr@rtfm.com> wrote:

These drafts seem quite low= value to publish:

The existing OCB document [RFC = 7253] is cited by exactly zero RFCs (https://datatracker.ietf.org= /doc/rfc7253/referencedby/), so having a specification for ciphers with= block size !=3D 128 seems of particularly low value.

The existing RC5 document [RFC 2040] has 6 RFC-level citations, bu= t as far as I know, RC5 has practically no usage in IETF protocols. AFAICT,= RC6 isn't even specified in an RFC. Thus, test vectors for these algor= ithms don't seem that interesting.

-Ekr
<= div>




=
On Fri, Ma= r 8, 2019 at 9:20 AM RFC ISE (Adrian Farrel) <rfc-ise@rfc-editor.org> wrote:
=
Hi CFRG and SecDir,=

Ted Krovetz has asked for publication of ...

https://datatracker.ietf.org/doc/draft-= krovetz-ocb-wideblock/
....and...
https://datatracker.ietf.org/doc/draf= t-krovetz-rc6-rc5-vectors/

....in the Independent Stream.

These are both currently in expired state, but available in the archive.
At this stage I am looking to know whether anyone feels that publication would be a bad thing:
- at this stage
- ever

Please send me your opinions direct (I am not subscribed to this list, but<= br> will check the archives).

Please also let me know if you would be willing to be a detailed reviewer of this work.

Thanks,
Adrian
--
Adrian Farrel (ISE),
rfc-ise@rfc-edi= tor.org

_______= ________________________________________
Cfrg mailing list<= /span>
Cfrg@irt= f.org
https://www.irtf.org/mailman/listinfo/cfrg
--0000000000000c2bf90586042462-- From nobody Mon Apr 8 06:32:36 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AAC2120302; Mon, 8 Apr 2019 06:32:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable 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 bMz5T-MoyQzb; Mon, 8 Apr 2019 06:32:24 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89B001200E9; Mon, 8 Apr 2019 06:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12541; q=dns/txt; s=iport; t=1554730344; x=1555939944; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=ggjtacdMWujc/LMtmxO226jFrlIgKK4WqTnjhZBxbQg=; b=OeMMnjpn3Z4piMfUDQm0Yn/+bsOyxpVuMbq4y6JQyCqWWDH+P93GIdbv HHSqFSBibQIi9vYKvbXBmHZc4sxYjn7aCvad6OiJIk2X1fFca6yt2wiya q/1CcVCK1I4QWLzqSFvxCy4T5paz7F4eGThhf7BxnJKEbkT805ZvTr960 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAABGTKtc/5FdJa1lDgsBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYIQaIEDJwqEBIgcjSt+kVCFeIF7DgE?= =?us-ascii?q?BGAEMhEcChWUiNAkNAQEDAQEJAQIBAm0cDIVKAQEBAQIBAQEhSwYFBQsLCQ8?= =?us-ascii?q?nAwICJx8RBg4FgyIBgW0ID61SgS+ERQMPL0CEWQWBMAGEXIUmgUQXgT9AgRE?= =?us-ascii?q?nH4FOSQcuPoJhAQECAQGEZzGCJgOKUYIWLIY3kjwJg06ENYwAGoIFhhaJWIJ?= =?us-ascii?q?pjG2FCIppgnMCERWBTziBQgwIcBU7KgGCDQEzPoU7hRSFBFcjAQExAY9MAYE?= =?us-ascii?q?fAQE?= X-IronPort-AV: E=Sophos;i="5.60,325,1549929600"; d="scan'208,217";a="545130140" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Apr 2019 13:32:23 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x38DWNhl005130 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Apr 2019 13:32:23 GMT Received: from rtp-mcgrew-nitro2.cisco.com (10.117.145.147) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 8 Apr 2019 08:32:22 -0500 From: mcgrew Message-ID: <3D2D9C29-6FBB-45F5-ABA8-C52D3583C273@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_1F7E2104-EE71-4103-AEA6-C986148B9030" MIME-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Mon, 8 Apr 2019 09:32:08 -0400 In-Reply-To: <35FC8AD5-BF45-4C3E-A0A8-0EA426970DEA@ll.mit.edu> CC: Eric Rescorla , "" , cfrg , Nevil Brownlee , "secdir@ietf.org" To: "Blumenthal, Uri - 0553 - MITLL" References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <35FC8AD5-BF45-4C3E-A0A8-0EA426970DEA@ll.mit.edu> X-Mailer: Apple Mail (2.3445.104.8) X-Originating-IP: [10.117.145.147] X-ClientProxiedBy: xch-rtp-001.cisco.com (64.101.220.141) To XCH-ALN-004.cisco.com (173.36.7.14) X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 13:32:28 -0000 --Apple-Mail=_1F7E2104-EE71-4103-AEA6-C986148B9030 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi Uri, > On Apr 8, 2019, at 8:30 AM, Blumenthal, Uri - 0553 - MITLL = wrote: >=20 > Well, we *are* interested in OCB and ciphers with block size !=3D 128 = bits, even if we won't necessarily document our use in another RFC. The draft on OCB with general block size needs more usage guidance, as I = discussed with Ted and you when the drafts were first discussed last = year (please see = https://cfrg.irtf.narkive.com/QRDFp12y/rfcs-for-wider-block-rc6-and-ocb#po= st5). It is really important that an RFC provide strong guidance to = users, as their target audience is implementers and users that might not = understand the security ramifications. I am not opposed to publishing = this draft, but I see it as a critical next step to fully document the = interest that you mention, either in draft-krovetz-ocb-wideblock or in a = document that can be referenced by that one, along with usage guidance = on when it is a good idea to do AEAD with a wide block cipher or a small = block cipher. =20 The general block size draft would be more appealing if it could be tied = to a w !=3D 128 cipher that has withstood significant significant = cryptanalysis. For smaller block sizes, this could be one of the = modern 64-bit ciphers like PRESENT, SIMON, or SPECK, though I don=E2=80=99= t think we should be promoting the use of 64-bit modes of operation for = general-purpose use. For implementation environments where a 64-bit = cipher fits better than AES, it would be really attractive to use an = AEAD mode that is secure beyond the birthday bound, as a way to = compensate for the significant security degradation due to short blocks. = It would be great if we could leverage whatever interest there is in = small block ciphers into some momentum towards higher-security modes of = operation. =20 It looks like the drafts haven=E2=80=99t been updated since they were = first posted, though Ted expressed a willingness to update them. Thanks David >=20 > Thus, I see your point but disagree with it's apparent conclusion. = IMHO the OCB draft should be published.=20 >=20 > Not sure about RC{5,6} - not my cup of tea. >=20 > Regards, > Uri >=20 > Sent from my iPhone >=20 > On Apr 8, 2019, at 08:21, Eric Rescorla > wrote: >=20 >> These drafts seem quite low value to publish: >>=20 >> The existing OCB document [RFC 7253] is cited by exactly zero RFCs = (https://datatracker.ietf.org/doc/rfc7253/referencedby/ = ), so having a = specification for ciphers with block size !=3D 128 seems of particularly = low value.=20 >>=20 >> The existing RC5 document [RFC 2040] has 6 RFC-level citations, but = as far as I know, RC5 has practically no usage in IETF protocols. = AFAICT, RC6 isn't even specified in an RFC. Thus, test vectors for these = algorithms don't seem that interesting. >>=20 >> -Ekr >>=20 >>=20 >>=20 >>=20 >>=20 >> On Fri, Mar 8, 2019 at 9:20 AM RFC ISE (Adrian Farrel) = > wrote: >> Hi CFRG and SecDir, >>=20 >> Ted Krovetz has asked for publication of ... >>=20 >> https://datatracker.ietf.org/doc/draft-krovetz-ocb-wideblock/ = >> ....and... >> https://datatracker.ietf.org/doc/draft-krovetz-rc6-rc5-vectors/ = >>=20 >> ....in the Independent Stream. >>=20 >> These are both currently in expired state, but available in the = archive. >>=20 >> At this stage I am looking to know whether anyone feels that = publication >> would be a bad thing: >> - at this stage >> - ever >>=20 >> Please send me your opinions direct (I am not subscribed to this = list, but >> will check the archives). >>=20 >> Please also let me know if you would be willing to be a detailed = reviewer >> of this work. >>=20 >> Thanks, >> Adrian >> --=20 >> Adrian Farrel (ISE), >> rfc-ise@rfc-editor.org >>=20 >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg = > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg --Apple-Mail=_1F7E2104-EE71-4103-AEA6-C986148B9030 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Hi = Uri,

On Apr 8, 2019, at 8:30 AM, Blumenthal, Uri - = 0553 - MITLL <uri@ll.mit.edu> wrote:

Well, we *are* interested in OCB = and ciphers with block size !=3D 128 bits, even if we won't necessarily = document our use in another RFC.

The draft on OCB with general block size needs = more usage guidance, as I discussed with Ted and you when the drafts = were first discussed last year (please see https://cfrg.irtf.narkive.com/QRDFp12y/rfcs-for-wider-block-rc6= -and-ocb#post5).   It is really important that an RFC provide = strong guidance to users, as their target audience is implementers and = users that might not understand the security ramifications.   I am = not opposed to publishing this draft, but I see it as a critical next = step to fully document the interest that you mention, either in = draft-krovetz-ocb-wideblock or in a document that can be referenced by = that one, along with usage guidance on when it is a good idea to do AEAD = with a wide block cipher or a small block cipher. =   

The general block size = draft would be more appealing if it could be tied to a w !=3D 128 cipher = that has withstood significant significant cryptanalysis.   For = smaller block sizes, this could be one of the modern 64-bit ciphers like = PRESENT, SIMON, or SPECK, though I don=E2=80=99t think we should be = promoting the use of 64-bit modes of operation for general-purpose use. =   For implementation environments where a 64-bit cipher fits better = than AES, it would be really attractive to use an AEAD mode that is = secure beyond the birthday bound, as a way to compensate for the = significant security degradation due to short blocks.   It would be = great if we could leverage whatever interest there is in small block = ciphers into some momentum towards higher-security modes of operation. =  

It looks like the drafts = haven=E2=80=99t been updated since they were first posted, though Ted = expressed a willingness to update them.

Thanks

David


Thus, I see your point = but disagree with it's apparent conclusion. IMHO the OCB draft should be = published. 

Not sure about RC{5,6} - not my cup of tea.

Regards,
Uri

Sent from my iPhone

On Apr 8, 2019, at 08:21, Eric Rescorla <ekr@rtfm.com> wrote:

These drafts seem = quite low value to publish:

The existing OCB document [RFC 7253] is cited by exactly = zero RFCs (https://datatracker.ietf.org/doc/rfc7253/referencedby/), = so having a specification for ciphers with block size !=3D 128 seems of = particularly low value.

The existing RC5 document [RFC 2040] = has 6 RFC-level citations, but as far as I know, RC5 has practically no = usage in IETF protocols. AFAICT, RC6 isn't even specified in an RFC. = Thus, test vectors for these algorithms don't seem that = interesting.

-Ekr





On Fri, Mar = 8, 2019 at 9:20 AM RFC ISE (Adrian Farrel) <rfc-ise@rfc-editor.org> wrote:
Hi CFRG and SecDir,

Ted Krovetz has asked for publication of ...

https://datatracker.ietf.org/doc/draft-krovetz-ocb-wideblock/
....and...
https://datatracker.ietf.org/doc/draft-krovetz-rc6-rc5-vectors/=

....in the Independent Stream.

These are both currently in expired state, but available in the = archive.

At this stage I am looking to know whether anyone feels that = publication
would be a bad thing:
- at this stage
- ever

Please send me your opinions direct (I am not subscribed to this list, = but
will check the archives).

Please also let me know if you would be willing to be a detailed = reviewer
of this work.

Thanks,
Adrian
--
Adrian Farrel (ISE),
rfc-ise@rfc-editor.org

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
________________________________= _______________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

= --Apple-Mail=_1F7E2104-EE71-4103-AEA6-C986148B9030-- From nobody Mon Apr 8 10:16:25 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 193021200B7; Mon, 8 Apr 2019 10:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=cNRwgUN5; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=dDMXcZiX 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 9Xgyw_e-S_sK; Mon, 8 Apr 2019 10:16:20 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D65BC120103; Mon, 8 Apr 2019 10:16:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2634; q=dns/txt; s=iport; t=1554743780; x=1555953380; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=oc5GspCFN4BWWIjb5Ifk12QHe17bE22IxL2KMY18yxc=; b=cNRwgUN5zTm/caXA/b1VhoarhHPdsDaB+CKFG/hXZMVZCI3IMYTBZGwU UPRUqTuc4RYLqg6kzfrWyr/5ik7a870Y8WZqHsjoHr2sE6GOwpbEVa4s3 Y9gGthj1FUZfdI8A53yVSjGGHEBuDkPQ7SwrkrhSzjdJtWU5haGVFwcP0 A=; IronPort-PHdr: =?us-ascii?q?9a23=3AJJsgKxI/hEtS+lRrFdmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXFX4JfvyZiozNM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAAAWgatc/4wNJK1lGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgT1QA2hUIAQLJ4dVA4RSilaCV5cYgS6?= =?us-ascii?q?BJANUDgEBGAsJhEAChWUiNAkNAQEDAQEJAQIBAm0cDIVKAQEBBAEBOAYBASw?= =?us-ascii?q?LAQsEAgEIDgMEAQEfECcLHQgCBAENBQiDG4FdAxUBDqMcAooUgiCCeQEBBYR?= =?us-ascii?q?6GIIMAwWBMAGLRheBQD+BEUaCTD6CYQEBgWODOYImpgkJAogBjBqUXItThiK?= =?us-ascii?q?NXAIEAgQFAg4BAQWBTziBVnAVO4JsggoLAReDTIUUhT9ygSiPRQEB?= X-IronPort-AV: E=Sophos;i="5.60,326,1549929600"; d="scan'208";a="544977749" Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Apr 2019 17:16:18 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x38HGI3O006786 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Apr 2019 17:16:18 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 8 Apr 2019 12:16:17 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 8 Apr 2019 13:16:16 -0400 Received: from NAM05-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 8 Apr 2019 12:16:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=rf5sFZfy1N/OtilfylmeqcOZeqxmNw/zupd9ecLTLCs=; b=dDMXcZiXHb8BDm34CxWB212BB8yVuzo7dPIcRJ9KreChqPih7SZBeAKsc8uiPCLoahZwTu/P7jywrTuMJSOIORute588662i+Jxug6Zhhk7XdoxBuL4fH7sOVnfBhDCTOlXin/s5i0L3Nkl3vG4JVaVinqjZissadCMOfGzi3Lk= Received: from CY4PR11MB1527.namprd11.prod.outlook.com (10.172.70.18) by CY4PR11MB1894.namprd11.prod.outlook.com (10.175.61.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1771.21; Mon, 8 Apr 2019 17:16:14 +0000 Received: from CY4PR11MB1527.namprd11.prod.outlook.com ([fe80::11b1:a7a0:b5b8:bef]) by CY4PR11MB1527.namprd11.prod.outlook.com ([fe80::11b1:a7a0:b5b8:bef%8]) with mapi id 15.20.1771.016; Mon, 8 Apr 2019 17:16:14 +0000 From: "Panos Kampanakis (pkampana)" To: Yoav Nir , "secdir@ietf.org" CC: "spasm@ietf.org" , "ietf@ietf.org" , "draft-ietf-lamps-pkix-shake.all@ietf.org" Thread-Topic: [lamps] Secdir last call review of draft-ietf-lamps-pkix-shake-08 Thread-Index: AQHU5/ykXrE8DKHUeE+V24TJfSdmxKYyhOZQ Date: Mon, 8 Apr 2019 17:16:14 +0000 Message-ID: References: <155406252797.12369.12070204875103995275@ietfa.amsl.com> In-Reply-To: <155406252797.12369.12070204875103995275@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pkampana@cisco.com; x-originating-ip: [2001:420:c0c4:1005::f1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: da184403-edb3-4939-27fe-08d6bc45e7d6 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:CY4PR11MB1894; x-ms-traffictypediagnostic: CY4PR11MB1894: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0001227049 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(376002)(346002)(366004)(136003)(13464003)(51914003)(199004)(189003)(229853002)(106356001)(52536014)(71200400001)(71190400001)(2501003)(99286004)(5660300002)(7736002)(305945005)(74316002)(2906002)(105586002)(256004)(14444005)(86362001)(102836004)(6506007)(53546011)(7696005)(46003)(76176011)(186003)(478600001)(476003)(11346002)(68736007)(6116002)(14454004)(6436002)(6246003)(966005)(54906003)(97736004)(25786009)(8676002)(110136005)(316002)(4326008)(81166006)(81156014)(53936002)(6306002)(9686003)(8936002)(55016002)(446003)(486006)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR11MB1894; H:CY4PR11MB1527.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 9OW8GlQKCW/5vL8EMM4t7lXi7YdASREpW+XjMIWD9wU0176ob6JB76QGpaiPVipky/1Fqcxsz+VquJNx1cW3iIfxou8wuYNTHt5UUKxx3jXZfVySNLl7aCV3lkZU9FQbbLz/9iPGbtcUdhaygpiwF7VKTcEOdWvzOQeutwjD3fQsqMF/bRY6D4jRzq4fJbXQ9BE76SYCRXcf5YNfHp8uejHjrsHQa2P4aqjeATMWU0aKy11wT38KPrKAM9gBZmIBRll+bh8ttDfCeogJTnLzBeYGjyK8uj4mk9QaeP7ZKoFUcEXW2rM2YVDCZgaBnvZrGJaNn8Uqk+BgpBh+IqABKGc8Oif95S9A9Roblsl+5Z9b1wHBxMq5CeUw6SkmKw0XF+U5QmqsLxCidFrA0ekcn04kH6pDg04mgaRw6gfn7Sw= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: da184403-edb3-4939-27fe-08d6bc45e7d6 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Apr 2019 17:16:14.6459 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR11MB1894 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [secdir] [lamps] Secdir last call review of draft-ietf-lamps-pkix-shake-08 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 17:16:23 -0000 Thanks for the review Yoav.=20 I made changes in the Sec Considerations to address your comments. The chan= ges are described here https://github.com/csosto-pk/adding-shake-to-pkix/is= sues/42=20 I will reupload the draft at the end of this week probably unless there are= more comments while in IESG review. Panos -----Original Message----- From: Spasm On Behalf Of Yoav Nir via Datatracker Sent: Sunday, March 31, 2019 4:02 PM To: secdir@ietf.org Cc: spasm@ietf.org; ietf@ietf.org; draft-ietf-lamps-pkix-shake.all@ietf.org Subject: [lamps] Secdir last call review of draft-ietf-lamps-pkix-shake-08 Reviewer: Yoav Nir 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 com= ments were written primarily for the benefit of the security area directors= . Document editors and WG chairs should treat these comments just like any = other last call comments. The document is almost ready. The intent is clear and the IANA instructions= are good. I have two issues with the Security Considerations section. That section h= as two paragraphs, and I'll start with the second one. The second paragraph has a SHOULD-level requirement to choose an ECDSA curv= e with an appropriate strength to match that of the hash function (SHAKE128= vs SHAKE256). This seems to me like a compliance requirement. While this i= s not a hard-and-fast rule, these should usually go in the body of the docu= ment, such as in section 5 rather than in security considerations. It's al= so puzzling why there are no similar recommendations for the strength of th= e RSA key. The first paragraph I find confusing. It states that the SHAKE functions a= re deterministic, and goes on to explain that this means that executing the= m on the same input will result in the same output, and that users should n= ot expect this to be the case. Why does this need to be said? Is this not t= he same for any hash function? The paragraph than goes on to tell the reade= r that with different output lengths, the shorter ones are prefixes of the= longer ones, and that this is like hash function truncation. Why do we ne= ed any of this information and why is this related to security? This is es= pecially puzzling considering that the document fixes the output length to = a specific value for each of the two functions. _______________________________________________ Spasm mailing list Spasm@ietf.org https://www.ietf.org/mailman/listinfo/spasm From nobody Mon Apr 8 13:25:46 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3730712049C; Mon, 8 Apr 2019 13:24:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1554755083; bh=blB4SB48I27oKHPs57G84hYY3Zao1Bas+fUQVYiYWSY=; h=From:Date:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=lqlOJ3ly5704oUjoMPqE2e4wraoYcSfijYO6enmdP5LVF4ZoNEGTUTPyKzCSm3RUX p1GsCcz+rVmWn25hwD1qIGkRA7arGUwcQzJc5GCrcSzzVXyGLH94lcdA9bTwwtxi1h 6nNVGMat/oIJj5Tbf++MCqC3aWIFhJJ1o2OqgB1k= X-Mailbox-Line: From new-work-bounces@ietf.org Mon Apr 8 13:24:42 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C21C120494; Mon, 8 Apr 2019 13:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1554755082; bh=blB4SB48I27oKHPs57G84hYY3Zao1Bas+fUQVYiYWSY=; h=From:Date:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=ok2dStSUWOZFUgj7VFpTNXeuWxOdh8DI2tfrhDcNzaocpBPjq1C4aGA2q6vkErXjb 9bYTfRxI8o0CHFQ7SXIrmMsrWmW/B7Uaa3jTanWR/VzZTIENd1jPMFCBmhypz2sxCZ nsxlUgaSBO8CysoAaEx9XbSBK3nmdMaNev5jzt50= 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 979FC120494 for ; Mon, 8 Apr 2019 13:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vlF5AxyR1_w8 for ; Mon, 8 Apr 2019 13:24:38 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A47CD12048B for ; Mon, 8 Apr 2019 13:24:38 -0700 (PDT) Received: from [207.253.195.10] (helo=[172.19.43.129]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hDaom-0002N8-ID; Mon, 08 Apr 2019 20:24:36 +0000 From: Coralie Mercier Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Mon, 8 Apr 2019 16:24:35 -0400 Message-Id: <174DA899-19F2-4FE6-8447-B83CD960053F@w3.org> To: new-work@ietf.org X-Mailer: Apple Mail (2.3445.104.8) Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Mon, 08 Apr 2019 13:25:45 -0700 Subject: [secdir] [new-work] Proposed W3C Charters: HTML Working Group; Internationalization (i18n) Working Group and Interest Group (until 2019-05-03) X-BeenThere: secdir@ietf.org List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 20:24:46 -0000 Hello, The W3C Advisory Committee Representatives received a Proposal to review the following draft charters: * HTML Working Group: https://www.w3.org/2018/12/html.html * Internationalization (i18n) Working Group: https://www.w3.org/2019/04/proposed-i18n-wg-charter.html * Internationalization (i18n) Interest Group Charter: https://www.w3.org/2019/04/proposed-i18n-ig-charter.html As part of ensuring that the community is aware of proposed work at W3C, this draft charter is public during the Advisory Committee review period. W3C invites public comments through 2019-05-03 on the proposed charter. Please send comments to , 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 Wendy Seltzer , or Philippe Le Hegaret . Thank you, Coralie Mercier, Head of W3C Marketing & Communications [1] http://www.w3.org/Consortium/Member/List -- Coralie Mercier - W3C Marketing & Communications - https://www.w3.org mailto:coralie@w3.org +337 810 795 22 https://www.w3.org/People/Coralie/ _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Mon Apr 8 14:38:32 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77DAA120100; Mon, 8 Apr 2019 14:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=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 LdxDrUh3rvLK; Mon, 8 Apr 2019 14:38:19 -0700 (PDT) Received: from llmx3.ll.mit.edu (LLMX3.LL.MIT.EDU [129.55.12.49]) by ietfa.amsl.com (Postfix) with ESMTP id A238012034F; Mon, 8 Apr 2019 14:38:19 -0700 (PDT) Received: from LLE2K16-MBX02.mitll.ad.local (LLE2K16-MBX02.mitll.ad.local) by llmx3.ll.mit.edu (unknown) with ESMTP id x38LcHfF000774; Mon, 8 Apr 2019 17:38:17 -0400 From: "Blumenthal, Uri - 0553 - MITLL" To: mcgrew CC: "" , cfrg , "secdir@ietf.org" Thread-Topic: [Cfrg] ISE seeks help with some crypto drafts Thread-Index: AQHU1dNTVBBNlvC7XkWW3z1y4bZa2qYyogiAgAADAoCAABFKAIAARMSA Date: Mon, 8 Apr 2019 21:38:15 +0000 Message-ID: <5DCA3352-8546-4124-AAF6-E0C2E3362AD3@ll.mit.edu> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <35FC8AD5-BF45-4C3E-A0A8-0EA426970DEA@ll.mit.edu> <3D2D9C29-6FBB-45F5-ABA8-C52D3583C273@cisco.com> In-Reply-To: <3D2D9C29-6FBB-45F5-ABA8-C52D3583C273@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.17.0.190309 x-originating-ip: [172.25.1.90] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3637589895_540127552" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-08_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904080158 Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 21:38:24 -0000 --B_3637589895_540127552 Content-type: multipart/alternative; boundary="B_3637589895_1944450445" --B_3637589895_1944450445 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Hi Uri, On Apr 8, 2019, at 8:30 AM, Blumenthal, Uri - 0553 - MITLL = wrote: =20 Well, we *are* interested in OCB and ciphers with block size !=3D 128 bits, e= ven if we won't necessarily document our use in another RFC. =20 The draft on OCB with general block size needs more usage guidance, as I di= scussed with Ted and you when the drafts were first discussed last year (ple= ase see https://cfrg.irtf.narkive.com/QRDFp12y/rfcs-for-wider-block-rc6-and-= ocb#post5). =20 =20 Yes I remember. I will remind Ted. =20 It is really important that an RFC provide strong guidance to users, as the= ir target audience is implementers and users that might not understand the s= ecurity ramifications. =20 =20 Yes I agree with your point here.=20 =20 I am not opposed to publishing this draft,=20 =20 Thanks =20 but I see it as a critical next step to fully document the interest that yo= u mention, either in draft-krovetz-ocb-wideblock or in a document that can b= e referenced by that one, along with usage guidance on when it is a good ide= a to do AEAD with a wide block cipher or a small block cipher. =20 I think it would not be proper to document *my* interest. What IMHO would b= e good is documenting use cases, benefits and caveats of using blocks wider = and shorter than 128 bits. =20 The general block size draft would be more appealing if it could be tied to= a w !=3D 128 cipher that has withstood significant significant cryptanalysis.= =20 =20 Shorter blocks are for special applications only (or for classroom exercise= s). Longer blocks weren=E2=80=99t=20 =20 For smaller block sizes, this could be one of the modern 64-bit ciphers lik= e PRESENT, SIMON, or SPECK, though I don=E2=80=99t think we should be promoting th= e use of 64-bit modes of operation for general-purpose use. =20 =20 When AES-NI is in most every moderately large CPU? Nah, I=E2=80=99m not suggestin= g that we promote *general-purpose* use of 64-bit blocks. As I said, special= applications only. In general, =E2=80=9Cyou cannot get fired for selecting 128-bi= t block AES (and in my case =E2=80=93 with 256-bit key)=E2=80=9D. =F0=9F=98=89 =20 For implementation environments where a 64-bit cipher fits better than AES,= it would be really attractive to use an AEAD mode that is secure beyond the= birthday bound, as a way to compensate for the significant security degrada= tion due to short blocks. It would be great if we could leverage whatever = interest there is in small block ciphers into some momentum towards higher-s= ecurity modes of operation. =20 =20 That I=E2=80=99d need to discuss with Phil and Ted. I did not consider wide/gener= ic use of short blocks. =20 It looks like the drafts haven=E2=80=99t been updated since they were first poste= d, though Ted expressed a willingness to update them. =20 I=E2=80=99ll need to get hold of Ted. Somehow his email eludes me right now (than= ks, IT, for restoring only part of my email folders after the crash). =20 Thanks! =20 =20 =20 Thus, I see your point but disagree with it's apparent conclusion. IMHO the= OCB draft should be published.=20 =20 Not sure about RC{5,6} - not my cup of tea. Regards,=20 Uri =20 Sent from my iPhone On Apr 8, 2019, at 08:21, Eric Rescorla wrote: These drafts seem quite low value to publish: =20 The existing OCB document [RFC 7253] is cited by exactly zero RFCs (https:/= /datatracker.ietf.org/doc/rfc7253/referencedby/), so having a specification = for ciphers with block size !=3D 128 seems of particularly low value.=20 =20 The existing RC5 document [RFC 2040] has 6 RFC-level citations, but as far = as I know, RC5 has practically no usage in IETF protocols. AFAICT, RC6 isn't= even specified in an RFC. Thus, test vectors for these algorithms don't see= m that interesting. =20 -Ekr =20 =20 =20 =20 =20 On Fri, Mar 8, 2019 at 9:20 AM RFC ISE (Adrian Farrel) wrote: Hi CFRG and SecDir, Ted Krovetz has asked for publication of ... https://datatracker.ietf.org/doc/draft-krovetz-ocb-wideblock/ ....and... https://datatracker.ietf.org/doc/draft-krovetz-rc6-rc5-vectors/ ....in the Independent Stream. These are both currently in expired state, but available in the archive. At this stage I am looking to know whether anyone feels that publication would be a bad thing: - at this stage - ever Please send me your opinions direct (I am not subscribed to this list, but will check the archives). Please also let me know if you would be willing to be a detailed reviewer of this work. Thanks, Adrian --=20 Adrian Farrel (ISE), rfc-ise@rfc-editor.org _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg _______________________________________________ Cfrg mailing list Cfrg@irtf.org https://www.irtf.org/mailman/listinfo/cfrg --B_3637589895_1944450445 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Hi Uri,



On Apr 8, 2019, at 8:30 AM, Blumenthal, Uri - 0553 - = MITLL <uri@ll.mit.edu> wrote:=

 

Well, we *are* in= terested in OCB and ciphers with block size !=3D 128 bits, even if we won't ne= cessarily document our use in another RFC.

 

=

The draft on OCB with= general block size needs more usage guidance, as I discussed with Ted and y= ou when the drafts were first discussed last year (please see ht= tps://cfrg.irtf.narkive.com/QRDFp12y/rfcs-for-wider-block-rc6-and-ocb#post5<= /a>).  

 

Yes I remember. I will remind Ted.

 

It is really important that an RFC provide str= ong guidance to users, as their target audience is implementers and users th= at might not understand the security ramifications.  

 

<= p class=3DMsoNormal>Yes I agree with your point= here.

 

I= am not opposed to publishing this draft,

=  

Thanks

 

but I see it as a critical next step to fully= document the interest that you mention, either in draft-krovetz-ocb-wideblo= ck or in a document that can be referenced by that one, along with usage gui= dance on when it is a good idea to do AEAD with a wide block cipher or a sma= ll block cipher.

 

I think it would not be proper to document *my* interest. What= IMHO would be good is documenting use cases, benefits and caveats of using = blocks wider and shorter than 128 bits.

The general block size draft would b= e more appealing if it could be tied to a w !=3D 128 cipher that has withstood= significant significant cryptanalysis.  

 

Shorter blocks are for special applica= tions only (or for classroom exercises). Longer blocks weren=E2=80=99t =

 

For smaller block s= izes, this could be one of the modern 64-bit ciphers like PRESENT, SIMON, or= SPECK, though I don=E2=80=99t think we should be promoting the use of 64-bit mode= s of operation for general-purpose use.  

 

When AES-NI is in most every moderatel= y large CPU? Nah, I=E2=80=99m not suggesting that we promote *general-purpose* use of 64-bit blocks. As I said, special applications only. In general, = =E2=80=9Cyou cannot get fired for selecting 128-bit block AES (and in my case =E2=80=93 = with 256-bit key)=E2=80=9D. 😉

 =

For implementation en= vironments where a 64-bit cipher fits better than AES, it would be really at= tractive to use an AEAD mode that is secure beyond the birthday bound, as a = way to compensate for the significant security degradation due to short bloc= ks.   It would be great if we could leverage whatever interest there is= in small block ciphers into some momentum towards higher-security modes of = operation.  

 

That I=E2=80=99d need to discuss with Phil and Ted. I did not consider wid= e/generic use of short blocks.

 

Thanks!<= /span>

 

 

=

 

<= /div>

Thus, I see your point= but disagree with it's apparent conclusion. IMHO the OCB draft should be pu= blished. 

 

Not sur= e about RC{5,6} - not my cup of tea.

Regards,

Uri

 

Sent from my iPhone

These drafts seem quite low value t= o publish:

 

The existing OCB document [RFC 7253] is cited by exactly zero RFCs (https://datatracker.ietf.org/doc/rfc7253/referencedby/), so having a sp= ecification for ciphers with block size !=3D 128 seems of particularly low val= ue.

 

Th= e existing RC5 document [RFC 2040] has 6 RFC-level citations, but as far as = I know, RC5 has practically no usage in IETF protocols. AFAICT, RC6 isn't ev= en specified in an RFC. Thus, test vectors for these algorithms don't seem t= hat interesting.

 

-Ekr

 

 

 

 

 

On Fri, Mar 8, 2019 at 9:20 AM RFC ISE (Adrian Farrel) <rfc-ise@rfc-editor.org<= /a>> wrote:

Hi CFRG and SecDir,

Ted Krovetz = has asked for publication of ...

https://datatracker.ietf= .org/doc/draft-krovetz-ocb-wideblock/
....and...
htt= ps://datatracker.ietf.org/doc/draft-krovetz-rc6-rc5-vectors/

....= in the Independent Stream.

These are both currently in expired state,= but available in the archive.

At this stage I am looking to know whe= ther anyone feels that publication
would be a bad thing:
- at this sta= ge
- ever

Please send me your opinions direct (I am not subscribed= to this list, but
will check the archives).

Please also let me kn= ow if you would be willing to be a detailed reviewer
of this work.
Thanks,
Adrian
--
Adrian Farrel (ISE),
rfc-ise@rfc-editor.org

__________= _____________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

=

_= ______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/= listinfo/cfrg



--B_3637589895_1944450445-- --B_3637589895_540127552 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUfQYJKoZIhvcNAQcCoIIUbjCCFGoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJDMIIE8zCCA9ugAwIBAgITWQAAOzgEdUZQjK++4gAAAAA7ODANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01MB4XDTE4MDgyODIxNDUxMloXDTIxMDgy NzIxNDUxMlowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDE0zWuTga66uSgJTaWi2GCDYBG8hOb b4ShZyF5MmwbmeMe+YTLULi0X8PRdikj2OUS4HK8VV/q/6xpz9FfyprXqN7vkWdCyFXs9iDl Xl5ykQBho9yhpJh8bXmQNHmbePNC6vSK++E/u4bMg3geQ+mT2JFT/3ku/9s25L5HW7u+GCEV K7xGMVk3FT75NMa6epHJpUWhokBeUBUJqc4ETGV1eAvgwhMNGvjo4OszcLxYbf4tscQE72Bg +MRIB6Dsbv1/TUFjvJieIVWgkIJnvWDYFGkxZZVMW6DfiRAuSIRGMHpJ7MdskCkXmLpxhn6y dTwU3XBwAy9MPR95iDOiuIUHAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUfCB67qj53j+x7bB5 +ukYsqnhntMwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFC/vu8YNHbvpav6sZ/MHOwh2 9ktZMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvbGxj YTUwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUv Z2V0dG8vbGxjYTUwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9 BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+K cwIBZAIBCDAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAZBgNVHREEEjAQ gQ51cmlAbGwubWl0LmVkdTAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMCcGCSsGAQQBgjcU AgQaHhgATABMAFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAHW6pngg 31ognccfvFn3IjuRZKpZHsQk+VeDiVBW6xBE1vGhNDWmM/hiSSWOxvBwaTobtqrhacG0J6lm fNHiRYjCTVGp7aLbBncyCXIKncupe85QR3sBvkecnSgdP+NhSNeYgpciuRpqFnmNB1OH7/zb yZSpk/baZMZfSAW4Y9Fg5DGj25bslHje9z4u/Ikpn2ravGcIsHItrVuiGHyopzp6IK9PYv8l PMgxS6IKEQbduk6zHmk9fLQU0vG2KUsONKKkMJI/5kd5OTHLD3wvZIlIBOvOZD+emEDL6M8A LHfedidOxwtuQwo4dTv/1+C8EbYqHnjGsiK2GM/O76vDAOgwggTAMIIDqKADAgECAgEGMA0G CSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJv cmF0b3J5MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD01JVExMIFJvb3QgQ0EtMjAeFw0xNzAz MDIxMjAwMDBaFw0yNjAzMDIyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnmoMOvTkfw7nq19mrWazGaa+Q83Uv 0+ATXT3q6kr+WExIMIZ87C74WCcRXpvO7uvx7HvMsYWAFHW93wQwhjytxHIOZgKNJ4VnGVDU l+KI7g0n9+Zjt3hB3HhHbcvbe9+Y4jz+XzCiLl2OaYvICKbxvbBSCLtPEeZQ6x6Tb6EK0ym0 gvYeHO3kuuY+SJHJMltbrLnIVLxjZrNVS77zXKvu6Q3hSdkRIB7kJgEXfL+p/z/2p94bEEZ2 TnQz0TkOjG+Jq7UlXlFRtvsYcDPEQD3UNkZsWcXgC1hXG8TGknUcAhlGxVhlKlFLmNd7342s eGy2s9YxNDnSE+eXTtb0I5LLAgMBAAGjggGcMIIBmDASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdDgQWBBQv77vGDR276Wr+rGfzBzsIdvZLWTAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGu girH7vgy+zAOBgNVHQ8BAf8EBAMCAYYwZwYIKwYBBQUHAQEEWzBZMC4GCCsGAQUFBzAChiJo dHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExSQ0EyMCcGCCsGAQUFBzABhhtodHRwOi8v b2NzcC5sbC5taXQuZWR1L29jc3AwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC5sbC5t aXQuZWR1L2dldGNybC9MTFJDQTIwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsq hkiG9xICAQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMB CjANBgsqhkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG 9xICAQMBEDANBgkqhkiG9w0BAQsFAAOCAQEAMJYRwLPJ91K7e2mA2Nj10W0o5JMHYkaa+ctL 8/xY8QzIHFI5Ij+iydpPN9KCYn/4Sy80T3aNoYkFlS0GRQXhf0nsiY7TWJwAKw4AiO/yJ37/ oRKRgtyRicvaJ6RjlHCXBOalFLw9UtpodP4/idC51lxzsolaQZraBjVe7PL95PhS7D+22Nff InzLdIb1DBf54NwOVfPIgABtxH1fhZrja7EhR9RoUw5E1O6iWaAuP/xWhSTQFWlhyA0/kkIi 9/HXaY0hYnhcjcbPPqjpyfIhSFjjXhjqK7t2wPrSrBFLFUbnLiNlgQHrvNYF5IqgIfnSBWIr m3rfLhpZZJ/xJ7Yf6DCCA4owggJyoAMCAQICAQEwDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEY MBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMB4XDTE2MDQyMDEyMDAwMFoXDTM1MDQxOTIzNTk1 OVowVjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAK BgNVBAsTA1BLSTEYMBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAv3WoBEGOOJtm4ucvaf6vKIFPs8watCd6Smwq/XeRNo7P3jPIxNPw F398RGDUmPJIXA7idzD6j0opFIW+kLqYye9e788PV0dqaJlX8818fNDbSE+8B6hieqKTR7Vf OI74UVQEUKVRFuRFw6uVYuvgew2Tj/C2dEee37eruQl5nHkbV2OsWnZ7O+yt+etd6HRcaXLl P9q8WKgA3B7vkOVIMCKoAuaWj+BFq7K+WNkiyi/KdOH9JmOpbyRK4jcA7xbLnF8JFUSNg5c4 Y1BJrFaZtkCeG6Nm9p524GllkRFzPgpj8VicV+AK+9rY07dTx02kYotTnKuy0YxBAwsUXxAQ EwIDAQABo2MwYTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBT/ycllTFOA8akMPCGugirH 7vgy+zAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGugirH7vgy+zAOBgNVHQ8BAf8EBAMCAYYw DQYJKoZIhvcNAQELBQADggEBAHqYfEf/3J5aMKhlYQ0PnUAbMB8jZSr9/HvjfOF00crFUCfS rqG8JQwo+S/iq66gcp62FEgJ0fQkDgVg6m+C2ETo1LoWiSxhYCfcSIQECljlXwR8wFSayF82 2S69IqvHhdq4d58jU6gYi6ssjU4vwsvsVLRJKk/m/Cg/w8gW6YHM5ahBD6/5Ccel2fI7oSms kO991+otrC11YfDwCFvz7Am0r+K9iVhSWta4hmIuV0YBia07eZKSO02LPgQ8YOz3ku0Yt+mh 8VWRKux2CcYjMpk+WDV0BMp75tqb6pqBFkcKvEBXqxg+8+G/umjii4H0c5kvJhaQyykbmOKm xO9IcJIwggT2MIID3qADAgECAhNZAAA7OX5fo0OiIK0RAAAAADs5MA0GCSqGSIb3DQEBCwUA MFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYD VQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUwHhcNMTgwODI4MjE0NTI5WhcNMjEwODI3 MjE0NTI5WjBhMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEPMA0GA1UECxMGUGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI5Vc19RKc/69lmwhogDOjjzPQbmc8s6 Z6rzP6oUHAswDICqZWwPt+FTbKr0YTAqRNsTEN4YiW0fORK+fNRvClo0pdiCqj3DwDQZLRI4 Dak1yTsUtVe35oomQbXtO+0A0L/CowYri/UKeRG1i1/0cXSf4mAx0ed9wh2SordAb8o2FuOU 0B2ppnqjro1VFugHHX6QOggaeLFOprT5gnTZUmqM37/d4DGB9XDdTQi144zQSwSWKkaUThsy D9CHSRNcB79HBvlZGSM+BkIbayPdhQAuz4yKsOZEWPx/6LnMotzBevSswnCDf+u9ajCgMnje WbrZRN+xoYEuhycXyK2b8/MCAwEAAaOCAbUwggGxMB0GA1UdDgQWBBTZUpq7Rsccv42yU9UQ 4wvojOl4pzAOBgNVHQ8BAf8EBAMCBSAwHwYDVR0jBBgwFoAUL++7xg0du+lq/qxn8wc7CHb2 S1kwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9sbGNh NTBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9n ZXR0by9sbGNhNTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0G CSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0g AgFkAgEJMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBkGA1UdEQQS MBCBDnVyaUBsbC5taXQuZWR1MBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwJwYJKwYBBAGC NxQCBBoeGABMAEwAVQBzAGUAcgBFAG4AYwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEACyN6 Yhi9LApOPpf60ypSV2WmV3sqnrsrdlPTW+am4wMK/M/5PZmt5jFVtXaErkWYdrbMdjeo2o/G 9N2DnrFOhz7kDYM9HC9AH/rWCfoSkI/C2N6Rq/uDnRJfao61wyv37qKtanNdkp+reyLxdVPn foVrD/VZli4UV28u4XBuYDkjXPyyiH+bb395FnxOtTA3Uz41Ohpdvr6oLPEuy0IP4MPfK5wD mS6GXcB+ze9sYEp+DJxE7WAbkW5Y536WPl/rfWm/k6ZC1KPVSRM7mS+atk44VOgzPLXkl6Tu 6zY8tMczfr5F0om1JfN8G50s4QDUGtsMgzW+LXVDhFD24xnUojGCAf4wggH6AgEBMGgwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsM A1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNQITWQAAOzgEdUZQjK++4gAAAAA7ODANBglghkgB ZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCBK+HgnfSjV7eSW+AevxpWpaz+jr29+GFCIh6gc v3s9bTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xOTA0MDgy MTM4MTVaMA0GCSqGSIb3DQEBAQUABIIBAHep+JOEXTzORfNrJkarrhPkD/2P/mukgTZfO5lP NReUeHYMxpSjSMrh65aSESW7UPefzNHpsPHjJxc9f6cxEPduUtC+BHw1kFT9LZA3EBvbwRRr znxMvv+8Vwc6jHSpwL0WulJ2EEId/n1b0Y4TYd7QgHdXTHG8aWmIgqSDgEnuH6iooXH1XXl2 XikmkvbiR1R86WxCbifUalSJ/T8YUcbNN7VOXk7SX0XJp12Q4ROXOydRQ89pxaRmKqHqiL4f 2hcBHLFEUul5iJz5wnmcOh2xaHJvaQ8T9o9/yaCr0KiqBwkHQC2mNtQyHIaVrdZYr+/pVF8N Fmh+S27EjH8Fb24= --B_3637589895_540127552-- From nobody Mon Apr 8 14:59:31 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4568112009E; Mon, 8 Apr 2019 14:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 s7pGo85o0Tca; Mon, 8 Apr 2019 14:59:26 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2444C120052; Mon, 8 Apr 2019 14:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=33590; q=dns/txt; s=iport; t=1554760766; x=1555970366; h=from:message-id:mime-version:subject:date:in-reply-to:cc: to:references; bh=IpnLAEaChJ4+Isi8qmFeo5/TbYeh/quf28cZOExOIHU=; b=OCjxgQ29Hp46t1zPnmDxFRHeFh9lZMH9tGUAMFV7XbMFD2cFwbHcRz/q Ybrz9XYr6Ko/lLvdAfiXTlEVggAfFfn2LkOyEIhwni8DMmhPuMGlCsWGa PC/ay0NhPQy9/QMN4gOnn0AWP7+ioVEEHfcrpRNuWBgkUWmOz40BlfrS/ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AZAACqw6tc/4sNJK1lDgwBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVQCAQEBAQsBgQ6BAmhRMicKhASTPIINfpdcgWMEDgEBGAE?= =?us-ascii?q?MgxCBNwKFZSI3Bg0BAQMBAQkBAgECbRwMhUoBAQEDAQEBIUsGBQULCQIJDyA?= =?us-ascii?q?BBgMCAicfEQYOBYMiAYFtCA+SDJtlgS+ERQMPL0CEYQWBMAGEXIUmgUQXgT9?= =?us-ascii?q?AgREnH4FOSQcuPoJhAQECAQGBKgESAVWCVDGCJgOKUYJChjeFV4xlCYNOhDW?= =?us-ascii?q?MABqCBYYWiViCaYxthQiKaYJzAhEVgWUiZV0MCHAVOyoBgg0BMz6BKDAXg0y?= =?us-ascii?q?FFIUEVyMBATEBji2BHwGBHwEB?= X-IronPort-AV: E=Sophos;i="5.60,326,1549929600"; d="scan'208,217";a="459736476" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 08 Apr 2019 21:59:24 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x38LxNiV018590 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 8 Apr 2019 21:59:23 GMT Received: from rtp-mcgrew-nitro2.cisco.com (10.117.145.147) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 8 Apr 2019 16:59:22 -0500 From: mcgrew Message-ID: <168CCCFD-0A5D-4A12-958B-9ADB5B11B83C@cisco.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_7ABF367D-DE4E-4D43-9700-16C9BCD41E3F" MIME-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Date: Mon, 8 Apr 2019 17:59:10 -0400 In-Reply-To: <5DCA3352-8546-4124-AAF6-E0C2E3362AD3@ll.mit.edu> CC: "" , cfrg , "secdir@ietf.org" To: "Blumenthal, Uri - 0553 - MITLL" References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <35FC8AD5-BF45-4C3E-A0A8-0EA426970DEA@ll.mit.edu> <3D2D9C29-6FBB-45F5-ABA8-C52D3583C273@cisco.com> <5DCA3352-8546-4124-AAF6-E0C2E3362AD3@ll.mit.edu> X-Mailer: Apple Mail (2.3445.104.8) X-Originating-IP: [10.117.145.147] X-ClientProxiedBy: xch-rcd-010.cisco.com (173.37.102.20) To XCH-ALN-004.cisco.com (173.36.7.14) X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 21:59:30 -0000 --Apple-Mail=_7ABF367D-DE4E-4D43-9700-16C9BCD41E3F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Hi Uri, Please see inline: > On Apr 8, 2019, at 5:38 PM, Blumenthal, Uri - 0553 - MITLL = wrote: >=20 > Hi Uri, >=20 >=20 >> On Apr 8, 2019, at 8:30 AM, Blumenthal, Uri - 0553 - MITLL = > wrote: >> =20 >> Well, we *are* interested in OCB and ciphers with block size !=3D 128 = bits, even if we won't necessarily document our use in another RFC. > =20 > The draft on OCB with general block size needs more usage guidance, as = I discussed with Ted and you when the drafts were first discussed last = year (please see = https://cfrg.irtf.narkive.com/QRDFp12y/rfcs-for-wider-block-rc6-and-ocb#po= st5 = ). =20 > =20 > Yes I remember. I will remind Ted. > =20 > It is really important that an RFC provide strong guidance to users, = as their target audience is implementers and users that might not = understand the security ramifications. =20 > =20 > Yes I agree with your point here.=20 > =20 > I am not opposed to publishing this draft,=20 > =20 > Thanks > =20 > but I see it as a critical next step to fully document the interest = that you mention, either in draft-krovetz-ocb-wideblock or in a document = that can be referenced by that one, along with usage guidance on when it = is a good idea to do AEAD with a wide block cipher or a small block = cipher. > =20 > I think it would not be proper to document *my* interest. What IMHO = would be good is documenting use cases, benefits and caveats of using = blocks wider and shorter than 128 bits. > =20 > The general block size draft would be more appealing if it could be = tied to a w !=3D 128 cipher that has withstood significant significant = cryptanalysis. =20 > =20 > Shorter blocks are for special applications only (or for classroom = exercises). OCB with a w < 128 bit block cipher is a authenticated encryption = mechanism, not a length-preserving cipher, so I don=E2=80=99t understand = what special applications there are. =20 Classroom exercise don=E2=80=99t need an RFC. If there is no real-world = use case where we would recommend that someone use OCB with a w < 128 = bit block cipher, then we shouldn=E2=80=99t include that option in an = RFC. =20 > Longer blocks weren=E2=80=99t=20 > =20 Essentially the same issue arises with w > 128; what block ciphers have = seen enough cryptanalytic scrutiny at that width such that we would feel = good recommending their use in some situations? =20 Thanks David > For smaller block sizes, this could be one of the modern 64-bit = ciphers like PRESENT, SIMON, or SPECK, though I don=E2=80=99t think we = should be promoting the use of 64-bit modes of operation for = general-purpose use. =20 > =20 > When AES-NI is in most every moderately large CPU? Nah, I=E2=80=99m = not suggesting that we promote *general-purpose* use of 64-bit blocks. = As I said, special applications only. In general, =E2=80=9Cyou cannot = get fired for selecting 128-bit block AES (and in my case =E2=80=93 with = 256-bit key)=E2=80=9D. =F0=9F=98=89 > =20 > For implementation environments where a 64-bit cipher fits better than = AES, it would be really attractive to use an AEAD mode that is secure = beyond the birthday bound, as a way to compensate for the significant = security degradation due to short blocks. It would be great if we = could leverage whatever interest there is in small block ciphers into = some momentum towards higher-security modes of operation. =20 > =20 > That I=E2=80=99d need to discuss with Phil and Ted. I did not consider = wide/generic use of short blocks. > =20 > It looks like the drafts haven=E2=80=99t been updated since they were = first posted, though Ted expressed a willingness to update them. > =20 > I=E2=80=99ll need to get hold of Ted. Somehow his email eludes me = right now (thanks, IT, for restoring only part of my email folders after = the crash). > =20 > Thanks! > =20 > =20 >> =20 >> Thus, I see your point but disagree with it's apparent conclusion. = IMHO the OCB draft should be published.=20 >> =20 >> Not sure about RC{5,6} - not my cup of tea. >>=20 >> Regards,=20 >> Uri >> =20 >> Sent from my iPhone >>=20 >> On Apr 8, 2019, at 08:21, Eric Rescorla > wrote: >>=20 >>> These drafts seem quite low value to publish: >>> =20 >>> The existing OCB document [RFC 7253] is cited by exactly zero RFCs = (https://datatracker.ietf.org/doc/rfc7253/referencedby/ = ), so having a = specification for ciphers with block size !=3D 128 seems of particularly = low value.=20 >>> =20 >>> The existing RC5 document [RFC 2040] has 6 RFC-level citations, but = as far as I know, RC5 has practically no usage in IETF protocols. = AFAICT, RC6 isn't even specified in an RFC. Thus, test vectors for these = algorithms don't seem that interesting. >>> =20 >>> -Ekr >>> =20 >>> =20 >>> =20 >>> =20 >>> =20 >>> On Fri, Mar 8, 2019 at 9:20 AM RFC ISE (Adrian Farrel) = > wrote: >>>> Hi CFRG and SecDir, >>>>=20 >>>> Ted Krovetz has asked for publication of ... >>>>=20 >>>> https://datatracker.ietf..org/doc/draft-krovetz-ocb-wideblock/ = >>>> ....and... >>>> https://datatracker.ietf.org/doc/draft-krovetz-rc6-rc5-vectors/ = >>>>=20 >>>> ....in the Independent Stream. >>>>=20 >>>> These are both currently in expired state, but available in the = archive. >>>>=20 >>>> At this stage I am looking to know whether anyone feels that = publication >>>> would be a bad thing: >>>> - at this stage >>>> - ever >>>>=20 >>>> Please send me your opinions direct (I am not subscribed to this = list, but >>>> will check the archives). >>>>=20 >>>> Please also let me know if you would be willing to be a detailed = reviewer >>>> of this work. >>>>=20 >>>> Thanks, >>>> Adrian >>>> --=20 >>>> Adrian Farrel (ISE), >>>> rfc-ise@rfc-editor.org = ___________________________________________= ____ >>> Cfrg mailing list >>> Cfrg@irtf.org >>> https://www.irtf.org/mailman/listinfo/cfrg = >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> https://www.irtf.org/mailman/listinfo/cfrg >=20 >=20 >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg = --Apple-Mail=_7ABF367D-DE4E-4D43-9700-16C9BCD41E3F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8" Hi = Uri,

Please see = inline:

On Apr 8, 2019, at 5:38 PM, Blumenthal, Uri = - 0553 - MITLL <uri@ll.mit.edu> wrote:

Hi = Uri,


On Apr 8, 2019, at 8:30 AM, Blumenthal, = Uri - 0553 - MITLL <uri@ll.mit.edu> = wrote:
 
Well, we *are* = interested in OCB and ciphers with block size !=3D 128 bits, even if we = won't necessarily document our use in another RFC.
 
The draft on OCB with general block size needs = more usage guidance, as I discussed with Ted and you when the drafts = were first discussed last year (please see https://cfrg.irtf.narkive.com/QRDFp12y/rfcs-for-wider-block-rc6= -and-ocb#post5).   
 
Yes I remember. I = will remind Ted.
 
It is really important that an RFC provide strong guidance to = users, as their target audience is implementers and users that might not = understand the security ramifications.  
 
Yes I agree with = your point here. 
 
I am not opposed to publishing this draft, 
 
Thanks
 
but I see it as a critical next step to fully document the = interest that you mention, either in draft-krovetz-ocb-wideblock or in a = document that can be referenced by that one, along with usage guidance = on when it is a good idea to do AEAD with a wide block cipher or a small = block cipher.
 
I think it would = not be proper to document *my* interest. What IMHO = would be good is documenting use cases, benefits and caveats of using = blocks wider and shorter than 128 bits.
 
The general block = size draft would be more appealing if it could be tied to a w !=3D 128 = cipher that has withstood significant significant cryptanalysis. =   
 
Shorter blocks = are for special applications only (or for classroom exercises). =

OCB with a w < 128 bit = block cipher is a authenticated encryption mechanism, not a = length-preserving cipher, so I don=E2=80=99t understand what special = applications there are.  

Classroom exercise don=E2=80=99t need an RFC. =  If there is no real-world use case where we would recommend that = someone use OCB with a w < 128 bit block cipher, then we shouldn=E2=80=99= t include that option in an RFC.   

Longer blocks weren=E2=80=99t 
 
<= div>
Essentially the same issue arises with w > 128; = what block ciphers have seen enough cryptanalytic scrutiny at that width = such that we would feel good recommending their use in some situations? =   

Thanks

David

For smaller block sizes, this could be one of the modern = 64-bit ciphers like PRESENT, SIMON, or SPECK, though I don=E2=80=99t = think we should be promoting the use of 64-bit modes of operation for = general-purpose use.   
 
When AES-NI is in = most every moderately large CPU? Nah, I=E2=80=99m not suggesting that we = promote *general-purpose* use of 64-bit blocks. As I = said, special applications only. In general, =E2=80=9Cyou cannot get = fired for selecting 128-bit block AES (and in my case =E2=80=93 with = 256-bit key)=E2=80=9D. =F0=9F=98=89
 
For implementation environments where a 64-bit cipher fits = better than AES, it would be really attractive to use an AEAD mode that = is secure beyond the birthday bound, as a way to compensate for the = significant security degradation due to short blocks.   It would be = great if we could leverage whatever interest there is in small block = ciphers into some momentum towards higher-security modes of operation. =  
 
That I=E2=80=99d need to discuss with Phil and Ted. I did not = consider wide/generic use of short blocks.
 
It looks like the = drafts haven=E2=80=99t been updated since they were first posted, though = Ted expressed a willingness to update them.
 
I=E2=80=99ll need = to get hold of Ted. Somehow his email eludes me right now (thanks, IT, = for restoring only part of my email folders after the crash).
 
Thanks!
 
 
 
Thus, I see your point but disagree with it's = apparent conclusion. IMHO the OCB draft should be published. 
 

Not sure about RC{5,6} - not my = cup of tea.

Regards, 
Uri
 
Sent from my iPhone


On Apr 8, 2019, at 08:21, Eric = Rescorla <ekr@rtfm.com> wrote:

These drafts seem quite low value to publish:
 
The existing OCB document [RFC 7253] is = cited by exactly zero RFCs (https://datatracker.ietf.org/doc/rfc7253/referencedby/), = so having a specification for ciphers with block size !=3D 128 seems of = particularly low value. 
 
The existing RC5 document [RFC 2040] = has 6 RFC-level citations, but as far as I know, RC5 has practically no = usage in IETF protocols. AFAICT, RC6 isn't even specified in an RFC. = Thus, test vectors for these algorithms don't seem that interesting.
 
-Ekr
 
 
 
 
 
On Fri, Mar 8, 2019 = at 9:20 AM RFC ISE (Adrian Farrel) <rfc-ise@rfc-editor.org> wrote:

Hi CFRG and SecDir,

Ted = Krovetz has asked for publication of ...

https://datatracker.ietf..org/doc/draft-krovetz-ocb-wideblock/<= /a>
....and...
https://datatracker.ietf.org/doc/draft-krovetz-rc6-rc5-vectors/=

....in the Independent Stream.

These are both currently in expired state, but = available in the archive.

At this stage I = am looking to know whether anyone feels that publication
would be a bad thing:
- at this stage
- ever

Please send me your = opinions direct (I am not subscribed to this list, but
will = check the archives).

Please also let me = know if you would be willing to be a detailed reviewer
of = this work.

Thanks,
Adrian
-- 
Adrian Farrel (ISE),
rfc-ise@rfc-editor.org

_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg
_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg


_______________________________________________
Cfrg mailing list
Cfrg@irtf.org
https://www.irtf.org/mailman/listinfo/cfrg

= --Apple-Mail=_7ABF367D-DE4E-4D43-9700-16C9BCD41E3F-- From nobody Mon Apr 8 15:13:49 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3071120369 for ; Mon, 8 Apr 2019 15:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.122 X-Spam-Level: X-Spam-Status: No, score=-1.122 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=krovetz-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 GqgaIMSdqv_y for ; Mon, 8 Apr 2019 15:13:46 -0700 (PDT) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA826120362 for ; Mon, 8 Apr 2019 15:13:45 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id 188so8415739pfd.8 for ; Mon, 08 Apr 2019 15:13:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krovetz-net.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bRTcw54m/4s/p23TViMuvgpZ5B9Etd9731USoyxQBB8=; b=mdpIufeSK/g004y9MNl+sXWD6tX1+1MEYyv8hRC3OgWk9m+wuHKlOyXA0XLpezmZ2M KqzH55CDpYSxgbDXehqHnn+TSvh6kGKUNBKAAq49Je80xaBLdNhoSQL5zDQKnCMyt7W2 E8nV1Nu5pTXKF1C/ptGTseB9UyhAEWPFOI2JfTp9n3rSx03+8lIToG2QB72y0b+/iM7J wyKvVew5ObeRRiJyoFkbrCaZieZ4f80dxH/faDZ5s8puXbfWqHTsciBYidOr138Pca0a eXAX3D0ncrPgLrexJLeIFndwbmn9aN2EZpAJl1vhIQRcUCTy1ljZnjBzX9lOvw5Vm9A/ y6bg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bRTcw54m/4s/p23TViMuvgpZ5B9Etd9731USoyxQBB8=; b=HKDYg1wTZLkez2nu7cZUgXOzDXYNTjx03EwCijjYcDQCE8bigriCxvdH7bkrTB9wkC w5ja6E4DJv0ltS7xaNZlTTF8zKaUIbiN9eG75jer8rONV2WprnPM1Cyz/ZBxpnjEW9kE cq/yN2onkAQF9lIMZce8IgqxkhFvzwWQ54AyuK+Tq9cbeSnIMMp0e87mR3yPvOFTwtB3 6fIO68xiqX7MLE+JsyyTSVE8KFPkL7mdOg1k/G7exuDv+Igz+GTgeSgHrk9KHJa8Hr3B rysvFFI0x6+bI6LXdzXuqDUWQ8hyPscuatFjyIxUM8Qe5eNFX8VnQ6a3ffH8c2FPo+T2 ar+A== X-Gm-Message-State: APjAAAUpTHzkaCWs31lLB8RgEUe68eB1tLUtllZvzs58BOEjliWbCCCI z/tL1p/BPcCMMJUxHY/ZBXXDPg== X-Google-Smtp-Source: APXvYqxiA2MHM87WKSZKtIVEuxBsQekFByo1v3wZrcVG/FsHAV2ySQp2hJycFNTdyvq2SDbbxSweAg== X-Received: by 2002:a62:4ec8:: with SMTP id c191mr32162231pfb.138.1554761625378; Mon, 08 Apr 2019 15:13:45 -0700 (PDT) Received: from [130.86.69.236] ([130.86.69.236]) by smtp.gmail.com with ESMTPSA id i15sm44222527pfd.162.2019.04.08.15.13.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 08 Apr 2019 15:13:44 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) From: Ted Krovetz In-Reply-To: <3D2D9C29-6FBB-45F5-ABA8-C52D3583C273@cisco.com> Date: Mon, 8 Apr 2019 15:13:43 -0700 Cc: "Blumenthal, Uri - 0553 - MITLL" , cfrg , "" , Nevil Brownlee , "secdir@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <0C6D149C-781B-4E46-B3DB-0773452135FC@krovetz.net> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <35FC8AD5-BF45-4C3E-A0A8-0EA426970DEA@ll.mit.edu> <3D2D9C29-6FBB-45F5-ABA8-C52D3583C273@cisco.com> To: mcgrew X-Mailer: Apple Mail (2.3445.104.8) Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 22:13:47 -0000 > On Apr 8, 2019, at 6:32 AM, mcgrew wrote: >=20 > It looks like the drafts haven=E2=80=99t been updated since they were = first posted, though Ted expressed a willingness to update them. I have not updated anything as of now because my sense is that the = consensus will not be there for CFRG to adopt this project. = Additionally, there appears to be some agreement that crypto should not = go through the independent stream. That leaves this route as a likely = dead end. If this work does not become an RFC, I'd still like to publish it in = some stable way so that people could use it. Any suggestions?= From nobody Mon Apr 8 15:30:06 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9D2412010D; Mon, 8 Apr 2019 15:30:04 -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, 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 zS3SeZpBvsU8; Mon, 8 Apr 2019 15:30:03 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A9F012006E; Mon, 8 Apr 2019 15:30:03 -0700 (PDT) Received: from kduck.mit.edu (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.14.7/8.12.4) with ESMTP id x38MTwnL018224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 8 Apr 2019 18:30:00 -0400 Date: Mon, 8 Apr 2019 17:29:58 -0500 From: Benjamin Kaduk To: Ted Krovetz Cc: cfrg , "" , Nevil Brownlee , "secdir@ietf.org" Message-ID: <20190408222958.GV70202@kduck.mit.edu> References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <35FC8AD5-BF45-4C3E-A0A8-0EA426970DEA@ll.mit.edu> <3D2D9C29-6FBB-45F5-ABA8-C52D3583C273@cisco.com> <0C6D149C-781B-4E46-B3DB-0773452135FC@krovetz.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0C6D149C-781B-4E46-B3DB-0773452135FC@krovetz.net> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Apr 2019 22:30:05 -0000 On Mon, Apr 08, 2019 at 03:13:43PM -0700, Ted Krovetz wrote: > > > > On Apr 8, 2019, at 6:32 AM, mcgrew wrote: > > > > It looks like the drafts haven’t been updated since they were first posted, though Ted expressed a willingness to update them. > > > I have not updated anything as of now because my sense is that the consensus will not be there for CFRG to adopt this project. Additionally, there appears to be some agreement that crypto should not go through the independent stream. That leaves this route as a likely dead end. > > If this work does not become an RFC, I'd still like to publish it in some stable way so that people could use it. Any suggestions? There are probably a lot of options, including self-hosting (if you have a stable web space already) and publishing an I-D with a "tombstone" notice about "this document is not intended for publication as an RFC, but this revision is expected to be the final revision, and it is intended to have some use cases in this form". -Ben From nobody Tue Apr 9 23:44:33 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C51612029E; Tue, 9 Apr 2019 23:44:30 -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, RCVD_IN_DNSWL_LOW=-0.7] 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 yY6G2-ioKYDy; Tue, 9 Apr 2019 23:44:28 -0700 (PDT) Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.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 D0035120071; Tue, 9 Apr 2019 23:44:28 -0700 (PDT) Received: from in01.mta.xmission.com ([166.70.13.51]) by out02.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.87) (envelope-from ) id 1hE6xz-0004Tr-JY; Wed, 10 Apr 2019 00:44:15 -0600 Received: from [166.70.232.207] (helo=rumpleteazer.rhmr.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1hE6xz-0001Ay-2P; Wed, 10 Apr 2019 00:44:15 -0600 Received: from rumpleteazer.rhmr.com (localhost [127.0.0.1]) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Debian-4.1ubuntu1) with ESMTP id x3A6iBGx011576; Wed, 10 Apr 2019 00:44:11 -0600 Received: (from hilarie@localhost) by rumpleteazer.rhmr.com (8.14.4/8.14.4/Submit) id x3A6iBgD011575; Wed, 10 Apr 2019 00:44:11 -0600 Date: Wed, 10 Apr 2019 00:44:11 -0600 Message-Id: <201904100644.x3A6iBgD011575@rumpleteazer.rhmr.com> From: "Hilarie Orman" Reply-To: "Hilarie Orman" To: iesg@ietf.org, secdir@ietf.org, draft-ietf-acme-caa.all@tools.ietf.org X-XM-SPF: eid=1hE6xz-0001Ay-2P; ; ; mid=<201904100644.x3A6iBgD011575@rumpleteazer.rhmr.com>; ; ; hst=in01.mta.xmission.com; ; ; ip=166.70.232.207; ; ; frm=hilarie@purplestreak.com; ; ; spf=none X-XM-AID: U2FsdGVkX1/UWXFtybjlqHVwqeSbjyL7 X-SA-Exim-Connect-IP: 166.70.232.207 X-SA-Exim-Mail-From: hilarie@purplestreak.com X-Spam-DCC: XMission; sa03 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ***;iesg@ietf.org, secdir@ietf.org, draft-ietf-acme-caa.all@tools.ietf.org X-Spam-Relay-Country: X-Spam-Timing: total 251 ms - load_scoreonly_sql: 0.04 (0.0%), signal_user_changed: 3.2 (1.3%), b_tie_ro: 2.4 (0.9%), parse: 0.88 (0.4%), extract_message_metadata: 3.8 (1.5%), get_uri_detail_list: 1.04 (0.4%), tests_pri_-1000: 2.3 (0.9%), tests_pri_-950: 1.21 (0.5%), tests_pri_-900: 0.91 (0.4%), tests_pri_-90: 16 (6.5%), check_bayes: 15 (6.0%), b_tokenize: 4.2 (1.7%), b_tok_get_all: 5 (2.0%), b_comp_prob: 1.44 (0.6%), b_tok_touch_all: 2.7 (1.1%), b_finish: 0.62 (0.2%), tests_pri_0: 213 (85.0%), check_dkim_signature: 0.33 (0.1%), check_dkim_adsp: 6 (2.3%), poll_dns_idle: 4.0 (1.6%), tests_pri_10: 1.62 (0.6%), tests_pri_500: 4.1 (1.6%), rewrite_mail: 0.00 (0.0%) X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) Archived-At: Subject: [secdir] Security review of draft-ietf-acme-caa-06 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 06:44:31 -0000 Security review of CAA Record Extensions for Account URI and ACME Method Binding draft-ietf-acme-caa-06 Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The subject of this document is DNS records describing certificate issuance policies and how the policies can be made more granular through the use of two new parameters: accounturi and validationmethods. The first parameters designates particular accounts that can act as CAs for a domain, the second parameter names the methods that can be used for validation. It took me almost an hour to realize that "accounturi" was "account uri". It looked like some fancy foreign word. "He was not merely an accountant, he was an acounturi from a noble hereditary line." Moving on, the document claims that the only effect of the new parameters is to narrow the ways in which a certificate should be issued. There are no additional security measures. Bad actors can still be bad, men can remain in the middle. The new parameters are there for the use of good actors. I am not convinced that all of the items in section 5 really are "security considerations". The increased granularity is not in itself a security meaure. Some of the items relating to validation methods and DNSSEC are security consideration. As nearly as I can tell, there are no security problems. Hilarie From nobody Wed Apr 10 00:13:44 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AE0E1202BC; Wed, 10 Apr 2019 00:13:34 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Takeshi Takahashi via Datatracker To: Cc: draft-ietf-netconf-yang-push.all@ietf.org, netconf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Takeshi Takahashi Message-ID: <155488041402.1083.9565126428194093115@ietfa.amsl.com> Date: Wed, 10 Apr 2019 00:13:34 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-netconf-yang-push-22 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 07:13:34 -0000 Reviewer: Takeshi Takahashi Review result: Has Nits This draft talks about push-type update notifications of YANG datastore. It provides two types of subscriptions: periodic and on-change. I have one comments (item 4) and four clarification questions (items 1-3) below. 1. on the on-change subscription (in sections 3.3 and 3.10) The draft says "it will be important for client applications to have a way to identify for which objects on-change notifications are supported and for which ones they are not supported," but this issue is currently left to the implementation. It would be nice if you could provide some example solutions to this problem so that the implementers of this draft will not be confused. When a publisher accept on-change subscription even when the scope of the subscription contains objects for which on-change is not supported, I wonder sending some notification message on the situation could be helpful for the subscriber. By reading other part of the draft, I feel that the draft is indeed recommending to implement such comprehensive notifications. If so, it had better be clearly mentioned in this section. I also think it is not a bad idea to define such a comprehensive notification in this draft, though it is up to the authors. 2. on the differing dampening periods for multiple objects(in section 3) The draft says "In case whether a subscriber wants to have separate dampening periods for different objects, the subscriber has the option to create multiple subscriptions with different selection filters." That is a good solution. Then are the any other options for allowing to have separate dampening periods for different objects? The sentence gave me the impression that there are multiple options; so I am asking this question only for clarification. 3. imcomplete-update flag (in sections 3.11.1 and 4.3.2) I am not sure what would be the expected actions of the subscribers when they receive a message with incomplete-update flag on. Some navigations would be appreciated. Meanwhile, according to section 4.3.2, a publisher MAY subsequently send a push-update containing a full selection snapshot of subscribed data. If such a push-update is subsequently sent, does the publisher need to send anoter message with incomplete-update flag on prior to the push-update with a full selection snapshot of subscribed data? 4. security considerations (in section 7) This section enumerates four threats that are newly introduced by this draft. Some countermeasures, or directions to address these threats, had better be provided here. From nobody Wed Apr 10 12:01:56 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A76DD120389; Wed, 10 Apr 2019 12:01:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Daniel Migault via Datatracker To: Cc: roll@ietf.org, ietf@ietf.org, draft-ietf-roll-useofrplinfo.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Daniel Migault Message-ID: <155492289657.22741.9562291002133198844@ietfa.amsl.com> Date: Wed, 10 Apr 2019 12:01:36 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-roll-useofrplinfo-25 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2019 19:01:43 -0000 Reviewer: Daniel Migault Review result: Ready Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The summary of the review is READY nits: ROLL Working Group M. Robles Internet-Draft Aalto Updates: 6553, 6550, 8138 (if approved) M. Richardson Intended status: Standards Track SSW Expires: September 12, 2019 P. Thubert Cisco March 11, 2019 Using RPL Option Type, Routing Header for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data Plane draft-ietf-roll-useofrplinfo-25 Abstract This document looks at different data flows through LLN (Low-Power and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) is used to establish routing. The document enumerates the cases where RFC 6553 (RPL Option Type), RFC 6554 (Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is required in data plane. This analysis provides the basis on which to design efficient compression of these headers. """ s/on which// s/. /. / """ This document updates RFC 6553 adding a change to the RPL Option Type. Additionally, this document updates RFC 6550 to indicate about this change and updates RFC8138 as well to consider the new Option Type when RPL Option is decompressed. 1. Introduction RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) [RFC6550] is a routing protocol for constrained networks. RFC 6553 [RFC6553] defines the "RPL option" (RPI), carried within the IPv6 Hop-by-Hop header to quickly identify inconsistencies (loops) in the routing topology. RFC 6554 [RFC6554] defines the "RPL Source Route Header" (RH3), an IPv6 Extension Header to deliver datagrams within a There is certainly a reason for the RH3 spelling, but from 6554 it seems to me that the abbreviation of Source Routing Header is SRH. RPL routing domain, particularly in non-storing mode. For my personal knowledge, I do not understand why this is specific to non-storing mode. Is the reason that in non-storing modes nodes S steer datagram D via the root node R. The IPv6 packet (S,D) is tunneled from S to R and then from R to D. The first tunnel from S to R does not need SRH as nodes are able to steer this to the root (upward routing), while downward routing needs SRH extension. In a storing mode *regular* routing tables are able to steer the traffic from S, to D. There is no need of tunnel and SRH extension. Am I correct, or I am missing something? I apology in advance for the noise. 3. Updates to RFC6553, RFC6550 and RFC 8138 3.1. Updates to RFC 6553 This modification is required to be able to send, for example, IPv6 packets from a RPL-aware-leaf to a not-RPL-aware node through Internet (see Section 6.2.1), without requiring IPv6-in-IPv6 encapsulation. [RFC6553] states as shown below, that in the Option Type field of the RPL Option header, the two high order bits must be set to '01' and the third bit is equal to '1'. The first two bits indicate that the IPv6 node must discard the packet if it doesn't recognize the option type, and the third bit indicates that the Option Data may change in route. The remaining bits serve as the option type. Robles, et al. Expires September 12, 2019 [Page 5] Internet-Draft RPL-data-plane March 2019 Hex Value Binary Value act chg rest Description Reference --------- --- --- ------- ----------------- ---------- 0x63 01 1 00011 RPL Option [RFC6553] Figure 1: Option Type in RPL Option. Recent changes in [RFC8200] (section 4, page 8), states: "it is now expected that nodes along a packet's delivery path only examine and process the Hop-by-Hop Options header if explicitly configured to do so". Processing of the Hop-by-Hop Options header (by IPv6 intermediate nodes) is now optional, but if they are configured to process the header, and if such nodes encounter an option with the first two bits set to 01, they will drop the packet (if they conform to [RFC8200]). Host systems should do the same, irrespective of the configuration. Based on that, if an IPv6 (intermediate) node (RPL-not-capable) receives a packet with an RPL Option, it should ignore the HBH RPL option (skip over this option and continue processing the header). This is relevant, as it was mentioned previously, in the case that there is a flow from RPL-aware-leaf to Internet (see Section 6.2.1). I might miss something, but it seems to me that 2460 would end up in the discard of packets with the RPL Option. 8200 introduces some instability. Typically, packets may reach their destination depending on the configuration of the intermediary nodes. In both cases communication between RPL-aware and not-RPL-aware nodes needs to relax the status of the RPL Option. It seems independent to the update of 2460. Thus, this document updates the Option Type field to: the two high order bits MUST be set to '00' and the third bit is equal to '1'. The first two bits indicate that the IPv6 node MUST skip over this option and continue processing the header ([RFC8200] Section 4.2) if it doesn't recognize the option type, and the third bit continues to be set to indicate that the Option Data may change en route. The remaining bits serve as the option type and remain as 0x3. This ensures that a packet that leaves the RPL domain of an LLN (or that leaves the LLN entirely) will not be discarded when it contains the [RFC6553] RPL Hop-by-Hop option known as RPI. This is a significant update to [RFC6553]. [RFCXXXX] represents this document. Hex Value Binary Value act chg rest Description Reference --------- --- --- ------- ----------------- ---------- 0x23 00 1 00011 RPL Option [RFCXXXX] Figure 2: Revised Option Type in RPL Option. 5. Use cases NOTE: There is some possible security risk when the RPI information is released to the Internet. At this point this is a theoretical situation; no clear attack has been described. At worst, it is clear that the RPI option would waste some network bandwidth when it escapes. This is traded off against the savings in the LLN by not having to encapsulate the packet in order to remove the artifact. I believe that worst means minimal here. One of the risk is at least marking the packet as originating to/from a LLN. It may reveal the type of the information carried by the packet in addition to the information contained in the RPI. Possible information leaked may be related to the topology of the LLN, but I am not familiar enough to define clearly how this could be exploited. The information may also reveals information about the stability of the LLN by observing the rate. IF that is correct this could eventually provide indication an attack is effective or not. My understanding is that with 63 the packet is dropped after the first non aware router, while this is not the case with 23. Now that I have been through the security consideration section, I believe a sinple reference to the security consideration woudl be sufficient. 11. Security Considerations The security considerations covered in [RFC6553] and [RFC6554] apply when the packets are in the RPL Domain. The IPv6-in-IPv6 mechanism described in this document is much more limited than the general mechanism described in [RFC2473]. The willingness of each node in the LLN to decapsulate packets and forward them could be exploited by nodes to disguise the origin of an attack. While a typical LLN may be a very poor origin for attack traffic (as the networks tend to be very slow, and the nodes often have very low duty cycles) given enough nodes, they could still have a significant impact, particularly if the attack was on another LLN! maybe it might be clearer - at least to me, but I am not English native. s/was on another LLN!/is targeting another LLN!/ Additionally, some uses of RPL involve large backbone ISP scale equipment [I-D.ietf-anima-autonomic-control-plane], which may be equipped with multiple 100Gb/s interfaces. Blocking or careful filtering of IPv6-in-IPv6 traffic entering the LLN as described above will make sure that any attack that is mounted must originate from compromised nodes within the LLN. The use of BCP38 filtering at the RPL root on egress traffic will both alert the operator to the existence of the attack, as well as drop the attack traffic. As the RPL network is typically numbered from a single prefix, which is itself assigned by RPL, BCP38 filtering involves a single prefix comparison and should be trivial to automatically configure. There are some scenarios where IPv6-in-IPv6 traffic should be allowed to pass through the RPL root, such as the IPv6-in-IPv6 mediated communications between a new Pledge and the Join Registrar/ Coordinator (JRC) when using [I-D.ietf-anima-bootstrapping-keyinfra] and [I-D.ietf-6tisch-dtsecurity-secure-join]. This is the case for the RPL root to do careful filtering: it occurs only when the Join Coordinator is not co-located inside the RPL root. Robles, et al. Expires September 12, 2019 [Page 45] Internet-Draft RPL-data-plane March 2019 With the above precautions, an attack using IPv6-in-IPv6 tunnels will be by a node within the LLN on another node within the LLN. Such an attack could, of course, be done directly. An attack of this kind is meaningful only if the source addresses are either fake or if the point is to amplify return traffic. Such an attack, could also be done without the use of IPv6-in-IPv6 headers using forged source addresses. If the attack requires bi-directional communication, then IPv6-in-IPv6 provides no advantages. [RFC2473] suggests that tunnel entry and exit points can be secured, via the "Use IPsec". The suggested solution has all the problems that [RFC5406] goes into. In an LLN such a solution would degenerate into every node having a tunnel with every other node. It would provide a small amount of origin address authentication at a very high cost; doing BCP38 at every node (linking layer-3 addresses to layer-2 addresses, and to already present layer-2 cryptographic mechanisms) would be cheaper should RPL be run in an environment where hostile nodes are likely to be a part of the LLN. My understanding is that IPsec SA will be needed between each parent - children and that a hop-by-hop decapsulation/encapsulation is happening. If that is correct, we may avoid the situation where each node deals with 2 * n *(n-1) SA. However without any transit devices IPsec provides no obvious advantages over L2 security. It might be god to recommend that one or the other layer implements security. In addition, I am also wondering if the use of IPsec would not be recommended as an alternative when LLN are involving communication over the Internet. From nobody Wed Apr 10 17:26:12 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57C601203D2; Wed, 10 Apr 2019 17:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 NK-7FTbjnSqZ; Wed, 10 Apr 2019 17:25:31 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B20F1200A0; Wed, 10 Apr 2019 17:25:28 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [207.164.179.98]) by relay.sandelman.ca (Postfix) with ESMTPS id 9F82B1F482; Thu, 11 Apr 2019 00:25:25 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id 1FFC84289; Thu, 11 Apr 2019 01:31:13 +0200 (CEST) From: Michael Richardson To: Daniel Migault cc: secdir@ietf.org, roll@ietf.org, ietf@ietf.org, draft-ietf-roll-useofrplinfo.all@ietf.org In-reply-to: <155492289657.22741.9562291002133198844@ietfa.amsl.com> References: <155492289657.22741.9562291002133198844@ietfa.amsl.com> Comments: In-reply-to Daniel Migault via Datatracker message dated "Wed, 10 Apr 2019 12:01:36 -0700." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Wed, 10 Apr 2019 19:31:13 -0400 Message-ID: <22524.1554939073@dooku.sandelman.ca> Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-roll-useofrplinfo-25 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 00:25:42 -0000 --=-=-= Content-Type: text/plain Thank you for the review Daniel. I'm unclear if there are any changes you want, given that you've given it a "ready" Some replies/clarifications to your comments. Daniel Migault via Datatracker wrote: > RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) > [RFC6550] is a routing protocol for constrained networks. RFC 6553 > [RFC6553] defines the "RPL option" (RPI), carried within the IPv6 > Hop-by-Hop header to quickly identify inconsistencies (loops) in the > routing topology. RFC 6554 [RFC6554] defines the "RPL Source Route > Header" (RH3), an IPv6 Extension Header to deliver datagrams within a > There is certainly a reason for the RH3 spelling, but from 6554 > it seems to me that the abbreviation of Source Routing Header is SRH. > It's SRH type 3. The use of "RHx" is common in many documents, including 6554, so it would be wrong for us to change that, I think. > RPL routing domain, particularly in non-storing mode. > For my personal knowledge, I do not understand why this is > specific to non-storing mode. Is the reason that in non-storing modes > nodes S steer datagram D via the root node R. The IPv6 packet (S,D) is > tunneled from S to R and then from R to D. The first tunnel from S to R > does not need SRH as nodes are able to steer this to the root (upward > routing), while downward routing needs SRH extension. > In a storing mode *regular* routing tables are able to steer the > traffic from S, to D. There is no need of tunnel and SRH extension. > Am I correct, or I am missing something? I apology in advance for the > noise. Yes, that's correct. > Based on that, if an IPv6 (intermediate) node (RPL-not-capable) > receives a packet with an RPL Option, it should ignore the HBH RPL > option (skip over this option and continue processing the header). > This is relevant, as it was mentioned previously, in the case that > there is a flow from RPL-aware-leaf to Internet (see Section 6.2.1). > I might miss something, but it seems to me that 2460 would end > up in the discard of packets with the RPL Option. 8200 introduces some > instability. Typically, packets may reach their destination depending > on the configuration of the intermediary nodes. In both cases > communication between RPL-aware and not-RPL-aware nodes needs to relax > the status of the RPL Option. It seems independent to the update of > 2460. 2460 says that you have to examine all options, and discard if you do not understand. 8200 says that you examine options you are configured to examine. 8200 gives us additional options and removes the need for some IPIP tunnels, as we do not need to remove the option. > NOTE: There is some possible security risk when the RPI information > is released to the Internet. At this point this is a theoretical > situation; no clear attack has been described. At worst, it is clear > that the RPI option would waste some network bandwidth when it escapes. > This is traded off against the savings in the LLN by not having to > encapsulate the packet in order to remove the artifact. > I believe that worst means minimal here. One of the risk is at > least marking the packet as originating to/from a LLN. It may reveal > the type of the information carried by the packet in addition to the > information contained in the RPI. Possible information leaked may be > related to the topology of the LLN, but I am not familiar enough to > define clearly how this could be exploited. The information may also > reveals information about the stability of the LLN by observing the > rate. IF that is correct this could eventually provide indication an > attack is effective or not. > My understanding is that with 63 the packet is dropped after the first > non aware router, while this is not the case with 23. Correct. We picked 63 back in the day, so that packets that "escaped" would never reveal anything. But that was just too restrictive, and basically many assumed that they could just add/remove extension headers whenever they wanted. > Now that I have been through the security consideration section, I > believe a sinple reference to the security consideration woudl be > sufficient. I personally do not like writing text in SC that is new, I prefer to refer back to normative text in the Security Considerations, because non-security people do not read Security Considerations. > [RFC2473] suggests that tunnel entry and exit points can be secured, > via the "Use IPsec". The suggested solution has all the problems that > [RFC5406] goes into. In an LLN such a solution would degenerate into > every node having a tunnel with every other node. It would provide a > small amount of origin address authentication at a very high cost; > doing BCP38 at every node (linking layer-3 addresses to layer-2 > addresses, and to already present layer-2 cryptographic mechanisms) > would be cheaper should RPL be run in an environment where hostile > nodes are likely to be a part of the LLN. > My understanding is that IPsec SA will be needed between each > parent - children and that a hop-by-hop decapsulation/encapsulation is > happening. If that is correct, we may avoid the situation where each > node deals with 2 * n *(n-1) SA. However without any transit devices > IPsec provides no obvious advantages over L2 security. It might be god > to recommend that one or the other layer implements security. In > addition, I am also wondering if the use of IPsec would not be > recommended as an alternative when LLN are involving communication over > the Internet. A recommendation for End to End IPsec or End to End OSCORE/EDHOC or End to End DTLS for application data is certainly reasonably, but seems out of scope for this document. There are cases where we insert IPIP headers between nodes which are not parent-child. For instance, from root to leaf in the non-storing downward direction (because we add RH3). If we were to "Use IPsec", then we'd need more tunnels. In the cases where an RPL-aware 6LR adds an RPI header (in storing mode), for an RPL-unaware-leaf, and then sends it to some other leaf, we'd need an IPsec tunnel from two random nodes in order to secure the IPIP. So while we don't need 2*n*(n-1) SAs in every case, that is the worst case scenario. (btw: I think that there are some non-constrained, non-LLN uses of RPL where that actually might be worth doing) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAlyufMAACgkQlUzhVv38 QpDtXgf9G2QnODnORwLuHF5yjb2rLTgh9namaVq6bUFvNsPlHVooKKm/IMR8pozb P0UYK7xJJ616ItqHQTxJUejUwx7JvACRth8DUsfWmJztQRzCMH5YsRUfvCBpDcXu t9X1rXpt8tpPyCnFWu2sRj9vOEazA/zRlGG+Oaks8wR/SJSKBslj8xERtJMYqwoo iHWMHova4yy6tltkoXp73sY4j/m4sXzAFS+RzDhRycdMdXUPBXcumc5alYoQG2lC qx7icJdz9dbtAWIyGVubI1Zfwl9GRMtz9s9FZ8TGuAPAV1+PriH2Z1f61JuvGxhz izPHjMik27oVrLT/98ygU7gN3AYlrQ== =1s3k -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Apr 10 18:12:17 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B7A120465; Wed, 10 Apr 2019 18:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 lDiyK80ZsWGI; Wed, 10 Apr 2019 18:11:57 -0700 (PDT) Received: from NAM05-CO1-obe.outbound.protection.outlook.com (mail-eopbgr720041.outbound.protection.outlook.com [40.107.72.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C463E120125; Wed, 10 Apr 2019 18:11:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GCh32v/atE0NwLDyVGZLnpgdDRoG42OiWTdLKuwK6hM=; b=jEKvTk/QFhTDsm6raRhIN2zrbafoFRE3Sw6L40Ri/1r5Gre8ZyBWepkSh3XfUhVvqT6TPLws5FQM0SJoggGpZR7Rjxp8+y8TpLi38jUCO59CltZ7TYgf1eWtwUcDJBivb39DiOjO607tf8/DsMvt0K1W2XOlzRteC8HSM+Z5QfM= Received: from MN2PR15MB3310.namprd15.prod.outlook.com (20.179.21.142) by MN2PR15MB2735.namprd15.prod.outlook.com (20.179.147.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.14; Thu, 11 Apr 2019 01:11:54 +0000 Received: from MN2PR15MB3310.namprd15.prod.outlook.com ([fe80::3568:7582:3c7d:6f18]) by MN2PR15MB3310.namprd15.prod.outlook.com ([fe80::3568:7582:3c7d:6f18%2]) with mapi id 15.20.1771.016; Thu, 11 Apr 2019 01:11:54 +0000 From: Daniel Migault To: Michael Richardson CC: "secdir@ietf.org" , "roll@ietf.org" , "ietf@ietf.org" , "draft-ietf-roll-useofrplinfo.all@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-roll-useofrplinfo-25 Thread-Index: AQHU7/0VC3CEKOMN4UKr1zrsdJOI3aY2IUHA Date: Thu, 11 Apr 2019 01:11:53 +0000 Message-ID: References: <155492289657.22741.9562291002133198844@ietfa.amsl.com> <22524.1554939073@dooku.sandelman.ca> In-Reply-To: <22524.1554939073@dooku.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniel.migault@ericsson.com; x-originating-ip: [70.80.131.240] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: becde922-ddec-41f5-be94-08d6be1aaf6c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:MN2PR15MB2735; x-ms-traffictypediagnostic: MN2PR15MB2735: x-microsoft-antispam-prvs: x-forefront-prvs: 00046D390F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(346002)(136003)(39860400002)(366004)(51914003)(13464003)(51444003)(199004)(189003)(106356001)(33656002)(102836004)(4326008)(486006)(7736002)(7696005)(53936002)(6436002)(66066001)(105586002)(9686003)(476003)(305945005)(55016002)(229853002)(99286004)(186003)(446003)(86362001)(74316002)(25786009)(6246003)(44832011)(52536014)(11346002)(5660300002)(316002)(54906003)(81156014)(81166006)(2906002)(3846002)(53546011)(8676002)(14444005)(71200400001)(256004)(71190400001)(8936002)(26005)(97736004)(478600001)(6506007)(68736007)(76176011)(14454004)(6116002)(66574012); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR15MB2735; H:MN2PR15MB3310.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: LHwZzHV3nsMYzIOMdxIFokKdn1FknRms8J3CpcLArt/6h2eJUluIvGGgADU5LBF8bHxle87OnsireiQXGAh2dszp98ywVouucnbO3YdeSvr6nGufTSV0gADqyY5UQnc6e0pyOsvyQsmLu/8Dk85/RuD0dj3a85zBZj4Jxt9vShWiXlzEH0PLyBMAiGZf4eCurZxYurNAHz70zARSEmxx6FddQ9gHaMt3Hbvn/rCUCpa+yvYxGPNY3BIu/VkmwsmyvjDEvrTWEuWgdUq+2Dzvcru4LbWpiOWgHBhk26kvFM0l/dM4NT0vqgE/VR5BVki4Qnk9Gps/RkL0Xwe7JXET9/Of5Ci3b8gic3bFK9WrLWxyE2s8GJBpcn0FDLxgr7YKtsLv0qR5BbJmuFYeSgWpiftjsXQ+Eg9AqpagqYXjlI4= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: becde922-ddec-41f5-be94-08d6be1aaf6c X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Apr 2019 01:11:53.9139 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR15MB2735 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-roll-useofrplinfo-25 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 01:12:00 -0000 Thanks for the responses. I am not requesting any changes. My comments most= ly reflected some personal interests/questions. I found pretty much what I = needed in the text and let you decide if my comments may lead to some chang= es in the text. In any case that seems nits and I find the document ready.= =20 Yours,=20 Daniel -----Original Message----- From: Michael Richardson =20 Sent: Wednesday, April 10, 2019 7:31 PM To: Daniel Migault Cc: secdir@ietf.org; roll@ietf.org; ietf@ietf.org; draft-ietf-roll-useofrpl= info.all@ietf.org Subject: Re: Secdir last call review of draft-ietf-roll-useofrplinfo-25 Thank you for the review Daniel. I'm unclear if there are any changes you want, given that you've given it a= "ready" Some replies/clarifications to your comments. Daniel Migault via Datatracker wrote: > RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) > [RFC6550] is a routing protocol for constrained networks. RFC 6553 > [RFC6553] defines the "RPL option" (RPI), carried within the IPv6 > Hop-by-Hop header to quickly identify inconsistencies (loops) in the > routing topology. RFC 6554 [RFC6554] defines the "RPL Source Route > Header" (RH3), an IPv6 Extension Header to deliver datagrams within a > There is certainly a reason for the RH3 spelling, but from 655= 4 > it seems to me that the abbreviation of Source Routing Header is SRH. > It's SRH type 3. The use of "RHx" is common in many documents, including 6= 554, so it would be wrong for us to change that, I think. > RPL routing domain, particularly in non-storing mode. > For my personal knowledge, I do not understand why this is > specific to non-storing mode. Is the reason that in non-storing modes > nodes S steer datagram D via the root node R. The IPv6 packet (S,D) i= s > tunneled from S to R and then from R to D. The first tunnel from S to= R > does not need SRH as nodes are able to steer this to the root (upward > routing), while downward routing needs SRH extension. > In a storing mode *regular* routing tables are able to steer the > traffic from S, to D. There is no need of tunnel and SRH extension. > Am I correct, or I am missing something? I apology in advance for the > noise. Yes, that's correct. > Based on that, if an IPv6 (intermediate) node (RPL-not-capable) > receives a packet with an RPL Option, it should ignore the HBH RPL > option (skip over this option and continue processing the header). > This is relevant, as it was mentioned previously, in the case that > there is a flow from RPL-aware-leaf to Internet (see Section 6.2.1). > I might miss something, but it seems to me that 2460 would end > up in the discard of packets with the RPL Option. 8200 introduces som= e > instability. Typically, packets may reach their destination depending > on the configuration of the intermediary nodes. In both cases > communication between RPL-aware and not-RPL-aware nodes needs to rela= x > the status of the RPL Option. It seems independent to the update of > 2460. 2460 says that you have to examine all options, and discard if you do not u= nderstand. 8200 says that you examine options you are configured to examine= . 8200 gives us additional options and removes the need for some IPIP tunnels= , as we do not need to remove the option. > NOTE: There is some possible security risk when the RPI informatio= n > is released to the Internet. At this point this is a theoretical > situation; no clear attack has been described. At worst, it is clear > that the RPI option would waste some network bandwidth when it escape= s. > This is traded off against the savings in the LLN by not having to > encapsulate the packet in order to remove the artifact. > I believe that worst means minimal here. One of the risk is at > least marking the packet as originating to/from a LLN. It may reveal > the type of the information carried by the packet in addition to the > information contained in the RPI. Possible information leaked may be > related to the topology of the LLN, but I am not familiar enough to > define clearly how this could be exploited. The information may also > reveals information about the stability of the LLN by observing the > rate. IF that is correct this could eventually provide indication an > attack is effective or not. > My understanding is that with 63 the packet is dropped after the firs= t > non aware router, while this is not the case with 23. Correct. We picked 63 back in the day, so that packets that "escaped" woul= d never reveal anything. But that was just too restrictive, and basically = many assumed that they could just add/remove extension headers whenever the= y wanted. > Now that I have been through the security consideration section, I > believe a sinple reference to the security consideration woudl be > sufficient. I personally do not like writing text in SC that is new, I prefer to refer = back to normative text in the Security Considerations, because non-security= people do not read Security Considerations. > [RFC2473] suggests that tunnel entry and exit points can be secure= d, > via the "Use IPsec". The suggested solution has all the problems tha= t > [RFC5406] goes into. In an LLN such a solution would degenerate into > every node having a tunnel with every other node. It would provide a > small amount of origin address authentication at a very high cost; > doing BCP38 at every node (linking layer-3 addresses to layer-2 > addresses, and to already present layer-2 cryptographic mechanisms) > would be cheaper should RPL be run in an environment where hostile > nodes are likely to be a part of the LLN. > My understanding is that IPsec SA will be needed between each > parent - children and that a hop-by-hop decapsulation/encapsulation i= s > happening. If that is correct, we may avoid the situation where each > node deals with 2 * n *(n-1) SA. However without any transit devices > IPsec provides no obvious advantages over L2 security. It might be go= d > to recommend that one or the other layer implements security. In > addition, I am also wondering if the use of IPsec would not be > recommended as an alternative when LLN are involving communication ov= er > the Internet. A recommendation for End to End IPsec or End to End OSCORE/EDHOC or End to = End DTLS for application data is certainly reasonably, but seems out of sco= pe for this document. There are cases where we insert IPIP headers between nodes which are not pa= rent-child. For instance, from root to leaf in the non-storing downward di= rection (because we add RH3). If we were to "Use IPsec", then we'd need mo= re tunnels. In the cases where an RPL-aware 6LR adds an RPI header (in storing mode), f= or an RPL-unaware-leaf, and then sends it to some other leaf, we'd need an = IPsec tunnel from two random nodes in order to secure the IPIP. So while we don't need 2*n*(n-1) SAs in every case, that is the worst case = scenario. (btw: I think that there are some non-constrained, non-LLN uses of RPL wher= e that actually might be worth doing) -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Thu Apr 11 14:54:31 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC0C01205FD; Thu, 11 Apr 2019 14:54:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Aanchal Malhotra via Datatracker To: Cc: netconf@ietf.org, ietf@ietf.org, draft-ietf-netconf-restconf-notif.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Aanchal Malhotra Message-ID: <155501965074.14152.2835369201856309773@ietfa.amsl.com> Date: Thu, 11 Apr 2019 14:54:10 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-netconf-restconf-notif-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 21:54:11 -0000 Reviewer: Aanchal Malhotra Review result: Ready The document is very clear and concise. I just have one minor clarification question. Section 3.4 Page 9 that says the following: "In addition to any required ........SHOULD only be allowed......". Is there a reason for using SHOULD instead of MUST? From nobody Thu Apr 11 15:04:00 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA3F12040D for ; Thu, 11 Apr 2019 15:03:59 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <155502023917.13813.14042575607870056622.idtracker@ietfa.amsl.com> Date: Thu, 11 Apr 2019 15:03:59 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 22:03:59 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-04-11 Reviewer LC end Draft Derek Atkins 2019-03-03 draft-ietf-netmod-module-tags-07 Daniel Franke 2019-03-18 draft-ietf-sidrops-https-tal-07 Phillip Hallam-Baker 2019-03-18 draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-04 For telechat 2019-05-02 Reviewer LC end Draft Shaun Cooley 2019-03-13 draft-ietf-dots-data-channel-28 Stephen Farrell R2019-03-19 draft-ietf-dots-signal-channel-31 Last calls: Reviewer LC end Draft Nancy Cam-Winget 2019-02-15 draft-ietf-rtcweb-security-11 Daniel Gillmor 2018-03-19 draft-gutmann-scep-13 Charlie Kaufman 2019-03-14 draft-ietf-trans-rfc6962-bis-31 Catherine Meadows 2019-04-12 draft-ietf-mmusic-rfc4566bis-34 Alexey Melnikov 2019-04-11 draft-ietf-sidrops-lta-use-cases-05 Matthew Miller 2019-04-08 draft-ietf-core-multipart-ct-03 Russ Mundy 2019-04-22 draft-housley-hkdf-oids-01 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-08 Tim Polk 2019-04-17 draft-ietf-isis-segment-routing-extensions-23 Vincent Roca R2019-02-13 draft-ietf-perc-private-media-framework-09 Kyle Rose 2019-04-15 draft-ietf-pce-hierarchy-extensions-10 Joseph Salowey 2019-04-23 draft-ietf-opsawg-tacacs-13 David Waltermire 2019-02-15 draft-ietf-rtcweb-ip-handling-11 Klaas Wierenga 2019-02-26 draft-ietf-mpls-sr-over-ip-03 Taylor Yu 2019-02-15 draft-ietf-rtcweb-security-arch-18 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-11 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Kathleen Moriarty 2019-04-08 draft-ietf-bmwg-ngfw-performance-00 Next in the reviewer rotation: Rich Salz Stefan Santesson Yaron Sheffer Rifaat Shekh-Yusef Melinda Shore Valery Smyslov Robert Sparks Takeshi Takahashi Tina Tsou From nobody Fri Apr 12 10:28:54 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A0C12082D; Fri, 12 Apr 2019 10:16:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1555089361; bh=qBzGbkAkCVy0YjvjxU9QbkQao6eakI+Yld+h/7kkby0=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=DxspPie0jEVrnC9b9Yi9DD8KFdPqTLRgP10+UvnlJURyAoR4alI7l5QiO7wjfEOYU dTwuNkqQ7eDR4AeuLyGAxbHc3hjnhwGHvVoMiPdnxF6200h4kg6yyITbT/K3JT7UOh 80ROD6dAVCJJAxV4/3Mk6bVpI/Lv9nNgDR4xem5g= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Apr 12 10:15:57 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E4335120850; Fri, 12 Apr 2019 10:15:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1555089356; bh=qBzGbkAkCVy0YjvjxU9QbkQao6eakI+Yld+h/7kkby0=; h=From:To:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=uF1rg5C+VoHBNLrm2nmw1Zf1ET6gIOFYZ01NXuxFc3mSIatAJWNkRlZqj0+CwSsvt 0czreHvs7Rz+K3Z4Y0H3WFDLlDzwNNyuJF4gbMM8M0+jQ+HBUpSOKCGJ8Jk5QyucM5 T3RzQ+zgsFRQO1ny9ieZV1DiZN2oe295thaqTcuk= X-Original-To: new-work@ietf.org Delivered-To: new-work@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A5B2A12048E for ; Fri, 12 Apr 2019 10:15:47 -0700 (PDT) MIME-Version: 1.0 From: The IESG To: X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply_to: MIME-Version: 1.0 Message-ID: <155508934767.16732.17838167893922593299.idtracker@ietfa.amsl.com> Date: Fri, 12 Apr 2019 10:15:47 -0700 Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 12 Apr 2019 10:28:53 -0700 Subject: [secdir] [new-work] WG Review: JSON Mail Access Protocol (jmap) 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, 12 Apr 2019 17:16:06 -0000 The JSON Mail Access Protocol (jmap) WG in the Applications and Real-Time Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by 2019-04-22. JSON Mail Access Protocol (jmap) ----------------------------------------------------------------------- Current status: Active WG Chairs: Bron Gondwana Jim Fenton Assigned Area Director: Alexey Melnikov Applications and Real-Time Area Directors: Adam Roach Alexey Melnikov Barry Leiba Mailing list: Address: jmap@ietf.org To subscribe: https://www.ietf.org/mailman/listinfo/jmap Archive: https://mailarchive.ietf.org/arch/search/?email_list=jmap Group page: https://datatracker.ietf.org/group/jmap/ Charter: https://datatracker.ietf.org/doc/charter-ietf-jmap/ The JMAP protocol defined in draft-ietf-jmap-core is designed to be extensible to multiple datatypes which are useful for personal information management related to email stores. Now that draft-ietf-jmap-mail is completed, the working group will produce specifications for related data types, begining with calendars. The calendar work will be based on draft-ietf-calext-jscalandar as the data format. This working group will consult with the CALEXT working group to ensure that calendar access via JMAP remains compatible with existing calendar standards. Extensions to the existing core and mail JMAP specifications are also within scope for this working group, for example any additional parts of SIEVE, IMAP, SMTP submission, as well as transport of JMAP over different protocols than HTTPS. Work on JMAP extensions will be bound by the following constraints: 1) The work of this group is limited to developing protocols for a client synchronising data with a server. Any server-to-server issues are out of scope for this working group. 2) Object models will use existing IETF work where possible. 3) JMAP Extensions will be built following the core principles: 3.1) The server will not be required to perform work not explicitly requested by the client, and the default should always be the mode which requires the least server work. 3.2) The client can discover limits enforced by the server on resources or request complexity. 3.3) Where side effects generated by the server are optional, the protocol will default to no side effects, and the client must explicitly request that those side effects happen (for example: sending a calendar invitation or reply when updating an event) The working group will deliver documents for the following: - JMAP access to calendars using the JSCalendar format - accessing JMAP over Websockets - handling of S/MIME email messages (e.g. signature verification) over JMAP - Message Disposition Notifications (RFC 8098) via JMAP - other extensions which the working group considers related to email and compatible with the constraints listed above Milestones: Done - Update charter to reflect current and planned work Apr 2019 - Adopt a document for calendar access via JMAP Apr 2019 - Adopt a document for S/MIME interaction via JMAP Sep 2019 - Submit JMAP over websockets document to the IESG Sep 2019 - Submit Message Disposition Notification document to the IESG Dec 2019 - Submit document with guidance for implementation of IMAP servers and proxies (Informational) _______________________________________________ new-work mailing list new-work@ietf.org https://www.ietf.org/mailman/listinfo/new-work From nobody Fri Apr 12 14:30:12 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAE56120174; Fri, 12 Apr 2019 14:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=iEP9YD9Y; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=T3JlgMFR 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 OiRwbpmpDaSB; Fri, 12 Apr 2019 14:29:51 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BE831200B4; Fri, 12 Apr 2019 14:29:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1602; q=dns/txt; s=iport; t=1555104590; x=1556314190; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=hrcwsI6QKR0c7Srm7UgO0VjXxVA6tjB/d65lxmWne2A=; b=iEP9YD9YLvqTQdC2njLW6jMXtO/aa4BpAlByJZBFNDhYhwprK9drXd0j 3FJvTwEs4jAAEsYTDm0I4jCI8sJmg8PTH/vxUmByMtWTQ/uXLsLYvOEoO vn09r6UoZJziR2eH7jYY/+ga9VKaWaSk19gTvpRz9tJrci5X/FGwWy+Se E=; IronPort-PHdr: =?us-ascii?q?9a23=3AR/OwfxIal0zwunzaodmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvad2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXFfhJf7vZioSF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AXAAD1ArFc/40NJK1lDg0BAQEBAwE?= =?us-ascii?q?BAQcDAQEBgVEGAQEBCwGBPVADaFQgBAsoCoQEg0cDhFKKRJlxgS6BJANUDgE?= =?us-ascii?q?BGAsKg3pGAheFXyM0CQ4BAwEBCgECAQJtHAyFSwIEAQEhEQwBASwLAQ8CAQg?= =?us-ascii?q?aAiYCAgIlCxUQAgQBDQWDIgGBaQMcAQIMoUoCihRxgS+CeQEBBYUDGIINAwa?= =?us-ascii?q?BCycBi0gXgUA/gREnH4JMPoJhAQGBYReCczGCJo0lmQQJAoIFjlCDRBqCCIY?= =?us-ascii?q?ajFCLYpQUAgQCBAUCDgEBBYFPOIFWcBU7KgGCQYIKg2+FFIUEO3KBKY4oAYE?= =?us-ascii?q?fAQE?= X-IronPort-AV: E=Sophos;i="5.60,342,1549929600"; d="scan'208";a="546262128" Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Apr 2019 21:29:38 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id x3CLTcLu022670 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Apr 2019 21:29:38 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 12 Apr 2019 16:29:38 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 12 Apr 2019 17:29:37 -0400 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 12 Apr 2019 16:29:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hrcwsI6QKR0c7Srm7UgO0VjXxVA6tjB/d65lxmWne2A=; b=T3JlgMFR+2qBDDDHu6/FHDbC2j07n7Y0z57yNcdMvCJ5ceR2A/wLa1gojAd0TPoa09CddjubjYKGo3V+zSwedjBCX9LVADMJA3lhuZyNZVzFgIITmMQHYV2dfxkawF6j/5xxd4IDi5hUDW1I+OMi4RU620jxv1qerhyd+VyTyKE= Received: from MN2PR11MB3695.namprd11.prod.outlook.com (20.178.252.156) by MN2PR11MB4015.namprd11.prod.outlook.com (10.255.181.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.17; Fri, 12 Apr 2019 21:29:35 +0000 Received: from MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::8467:9ef7:d982:e972]) by MN2PR11MB3695.namprd11.prod.outlook.com ([fe80::8467:9ef7:d982:e972%3]) with mapi id 15.20.1771.021; Fri, 12 Apr 2019 21:29:35 +0000 From: "Reshad Rahman (rrahman)" To: Aanchal Malhotra , "secdir@ietf.org" CC: "draft-ietf-netconf-restconf-notif.all@ietf.org" , "netconf@ietf.org" , "ietf@ietf.org" Thread-Topic: [netconf] Secdir last call review of draft-ietf-netconf-restconf-notif-13 Thread-Index: AQHU8LEm3/ufrU/2dEa8pjPJiNurYqY4yTOA Date: Fri, 12 Apr 2019 21:29:35 +0000 Message-ID: References: <155501965074.14152.2835369201856309773@ietfa.amsl.com> In-Reply-To: <155501965074.14152.2835369201856309773@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.6.190114 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; x-originating-ip: [173.38.117.84] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 13697ad4-1be5-43d3-5f4b-08d6bf8df5e9 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600139)(711020)(4605104)(2017052603328)(7193020); SRVR:MN2PR11MB4015; x-ms-traffictypediagnostic: MN2PR11MB4015: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0005B05917 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(366004)(39860400002)(396003)(346002)(199004)(189003)(51914003)(14454004)(99286004)(83716004)(71190400001)(478600001)(4326008)(71200400001)(86362001)(53936002)(6246003)(2171002)(82746002)(6306002)(33656002)(256004)(105586002)(2501003)(106356001)(36756003)(966005)(8936002)(8676002)(66066001)(81156014)(81166006)(6512007)(54906003)(2906002)(25786009)(26005)(6436002)(305945005)(58126008)(7736002)(316002)(110136005)(76176011)(186003)(6116002)(11346002)(3846002)(102836004)(4744005)(5660300002)(6506007)(476003)(486006)(6486002)(97736004)(446003)(2616005)(68736007)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4015; H:MN2PR11MB3695.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: K9zo16CHGWjsbj6obb6XHx1rIvrNxQvSzcyW23T664xDAGn8/wvNIfBPVfE4bZoeucOJBZKEqWAox1BJqyAT7jjQJqI/YmtlZgv/b4z2DRV5gwibB+LqEzhor7sNKMoR/dWctw5QLp9Lwne87a20533pLKsIE7GE/901c1g37XhB0FvRXkh10HCmbNKinxxrk/w7GeeNpAnKjC8mkDCZnXAct9vgHwdIjbWvTq3D3cLFzqipz2r3HTCQ0sOu/Nz97hCAJlJdmoVC+/6VdWV61785Qo1BqjsWMusmaX5D9V8R4FZ7KjIvC7mZwoO1KzcrnhfUo5dYM4Gz29A2FnV0XKRuQJEkAeOuv5RQKHMjtjQgZrE2Tf2nrcoI36vYWnSJranDt/rVjKTidZB/A48cVIhOhhTEM6XtAl/mzBivses= Content-Type: text/plain; charset="utf-8" Content-ID: <2B51749631259B4796C32C5CEB11ECA9@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 13697ad4-1be5-43d3-5f4b-08d6bf8df5e9 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Apr 2019 21:29:35.5599 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4015 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-8.cisco.com Archived-At: Subject: Re: [secdir] [netconf] Secdir last call review of draft-ietf-netconf-restconf-notif-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 21:29:53 -0000 SGkgQWFuY2hhbCwNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3LiBQbGVhc2Ugc2VlIGlubGluZS4N Cg0K77u/T24gMjAxOS0wNC0xMSwgNTo1NCBQTSwgIm5ldGNvbmYgb24gYmVoYWxmIG9mIEFhbmNo YWwgTWFsaG90cmEgdmlhIERhdGF0cmFja2VyIiA8bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnIG9u IGJlaGFsZiBvZiBub3JlcGx5QGlldGYub3JnPiB3cm90ZToNCg0KICAgIFJldmlld2VyOiBBYW5j aGFsIE1hbGhvdHJhDQogICAgUmV2aWV3IHJlc3VsdDogUmVhZHkNCiAgICANCiAgICBUaGUgZG9j dW1lbnQgaXMgdmVyeSBjbGVhciBhbmQgY29uY2lzZS4gIEkganVzdCBoYXZlIG9uZSBtaW5vciBj bGFyaWZpY2F0aW9uIHF1ZXN0aW9uLg0KICAgIFNlY3Rpb24gMy40IFBhZ2UgOSB0aGF0IHNheXMg dGhlIGZvbGxvd2luZzoNCiAgICAiSW4gYWRkaXRpb24gdG8gYW55IHJlcXVpcmVkIC4uLi4uLi4u U0hPVUxEIG9ubHkgYmUgYWxsb3dlZC4uLi4uLiIuICANCiAgICANCiAgICBJcyB0aGVyZSBhIHJl YXNvbiBmb3IgdXNpbmcgU0hPVUxEIGluc3RlYWQgb2YgTVVTVD8gDQoNClRoZXJlIG1heSBiZSBy ZWFzb25zIHdoeSBhbiBpbXBsZW1lbnRhdGlvbiBkZWNpZGVzIG5vdCB0byBlbmZvcmNlIHRoaXMg cmVzdHJpY3Rpb24uIEdvaW5nIGJ5IFJGQzIxMTkgZGVmaW5pdGlvbnMsIHRoaXMgaXMgd2h5IHdl IGNob3NlIFNIT1VMRCBpbnN0ZWFkIG9mIE1VU1QuDQozLiBTSE9VTEQgICBUaGlzIHdvcmQsIG9y IHRoZSBhZGplY3RpdmUgIlJFQ09NTUVOREVEIiwgbWVhbiB0aGF0IHRoZXJlDQogICBtYXkgZXhp c3QgdmFsaWQgcmVhc29ucyBpbiBwYXJ0aWN1bGFyIGNpcmN1bXN0YW5jZXMgdG8gaWdub3JlIGEN CiAgIHBhcnRpY3VsYXIgaXRlbSwgYnV0IHRoZSBmdWxsIGltcGxpY2F0aW9ucyBtdXN0IGJlIHVu ZGVyc3Rvb2QgYW5kDQogICBjYXJlZnVsbHkgd2VpZ2hlZCBiZWZvcmUgY2hvb3NpbmcgYSBkaWZm ZXJlbnQgY291cnNlLg0KDQpSZWdhcmRzLA0KUmVzaGFkLiAgICANCiAgICBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIG5ldGNvbmYgbWFpbGluZyBs aXN0DQogICAgbmV0Y29uZkBpZXRmLm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbmV0Y29uZg0KICAgIA0KDQo= From nobody Mon Apr 15 05:21:30 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19865120170; Mon, 15 Apr 2019 05:21:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Stephen Farrell via Datatracker To: Cc: draft-ietf-dots-signal-channel.all@ietf.org, ietf@ietf.org, dots@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Stephen Farrell Message-ID: <155533088202.10777.9128855796755282458@ietfa.amsl.com> Date: Mon, 15 Apr 2019 05:21:22 -0700 Archived-At: Subject: [secdir] Secdir telechat review of draft-ietf-dots-signal-channel-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 12:21:22 -0000 Reviewer: Stephen Farrell Review result: Has Issues I took a look at the changes between -30 and -31 and at the mail following my earlier review of -30. To explain the "has issues" status for this review: Generally, I think this is probably ok, but I (still) have the concerns listed below that the ADs might wanna think about. The authors already responded on each of these points, and made some corresponding changes, so I guess they reckon these are non-issues. (Which is of course fine - even if I don't quite agree, I'm often wrong:-) - p13: The cuid still seems to me to be too static (there's a SHOULD saying to tie it to the client certificate public key or an equivalent). I still think recommending a way to generate an identifier that isn't tied to a key pair would be better, esp if this could be used in a CPE. (Creating a new long-lived identifier for a CPE seems like a bad plan if it's not really needed.) For example, one could use both the SPKI and a timestamp as input for a recommended way to generate a cuid and that should be as unique, but without mapping 1:1 to possibly long-lived key pairs. (-31 does say some more about how to change cuid, but still has the same SHOULD/RECOMMENDED way to generate cuid values.) - I wondered if a bad actor in control of an authorised DOTS client colluding with the controller of a DDoS attack could use this protocol to probe the network to see how their attack is going and change the attack to be more effective. In mail, the authors stated that this isn't possible, and added text saying that to -31. That may be true, but I'm not sure (given the complexity of the protocol). A nit: - p91: The mention of TCP-AO seems to require suspension of disbelief (given the lack of deployment of TCP-AO). If we don't think it'll be used, it'd be better to not pretend it might get used. From nobody Mon Apr 15 06:16:57 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73F921203A2; Mon, 15 Apr 2019 06:16:40 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 7Pfha5x7ptcU; Mon, 15 Apr 2019 06:16:38 -0700 (PDT) Received: from orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1F7D120390; Mon, 15 Apr 2019 06:16:37 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar26.francetelecom.fr (ESMTP service) with ESMTP id 44jTY03n6pzFpbq; Mon, 15 Apr 2019 15:16:36 +0200 (CEST) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.76]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 44jTY02F93zCqlN; Mon, 15 Apr 2019 15:16:36 +0200 (CEST) Received: from OPEXCAUBMA2.corporate.adroot.infra.ftgroup ([fe80::e878:bd0:c89e:5b42]) by OPEXCAUBM7E.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0439.000; Mon, 15 Apr 2019 15:16:36 +0200 From: To: Stephen Farrell , "secdir@ietf.org" CC: "draft-ietf-dots-signal-channel.all@ietf.org" , "ietf@ietf.org" , "dots@ietf.org" Thread-Topic: Secdir telechat review of draft-ietf-dots-signal-channel-31 Thread-Index: AQHU84W+t2C1NhRJPEGTSxi4oDGffqY9MHkg Date: Mon, 15 Apr 2019 13:16:35 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93302EA60294@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> References: <155533088202.10777.9128855796755282458@ietfa.amsl.com> In-Reply-To: <155533088202.10777.9128855796755282458@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.245] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-dots-signal-channel-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 13:16:44 -0000 SGkgU3RlcGhlbiwgYWxsLCANCg0KUGxlYXNlIHNlZSBpbmxpbmUgZm9yIHRoZSBmaXJzdCBpdGVt LiANCg0KQ2hlZXJzLA0KTWVkDQoNCj4gLS0tLS1NZXNzYWdlIGQnb3JpZ2luZS0tLS0tDQo+IERl wqA6IFN0ZXBoZW4gRmFycmVsbCB2aWEgRGF0YXRyYWNrZXIgW21haWx0bzpub3JlcGx5QGlldGYu b3JnXQ0KPiBFbnZvecOpwqA6IGx1bmRpIDE1IGF2cmlsIDIwMTkgMTQ6MjENCj4gw4DCoDogc2Vj ZGlyQGlldGYub3JnDQo+IENjwqA6IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2hhbm5lbC5hbGxA aWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmc7DQo+IGRvdHNAaWV0Zi5vcmcNCj4gT2JqZXTCoDogU2Vj ZGlyIHRlbGVjaGF0IHJldmlldyBvZiBkcmFmdC1pZXRmLWRvdHMtc2lnbmFsLWNoYW5uZWwtMzEN Cj4gDQo+IFJldmlld2VyOiBTdGVwaGVuIEZhcnJlbGwNCj4gUmV2aWV3IHJlc3VsdDogSGFzIElz c3Vlcw0KPiANCj4gSSB0b29rIGEgbG9vayBhdCB0aGUgY2hhbmdlcyBiZXR3ZWVuIC0zMCBhbmQg LTMxIGFuZCBhdCB0aGUgbWFpbA0KPiBmb2xsb3dpbmcgbXkgZWFybGllciByZXZpZXcgb2YgLTMw Lg0KPiANCj4gVG8gZXhwbGFpbiB0aGUgImhhcyBpc3N1ZXMiIHN0YXR1cyBmb3IgdGhpcyByZXZp ZXc6IEdlbmVyYWxseSwgSQ0KPiB0aGluayB0aGlzIGlzIHByb2JhYmx5IG9rLCBidXQgSSAoc3Rp bGwpIGhhdmUgdGhlIGNvbmNlcm5zIGxpc3RlZA0KPiBiZWxvdyB0aGF0IHRoZSBBRHMgbWlnaHQg d2FubmEgdGhpbmsgYWJvdXQuIFRoZSBhdXRob3JzIGFscmVhZHkNCj4gcmVzcG9uZGVkIG9uIGVh Y2ggb2YgdGhlc2UgcG9pbnRzLCBhbmQgbWFkZSBzb21lIGNvcnJlc3BvbmRpbmcNCj4gY2hhbmdl cywgc28gSSBndWVzcyB0aGV5IHJlY2tvbiB0aGVzZSBhcmUgbm9uLWlzc3Vlcy4gKFdoaWNoIGlz IG9mDQo+IGNvdXJzZSBmaW5lIC0gZXZlbiBpZiBJIGRvbid0IHF1aXRlIGFncmVlLCBJJ20gb2Z0 ZW4gd3Jvbmc6LSkNCj4gDQo+IC0gcDEzOiBUaGUgY3VpZCBzdGlsbCBzZWVtcyB0byBtZSB0byBi ZSB0b28gc3RhdGljICh0aGVyZSdzIGENCg0KW01lZF0gVGhpcyBpcyBhIGZlYXR1cmUgbm90IGEg YnVnLiBUaGlzIHNjaGVtZSBpcyBwYXJ0aWN1bGFybHkgdXNlZnVsIHRvIHJlY292ZXIgc3RhdGUs IGZvciBleGFtcGxlLCB1cG9uIHJlYm9vdCBvciBjcmFzaCBvZiBhIERPVFMgY2xpZW50LiANCg0K PiBTSE9VTEQgc2F5aW5nIHRvIHRpZSBpdCB0byB0aGUgY2xpZW50IGNlcnRpZmljYXRlIHB1Ymxp YyBrZXkNCj4gb3IgYW4gZXF1aXZhbGVudCkuICBJIHN0aWxsIHRoaW5rIHJlY29tbWVuZGluZyBh IHdheSB0byBnZW5lcmF0ZQ0KPiBhbiBpZGVudGlmaWVyIHRoYXQgaXNuJ3QgdGllZCB0byBhIGtl eSBwYWlyIHdvdWxkIGJlIGJldHRlciwgZXNwDQo+IGlmIHRoaXMgY291bGQgYmUgdXNlZCBpbiBh IENQRS4gKENyZWF0aW5nIGEgbmV3IGxvbmctbGl2ZWQNCj4gaWRlbnRpZmllciBmb3IgYSBDUEUg c2VlbXMgbGlrZSBhIGJhZCBwbGFuIGlmIGl0J3Mgbm90IHJlYWxseQ0KPiBuZWVkZWQuKSBGb3Ig ZXhhbXBsZSwgb25lIGNvdWxkIHVzZSBib3RoIHRoZSBTUEtJIGFuZCBhIHRpbWVzdGFtcA0KPiBh cyBpbnB1dCBmb3IgYSByZWNvbW1lbmRlZCB3YXkgdG8gZ2VuZXJhdGUgYSBjdWlkIGFuZCB0aGF0 IHNob3VsZA0KPiBiZSBhcyB1bmlxdWUsIGJ1dCB3aXRob3V0IG1hcHBpbmcgMToxIHRvIHBvc3Np Ymx5IGxvbmctbGl2ZWQga2V5DQo+IHBhaXJzLiAoLTMxIGRvZXMgc2F5IHNvbWUgbW9yZSBhYm91 dCBob3cgdG8gY2hhbmdlIGN1aWQsIGJ1dCBzdGlsbA0KPiBoYXMgdGhlIHNhbWUgU0hPVUxEL1JF Q09NTUVOREVEIHdheSB0byBnZW5lcmF0ZSBjdWlkIHZhbHVlcy4pDQo+IA0KPiAtIEkgd29uZGVy ZWQgaWYgYSBiYWQgYWN0b3IgaW4gY29udHJvbCBvZiBhbiBhdXRob3Jpc2VkIERPVFMNCj4gY2xp ZW50IGNvbGx1ZGluZyB3aXRoIHRoZSBjb250cm9sbGVyIG9mIGEgRERvUyBhdHRhY2sgY291bGQg dXNlDQo+IHRoaXMgcHJvdG9jb2wgdG8gcHJvYmUgdGhlIG5ldHdvcmsgdG8gc2VlIGhvdyB0aGVp ciBhdHRhY2sgaXMNCj4gZ29pbmcgYW5kIGNoYW5nZSB0aGUgYXR0YWNrIHRvIGJlIG1vcmUgZWZm ZWN0aXZlLiAgSW4gbWFpbCwgdGhlDQo+IGF1dGhvcnMgc3RhdGVkIHRoYXQgdGhpcyBpc24ndCBw b3NzaWJsZSwgYW5kIGFkZGVkIHRleHQgc2F5aW5nDQo+IHRoYXQgdG8gLTMxLiBUaGF0IG1heSBi ZSB0cnVlLCBidXQgSSdtIG5vdCBzdXJlIChnaXZlbiB0aGUNCj4gY29tcGxleGl0eSBvZiB0aGUg cHJvdG9jb2wpLg0KPiANCj4gQSBuaXQ6DQo+IA0KPiAtIHA5MTogVGhlIG1lbnRpb24gb2YgVENQ LUFPIHNlZW1zIHRvIHJlcXVpcmUgc3VzcGVuc2lvbiBvZg0KPiBkaXNiZWxpZWYgKGdpdmVuIHRo ZSBsYWNrIG9mIGRlcGxveW1lbnQgb2YgVENQLUFPKS4gIElmIHdlIGRvbid0DQo+IHRoaW5rIGl0 J2xsIGJlIHVzZWQsIGl0J2QgYmUgYmV0dGVyIHRvIG5vdCBwcmV0ZW5kIGl0IG1pZ2h0IGdldA0K PiB1c2VkLg0KPiANCj4gDQoNCg== From nobody Mon Apr 15 06:26:02 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D752F120143; Mon, 15 Apr 2019 06:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 zR8MOHKdIhjl; Mon, 15 Apr 2019 06:25:52 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B3BE120127; Mon, 15 Apr 2019 06:25:52 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 26C57BE7B; Mon, 15 Apr 2019 14:25:50 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ES1nAfyENBoH; Mon, 15 Apr 2019 14:25:50 +0100 (IST) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CAD3EBE74; Mon, 15 Apr 2019 14:25:49 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1555334749; bh=SNEXtyg13k8PsHEoJEy5GVDV+csMIkLYWClBvdLOcVY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=mRaPSd81Ge0AUgUYoqrd9Jj1/QAQbaSAQDKfe3sC0+TFM93XH4U19EuyD6nWpHLU1 lCHEv091RCVaLgeDuA+xLofUISrvhfiE4KcJ5Xa/TcK0g1L6CojxXr2PqVBZB+LGtv 51Dd5IwoyeB3aaSCs5gKQiw89w+U7Eq+E0YeaKdU= To: mohamed.boucadair@orange.com, "secdir@ietf.org" Cc: "draft-ietf-dots-signal-channel.all@ietf.org" , "ietf@ietf.org" , "dots@ietf.org" References: <155533088202.10777.9128855796755282458@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA60294@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <6c4b8d89-c114-103e-9a6e-5a8ae6a59350@cs.tcd.ie> Date: Mon, 15 Apr 2019 14:25:43 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA60294@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="uW7qq4xEiivNmN862CpuVxqTE6lrc9Cwp" Archived-At: Subject: Re: [secdir] Secdir telechat review of draft-ietf-dots-signal-channel-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 13:25:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uW7qq4xEiivNmN862CpuVxqTE6lrc9Cwp Content-Type: multipart/mixed; boundary="ot53OlrZcHHDWFud1am6uJO3DkxLeiCh7"; protected-headers="v1" From: Stephen Farrell To: mohamed.boucadair@orange.com, "secdir@ietf.org" Cc: "draft-ietf-dots-signal-channel.all@ietf.org" , "ietf@ietf.org" , "dots@ietf.org" Message-ID: <6c4b8d89-c114-103e-9a6e-5a8ae6a59350@cs.tcd.ie> Subject: Re: Secdir telechat review of draft-ietf-dots-signal-channel-31 References: <155533088202.10777.9128855796755282458@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA60294@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B93302EA60294@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> --ot53OlrZcHHDWFud1am6uJO3DkxLeiCh7 Content-Type: multipart/mixed; boundary="------------4AFFDD1103EAED0DC1E49C86" Content-Language: en-GB This is a multi-part message in MIME format. --------------4AFFDD1103EAED0DC1E49C86 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 15/04/2019 14:16, mohamed.boucadair@orange.com wrote: >> - p13: The cuid still seems to me to be too static (there's a > > [Med] This is a feature not a bug. This scheme is particularly useful > to recover state, for example, upon reboot or crash of a DOTS client. >=20 Well, fair enough, but FWIW I'm not convinced that a client that can keep state (the private key and other dots stuff) couldn't also as easily keep a cuid value. And ISTM there should also be equally good ways to recommend for generating a cuid that don't have that 1:1 mapping to a key pair. All that said, it's not me needs to be convinced, but the IESG, so probably best to wait and see if they think this is worth changing or not before doing so. S. --------------4AFFDD1103EAED0DC1E49C86 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------4AFFDD1103EAED0DC1E49C86-- --ot53OlrZcHHDWFud1am6uJO3DkxLeiCh7-- --uW7qq4xEiivNmN862CpuVxqTE6lrc9Cwp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAly0hlcACgkQWrL68XsX K+rfng/8CMcx1YDTxTA4iUfjcQf27Fx5XrHLYBeHijTR4jqxQbF5OH+QyBfDjnp8 up8RpxJ2onRt/Cd948r0YWlPhPe+hyeqtGnbj7hEg09slkE+5oZi+w3VXmiZIDHq TkAze7pU9IMG+FFaIJeXhzVObjrkO8qiIZZ95h12xXjSVjptBSLSBQkOinfQodp3 2HU33eIDNHqu+KEHAUFW6sRfpFWJEStS+bx8bS/XMb9uJtyfMm/IZ/DxraG3Y1LV x/cmP4N6ECYtUvw+9XLRKlkpuMmiYubXxUVXrZY/glJYS0DkFv4ct4eTODg+8uYC w9Y7tYvWHlAAaGQxXFJXPkunohVeu3sA42PAt3N/NLbVXUVyhHtA3F2sH+dygjFx yEVDvoiaevgIRdGfwOySZPIyJ+nXWdES3DNP50oMCpfy3WsqgUM2UbHLQqitl5do GzaP19KUaw2WwpLaTzCWbgMEtxceY+qN5IeFz77gw+v4J7lOsalA0X0I06Z5NYvR dZtALsuo90PULWjUtkPs5cFVfPXZs4+tQnassl8H7k8EhuiDjRBlHm8irI0V4ER0 /HKXPufAta9ulVI/HWejamH9sSUxK7lr1QHfrd5ujZIXpiDlcNVd0MXvTjn4/b9o FI0wzp9+p7nxPGMfaIw5clgD18wp95pH4mofCM8FHzB+6RuhdMc= =GUBi -----END PGP SIGNATURE----- --uW7qq4xEiivNmN862CpuVxqTE6lrc9Cwp-- From nobody Mon Apr 15 07:38:59 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90924120375; Mon, 15 Apr 2019 07:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3h_xRK2hLS8; Mon, 15 Apr 2019 07:38:39 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D63B712001E; Mon, 15 Apr 2019 07:38:38 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1555338792; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=johPuquT+BHHWtTLa0B8r5qRfkWVSaa0iAzD2j i6Blc=; b=WFftUXDkqJOTXOFfDzYuuYwUqwxIaBFMSMKWLwrs bWWzZAccJK7b4H/yMgGMp7T3aZXiWqipOAACZ+A/k70yYCDuRP cuRdUlrK1YYH9tZri19BBaw9yQvM3hLmTTTcE1KuWSlNFFndHr gaVQq6z98NR6kxlybbO1h3wfHeS7zCc= Received: from DNVEXAPP1N04.corpzone.internalzone.com (DNVEXAPP1N04.corpzone.internalzone.com [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5716_b4ae_acce3622_b5e9_4499_8eaf_46bc524fa5d2; Mon, 15 Apr 2019 08:33:11 -0600 Received: from DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 15 Apr 2019 08:38:22 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N05.corpzone.internalzone.com (10.44.48.89) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Mon, 15 Apr 2019 08:38:22 -0600 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 15 Apr 2019 08:38:02 -0600 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2567.namprd16.prod.outlook.com (20.177.226.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.19; Mon, 15 Apr 2019 14:38:01 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::4873:7200:9e57:9e62]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::4873:7200:9e57:9e62%5]) with mapi id 15.20.1792.018; Mon, 15 Apr 2019 14:38:01 +0000 From: "Konda, Tirumaleswar Reddy" To: Stephen Farrell , "mohamed.boucadair@orange.com" , "secdir@ietf.org" CC: "draft-ietf-dots-signal-channel.all@ietf.org" , "ietf@ietf.org" , "dots@ietf.org" Thread-Topic: [Dots] Secdir telechat review of draft-ietf-dots-signal-channel-31 Thread-Index: AQHU842Y1PTA/7yjVUSrEcvW+vhbdqY9NliAgAAS56A= Date: Mon, 15 Apr 2019 14:38:01 +0000 Message-ID: References: <155533088202.10777.9128855796755282458@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA60294@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <6c4b8d89-c114-103e-9a6e-5a8ae6a59350@cs.tcd.ie> In-Reply-To: <6c4b8d89-c114-103e-9a6e-5a8ae6a59350@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [1.39.154.147] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5a7b5934-5944-4245-072d-08d6c1aff63c x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BYAPR16MB2567; x-ms-traffictypediagnostic: BYAPR16MB2567: x-microsoft-antispam-prvs: x-forefront-prvs: 000800954F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(376002)(136003)(39860400002)(346002)(366004)(396003)(199004)(189003)(13464003)(32952001)(11346002)(54906003)(110136005)(446003)(316002)(3846002)(53936002)(9686003)(55016002)(6246003)(229853002)(6116002)(33656002)(476003)(25786009)(6436002)(99286004)(68736007)(81156014)(81166006)(296002)(8936002)(8676002)(2906002)(52536014)(5660300002)(7736002)(74316002)(256004)(6506007)(14444005)(76176011)(106356001)(71200400001)(72206003)(105586002)(26005)(97736004)(4326008)(486006)(71190400001)(2501003)(80792005)(102836004)(478600001)(53546011)(2201001)(14454004)(7696005)(186003)(86362001)(66066001)(305945005)(85282002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2567; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: vwIfLEoumsYAINzJfBxm7gYLlIQQwC7zHrFg26EZs3UQK58vGTr/Vzy9z5UWjg5zNPwQAH1t5XPma97iKGcANsfQvtNi8vG6S6QCOwA4LuGc+frBWs8oExZ4NxdOT5gIOcoiJEF2eRgGZao70sF7vAU9MAGXPz6F70XPsfQglW8Si6rGVZLULHoHXcClC3vqtvqusMvcUbXFo7p8SbMAgkfYF05UpdHUbaoGcsFaTUPMvxCXUFYeMGn4WySNgnOcKHOqXQduKZJoZr/SH1Ehcc1WGUXLxr+5qx908GZLDFHt+7VNqmyFwIktX/KOELUXbd5EKB94T26aoXaJmE6ZxBG5c3pL2mG5f/FGBPLBvfj8FlOkeMkUGMFP1T7MOGVMIXCs+5Kt0V1aRtv7lfTsluPCkcVI8boZrs9WQoKRo6E= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5a7b5934-5944-4245-072d-08d6c1aff63c X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2019 14:38:01.2579 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR16MB2567 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6525> : inlines <7052> : streams <1818738> : uri <2832435> Archived-At: Subject: Re: [secdir] [Dots] Secdir telechat review of draft-ietf-dots-signal-channel-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 14:38:42 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBEb3RzIDxkb3RzLWJvdW5jZXNA aWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBTdGVwaGVuIEZhcnJlbGwNCj4gU2VudDogTW9uZGF5LCBB cHJpbCAxNSwgMjAxOSA2OjU2IFBNDQo+IFRvOiBtb2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29t OyBzZWNkaXJAaWV0Zi5vcmcNCj4gQ2M6IGRyYWZ0LWlldGYtZG90cy1zaWduYWwtY2hhbm5lbC5h bGxAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmc7IGRvdHNAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6 IFtEb3RzXSBTZWNkaXIgdGVsZWNoYXQgcmV2aWV3IG9mIGRyYWZ0LWlldGYtZG90cy1zaWduYWwt Y2hhbm5lbC0zMQ0KPiANCj4gDQo+IEhpeWEsDQo+IA0KPiBPbiAxNS8wNC8yMDE5IDE0OjE2LCBt b2hhbWVkLmJvdWNhZGFpckBvcmFuZ2UuY29tIHdyb3RlOg0KPiA+PiAtIHAxMzogVGhlIGN1aWQg c3RpbGwgc2VlbXMgdG8gbWUgdG8gYmUgdG9vIHN0YXRpYyAodGhlcmUncyBhDQo+ID4NCj4gPiBb TWVkXSBUaGlzIGlzIGEgZmVhdHVyZSBub3QgYSBidWcuIFRoaXMgc2NoZW1lIGlzIHBhcnRpY3Vs YXJseSB1c2VmdWwNCj4gPiB0byByZWNvdmVyIHN0YXRlLCBmb3IgZXhhbXBsZSwgdXBvbiByZWJv b3Qgb3IgY3Jhc2ggb2YgYSBET1RTIGNsaWVudC4NCj4gPg0KPiANCj4gV2VsbCwgZmFpciBlbm91 Z2gsIGJ1dCBGV0lXIEknbSBub3QgY29udmluY2VkIHRoYXQgYSBjbGllbnQgdGhhdCBjYW4ga2Vl cCBzdGF0ZQ0KPiAodGhlIHByaXZhdGUga2V5IGFuZCBvdGhlciBkb3RzIHN0dWZmKSBjb3VsZG4n dCBhbHNvIGFzIGVhc2lseSBrZWVwIGEgY3VpZCB2YWx1ZS4NCj4gQW5kIElTVE0gdGhlcmUgc2hv dWxkIGFsc28gYmUgZXF1YWxseSBnb29kIHdheXMgdG8gcmVjb21tZW5kIGZvciBnZW5lcmF0aW5n DQo+IGEgY3VpZCB0aGF0IGRvbid0IGhhdmUgdGhhdA0KPiAxOjEgbWFwcGluZyB0byBhIGtleSBw YWlyLiBBbGwgdGhhdCBzYWlkLCBpdCdzIG5vdCBtZSBuZWVkcyB0byBiZSBjb252aW5jZWQsIGJ1 dA0KPiB0aGUgSUVTRywgc28gcHJvYmFibHkgYmVzdCB0byB3YWl0IGFuZCBzZWUgaWYgdGhleSB0 aGluayB0aGlzIGlzIHdvcnRoIGNoYW5naW5nIG9yDQo+IG5vdCBiZWZvcmUgZG9pbmcgc28uDQoN ClRoZSBhZHZhbnRhZ2Ugb2YgdGhlIDE6MSBtYXBwaW5nIGlzIHRoZSBET1RTIHNlcnZlcnMgY2Fu IHZhbGlkYXRlIHRoZSBET1RTIGNsaWVudCBpcyBub3QgdXNpbmcgdGhlICdjdWlkJyBvZiBhbm90 aGVyIGNsaWVudC4gDQoNCi1UaXJ1DQoNCj4gDQo+IFMuDQo+IA0KDQo= From nobody Mon Apr 15 07:58:16 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B21B1203DB; Mon, 15 Apr 2019 07:57:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 uiOEacBaFz-0; Mon, 15 Apr 2019 07:57:55 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 840701203FD; Mon, 15 Apr 2019 07:57:54 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 037D7BE7B; Mon, 15 Apr 2019 15:57:51 +0100 (IST) Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8S-q_0U9qED; Mon, 15 Apr 2019 15:57:50 +0100 (IST) Received: from [134.226.36.93] (unknown [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B7A6EBE4D; Mon, 15 Apr 2019 15:57:50 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1555340270; bh=nqgIdWFnmb68BYGJBgLfGphBI/0LCMwTvDRv8sFdf5Q=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=BzU0w7yTTum38GTmEPDmGVIDfwR98PwR7GzWnyAR5eyopth7mYcpymY5md6XtWkpa CnwjvMERNANvk9nw0QPBdnQSxGadwmd3tEU/oI8yr3CMHdCnYVXxxKLePmGdfE3xng eW6WtNbMPUADjfsO15QVtdIwIJcpwlTEJ5vg8/L4= To: "Konda, Tirumaleswar Reddy" , "mohamed.boucadair@orange.com" , "secdir@ietf.org" Cc: "draft-ietf-dots-signal-channel.all@ietf.org" , "ietf@ietf.org" , "dots@ietf.org" References: <155533088202.10777.9128855796755282458@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA60294@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <6c4b8d89-c114-103e-9a6e-5a8ae6a59350@cs.tcd.ie> From: Stephen Farrell Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url= Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Mon, 15 Apr 2019 15:57:49 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="ThhBnFdYYoob1a6MzfcaqKyFuHZLQkcp3" Archived-At: Subject: Re: [secdir] [Dots] Secdir telechat review of draft-ietf-dots-signal-channel-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 14:58:02 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ThhBnFdYYoob1a6MzfcaqKyFuHZLQkcp3 Content-Type: multipart/mixed; boundary="qn4RbnWkMlcJSrR6buKomXVBe8ZuY2VqK"; protected-headers="v1" From: Stephen Farrell To: "Konda, Tirumaleswar Reddy" , "mohamed.boucadair@orange.com" , "secdir@ietf.org" Cc: "draft-ietf-dots-signal-channel.all@ietf.org" , "ietf@ietf.org" , "dots@ietf.org" Message-ID: Subject: Re: [Dots] Secdir telechat review of draft-ietf-dots-signal-channel-31 References: <155533088202.10777.9128855796755282458@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA60294@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <6c4b8d89-c114-103e-9a6e-5a8ae6a59350@cs.tcd.ie> In-Reply-To: --qn4RbnWkMlcJSrR6buKomXVBe8ZuY2VqK Content-Type: multipart/mixed; boundary="------------F67211906672D983026AA7A1" Content-Language: en-GB This is a multi-part message in MIME format. --------------F67211906672D983026AA7A1 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 15/04/2019 15:38, Konda, Tirumaleswar Reddy wrote: >> -----Original Message----- From: Dots On >> Behalf Of Stephen Farrell Sent: Monday, April 15, 2019 6:56 PM To: >> mohamed.boucadair@orange.com; secdir@ietf.org Cc: >> draft-ietf-dots-signal-channel.all@ietf.org; ietf@ietf.org; >> dots@ietf.org Subject: Re: [Dots] Secdir telechat review of >> draft-ietf-dots-signal-channel-31 >>=20 >>=20 >> Hiya, >>=20 >> On 15/04/2019 14:16, mohamed.boucadair@orange.com wrote: >>>> - p13: The cuid still seems to me to be too static (there's a >>>=20 >>> [Med] This is a feature not a bug. This scheme is particularly >>> useful to recover state, for example, upon reboot or crash of a >>> DOTS client. >>>=20 >>=20 >> Well, fair enough, but FWIW I'm not convinced that a client that >> can keep state (the private key and other dots stuff) couldn't also >> as easily keep a cuid value. And ISTM there should also be equally >> good ways to recommend for generating a cuid that don't have that=20 >> 1:1 mapping to a key pair. All that said, it's not me needs to be >> convinced, but the IESG, so probably best to wait and see if they >> think this is worth changing or not before doing so. >=20 > The advantage of the 1:1 mapping is the DOTS servers can validate the > DOTS client is not using the 'cuid' of another client. So that'd be "an" advantage, if it is one;-) But given the servers are supposed to authenticate the client via TLS client-auth (or else the server doesn't see the public key), I don't see the need. Nor do I recall that the server is supposed to compare the key to the cuid - if that check is to be done, then that'd need to be in the spec or a client that re-keys would have to make a new cuid. (Apologies if that's in the spec and I've forgotten it.) Cheers, S. >=20 > -Tiru >=20 >>=20 >> S. >>=20 >=20 --------------F67211906672D983026AA7A1 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------F67211906672D983026AA7A1-- --qn4RbnWkMlcJSrR6buKomXVBe8ZuY2VqK-- --ThhBnFdYYoob1a6MzfcaqKyFuHZLQkcp3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAly0m+0ACgkQWrL68XsX K+qQhA//WJJY1LEZBGCUdIXIMssHr064Bm4t3CNS4JzN8M1AL4WCrjlocnQbgPTk uWAHJX2ME/d7jeqkfoaqFtunh8ccu+8oZRz5u2S0M89hiui7d1x/FjioYdvG+pRK SVRWxEGuY04OIzlg8jle4mnVVWjYP8YJKceJ77IHNPxFvUziOvUu4CB4SfLQxkiR myhV+A6EYKtQj2/3tawzcFBlBiMW8wNp8JYJcD5oGjGxnUPrgWxj/PEZlC4GAx4e F5dFfifom2UT7jrMksZ26PzNcPThqzTbqNF4CfEa1l7X8LxmCmJGI9bcBwyBkEJ/ Vd2JM55HH/hQqjvZuk/S0uXAMzVZ/HR0BI5z6gE2OjZDzEJkE8cacE6cn1jljbkh qkuHngkBCYwDt9vk4NpkyuD0imz8VjqQi2yfo1woo2NViWJ0Zi1mXHU6YZsi9LFy dN3PxJ8cE/8pwTl2O3z8OajwXVVz/ykLl3fK+HBeM3UGu7C+nQxLbhhx8rRo8m7y ugs6eZFcXKEGx2IGgeSod2kUIbng5T9MDgyti99bcaYwB+4UHXz8Rxg1R5sTBub7 XlzdK6n8HMkIVngWwggMxhhycx7upH6Wnf7v/RcMvDtdy+TahUyZaRfRu95j369I W1cWxI2L/8Bi2aQ3U3awP+pKQaMYb+FOv0NXk1ZUTGCxxcO9otU= =3jaa -----END PGP SIGNATURE----- --ThhBnFdYYoob1a6MzfcaqKyFuHZLQkcp3-- From nobody Mon Apr 15 08:19:32 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9E311203D1; Mon, 15 Apr 2019 08:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mcafee.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mBqc45JSgSWS; Mon, 15 Apr 2019 08:19:27 -0700 (PDT) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F3381203A1; Mon, 15 Apr 2019 08:19:26 -0700 (PDT) X-NAI-Header: Modified by McAfee Email Gateway (5500) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1555341238; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-microsoft-antispam-prvs:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=AJoee3Us06mbUXKdxUHjxlc9B8jNKw+Ur618pJ BSW3M=; b=ivEaxfazxO7lPV9GVsCCzSemfrSE8mSWNGZ2FCLr +qcojkzXNctHF4S2/e+//lcfZdsYfWfE/4p5J8SUt1fa8PNfDY IiZvwqflbBNL81Td3VX6Gbar4oqjzQXJLWcmfSXXXzg5XbeJyY f2EO1HEFLDDq/hXR3Vr3lIOyDb/8j58= Received: from DNVEXAPP1N04.corpzone.internalzone.com (DNVEXAPP1N04.corpzone.internalzone.com [10.44.48.88]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 5712_623f_b161d121_ff93_4de0_aa03_09b8a8bceb9f; Mon, 15 Apr 2019 09:13:58 -0600 Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXAPP1N04.corpzone.internalzone.com (10.44.48.88) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 15 Apr 2019 09:18:51 -0600 Received: from DNVO365EDGE2.corpzone.internalzone.com (10.44.176.74) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Mon, 15 Apr 2019 09:18:52 -0600 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.44.176.243) by edge.mcafee.com (10.44.176.74) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 15 Apr 2019 09:18:41 -0600 Received: from BYAPR16MB2790.namprd16.prod.outlook.com (20.178.233.91) by BYAPR16MB2581.namprd16.prod.outlook.com (20.177.226.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1792.14; Mon, 15 Apr 2019 15:18:40 +0000 Received: from BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::4873:7200:9e57:9e62]) by BYAPR16MB2790.namprd16.prod.outlook.com ([fe80::4873:7200:9e57:9e62%5]) with mapi id 15.20.1792.018; Mon, 15 Apr 2019 15:18:40 +0000 From: "Konda, Tirumaleswar Reddy" To: Stephen Farrell , "mohamed.boucadair@orange.com" , "secdir@ietf.org" CC: "draft-ietf-dots-signal-channel.all@ietf.org" , "ietf@ietf.org" , "dots@ietf.org" Thread-Topic: [Dots] Secdir telechat review of draft-ietf-dots-signal-channel-31 Thread-Index: AQHU842Y1PTA/7yjVUSrEcvW+vhbdqY9NliAgAAS56CAAAbVgIAAAslg Date: Mon, 15 Apr 2019 15:18:40 +0000 Message-ID: References: <155533088202.10777.9128855796755282458@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B93302EA60294@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <6c4b8d89-c114-103e-9a6e-5a8ae6a59350@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.2.0.6 dlp-reaction: no-action authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [1.39.154.147] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 234e268e-919d-48b3-5c5e-08d6c1b5a43b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600140)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:BYAPR16MB2581; x-ms-traffictypediagnostic: BYAPR16MB2581: x-microsoft-antispam-prvs: x-forefront-prvs: 000800954F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(396003)(136003)(39860400002)(346002)(32952001)(199004)(189003)(13464003)(33656002)(2201001)(305945005)(68736007)(316002)(296002)(5660300002)(4326008)(229853002)(102836004)(478600001)(86362001)(2906002)(6506007)(71200400001)(66066001)(53546011)(74316002)(71190400001)(110136005)(54906003)(72206003)(14454004)(7696005)(2501003)(7736002)(486006)(446003)(52536014)(55016002)(11346002)(93886005)(9686003)(53936002)(8936002)(76176011)(105586002)(106356001)(186003)(80792005)(6246003)(25786009)(81156014)(99286004)(3846002)(97736004)(6116002)(476003)(81166006)(6436002)(8676002)(26005)(256004)(14444005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR16MB2581; H:BYAPR16MB2790.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: f0NBsnknE9dZcMmLBKI5H4mHzCTxyLf5PRw34FWLB4OYZ5b7jYbnrxBuMZo0KxCNLGqyzgrPv5dL+Zql0oVCXVcDkEf4Y4dClILooN/ZwdK8B+rNpHuOslXhh4IVjOwf/1msIs+iYiN/Eudm41AOCksWqegqik/iHoEXHUKo/FrQSTwLFa/ITJULmBqXxhPBbNnILKjWqg2ErkakGnQ064kq/i782diXoPhwWXvW0ceUuSptDh1z6UxpjFO4wRCSQ1C0U6WZ4lBbThDqDZBkCaGaPlfH5Fu9vxiwmsjwFvYKEuI/G9nTf6ydF0qW1PxNS5fP7rEHXqUVX+sQxzzfpQcJx2IjhmAIufqg5Z0FtDcSSj6aV4UiSm5xkgalurL6qPALWsJ8dtNvzAQ8XYd1djOTAojOswEzTMGjgkE55rc= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 234e268e-919d-48b3-5c5e-08d6c1b5a43b X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Apr 2019 15:18:40.6387 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR16MB2581 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0.1 X-NAI-Spam-Version: 2.3.0.9418 : core <6525> : inlines <7052> : streams <1818740> : uri <2832450> Archived-At: Subject: Re: [secdir] [Dots] Secdir telechat review of draft-ietf-dots-signal-channel-31 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 15:19:30 -0000 PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBTdGVwaGVuIEZhcnJlbGwgPHN0 ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+DQo+IFNlbnQ6IE1vbmRheSwgQXByaWwgMTUsIDIwMTkg ODoyOCBQTQ0KPiBUbzogS29uZGEsIFRpcnVtYWxlc3dhciBSZWRkeSA8VGlydW1hbGVzd2FyUmVk ZHlfS29uZGFATWNBZmVlLmNvbT47DQo+IG1vaGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNl Y2RpckBpZXRmLm9yZw0KPiBDYzogZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsLmFsbEBp ZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsgZG90c0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0Rv dHNdIFNlY2RpciB0ZWxlY2hhdCByZXZpZXcgb2YgZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFu bmVsLTMxDQo+IA0KPiANCj4gDQo+IE9uIDE1LzA0LzIwMTkgMTU6MzgsIEtvbmRhLCBUaXJ1bWFs ZXN3YXIgUmVkZHkgd3JvdGU6DQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIEZyb206 IERvdHMgPGRvdHMtYm91bmNlc0BpZXRmLm9yZz4gT24NCj4gPj4gQmVoYWxmIE9mIFN0ZXBoZW4g RmFycmVsbCBTZW50OiBNb25kYXksIEFwcmlsIDE1LCAyMDE5IDY6NTYgUE0gVG86DQo+ID4+IG1v aGFtZWQuYm91Y2FkYWlyQG9yYW5nZS5jb207IHNlY2RpckBpZXRmLm9yZyBDYzoNCj4gPj4gZHJh ZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsLmFsbEBpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZzsN Cj4gPj4gZG90c0BpZXRmLm9yZyBTdWJqZWN0OiBSZTogW0RvdHNdIFNlY2RpciB0ZWxlY2hhdCBy ZXZpZXcgb2YNCj4gPj4gZHJhZnQtaWV0Zi1kb3RzLXNpZ25hbC1jaGFubmVsLTMxDQo+ID4+DQo+ ID4+DQo+ID4+IEhpeWEsDQo+ID4+DQo+ID4+IE9uIDE1LzA0LzIwMTkgMTQ6MTYsIG1vaGFtZWQu Ym91Y2FkYWlyQG9yYW5nZS5jb20gd3JvdGU6DQo+ID4+Pj4gLSBwMTM6IFRoZSBjdWlkIHN0aWxs IHNlZW1zIHRvIG1lIHRvIGJlIHRvbyBzdGF0aWMgKHRoZXJlJ3MgYQ0KPiA+Pj4NCj4gPj4+IFtN ZWRdIFRoaXMgaXMgYSBmZWF0dXJlIG5vdCBhIGJ1Zy4gVGhpcyBzY2hlbWUgaXMgcGFydGljdWxh cmx5DQo+ID4+PiB1c2VmdWwgdG8gcmVjb3ZlciBzdGF0ZSwgZm9yIGV4YW1wbGUsIHVwb24gcmVi b290IG9yIGNyYXNoIG9mIGEgRE9UUw0KPiA+Pj4gY2xpZW50Lg0KPiA+Pj4NCj4gPj4NCj4gPj4g V2VsbCwgZmFpciBlbm91Z2gsIGJ1dCBGV0lXIEknbSBub3QgY29udmluY2VkIHRoYXQgYSBjbGll bnQgdGhhdCBjYW4NCj4gPj4ga2VlcCBzdGF0ZSAodGhlIHByaXZhdGUga2V5IGFuZCBvdGhlciBk b3RzIHN0dWZmKSBjb3VsZG4ndCBhbHNvIGFzDQo+ID4+IGVhc2lseSBrZWVwIGEgY3VpZCB2YWx1 ZS4gQW5kIElTVE0gdGhlcmUgc2hvdWxkIGFsc28gYmUgZXF1YWxseSBnb29kDQo+ID4+IHdheXMg dG8gcmVjb21tZW5kIGZvciBnZW5lcmF0aW5nIGEgY3VpZCB0aGF0IGRvbid0IGhhdmUgdGhhdA0K PiA+PiAxOjEgbWFwcGluZyB0byBhIGtleSBwYWlyLiBBbGwgdGhhdCBzYWlkLCBpdCdzIG5vdCBt ZSBuZWVkcyB0byBiZQ0KPiA+PiBjb252aW5jZWQsIGJ1dCB0aGUgSUVTRywgc28gcHJvYmFibHkg YmVzdCB0byB3YWl0IGFuZCBzZWUgaWYgdGhleQ0KPiA+PiB0aGluayB0aGlzIGlzIHdvcnRoIGNo YW5naW5nIG9yIG5vdCBiZWZvcmUgZG9pbmcgc28uDQo+ID4NCj4gPiBUaGUgYWR2YW50YWdlIG9m IHRoZSAxOjEgbWFwcGluZyBpcyB0aGUgRE9UUyBzZXJ2ZXJzIGNhbiB2YWxpZGF0ZSB0aGUNCj4g PiBET1RTIGNsaWVudCBpcyBub3QgdXNpbmcgdGhlICdjdWlkJyBvZiBhbm90aGVyIGNsaWVudC4N Cj4gDQo+IFNvIHRoYXQnZCBiZSAiYW4iIGFkdmFudGFnZSwgaWYgaXQgaXMgb25lOy0pDQo+IA0K PiBCdXQgZ2l2ZW4gdGhlIHNlcnZlcnMgYXJlIHN1cHBvc2VkIHRvIGF1dGhlbnRpY2F0ZSB0aGUg Y2xpZW50IHZpYSBUTFMgY2xpZW50LWF1dGgNCj4gKG9yIGVsc2UgdGhlIHNlcnZlciBkb2Vzbid0 IHNlZSB0aGUgcHVibGljIGtleSksIEkgZG9uJ3Qgc2VlIHRoZSBuZWVkLg0KDQpUaGUgYWJvdmUg dmFsaWRhdGlvbiBoZWxwcyBkZWZlbmQgYWdhaW5zdCBhIGNvbXByb21pc2VkIERPVFMgY2xpZW50 IHVzaW5nIHRoZSAnY3VpZCcgb2YgYW5vdGhlciBET1RTIGNsaWVudC4gDQoNCi1UaXJ1DQoNCj4g Tm9yIGRvIEkgcmVjYWxsIHRoYXQgdGhlIHNlcnZlciBpcyBzdXBwb3NlZCB0byBjb21wYXJlIHRo ZSBrZXkgdG8gdGhlIGN1aWQgLSBpZg0KPiB0aGF0IGNoZWNrIGlzIHRvIGJlIGRvbmUsIHRoZW4g dGhhdCdkIG5lZWQgdG8gYmUgaW4gdGhlIHNwZWMgb3IgYSBjbGllbnQgdGhhdCByZS0NCj4ga2V5 cyB3b3VsZCBoYXZlIHRvIG1ha2UgYSBuZXcgY3VpZC4gKEFwb2xvZ2llcyBpZiB0aGF0J3MgaW4g dGhlIHNwZWMgYW5kIEkndmUNCj4gZm9yZ290dGVuIGl0LikNCj4gDQo+IENoZWVycywNCj4gUy4N Cj4gDQo+IA0KPiA+DQo+ID4gLVRpcnUNCj4gPg0KPiA+Pg0KPiA+PiBTLg0KPiA+Pg0KPiA+DQo= From nobody Mon Apr 15 13:17:41 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AAB641203DD; Mon, 15 Apr 2019 13:17:32 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Kyle Rose via Datatracker To: Cc: draft-ietf-pce-hierarchy-extensions.all@ietf.org, pce@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Kyle Rose Message-ID: <155535945259.10773.14556389726269462856@ietfa.amsl.com> Date: Mon, 15 Apr 2019 13:17:32 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-pce-hierarchy-extensions-10 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2019 20:17:33 -0000 Reviewer: Kyle Rose Review result: Has Nits I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. For background, Wikipedia has the following to say about PCE: q( Routing can be subject to a set of constraints, such as Quality of Service (QoS), policy, or price. Constraint-based path computation is a strategic component of traffic engineering in MPLS, GMPLS and Segment Routing networks. It is used to determine the path through the network that traffic should follow, and provides the route for each Label Switched Path (LSP) that is set up. Path computation has previously been performed either in a management system or at the head end of each LSP. But path computation in large, multi-domain networks may be very complex and may require more computational power and network information than is typically available at a network element, yet may still need to be more dynamic than can be provided by a management system. Thus, a PCE is an entity capable of computing paths for a single or set of services. A PCE might be a network node, network management station, or dedicated computational platform that is resource-aware and has the ability to consider multiple constraints for sophisticated path computation. PCE applications compute label switched paths for MPLS and GMPLS traffic engineering. ) The document is nearly ready. In addition to numerous grammatical errors throughout, I see one minor but substantive issue. In section 6.1.2, the last sentence reads: q( This means that a parent PCE must be configured with the identities and security credentials of all of its child PCEs, or there must be some form of shared secret that allows an unknown child PCE to be authorized by the parent PCE. ) A secret shared by more than two parties cannot be used to establish identity. If there are two, then assuming exfiltration and reflection attacks are not part of your threat model, each party knows it is talking to the single other legitimate possessor of the shared secret. If there are more than two, this is no longer the case. That said, in this case it's not clear you need to identify individual child PCEs, and so (notwithstanding potential impersonation attacks in a shared secret scheme) you may wish to shorten this sentence to: q( This means that a parent PCE MUST* be able to cryptographically authenticate requests from child PCEs. ) The choice of authentication scheme can then be left to implementors, or recommendations to a different document. You might add a sentence to the security considerations section suggesting that multi-party shared key authentication schemes are not recommended for inter-domain relationships because of the potential for impersonation and repudiation and for the operational difficulties should revocation be required. *Whether this "MUST" should be BCP 14 language or not is unclear to me. From nobody Thu Apr 18 04:26:41 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EA7B2120145 for ; Thu, 18 Apr 2019 04:26:39 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <155558679988.12217.11622523250481254461.idtracker@ietfa.amsl.com> Date: Thu, 18 Apr 2019 04:26:39 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2019 11:26:40 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-05-02 Reviewer LC end Draft Shaun Cooley 2019-03-13 draft-ietf-dots-data-channel-28 Alexey Melnikov 2019-04-11 draft-ietf-sidrops-lta-use-cases-05 Matthew Miller 2019-04-08 draft-ietf-core-multipart-ct-03 Last calls: Reviewer LC end Draft Derek Atkins 2019-03-03 draft-ietf-netmod-module-tags-07 Nancy Cam-Winget 2019-02-15 draft-ietf-rtcweb-security-11 Daniel Franke 2019-03-18 draft-ietf-sidrops-https-tal-07 Daniel Gillmor 2018-03-19 draft-gutmann-scep-13 Phillip Hallam-Baker 2019-03-18 draft-ietf-sidrops-bgpsec-algs-rfc8208-bis-05 Charlie Kaufman 2019-03-14 draft-ietf-trans-rfc6962-bis-31 Catherine Meadows 2019-04-12 draft-ietf-mmusic-rfc4566bis-34 Russ Mundy 2019-04-22 draft-housley-hkdf-oids-01 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-08 Tim Polk 2019-04-17 draft-ietf-isis-segment-routing-extensions-24 Vincent Roca R2019-02-13 draft-ietf-perc-private-media-framework-09 Joseph Salowey 2019-04-23 draft-ietf-opsawg-tacacs-13 Rich Salz 2019-04-29 draft-ietf-calext-eventpub-extensions-12 David Waltermire 2019-02-15 draft-ietf-rtcweb-ip-handling-11 Klaas Wierenga 2019-02-26 draft-ietf-mpls-sr-over-ip-04 Taylor Yu 2019-02-15 draft-ietf-rtcweb-security-arch-18 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-11 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Kathleen Moriarty 2019-04-08 draft-ietf-bmwg-ngfw-performance-00 Next in the reviewer rotation: Stefan Santesson Yaron Sheffer Rifaat Shekh-Yusef Melinda Shore Valery Smyslov Robert Sparks Takeshi Takahashi Tina Tsou Sean Turner From nobody Fri Apr 19 08:50:50 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98AB212013F; Fri, 19 Apr 2019 03:41:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1555670493; bh=M2R8kSXiWV8VUGMzdwmcdUFJ70GbkpLZKzMd2PwHU6Q=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=vIdQ1wSyn9u2pPnv2/UL0NC3muIdjXEiYvYhs4AuY79WzNnYuqRek9Av7weyj1TuT AF1iCPv7QFgOJxO3XbQIeKUJDnsI3wxAz4tRRRJVR33DI+jPVW/LJRewKE2gcQSA6T KWv0PZZATFV8s2zagTJCyAfDNk3qqZpb7VHAjilU= X-Mailbox-Line: From new-work-bounces@ietf.org Fri Apr 19 03:41:33 2019 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D774F12012D; Fri, 19 Apr 2019 03:41:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1555670492; bh=M2R8kSXiWV8VUGMzdwmcdUFJ70GbkpLZKzMd2PwHU6Q=; h=To:From:Date:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=B/hdPKm4J3oLH0AjEQ7wRqKOmnGibIvaTWzQgfl9BemnAaMxeUHWswaQ0VUQK7Ama EeljOZsMOkQ07pxGR7pvvvxpN7p9k0BzoTapXjOUS4/vThRriLjNxrBo7aAkGvKMRH Om4j1n5oVe0E0xarw77COwtjIVxxZw9RBxR5cDKk= 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 8A8D312012D for ; Fri, 19 Apr 2019 03:41:31 -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, HK_RANDOM_ENVFROM=0.001, 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 Hi0ybIeXkO6K for ; Fri, 19 Apr 2019 03:41:29 -0700 (PDT) Received: from raoul.w3.org (raoul.w3.org [128.30.52.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82A24120123 for ; Fri, 19 Apr 2019 03:41:29 -0700 (PDT) Received: from [42.100.5.155] (helo=[192.168.1.3]) by raoul.w3.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1hHQxT-0000sB-Iv for new-work@ietf.org; Fri, 19 Apr 2019 10:41:27 +0000 To: new-work@ietf.org From: xueyuan Message-ID: <7b05ba49-6115-66cb-9ff2-1899874ed4e6@w3.org> Date: Fri, 19 Apr 2019 18:41:24 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 Content-Language: en-US Archived-At: X-BeenThere: new-work@ietf.org X-Mailman-Version: 2.1.29 Precedence: list Content-Transfer-Encoding: base64 Content-Type: text/plain; charset="utf-8"; Format="flowed" Errors-To: new-work-bounces@ietf.org Sender: "new-work" Archived-At: X-Mailman-Approved-At: Fri, 19 Apr 2019 08:50:49 -0700 Subject: [secdir] [new-work] Proposed W3C Charter: Media and Entertainment Interest Group (until 2019-05-21) 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, 19 Apr 2019 10:41:36 -0000 CkhlbGxvLAoKVG9kYXkgVzNDIEFkdmlzb3J5IENvbW1pdHRlZSBSZXByZXNlbnRhdGl2ZXMgcmVj ZWl2ZWQgYSBQcm9wb3NhbAp0byByZXZpZXcgYSBkcmFmdCBjaGFydGVyIGZvciB0aGUgTWVkaWEg YW5kIEVudGVydGFpbm1lbnQgSW50ZXJlc3QgR3JvdXA6CiDCoCBodHRwczovL3d3dy53My5vcmcv MjAxOS8wNC9tZS1pZy1jaGFydGVyLWRyYWZ0Lmh0bWwKCkFzIHBhcnQgb2YgZW5zdXJpbmcgdGhh dCB0aGUgY29tbXVuaXR5IGlzIGF3YXJlIG9mIHByb3Bvc2VkIHdvcmsKYXQgVzNDLCB0aGlzIGRy YWZ0IGNoYXJ0ZXIgaXMgcHVibGljIGR1cmluZyB0aGUgQWR2aXNvcnkKQ29tbWl0dGVlIHJldmll dyBwZXJpb2QuCgpXM0MgaW52aXRlcyBwdWJsaWMgY29tbWVudHMgdGhyb3VnaCAyMDE5LTA1LTIx IG9uIHRoZQpwcm9wb3NlZCBjaGFydGVyLiBQbGVhc2Ugc2VuZCBjb21tZW50cyB0bwpwdWJsaWMt bmV3LXdvcmtAdzMub3JnLCB3aGljaCBoYXMgYSBwdWJsaWMgYXJjaGl2ZToKIMKgIGh0dHA6Ly9s aXN0cy53My5vcmcvQXJjaGl2ZXMvUHVibGljL3B1YmxpYy1uZXctd29yay8KCk90aGVyIHRoYW4g Y29tbWVudHMgc2VudCBpbiBmb3JtYWwgcmVzcG9uc2VzIGJ5IFczQyBBZHZpc29yeQpDb21taXR0 ZWUgUmVwcmVzZW50YXRpdmVzLCBXM0MgY2Fubm90IGd1YXJhbnRlZSBhIHJlc3BvbnNlIHRvCmNv bW1lbnRzLiBJZiB5b3Ugd29yayBmb3IgYSBXM0MgTWVtYmVyIFsxXSwgcGxlYXNlIGNvb3JkaW5h dGUKeW91ciBjb21tZW50cyB3aXRoIHlvdXIgQWR2aXNvcnkgQ29tbWl0dGVlIFJlcHJlc2VudGF0 aXZlLiBGb3IKZXhhbXBsZSwgeW91IG1heSB3aXNoIHRvIG1ha2UgcHVibGljIGNvbW1lbnRzIHZp YSB0aGlzIGxpc3QgYW5kCmhhdmUgeW91ciBBZHZpc29yeSBDb21taXR0ZWUgUmVwcmVzZW50YXRp dmUgcmVmZXIgdG8gaXQgZnJvbSBoaXMKb3IgaGVyIGZvcm1hbCByZXZpZXcgY29tbWVudHMuCgpJ ZiB5b3Ugc2hvdWxkIGhhdmUgYW55IHF1ZXN0aW9ucyBvciBuZWVkIGZ1cnRoZXIgaW5mb3JtYXRp b24sIHBsZWFzZQpjb250YWN0IEthenV5dWtpIEFzaGltdXJhLCBXM0MgU3RhZmYgQ29udGFjdCBm b3IgdGhlIE1lZGlhIGFuZApFbnRlcnRhaW5tZW50IEludGVyZXN0IEdyb3VwLCBhdCA8YXNoaW11 cmFAdzMub3JnPi4KClRoYW5rIHlvdSwKClh1ZXl1YW4gSmlhLCBXM0MgTWFya2V0aW5nIGFuZCBD b21tdW5pY2F0aW9ucwoKWzFdIGh0dHA6Ly93d3cudzMub3JnL0NvbnNvcnRpdW0vTWVtYmVyL0xp c3QKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCm5ldy13 b3JrIG1haWxpbmcgbGlzdApuZXctd29ya0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldy13b3JrCg== From nobody Fri Apr 19 20:56:42 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F2F0120497; Fri, 19 Apr 2019 20:56:25 -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, 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 J-wGQayb79jt; Fri, 19 Apr 2019 20:56:23 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 839361203DD; Fri, 19 Apr 2019 20:56:20 -0700 (PDT) Received: from kduck.mit.edu (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.14.7/8.12.4) with ESMTP id x3K3uDlZ029905 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 19 Apr 2019 23:56:15 -0400 Date: Fri, 19 Apr 2019 22:56:13 -0500 From: Benjamin Kaduk To: "Reshad Rahman (rrahman)" Cc: Aanchal Malhotra , "secdir@ietf.org" , "ietf@ietf.org" , "draft-ietf-netconf-restconf-notif.all@ietf.org" , "netconf@ietf.org" Message-ID: <20190420035612.GR51586@kduck.mit.edu> References: <155501965074.14152.2835369201856309773@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [secdir] [netconf] Secdir last call review of draft-ietf-netconf-restconf-notif-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Apr 2019 03:56:26 -0000 On Fri, Apr 12, 2019 at 09:29:35PM +0000, Reshad Rahman (rrahman) wrote: > Hi Aanchal, > > Thanks for the review. Please see inline. > > On 2019-04-11, 5:54 PM, "netconf on behalf of Aanchal Malhotra via Datatracker" wrote: > > Reviewer: Aanchal Malhotra > Review result: Ready > > The document is very clear and concise. I just have one minor clarification question. > Section 3.4 Page 9 that says the following: > "In addition to any required ........SHOULD only be allowed......". > > Is there a reason for using SHOULD instead of MUST? > > There may be reasons why an implementation decides not to enforce this restriction. Going by RFC2119 definitions, this is why we chose SHOULD instead of MUST. If you have some reasons in mind, it is often helpful to list them as examples of when the recommended behavior would not be followed. Thank you Aanchal for the review! -Ben From nobody Sun Apr 21 20:49:26 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 78C601201EC; Sun, 21 Apr 2019 20:49:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Joseph Salowey via Datatracker To: Cc: opsawg@ietf.org, iesg@ietf.org, draft-ietf-opsawg-tacacs.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Joseph Salowey Message-ID: <155590495142.9736.10585624358883108199@ietfa.amsl.com> Date: Sun, 21 Apr 2019 20:49:11 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-opsawg-tacacs-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 03:49:12 -0000 Reviewer: Joseph Salowey Review result: Serious Issues As the draft mentions the MD5 based stream cipher used by TACACS+ is completely insecure. I think there is too much discussion in the security considerations that may lead one to think that in some cases it provides sufficient protection. Section 10.1 - There have been plenty of analysis of the problems with the TACACS+ message protection. This section should just simply say the encryption/obfuscation mechanism provides no integrity protection, no privacy protection and no replay protection. An attacker with access to the data stream should be assumed to be able to read and modify all TACACS+ packets. There are just too many flaws to to enumerate in this document and the rest of the information in this section is wrong or incomplete at best. Section 10.2 - Why not MUST NOT for TAC_PLUS_AUTHEN_STATUS_FOLLOW? Is this really still used? Section 10.2, 10.3, 10.4 - You can probably replace most of these sections with "TACACS+ MUST be used with an addition security mechanism to protection of the communication such as IPSEC or a secure network such as described in 10.5. " Section 10.5.1 and 10.5.2 - Why should I care about secrets if they are just providing obfuscation? Are you relying on these secrets for something other than obfuscation? Section 10.5.3 - Use "less weak" instead of stronger when referring to CHAP, MS-CHAP, and MSCHAPv2. Its pretty debatable how much better they are than plaintext passwords. From nobody Sun Apr 21 20:57:12 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8084F1201DB; Sun, 21 Apr 2019 20:56:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 i9XkAKevJiiv; Sun, 21 Apr 2019 20:56:55 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 3FF141200B4; Sun, 21 Apr 2019 20:56:55 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1hIQ4b-0002sn-I2; Mon, 22 Apr 2019 03:56:53 +0000 Date: Sun, 21 Apr 2019 20:56:52 -0700 Message-ID: From: Randy Bush To: Joseph Salowey via Datatracker Cc: , opsawg@ietf.org, iesg@ietf.org, draft-ietf-opsawg-tacacs.all@ietf.org In-Reply-To: <155590495142.9736.10585624358883108199@ietfa.amsl.com> References: <155590495142.9736.10585624358883108199@ietfa.amsl.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/25.3 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [secdir] [OPSAWG] Secdir last call review of draft-ietf-opsawg-tacacs-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 03:56:57 -0000 > "TACACS+ MUST be used with an addition security mechanism to > protection of the communication such as IPSEC or a secure network such > as described in 10.5. " not operationaly viable randy From nobody Mon Apr 22 11:14:37 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D3901120128; Mon, 22 Apr 2019 11:14:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rich Salz via Datatracker To: Cc: draft-ietf-calext-eventpub-extensions.all@ietf.org, ietf@ietf.org, calsify@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Rich Salz Message-ID: <155595686177.21216.4076761255030943970@ietfa.amsl.com> Date: Mon, 22 Apr 2019 11:14:21 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-calext-eventpub-extensions-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 18:14:22 -0000 Reviewer: Rich Salz Review result: Has Nits This is the SECDIR last-call review, intended to be input to the Security AD's. Ready with nits. The Security Considerations and Privacy Considerations are short, but they seem to reasonably refer to already-published documents. Following are nits I noticed. Abstract "a number of new iCalendar properties and components" -> "a new iCalendar component and a number of properties" Maybe stike "iCalendar" Sec 1, STRUCTURED-DATA. In my opinion the confirmation code would be the most useful new info :) Sec 1, SOURCE Is it redefined or extended? Sec 2, para 2. "In a break with this 'tradition' ..." --> "Breaking with this practice, ..." Sec 3, "When a calendar client receives a calendar component" Should the second calendar be CALENDAR? Should the first be "iCalendar"? Sec 3.1.1, uppercase "vcard"? Sec 3.1.2.1 "non of which" --> "none of which" Sec 4 Perhaps add a sentence saying where this syntax is defined. Is this the complete iCalendar spec or is it just changing a few things? Sec 5.1, etc "as laid down in" Is kind of informal wording. Sec 6, the notation has "value=URI" but the example has "URL" (Sec 7.3, etc., uses URI in both parts) Sec 10, "applications using" Is "acting on" better? From nobody Mon Apr 22 11:24:30 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB0EE120132; Mon, 22 Apr 2019 11:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral (1024-bit key) reason="invalid (public key: does not support hash algorithm 'sha256')" header.d=ota.si 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 b2KuenUapQTv; Mon, 22 Apr 2019 11:24:26 -0700 (PDT) Received: from mta2.toshio.eu (mta2.toshio.eu [IPv6:2001:470:99f7::b423]) by ietfa.amsl.com (Postfix) with ESMTP id 2F17F120092; Mon, 22 Apr 2019 11:24:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mta2.toshio.eu (Postfix) with ESMTP id A94DC17829; Mon, 22 Apr 2019 18:24:01 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ota.si; h= message-id:references:content-transfer-encoding:date:date :in-reply-to:from:from:subject:subject:mime-version:content-type :content-type:received; s=toshio; t=1555957439; x=1557771840; bh=m/Mzp39GuiHtPxN4cRJdy1V3oRT1Ihpllg7fkp5DD/I=; b=rpu+j6kgzMDK LdgRrKFAROpsf/AeevznKriWwFqQFe1hk70Irwr+gaXPErNDhVFSuiIvqu4yVPok +4Vl8X6D//3j2qF7kJHVR+Aecg5KhgVXo112vZZSOyJIJCRpxUuKzfr1Ngzp/yRl ieZpfJztuSY4U4US8tdyNg3mRw42EkE= X-Virus-Scanned: amavisd-new at toshio.org Received: from mta2.toshio.eu ([89.143.197.195]) by localhost (srv-fe-3.dom.ota.si [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id pd99ivsENu02; Mon, 22 Apr 2019 18:23:59 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Andrej Ota In-Reply-To: <155590495142.9736.10585624358883108199@ietfa.amsl.com> Date: Mon, 22 Apr 2019 19:24:17 +0100 Cc: secdir@ietf.org, opsawg@ietf.org, iesg@ietf.org, draft-ietf-opsawg-tacacs.all@ietf.org Content-Transfer-Encoding: quoted-printable References: <155590495142.9736.10585624358883108199@ietfa.amsl.com> To: Joseph Salowey Message-Id: <20190422182358.B69FB17821@mta2.toshio.eu> Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-opsawg-tacacs-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 18:24:29 -0000 Hi Joseph, Thank you for taking time to review the document. Answers are in-line. > On 22 Apr 2019, at 04:49, Joseph Salowey via Datatracker = wrote: >=20 > Reviewer: Joseph Salowey > Review result: Serious Issues >=20 > As the draft mentions the MD5 based stream cipher used by TACACS+ is=20= > completely insecure. I think there is too much discussion in the = security > considerations that may lead one to think that in some cases it = provides > sufficient protection. >=20 > Section 10.1 - > There have been plenty of analysis of the problems with the TACACS+ = message > protection. This section should just simply say the = encryption/obfuscation > mechanism provides no integrity protection, no privacy protection and = no replay > protection. An attacker with access to the data stream should be = assumed to be > able to read and modify all TACACS+ packets. There are just too many = flaws to > to enumerate in this document and the rest of the information in this = section > is wrong or incomplete at best. Agreed to replace the section with a simple statement that obfuscation = provides no integrity or replay protection. I'm assuming this refers = just to 10.1 and not the whole of 10. I think we should still press the point that everyone MUST use = obfuscation as even though the privacy is almost non-existent, it's = still slightly better than plain-text and ROT13. >=20 > Section 10.2 - > Why not MUST NOT for TAC_PLUS_AUTHEN_STATUS_FOLLOW? Is this really = still used? I think Douglas is best positioned to answer this question. >=20 > Section 10.2, 10.3, 10.4 - > You can probably replace most of these sections with > "TACACS+ MUST be used with an addition security mechanism to = protection of the > communication such as IPSEC or a secure network such as described in = 10.5. " Agreed. >=20 > Section 10.5.1 and 10.5.2 - > Why should I care about secrets if they are just providing = obfuscation? Are > you relying on these secrets for something other than obfuscation? Shared secrets also serve to "authenticate" a NAS to a server and vice = versa. Which may or may not matter when we state that secure transport MUST be = used. I would like to err on the safe side because mistakes happen and = sometimes unauthorized devices do connect to otherwise secured networks = - intentionally or unintentionally (lab devices and similar come to my = mind). >=20 > Section 10.5.3 - > Use "less weak" instead of stronger when referring to CHAP, MS-CHAP, = and > MSCHAPv2. Its pretty debatable how much better they are than = plaintext > passwords. >=20 I think "less weak" is acceptable. When you wrote that their value is debatable, did that refer to safety = of the authentication session (as in it can be successfully attacked), = to ability of a network attacker (active or passive) to deduce the = user's password, or both? My understanding is that they're still viable for the purpose of = limiting the loss of user's password from MiTM attacks. If I'm wrong = about this, let me know so we can be explicit about it in the document = as well. Andrej.= From nobody Mon Apr 22 14:19:39 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08E6C1200B9 for ; Mon, 22 Apr 2019 14:19:30 -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, HTML_MESSAGE=0.001, 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=salowey-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 Fsy9vpzdi9hZ for ; Mon, 22 Apr 2019 14:19:27 -0700 (PDT) Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) (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 D6CF71200EB for ; Mon, 22 Apr 2019 14:19:26 -0700 (PDT) Received: by mail-qk1-x72f.google.com with SMTP id c190so3540844qke.9 for ; Mon, 22 Apr 2019 14:19:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b2Si+H/Gt+CxCpKYL13cPo2PHRAIZrpyYkE6+jYorgI=; b=T8SNj8aLIVMTBlxB6pGQOnO2doywJUlUaYfqetWK4aASvWtvbS9R1sf8ySfEgTH951 9pSQq0M5n7needndRQ1pgTqd/tvDnlaDXZpxIn0/3Q0AnRa3ypXBqzD+Oi6LfT2ZE8Wo eV3wHyl4AGVDGKJvaRT+rwVJwEwbfC/fIn/RtsDI1SQH77EPaS94iScCaVmYnMJK0vaV rUsCTpvZ/UBxfblzPU++4x29RZRMjz+GCQ/6Fu/RlRWz2qBSTiDlNnBsk5gWxV3UNp+1 +SA/E1Nh9lsZiKi+I8Hxq/VsW4h0tDJtNNTg3yxL985h7w510xzmOYvKso1SNoOCGPsf IDzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b2Si+H/Gt+CxCpKYL13cPo2PHRAIZrpyYkE6+jYorgI=; b=ty2qTr8g+9yc52S6Q09zGLX0a9jt+kEzh66TqRBUvz8DXUlXJZYwIUavbIZeKBZuCD sFyDUNZfNxXfVBTYRok6uaS6avoI+RmySixZfPgqIM1F46qDZYX37gNlpOfDf3OeKHNK TTFLEqZn/mcyIcxZdG9ylYEKR6kxhC97gXgbmnPug1C7JU26ZacgSMhTt4cRWHhGnb8w nFgy5IlMB0l3yEUc18cjWGCSLXL3pAqoUdnYf+KOjC0x09GxxbedNLidCXwSdIFyx3T6 TMCkPViFJ2P+tmyHUVHLutxZzNgdSD4i5OD54kX9yjKfLhEaJqfTa+Lie+kRxttJTavi /3HA== X-Gm-Message-State: APjAAAVN8YR0g429Gkuo3BlO4DOuxlDRbfpcpBr7DwMSaIgv/Tr6VRUV jevthbRcMzvN6xLgs1zXZXazrx9q6X2GORLvowUZlA== X-Google-Smtp-Source: APXvYqz0jXRhX/YuLLpsbZoUtdKNu/iQBOWW3BBQS3F70ec/YRi/zYIyPtPkfAQnqiVN4AIxMoJ0HFuc9ZiTFsm4go0= X-Received: by 2002:a05:620a:16b5:: with SMTP id s21mr15685289qkj.321.1555967965806; Mon, 22 Apr 2019 14:19:25 -0700 (PDT) MIME-Version: 1.0 References: <155590495142.9736.10585624358883108199@ietfa.amsl.com> <20190422182358.B69FB17821@mta2.toshio.eu> In-Reply-To: <20190422182358.B69FB17821@mta2.toshio.eu> From: Joseph Salowey Date: Mon, 22 Apr 2019 14:19:14 -0700 Message-ID: To: Andrej Ota Cc: secdir , opsawg@ietf.org, The IESG , draft-ietf-opsawg-tacacs.all@ietf.org Content-Type: multipart/alternative; boundary="000000000000e255c205872505e5" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-opsawg-tacacs-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2019 21:19:30 -0000 --000000000000e255c205872505e5 Content-Type: text/plain; charset="UTF-8" On Mon, Apr 22, 2019 at 11:24 AM Andrej Ota wrote: > Hi Joseph, > > Thank you for taking time to review the document. Answers are in-line. > > > On 22 Apr 2019, at 04:49, Joseph Salowey via Datatracker < > noreply@ietf.org> wrote: > > > > Reviewer: Joseph Salowey > > Review result: Serious Issues > > > > As the draft mentions the MD5 based stream cipher used by TACACS+ is > > completely insecure. I think there is too much discussion in the > security > > considerations that may lead one to think that in some cases it provides > > sufficient protection. > > > > Section 10.1 - > > There have been plenty of analysis of the problems with the TACACS+ > message > > protection. This section should just simply say the > encryption/obfuscation > > mechanism provides no integrity protection, no privacy protection and no > replay > > protection. An attacker with access to the data stream should be > assumed to be > > able to read and modify all TACACS+ packets. There are just too many > flaws to > > to enumerate in this document and the rest of the information in this > section > > is wrong or incomplete at best. > > Agreed to replace the section with a simple statement that obfuscation > provides no integrity or replay protection. I'm assuming this refers just > to 10.1 and not the whole of 10. > > [Joe] I think you could probably replace a large portion of 10.2, 3 and 4 as well. > I think we should still press the point that everyone MUST use obfuscation > as even though the privacy is almost non-existent, it's still slightly > better than plain-text and ROT13. > > [Joe] The current mechanism is roughly equivalent to ROT13 when compared to current encryption mechanisms. I don't think making it a must helps confidentiality, perhaps it helps with authentication below. > > > > Section 10.2 - > > Why not MUST NOT for TAC_PLUS_AUTHEN_STATUS_FOLLOW? Is this really > still used? > > I think Douglas is best positioned to answer this question. > > > > > Section 10.2, 10.3, 10.4 - > > You can probably replace most of these sections with > > "TACACS+ MUST be used with an addition security mechanism to protection > of the > > communication such as IPSEC or a secure network such as described in > 10.5. " > > Agreed. > > > > > Section 10.5.1 and 10.5.2 - > > Why should I care about secrets if they are just providing obfuscation? > Are > > you relying on these secrets for something other than obfuscation? > > Shared secrets also serve to "authenticate" a NAS to a server and vice > versa. > > Which may or may not matter when we state that secure transport MUST be > used. I would like to err on the safe side because mistakes happen and > sometimes unauthorized devices do connect to otherwise secured networks - > intentionally or unintentionally (lab devices and similar come to my mind). > > [Joe] I don't think this section talks about authentication as a goal at all. If this is a goal it should be stated. There will still be some limitations here in that an attacker who can observe the communication will be able to forge and replay messages. I think it could be useful to detect misconfiguration, but there should to be some other mechanism in place to provide stronger authentication. > > > > > Section 10.5.3 - > > Use "less weak" instead of stronger when referring to CHAP, MS-CHAP, and > > MSCHAPv2. Its pretty debatable how much better they are than plaintext > > passwords. > > > > I think "less weak" is acceptable. > > When you wrote that their value is debatable, did that refer to safety of > the authentication session (as in it can be successfully attacked), to > ability of a network attacker (active or passive) to deduce the user's > password, or both? > > My understanding is that they're still viable for the purpose of limiting > the loss of user's password from MiTM attacks. If I'm wrong about this, let > me know so we can be explicit about it in the document as well. > > [Joe] If an attacker can obtain the challenge and response in these mechanisms they can typically carry out an offline dictionary attack to recover the password. They're unsafe to use without a transport that provides confidentiality. > > > Andrej. --000000000000e255c205872505e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Apr 22, 2019 at 11:24 AM Andr= ej Ota <andrej@ota.si= > wrote:
= Hi Joseph,

Thank you for taking time to review the document. Answers are in-line.

> On 22 Apr 2019, at 04:49, Joseph Salowey via Datatracker <noreply@ietf.org> wro= te:
>
> Reviewer: Joseph Salowey
> Review result: Serious Issues
>
> As the draft mentions the MD5 based stream cipher used by TACACS+ is <= br> > completely insecure.=C2=A0 I think there is too much discussion in the= security
> considerations that may lead one to think that in some cases it provid= es
> sufficient protection.
>
> Section 10.1 -
> There have been plenty of analysis of the problems with the TACACS+ me= ssage
> protection.=C2=A0 This section should just simply say the encryption/o= bfuscation
> mechanism provides no integrity protection, no privacy protection and = no replay
> protection.=C2=A0 An attacker with access to the data stream should be= assumed to be
> able to read and modify all TACACS+ packets.=C2=A0 There are just too = many flaws to
> to enumerate in this document and the rest of the information in this = section
> is wrong or incomplete at best.

Agreed to replace the section with a simple statement that obfuscation prov= ides no integrity or replay protection. I'm assuming this refers just t= o 10.1 and not the whole of 10.

[Joe] I think you could probably replace a large port= ion of 10.2, 3 and 4 as well.=C2=A0
=C2=A0
I think we should still press the point that everyone MUST use obfuscation = as even though the privacy is almost non-existent, it's still slightly = better than plain-text and ROT13.

[Joe] The current mechanism is roughly equivalent to = ROT13 when compared to current encryption mechanisms.=C2=A0 =C2=A0I don'= ;t think making it a must helps confidentiality, perhaps it helps with auth= entication below.
=C2=A0
>
> Section 10.2 -
> Why not MUST NOT for TAC_PLUS_AUTHEN_STATUS_FOLLOW?=C2=A0 Is this real= ly still used?

I think Douglas is best positioned to answer this question.

>
> Section 10.2, 10.3, 10.4 -
> You can probably replace most of these sections with
> "TACACS+ MUST be used with an addition security mechanism to prot= ection of the
> communication such as IPSEC or a secure network such as described in 1= 0.5. "

Agreed.

>
> Section 10.5.1 and 10.5.2 -
> Why should I care about secrets if they are just providing obfuscation= ?=C2=A0 =C2=A0Are
> you relying on these secrets for something other than obfuscation?

Shared secrets also serve to "authenticate" a NAS to a server and= vice versa.

Which may or may not matter when we state that secure transport MUST be use= d. I would like to err on the safe side because mistakes happen and sometim= es unauthorized devices do connect to otherwise secured networks - intentio= nally or unintentionally (lab devices and similar come to my mind).


[Joe] I don't think this section t= alks about authentication as a goal at all.=C2=A0 =C2=A0If this is a goal i= t should be stated.=C2=A0 =C2=A0There will still be some limitations here i= n that an attacker who can observe the communication will be able to forge = and replay messages.=C2=A0 =C2=A0I think it could be useful to detect misco= nfiguration,=C2=A0 but there should to be some other mechanism in place to = provide stronger authentication.=C2=A0
=C2=A0

>
> Section 10.5.3 -
> Use "less weak" instead of stronger when referring to CHAP, = MS-CHAP, and
> MSCHAPv2.=C2=A0 =C2=A0Its pretty debatable how much better they are th= an plaintext
> passwords.
>

I think "less weak" is acceptable.

When you wrote that their value is debatable, did that refer to safety of t= he authentication session (as in it can be successfully attacked), to abili= ty of a network attacker (active or passive) to deduce the user's passw= ord, or both?

My understanding is that they're still viable for the purpose of limiti= ng the loss of user's password from MiTM attacks. If I'm wrong abou= t this, let me know so we can be explicit about it in the document as well.=


[Joe] If an attacker can obtain the ch= allenge and response in these mechanisms they can typically carry out an of= fline dictionary attack to recover the password.=C2=A0 They're unsafe t= o use without a transport that provides confidentiality.=C2=A0=C2=A0
<= div>=C2=A0


Andrej.
--000000000000e255c205872505e5-- From nobody Mon Apr 22 18:25:21 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B5F120113; Mon, 22 Apr 2019 18:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-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 b5WfGD9GKsV6; Mon, 22 Apr 2019 18:25:04 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (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 3A8D31200F7; Mon, 22 Apr 2019 18:25:04 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1hIkB8-0000EB-99; Tue, 23 Apr 2019 01:24:58 +0000 Date: Mon, 22 Apr 2019 18:24:56 -0700 Message-ID: From: Randy Bush To: Joseph Salowey Cc: Andrej Ota , opsawg@ietf.org, The IESG , draft-ietf-opsawg-tacacs.all@ietf.org, secdir In-Reply-To: References: <155590495142.9736.10585624358883108199@ietfa.amsl.com> <20190422182358.B69FB17821@mta2.toshio.eu> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.2 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [secdir] [OPSAWG] Secdir last call review of draft-ietf-opsawg-tacacs-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 01:25:06 -0000 >> Agreed to replace the section with a simple statement that >> obfuscation provides no integrity or replay protection. I'm assuming >> this refers just to 10.1 and not the whole of 10. >> > [Joe] I think you could probably replace a large portion of 10.2, 3 and 4 > as well. hyperbole is not constructive creaky as it is, this is an informational draft which is documenting an extremely widely used and distributed protocol. no one is gonna change millions of devices and thousands of servers for tweaks. no one moves for a 10% improvement, especially if there is no functional improvement. we need to document it so we can put this in the can and move forward to modernizing it. then, if we have a seriously functionally improved and modernized protocol, we will start the 42 year process of rolling it out. randy From nobody Tue Apr 23 01:03:40 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38B9E1202D2; Tue, 23 Apr 2019 01:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 nEoo4L1qVEGs; Tue, 23 Apr 2019 01:03:21 -0700 (PDT) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 181C3120072; Tue, 23 Apr 2019 01:03:21 -0700 (PDT) Received: from mb.local ([IPv6:2601:647:4201:4561:4980:15b:fa1a:79bf]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPA id x3N83Kb0011035; Tue, 23 Apr 2019 08:03:20 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2601:647:4201:4561:4980:15b:fa1a:79bf] claimed to be mb.local To: Randy Bush , Joseph Salowey via Datatracker Cc: opsawg@ietf.org, iesg@ietf.org, draft-ietf-opsawg-tacacs.all@ietf.org, secdir@ietf.org References: <155590495142.9736.10585624358883108199@ietfa.amsl.com> From: joel jaeggli Openpgp: preference=signencrypt Autocrypt: addr=joelja@bogus.com; prefer-encrypt=mutual; keydata= mQGiBD832SIRBADVEfzsfIX+fuN2XUPyyEXP4Mq8dqpjmcy+XTIHzZLVKzxmP+17zJYTj9MR dMA5vuZRsRpzFoeDMOJyHVVyaQeSwEApO3FJOej+CNAXpaTLYgobL1XcsQXMTbeNT5x9ZK+R ZQtoC8Vunv6UTygY+kHUHvNijhVtJtCcAW0NE2fiWwCgjKPAldaGNbPg6SKvSTFipsPPqoUE ALKjZApjCG/3Yi4kHgzCQw65mfE9u8O7bZcrvmzzRgmwShyQjrRNgxhwl2q9+e8Uo6kuk56q 0Q4On6y873W6EtBRYLTU5MiIK3mspi5YYpIi/F2XTkcW6Dx/C/ZQQ8WddAyX6QLAXHYMus86 x7tzjGM3HVlvJpWTb4CqcDOcvZakA/9aJhMEffleJx+6xrjZTUYvAQDYUSRWNmc+ehyAuh/B KH0DKqhkLlm0SBdsnKvQHXbdjhu9m9K4E6aR/s117QK60jZo1XNrVKJ1oM3X+2DNmDBl/K33 e/tPSC8byvD77doezHvWvE5n50KIEZezVgMkYWDSPWb0nefdXLY5+rgfmrQfSm9lbCBKYWVn Z2xpIDxqb2VsamFAYm9ndXMuY29tPohjBBMRAgAjAhsDBgsJCAcDAgQVAggDBBYCAwECHgEC F4AFAk3mKPcCGQEACgkQ8AA1q7Z/VrJ6vgCfYITQSd0+WXcYjEoj8+tNys5egPcAn3OUUHVt JElVkSSARJ4XWjRYqKiauQQNBD8320MQEACTNxol/GIZW4CGUnyIlr+13Dqx8aHZfbd96UQE Ys9mZkBxwP2V7D00tOETcY5apr9tr9oHf5p4xA2l2oE8KR4xbF6+0XIpeYzRcl5d0iUaSMwm HcX3J/+XyZegJqTG7zMEK72c1tPVrra9DRNZP+rhKFLJJornDiQJFQVhtQE37WA1kmC6rlyR KHA2RMYS3IugAgJfuy5pZn/5jKCv+ZxIv7tnk7GUQWwfPdr4PokPCBxSXUYch98Rcq3dbCio 8FPmrfI6K2Z9NMa/gXGpF3ynmxDJLY31aPgbUiv9VllZoeMkotbXHW1zrsXte/1MEgFrlkiQ WDJ/dHjlCdlFASfaPvVXxdiUgH7LV3cW+BOY2z4VVwhYM6/kTDoLKWZ3opBeN9KcAHPRFCkA fxwAu8PNgi74lMjcFzu66U8vVM37YqSYpXsi+mlwZDhzCJ8qm9FDwaH2bB1LJ7m41F098B29 SRG3s/XXgTCSt0js/yUp9EXRPQpME99GvwiBNFN9p9e45ZqS85Wll6GqHh+Jyvq0ODWH6XOz uop3UUqw6I2Q8rG7e/uxKWcFnt1q48uhdTHA0TfnYC5HpHf/tAuR+ui6s16xrENgFgeeu4b/ q/jA4N1ZuJU7IbnO5f28YTlJOef/HywY3OXBsrdhEXKLIc5xRj6NC4WphyQ9MQrx8cS1bwAD BQ//WNM1WUlr6tIn8/7SIqqHRg3UmzVNu4u+r9rK9LJkYRLA4xKb/TrqDhP9oyO7Oz2S5CsF wjiPc1vzGzfRgIOArPJrejM4BzHQ03tl1qb/5YNDaB1QzfPv6dT9OkhMMuth0tcmH5sjfbiF Nc41aKU5w4FFkTv3XmrXciz4+PWbAYGB7pYbhGmsx//9C2bS56Bu1QkFeSCzN5AvWAmJfyPU yMXFKDe21DlImMdkrn/K838Lm8o0CLOKbJBX8K0pE4rGEf20FLfmHx/bLZRcWhTm8cB/vHNd 8GhwFlvHylj6+5QtR0Tc0hBcOG8SZktjE/hEiYi+dAZCrwT9i8Hjulnx/vu+Knt40+5CB2hk L1VQwdGWLYO4FGqWwwv0Y8XhWOudLYCZQWrgOsIzYezahC5b9iobFx8dgAElXNPTxI/dymrI d/6foyBrGnzzOnV/gfWfQp7N1rbrh0mQXRhwwwQIjlmbUyz8fTlaTcAo8ocXTVUb6WY7U5nr ufzKsFceR/olFnvZKKhbGVG6VvqNLS1r5lcRR1J7GVZM+Sb2ZNKgnwiUf8yxKfWg84NUPt/b etviJ73LVPdjV1PNZgcxfPRO3XL6Y9FaBP9oB4f58ujuhzOLUt+6I0KuzY8H5RBBaIrJJptl DEOnxFn1J7Q0uxQ2BzqfZdKTwJS4OCjm+OsLd8GIRgQYEQIABgUCPzfbQwAKCRDwADWrtn9W soUzAJ4zatxnKYcGdyoFojBc1Y2jqaHZsQCbB25DmeFRx14xxuxdAXb0wsKf35w= Message-ID: <12014b5b-3fe4-c046-9fba-3d9f7a6a123a@bogus.com> Date: Tue, 23 Apr 2019 01:03:19 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="gLNYCDbIuMirEp2Gq1UejLDr3KuTrC8Lj" Archived-At: Subject: Re: [secdir] [OPSAWG] Secdir last call review of draft-ietf-opsawg-tacacs-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 08:03:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gLNYCDbIuMirEp2Gq1UejLDr3KuTrC8Lj Content-Type: multipart/mixed; boundary="ORS2zou0wgQ3heqZ51SRTOkJvQTs2iRuj"; protected-headers="v1" From: joel jaeggli To: Randy Bush , Joseph Salowey via Datatracker Cc: opsawg@ietf.org, iesg@ietf.org, draft-ietf-opsawg-tacacs.all@ietf.org, secdir@ietf.org Message-ID: <12014b5b-3fe4-c046-9fba-3d9f7a6a123a@bogus.com> Subject: Re: [OPSAWG] Secdir last call review of draft-ietf-opsawg-tacacs-13 References: <155590495142.9736.10585624358883108199@ietfa.amsl.com> In-Reply-To: --ORS2zou0wgQ3heqZ51SRTOkJvQTs2iRuj Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 4/21/19 20:56, Randy Bush wrote: >> "TACACS+ MUST be used with an addition security mechanism to >> protection of the communication such as IPSEC or a secure network such= >> as described in 10.5. " >=20 > not operationaly viable I don't deploy tacacs+ plus anymore, but when I did, concerted efforts were in place to insure that the management network and it's traffic inclusive of the tacacs traffic remained isolated from our production network as well as the internet as whole. that's more or less in keeping with the sentiments of 10.5. securiting it with ah or esp ipsec isn't going to to happen except in the context of route based vpns. > randy >=20 > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >=20 --ORS2zou0wgQ3heqZ51SRTOkJvQTs2iRuj-- --gLNYCDbIuMirEp2Gq1UejLDr3KuTrC8Lj Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iF0EARECAB0WIQRcbgEEuvBAsFvTw4vwADWrtn9WsgUCXL7GxwAKCRDwADWrtn9W slzKAJ9IvQYI0eu36KPmBe2GnGYHtQI1egCfQUjaQC+b73C5sxUkqzXxrLCAyFU= =Li+r -----END PGP SIGNATURE----- --gLNYCDbIuMirEp2Gq1UejLDr3KuTrC8Lj-- From nobody Tue Apr 23 06:03:07 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6616912042D; Tue, 23 Apr 2019 06:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 mJgtyg-AL91c; Tue, 23 Apr 2019 06:02:49 -0700 (PDT) Received: from NAM05-DM3-obe.outbound.protection.outlook.com (mail-eopbgr730084.outbound.protection.outlook.com [40.107.73.84]) (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 DA870120429; Tue, 23 Apr 2019 06:02:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=fgnshjnX6hY74jeoUypE04h8e/79anQ6QcqWnitx16M=; b=jV5QSgIMiUPyuzTzZ2JRclQW5mjoCtt+3w/HXe0TZuVWLzltyFqB8rSwkvosfFeZE4SzO8617yM0XuUMFFBOl2bYA7P8dAygEoOzqnH4RpFrliRIb32jb5bPx9zf5EQ0Cll6TXgoFi7mnRfrOgZo10H637uDPe2WhMt8hgu0/qc= Received: from MN2PR15MB3310.namprd15.prod.outlook.com (20.179.21.142) by MN2PR15MB2941.namprd15.prod.outlook.com (20.178.252.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.16; Tue, 23 Apr 2019 13:02:42 +0000 Received: from MN2PR15MB3310.namprd15.prod.outlook.com ([fe80::1526:901b:cb1a:5fef]) by MN2PR15MB3310.namprd15.prod.outlook.com ([fe80::1526:901b:cb1a:5fef%3]) with mapi id 15.20.1813.017; Tue, 23 Apr 2019 13:02:42 +0000 From: Daniel Migault To: Rich Salz , "secdir@ietf.org" CC: "draft-ietf-calext-eventpub-extensions.all@ietf.org" , "ietf@ietf.org" , "calsify@ietf.org" Thread-Topic: Secdir last call review of draft-ietf-calext-eventpub-extensions-12 Thread-Index: AQHU+Tc7pc5UYH8MwUCRn5sj/IlATaZJtyFw Date: Tue, 23 Apr 2019 13:02:42 +0000 Message-ID: References: <155595686177.21216.4076761255030943970@ietfa.amsl.com> In-Reply-To: <155595686177.21216.4076761255030943970@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=daniel.migault@ericsson.com; x-originating-ip: [192.75.88.130] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 58d2e83c-d93f-4155-eac5-08d6c7ebf901 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:MN2PR15MB2941; x-ms-traffictypediagnostic: MN2PR15MB2941: x-microsoft-antispam-prvs: x-forefront-prvs: 0016DEFF96 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(346002)(39860400002)(376002)(396003)(199004)(189003)(13464003)(51914003)(4326008)(110136005)(54906003)(66946007)(66476007)(73956011)(66556008)(66446008)(71200400001)(99286004)(6436002)(229853002)(66066001)(64756008)(8936002)(71190400001)(7696005)(86362001)(2501003)(14454004)(7736002)(76176011)(44832011)(33656002)(305945005)(478600001)(2906002)(26005)(76116006)(256004)(14444005)(186003)(74316002)(3846002)(6246003)(53936002)(476003)(11346002)(5660300002)(97736004)(6116002)(316002)(81166006)(6506007)(81156014)(486006)(25786009)(8676002)(53546011)(52536014)(102836004)(68736007)(446003)(9686003)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR15MB2941; H:MN2PR15MB3310.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: iI27AL15Bj4z9TcBMjbhm6fheg1lzsrVgwEYepsvKc/ncYb9Bcbnc3LbkjY/S6lHS8RO1ZUalT9/G+EhoZm5LpENcz2dJEkkNIvxjPNGw3fSzyJy7Z2QOGjwV4DPwq3ZEW+vnWF12YQbVhrDzKlSE0FoFS6Wq7mVbsgoQJw4vnblmwc7WV36P3vawHit3+XYqWj127w8/n9SknxivwKtrvzEQ9RlSmtH/unNLQJHmqVCPvZ00v7E4RXGmnlLT9QFlCaHVWPvH4sc0BLBh5MDDXX/4LKIHO+q8vagqayzInTtOB5TpxanY+Zj0tm+36mF9AsfqahgivuQ4qmeQQdhC6Wxjs4PUwoRkP3Uj+G9I4UHlZFSKiiP75234dBRfoOjvibpzyqs8WA0YK+utDT6CuGBTd2WbdqywBDJI2lmUS4= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 58d2e83c-d93f-4155-eac5-08d6c7ebf901 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Apr 2019 13:02:42.6707 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR15MB2941 Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-calext-eventpub-extensions-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 13:02:52 -0000 VGhhbmtzIGZvciB0aGUgcmV2aWV3IFJpY2ghDQpZb3VycywgDQpEYW5pZWwNCg0KLS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJpY2ggU2FseiB2aWEgRGF0YXRyYWNrZXIgPG5vcmVw bHlAaWV0Zi5vcmc+IA0KU2VudDogTW9uZGF5LCBBcHJpbCAyMiwgMjAxOSAyOjE0IFBNDQpUbzog c2VjZGlyQGlldGYub3JnDQpDYzogZHJhZnQtaWV0Zi1jYWxleHQtZXZlbnRwdWItZXh0ZW5zaW9u cy5hbGxAaWV0Zi5vcmc7IGlldGZAaWV0Zi5vcmc7IGNhbHNpZnlAaWV0Zi5vcmcNClN1YmplY3Q6 IFNlY2RpciBsYXN0IGNhbGwgcmV2aWV3IG9mIGRyYWZ0LWlldGYtY2FsZXh0LWV2ZW50cHViLWV4 dGVuc2lvbnMtMTINCg0KUmV2aWV3ZXI6IFJpY2ggU2Fseg0KUmV2aWV3IHJlc3VsdDogSGFzIE5p dHMNCg0KVGhpcyBpcyB0aGUgU0VDRElSIGxhc3QtY2FsbCByZXZpZXcsIGludGVuZGVkIHRvIGJl IGlucHV0IHRvIHRoZSBTZWN1cml0eSBBRCdzLg0KDQpSZWFkeSB3aXRoIG5pdHMuDQoNClRoZSBT ZWN1cml0eSBDb25zaWRlcmF0aW9ucyBhbmQgUHJpdmFjeSBDb25zaWRlcmF0aW9ucyBhcmUgc2hv cnQsIGJ1dCB0aGV5IHNlZW0gdG8gcmVhc29uYWJseSByZWZlciB0byBhbHJlYWR5LXB1Ymxpc2hl ZCBkb2N1bWVudHMuDQoNCkZvbGxvd2luZyBhcmUgbml0cyBJIG5vdGljZWQuDQoNCkFic3RyYWN0 ICJhIG51bWJlciBvZiBuZXcgaUNhbGVuZGFyIHByb3BlcnRpZXMgYW5kIGNvbXBvbmVudHMiIC0+ ICJhIG5ldyBpQ2FsZW5kYXIgY29tcG9uZW50IGFuZCBhIG51bWJlciBvZiBwcm9wZXJ0aWVzIiAg TWF5YmUgc3Rpa2UgImlDYWxlbmRhciINCg0KU2VjIDEsIFNUUlVDVFVSRUQtREFUQS4gSW4gbXkg b3BpbmlvbiB0aGUgY29uZmlybWF0aW9uIGNvZGUgd291bGQgYmUgdGhlIG1vc3QgdXNlZnVsIG5l dyBpbmZvIDopDQoNClNlYyAxLCBTT1VSQ0UgSXMgaXQgcmVkZWZpbmVkIG9yIGV4dGVuZGVkPw0K DQpTZWMgMiwgcGFyYSAyLiAgIkluIGEgYnJlYWsgd2l0aCB0aGlzICd0cmFkaXRpb24nIC4uLiIg LS0+ICJCcmVha2luZyB3aXRoIHRoaXMgcHJhY3RpY2UsIC4uLiINCg0KU2VjIDMsICJXaGVuIGEg Y2FsZW5kYXIgY2xpZW50IHJlY2VpdmVzIGEgY2FsZW5kYXIgY29tcG9uZW50IiBTaG91bGQgdGhl IHNlY29uZCBjYWxlbmRhciBiZSBDQUxFTkRBUj8gU2hvdWxkIHRoZSBmaXJzdCBiZSAiaUNhbGVu ZGFyIj8NCg0KU2VjIDMuMS4xLCB1cHBlcmNhc2UgInZjYXJkIj8NCg0KU2VjIDMuMS4yLjEgIm5v biBvZiB3aGljaCIgLS0+ICJub25lIG9mIHdoaWNoIg0KDQpTZWMgNCBQZXJoYXBzIGFkZCBhIHNl bnRlbmNlIHNheWluZyB3aGVyZSB0aGlzIHN5bnRheCBpcyBkZWZpbmVkLiBJcyB0aGlzIHRoZSBj b21wbGV0ZSBpQ2FsZW5kYXIgc3BlYyBvciBpcyBpdCBqdXN0IGNoYW5naW5nIGEgZmV3IHRoaW5n cz8NCg0KU2VjIDUuMSwgZXRjICJhcyBsYWlkIGRvd24gaW4iIElzIGtpbmQgb2YgaW5mb3JtYWwg d29yZGluZy4NCg0KU2VjIDYsIHRoZSBub3RhdGlvbiBoYXMgInZhbHVlPVVSSSIgYnV0IHRoZSBl eGFtcGxlIGhhcyAiVVJMIiAoU2VjIDcuMywgZXRjLiwgdXNlcyBVUkkgaW4gYm90aCBwYXJ0cykN Cg0KU2VjIDEwLCAiYXBwbGljYXRpb25zIHVzaW5nIiBJcyAiYWN0aW5nIG9uIiBiZXR0ZXI/DQoN Cg0K From nobody Tue Apr 23 07:56:44 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FA28120033 for ; Tue, 23 Apr 2019 07:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sphericalcowgroup-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HNWEOLCu_uSZ for ; Tue, 23 Apr 2019 07:56:39 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABB651200F9 for ; Tue, 23 Apr 2019 07:56:39 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id g1so8753901qki.5 for ; Tue, 23 Apr 2019 07:56:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sphericalcowgroup-com.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=5NFBL185QZVEpCuj6eVajLRQYiAXyxm9CgKlZoUY3cA=; b=ywlbYjDeQ9wLpRNTJV2Xd1aCKsDAHnJcN51/C/rDvUWRkQhQcDUUeUXZJiMKEL2Mh3 1hqKmM/6hO9fbNB9xN9eJxwD9R3ZzGPrkNdgbVVb6U+U/V60wz/pq7Je0cZVD1vxaXt/ SsYhVPbUZrT18GNpnLm2VYUhMyWQ93mKzFA0eXSxyDy4RLvgus6QF3v+Cogx1JERGYsT 49KuVCzItiTsrceOYGEZ+i0zkP5k8ENjoctS4sY8owB9pSqNAVw/rrc/NdkvkGSwRcCm 3ccSjLBCIkX6tM9svD4aXi0LE/1PiE8EgnvLDfwzyth2Rz0d95PvRAQL8KWRcD5QoAbH InyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=5NFBL185QZVEpCuj6eVajLRQYiAXyxm9CgKlZoUY3cA=; b=EBiXoC/pT+9s12ggmpbcSJy41KFKV4IwFZqcnUWgUBPspogKgR1FhEr2hInS3ym2bX grC+bAdDU+o4VbOp9gjAMmhu6KK8kP739Zyt78XUfOyTNo4E7oNFNWuBuBK9DZLOkyu9 /pwfk1xxdVNc6vnwzEOUGfmtzknIls5Fy49oOPBu7ZLkyB7rjAQTsQA1IXn4XB5o8yPA TAVpfE/FoOeJgiV29LCxS3syGuha7WzE2uIbix4qxbunbU3fjDe8GbgeRNGTxyEzAUQL PlldnTgymLR2MT8xLAxNRg52PavhHk5Ln+cthrPPx9FMhAvWZ3hlQwvbcUAVsKY5qb/x dZ4Q== X-Gm-Message-State: APjAAAU518nQCbpsq0Ckj9ejk/mivxiOhjWDzs1XBCKgxgWLisv5xIhP ZNiPHLJJjm//7ZdccxKYtkMtfw== X-Google-Smtp-Source: APXvYqzRrnAnDR6fOB4niF0a0urhF3iYZd8WRSCzdTpfYfK5WSNIe4xtxhYggJIbpwXDne8l8TbaJg== X-Received: by 2002:ae9:f00e:: with SMTP id l14mr20043781qkg.127.1556031398522; Tue, 23 Apr 2019 07:56:38 -0700 (PDT) Received: from a-192-168-131-11.dynapool.vpn.nyu.edu (vpnrasa-wwh-pat-01.natpool.nyu.edu. [216.165.95.84]) by smtp.gmail.com with ESMTPSA id x8sm9343729qtj.45.2019.04.23.07.56.36 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 23 Apr 2019 07:56:37 -0700 (PDT) To: Daniel Migault , Rich Salz , "secdir@ietf.org" Cc: "draft-ietf-calext-eventpub-extensions.all@ietf.org" , "ietf@ietf.org" , "calsify@ietf.org" References: <155595686177.21216.4076761255030943970@ietfa.amsl.com> From: Michael Douglass Message-ID: Date: Tue, 23 Apr 2019 10:56:35 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-calext-eventpub-extensions-12 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2019 14:56:42 -0000 Thanks for the comments: All useful - and yes - I'll add the confirmation code. I'll incorporate these changes On 4/23/19 09:02, Daniel Migault wrote: > Thanks for the review Rich! > Yours, > Daniel > > -----Original Message----- > From: Rich Salz via Datatracker > Sent: Monday, April 22, 2019 2:14 PM > To: secdir@ietf.org > Cc: draft-ietf-calext-eventpub-extensions.all@ietf.org; ietf@ietf.org; calsify@ietf.org > Subject: Secdir last call review of draft-ietf-calext-eventpub-extensions-12 > > Reviewer: Rich Salz > Review result: Has Nits > > This is the SECDIR last-call review, intended to be input to the Security AD's. > > Ready with nits. > > The Security Considerations and Privacy Considerations are short, but they seem to reasonably refer to already-published documents. > > Following are nits I noticed. > > Abstract "a number of new iCalendar properties and components" -> "a new iCalendar component and a number of properties" Maybe stike "iCalendar" > > Sec 1, STRUCTURED-DATA. In my opinion the confirmation code would be the most useful new info :) > > Sec 1, SOURCE Is it redefined or extended? > > Sec 2, para 2. "In a break with this 'tradition' ..." --> "Breaking with this practice, ..." > > Sec 3, "When a calendar client receives a calendar component" Should the second calendar be CALENDAR? Should the first be "iCalendar"? > > Sec 3.1.1, uppercase "vcard"? > > Sec 3.1.2.1 "non of which" --> "none of which" > > Sec 4 Perhaps add a sentence saying where this syntax is defined. Is this the complete iCalendar spec or is it just changing a few things? > > Sec 5.1, etc "as laid down in" Is kind of informal wording. > > Sec 6, the notation has "value=URI" but the example has "URL" (Sec 7.3, etc., uses URI in both parts) > > Sec 10, "applications using" Is "acting on" better? > > From nobody Tue Apr 23 20:51:46 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B2A14120335; Tue, 23 Apr 2019 20:51:37 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Russ Mundy via Datatracker To: Cc: draft-housley-hkdf-oids.all@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Russ Mundy Message-ID: <155607789763.32417.6538613672041855445@ietfa.amsl.com> Date: Tue, 23 Apr 2019 20:51:37 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-housley-hkdf-oids-01 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 03:51:38 -0000 Reviewer: Russ Mundy Review result: Ready This document is ready to go From nobody Wed Apr 24 10:53:23 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8827812011E; Wed, 24 Apr 2019 10:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=YnACJX2K; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=IRXjP3qA 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 bjxrtYd0TVWY; Wed, 24 Apr 2019 10:53:07 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0140012009E; Wed, 24 Apr 2019 10:53:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2612; q=dns/txt; s=iport; t=1556128387; x=1557337987; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=O0B7WxEbHvykayqkvyDTuWX6mepZyDtXp6vXGsyozxw=; b=YnACJX2K4MDt+Fh4LDH8ShHaNZzcVQ/2srvJ2364lvpkzk/K7wP4aIQq v7GIv4k4A2NDDzA7DU5IXDHHnAWEjLDpuKPpfQMSgSmxDsNfMdYvd0aFE 38ZszcqsAKglGToeHhnixctiT9bi+HEq24V2SM1/5LKFcmt1gz2p/M0Mn Y=; IronPort-PHdr: =?us-ascii?q?9a23=3AZY9dOxM1P33JKBPtGPkl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu60/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjhNvfqaiU8NM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAAD6ocBc/4sNJK1mDg0BAQEBAwE?= =?us-ascii?q?BAQcDAQEBgVEGAQEBCwGBPVADgT0gBAsohA+DRwOEUoo5gjIllx2BLoF7DgE?= =?us-ascii?q?BLYRAAheGGCM0CQ4BAwEBBAEBAgECbRwMhUsBBSMRDAEBNwEPAgEIGAICCR0?= =?us-ascii?q?CAgIwFRACBA4FgyKBagMcAZ4kAooUcYEvgnkBAQWFAxiCDQmBCycBi0kXgUA?= =?us-ascii?q?/gREnDBOCTD6ERBeCczGCJo0FLJhFZAkCggiOZINGG4ILhimMYKA/AgQCBAU?= =?us-ascii?q?CDgEBBYFPOIFWcBU7KgGCQYIPg2+KGDtygSmPSQEB?= X-IronPort-AV: E=Sophos;i="5.60,390,1549929600"; d="scan'208";a="554394742" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Apr 2019 17:53:06 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x3OHr5gO012972 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 24 Apr 2019 17:53:06 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 24 Apr 2019 12:53:05 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 24 Apr 2019 13:53:03 -0400 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 24 Apr 2019 12:53:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=O0B7WxEbHvykayqkvyDTuWX6mepZyDtXp6vXGsyozxw=; b=IRXjP3qAKbqznXuIJzRCVUsu9FYWYWzTfc5bRWD+F0yx2ENXBae5ESaPzUXi8Z7yVpyW/bAXnJGFhurVdxD3yYMyEgK7+I077IBh8w2Nw8pLKmZfnQ5FBi/5zBRSuBneCeQJ3cgih2TysyQtgPi3zDdp8IoOp0pwH9zr7gVeyp8= Received: from DM5PR1101MB2105.namprd11.prod.outlook.com (10.174.104.15) by DM5PR1101MB2186.namprd11.prod.outlook.com (10.174.104.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1813.18; Wed, 24 Apr 2019 17:53:02 +0000 Received: from DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::a113:a1ba:aae0:4a12]) by DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::a113:a1ba:aae0:4a12%6]) with mapi id 15.20.1813.017; Wed, 24 Apr 2019 17:53:02 +0000 From: "Reshad Rahman (rrahman)" To: Benjamin Kaduk CC: Aanchal Malhotra , "secdir@ietf.org" , "ietf@ietf.org" , "draft-ietf-netconf-restconf-notif.all@ietf.org" , "netconf@ietf.org" Thread-Topic: [netconf] Secdir last call review of draft-ietf-netconf-restconf-notif-13 Thread-Index: AQHU8LEm3/ufrU/2dEa8pjPJiNurYqY4yTOAgAuvaICABvAQgA== Date: Wed, 24 Apr 2019 17:53:02 +0000 Message-ID: <7820A8E4-692B-43D2-9611-437CC440EBC7@cisco.com> References: <155501965074.14152.2835369201856309773@ietfa.amsl.com> <20190420035612.GR51586@kduck.mit.edu> In-Reply-To: <20190420035612.GR51586@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.6.190114 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; x-originating-ip: [2001:420:2840:1250:2421:2f0a:1dbc:638e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c19eca6c-c162-4c8d-2642-08d6c8ddb22d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:DM5PR1101MB2186; x-ms-traffictypediagnostic: DM5PR1101MB2186: x-microsoft-antispam-prvs: x-forefront-prvs: 00179089FD x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(396003)(366004)(136003)(51914003)(199004)(189003)(66476007)(66446008)(66556008)(91956017)(76176011)(64756008)(66946007)(58126008)(54906003)(73956011)(316002)(486006)(6116002)(8936002)(5660300002)(256004)(8676002)(14444005)(305945005)(7736002)(76116006)(86362001)(82746002)(81156014)(36756003)(81166006)(2906002)(33656002)(6512007)(2616005)(229853002)(4326008)(11346002)(6246003)(68736007)(6436002)(25786009)(6486002)(186003)(476003)(53936002)(71190400001)(71200400001)(6916009)(99286004)(53546011)(6506007)(102836004)(14454004)(83716004)(2171002)(478600001)(46003)(446003)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR1101MB2186; H:DM5PR1101MB2105.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: eIexsg5QpVAU8xE/QSPJZsnr5qdaVioqdt1TxP7rQM6+ZbM7xq1x1XZDnSqkNEyvhhu9oFloeLVwvdL/wKKi9Atzxl20wVegRJuBp51b/t/JyUKJ4WuIXBSoxzGOOQUdC+7TGSPpf6CI2s2mZfotfOZuK9Y6qZtZO8dlPd0JjGs9715OpsKKQ8qy7I00otRM1o0hHObjPz48KBRlQgFTR4w7dJyGLRWRuCKE8uXwoWTjFWAqO2MNxrADptJAVkMb5ydfbbBFnEQVvSbUrwpCV/FFNSZ+nIA5nEb+WMfUjWaKonm4Ty/vDUvk/ZNeG2kAA6rCJxqHjFRSfVWZIJsxbeviKA3rgo4UV5xHIsBx5oCzsjVBRg+xEVRsoCYmZ6XRcax8eN7uKSpqYS5G4mXnVFlZYOsII4xB82sTmj8GKlI= Content-Type: text/plain; charset="utf-8" Content-ID: <12916BD1BF47974E99B6D32B44043839@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c19eca6c-c162-4c8d-2642-08d6c8ddb22d X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2019 17:53:02.0743 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1101MB2186 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: Re: [secdir] [netconf] Secdir last call review of draft-ietf-netconf-restconf-notif-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 17:53:10 -0000 T24gMjAxOS0wNC0xOSwgMTE6NTYgUE0sICJCZW5qYW1pbiBLYWR1ayIgPGthZHVrQG1pdC5lZHU+ IHdyb3RlOg0KDQogICAgT24gRnJpLCBBcHIgMTIsIDIwMTkgYXQgMDk6Mjk6MzVQTSArMDAwMCwg UmVzaGFkIFJhaG1hbiAocnJhaG1hbikgd3JvdGU6DQogICAgPiBIaSBBYW5jaGFsLA0KICAgID4g DQogICAgPiBUaGFua3MgZm9yIHRoZSByZXZpZXcuIFBsZWFzZSBzZWUgaW5saW5lLg0KICAgID4g DQogICAgPiBPbiAyMDE5LTA0LTExLCA1OjU0IFBNLCAibmV0Y29uZiBvbiBiZWhhbGYgb2YgQWFu Y2hhbCBNYWxob3RyYSB2aWEgRGF0YXRyYWNrZXIiIDxuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmcg b24gYmVoYWxmIG9mIG5vcmVwbHlAaWV0Zi5vcmc+IHdyb3RlOg0KICAgID4gDQogICAgPiAgICAg UmV2aWV3ZXI6IEFhbmNoYWwgTWFsaG90cmENCiAgICA+ICAgICBSZXZpZXcgcmVzdWx0OiBSZWFk eQ0KICAgID4gICAgIA0KICAgID4gICAgIFRoZSBkb2N1bWVudCBpcyB2ZXJ5IGNsZWFyIGFuZCBj b25jaXNlLiAgSSBqdXN0IGhhdmUgb25lIG1pbm9yIGNsYXJpZmljYXRpb24gcXVlc3Rpb24uDQog ICAgPiAgICAgU2VjdGlvbiAzLjQgUGFnZSA5IHRoYXQgc2F5cyB0aGUgZm9sbG93aW5nOg0KICAg ID4gICAgICJJbiBhZGRpdGlvbiB0byBhbnkgcmVxdWlyZWQgLi4uLi4uLi5TSE9VTEQgb25seSBi ZSBhbGxvd2VkLi4uLi4uIi4gIA0KICAgID4gICAgIA0KICAgID4gICAgIElzIHRoZXJlIGEgcmVh c29uIGZvciB1c2luZyBTSE9VTEQgaW5zdGVhZCBvZiBNVVNUPyANCiAgICA+IA0KICAgID4gVGhl cmUgbWF5IGJlIHJlYXNvbnMgd2h5IGFuIGltcGxlbWVudGF0aW9uIGRlY2lkZXMgbm90IHRvIGVu Zm9yY2UgdGhpcyByZXN0cmljdGlvbi4gR29pbmcgYnkgUkZDMjExOSBkZWZpbml0aW9ucywgdGhp cyBpcyB3aHkgd2UgY2hvc2UgU0hPVUxEIGluc3RlYWQgb2YgTVVTVC4NCiAgICANCiAgICBJZiB5 b3UgaGF2ZSBzb21lIHJlYXNvbnMgaW4gbWluZCwgaXQgaXMgb2Z0ZW4gaGVscGZ1bCB0byBsaXN0 IHRoZW0gYXMNCiAgICBleGFtcGxlcyBvZiB3aGVuIHRoZSByZWNvbW1lbmRlZCBiZWhhdmlvciB3 b3VsZCBub3QgYmUgZm9sbG93ZWQuDQoNCldoYXQgd2UgaGFkIGluIG1pbmQgaXMgYSAic3VwZXIt dXNlciIgd2hvIGNvdWxkIGJlIGdpdmVuIGFjY2VzcyB0byBzdWJzY3JpcHRpb25zIG9mIG90aGVy IHVzZXJzLiBJcyB0aGlzIG9idmlvdXMgb3Igc2hvdWxkIEkgY2FuIGFkZCB0ZXh0IHRvIHRoYXQg ZWZmZWN0IGF0IHRoZSBlbmQgdGhlIGJ1bGxldCBiZWxvdz8gU29tZXRoaW5nIGFsb25nIHRoZSBs aW5lcyBvZiAiRm9yIGV4YW1wbGUsIGEgUkVTVENPTkYgdXNlcm5hbWUgd2l0aCB0aGUgcmVxdWly ZWQgYWRtaW5pc3RyYXRpdmUgcGVybWlzc2lvbnMgY291bGQgYmUgYWxsb3dlZCB0byBpbnZva2Ug UlBDcyBtb2RpZnktc3Vic2NyaXB0aW9uLCByZXN5bmMtc3Vic2NyaXB0aW9uIGFuZCBkZWxldGUt c3Vic2NyaXB0aW9uIG9uIGEgc3Vic2NyaXB0aW9uIHdoaWNoIHdhcyBjcmVhdGVkIGJ5IGFub3Ro ZXIgdXNlcm5hbWUuIi4NCg0KICAgbyAgSW4gYWRkaXRpb24gdG8gYW55IHJlcXVpcmVkIGFjY2Vz cyBwZXJtaXNzaW9ucyAoZS5nLiwgTkFDTSksIFJQQ3MNCiAgICAgIG1vZGlmeS1zdWJzY3JpcHRp b24sIHJlc3luYy1zdWJzY3JpcHRpb24gYW5kIGRlbGV0ZS1zdWJzY3JpcHRpb24NCiAgICAgIFNI T1VMRCBvbmx5IGJlIGFsbG93ZWQgYnkgdGhlIHNhbWUgUkVTVENPTkYgdXNlcm5hbWUgW1JGQzgw NDBdDQogICAgICB3aGljaCBpbnZva2VkIGVzdGFibGlzaC1zdWJzY3JpcHRpb24uDQoNClJlZ2Fy ZHMsDQpSZXNoYWQuDQogICAgDQogICAgVGhhbmsgeW91IEFhbmNoYWwgZm9yIHRoZSByZXZpZXch DQogICAgDQogICAgLUJlbg0KICAgIA0KDQo= From nobody Wed Apr 24 11:48:48 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8D561201F8; Wed, 24 Apr 2019 11:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 TQycMOg4grZ0; Wed, 24 Apr 2019 11:48:38 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (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 1652F120100; Wed, 24 Apr 2019 11:48:37 -0700 (PDT) Received: from LAPTOPR7T053C2 ([73.189.160.186]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MNs0D-1hQnbX2FSd-007XFH; Wed, 24 Apr 2019 20:48:32 +0200 From: "Alexander Clemm" To: "'Takeshi Takahashi'" , Cc: , References: <155488041402.1083.9565126428194093115@ietfa.amsl.com> In-Reply-To: <155488041402.1083.9565126428194093115@ietfa.amsl.com> Date: Wed, 24 Apr 2019 11:48:30 -0700 Message-ID: <10a501d4face$513d3600$f3b7a200$@clemm.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQGkXl6tnNmJZ5U6rvHBJnkUSxkaRKaszf2w Content-Language: en-us X-Provags-ID: V03:K1:nuJdqaepsb4NRn/yC+/vgYtPBnm2jf3YLRt+25/hlOJ1v54mq9e 5y3vAH9ZOPPP8jN9rPg2WrApUvytWaxajyX7Fw5moRjjKd9G5mSZpPtpNLp36IAc86iOvYK YlBX7s9lOsGkFH259Wgqd5Hq37NTy91fRrGrPspX6LshWG+0fIIGRREQjptZ8n3Q2K/jA4+ iNWNp9kl/1c1fbySmK/wQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:eVc5fBhcLhM=:TQC8pC0+otFfJYgJ9ffzUD NbKtjF6cf6tckragEXGJZWlnve/JbbVpJwHuIVkx9Op4BYGbKXa8WEW7brgAZMtnUPZ7tCDKJ H01ETGIr+DpCXP7GVLbaAfCrir3ZR8z/1rlKIN7m5gWbfX5UpFvaYUNBujQaE+xDpOJc2u+AH 3RLre7TxbGAXw8PnVLyXzUwHm+/p4BUBcmA9z9REAQ2Do+xRAO9I3keqZmKu/trnYHkgbdtTQ v0kTAlvqE65pb03Ra3OTHGdp167ZH7dck/j1sQYvPpMnyJae6xLU4yy8JH4TGZ45sSwXOi/ED KfXnSDiRYhEyWTn2CZizE1eUuzCGrnaZuvDaUDYE55t+3684dZ3WHd2UHLhvQv9bpPZ7L6FIu Z4ZDsOd5+oJ/xmBGYxQIU7oRe1DDEn8W5Fwc9Uz5WqRKTR1eOo1ZK0gKStPDuDHYvGYfpakPC bmOmCd/llq+NhxEccrN2EVamzHSPwoRbjzPi0rYa7CPo8zzCGDic+OPI7qB/+4O/wIUj8UDMc h0RMxghrIEwWaobki0eRITrjrfPdh3JJLL00Fi49V4M+aRbDpwpwS0f1MHJ4h+yUFjhnT5vB3 OtkqBiyklABiGadYaCPFqu3bsWK0cXzXacitHTYODRU5WxFrSwTH1Eoz1P47hF53s9dvmkr6z 2emBASd2GiAhaFPfp9VwZKBVj3QoudGUO0LFBXm4SFNMvX0fTUah0Vawgg66umkaOl1X+NIWB 7NK/+CWCzgKsYC08rG4RotzrflKVMmlYHKktoCV5f/Wta8jlVgXALgnh3T8= Archived-At: Subject: Re: [secdir] [netconf] Secdir last call review of draft-ietf-netconf-yang-push-22 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2019 18:48:41 -0000 Hi Takeshi, Thank you for your review! Please see replies inline, --- Alex -----Original Message----- From: netconf On Behalf Of Takeshi Takahashi via Datatracker Sent: Wednesday, April 10, 2019 12:14 AM To: secdir@ietf.org Cc: draft-ietf-netconf-yang-push.all@ietf.org; netconf@ietf.org Subject: [netconf] Secdir last call review of draft-ietf-netconf-yang-push-22 Reviewer: Takeshi Takahashi Review result: Has Nits This draft talks about push-type update notifications of YANG datastore. It provides two types of subscriptions: periodic and on-change. I have one comments (item 4) and four clarification questions (items 1-3) below. 1. on the on-change subscription (in sections 3.3 and 3.10) The draft says "it will be important for client applications to have a way to identify for which objects on-change notifications are supported and for which ones they are not supported," but this issue is currently left to the implementation. It would be nice if you could provide some example solutions to this problem so that the implementers of this draft will not be confused. When a publisher accept on-change subscription even when the scope of the subscription contains objects for which on-change is not supported, I wonder sending some notification message on the situation could be helpful for the subscriber. By reading other part of the draft, I feel that the draft is indeed recommending to implement such comprehensive notifications. If so, it had better be clearly mentioned in this section. I also think it is not a bad idea to define such a comprehensive notification in this draft, though it is up to the authors. Because the solution to the topic of knowing for which objects on-change notifications are supported is indeed complex, this is actually being deferred to a different draft, draft-ietf-netconf-notification-capabilities, which allows a subscriber to precisely discover where this is supported and where not. As to what to do when a subscription's scope contains objects not capable of on-change notifications, section 3.3 states "Whether or not to accept or reject on-change subscription requests when the scope of the subscription contains objects for which on-change is not supported is up to the publisher implementation." There are no separate notifications that will be sent; instead this is handled through replies to the request. Notifications are only sent when the state of the subscription changes, which would include scenarios in which the server decides it can no longer support the subscription (due to dynamic changes, or whatever) after all. 2. on the differing dampening periods for multiple objects(in section 3) The draft says "In case whether a subscriber wants to have separate dampening periods for different objects, the subscriber has the option to create multiple subscriptions with different selection filters." That is a good solution. Then are the any other options for allowing to have separate dampening periods for different objects? The sentence gave me the impression that there are multiple options; so I am asking this question only for clarification. No, this is the only option. Within a subscription only one dampening period applies. Anything else would make configuration and figuring out what is going on super complex. Hence the solution of applying separate subscription if an application indeed requires different settings for different subscribed objects. 3. imcomplete-update flag (in sections 3.11.1 and 4.3.2) I am not sure what would be the expected actions of the subscribers when they receive a message with incomplete-update flag on. Some navigations would be appreciated. Meanwhile, according to section 4.3.2, a publisher MAY subsequently send a push-update containing a full selection snapshot of subscribed data. If such a push-update is subsequently sent, does the publisher need to send anoter message with incomplete-update flag on prior to the push-update with a full selection snapshot of subscribed data? When a message with an incomplete-update flag is received, what it will do is really up to the receiver. Really, the flag is there only for exceptions to let the receiver know if due to some unforeseen and unavoidable circumstance the server is not able to fulfill its obligation per the terms of the subscription. The actual exception handling that a receiver application would apply when receiving a push-update with an incomplete flag depends on the application. A receiver could choose to resynch (retrieving all subscribed information). It could choose to wait (some applications may be okay with the loss of some information, but at least they know). It could choose to tear down the subscription and start a new one, perhaps with a lesser scope. We will add this sentence to make this clear; will this address your concerns? I am not clear on the second part of your question regarding sending another message with incomplete flag. The goal of the push-update with a full selection snapshot of subscribed data is to make sure that the receiver is again in sync with the subscribed data; only if for some reason that would fail (and be incomplete again) an incomplete flag would be set. Obviously, if there are continuous problems (i.e. incomplete-update occurs all the time, no resync possible), this constitutes an error condition; the publisher may suspend the subscription in this case (as stated) and the subscribing application may decide that the subscription of the publisher are useless. 4. security considerations (in section 7) This section enumerates four threats that are newly introduced by this draft. Some countermeasures, or directions to address these threats, had better be provided here. Not exactly sure what to put here. We do mention that NACM should be used to restrict access. Since most of the attacks involve modifying the terms of the subscription, we can add a sentence to the effect of: "A subscriber could monitor the subscription configuration itself for any unexpected changes. For this, they should monitor notifications regarding updates to their subscriptions to validate that these updates were indeed intended. They could even subscribe to updates to the YANG datastore nodes that represent their datastore subscriptions." Will this address your concern? _______________________________________________ netconf mailing list netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Apr 25 03:23:48 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C20A3120225 for ; Thu, 25 Apr 2019 03:23:38 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Tero Kivinen via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: secdir-secretary@mit.edu, Tero Kivinen Message-ID: <155618781878.23454.9844389863110194782.idtracker@ietfa.amsl.com> Date: Thu, 25 Apr 2019 03:23:38 -0700 Archived-At: Subject: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Apr 2019 10:23:47 -0000 Review instructions and related resources are at: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview For telechat 2019-05-02 Reviewer LC end Draft Shaun Cooley 2019-03-13 draft-ietf-dots-data-channel-28 Alexey Melnikov 2019-04-11 draft-ietf-sidrops-lta-use-cases-05 Matthew Miller 2019-04-08 draft-ietf-core-multipart-ct-03 Last calls: Reviewer LC end Draft Derek Atkins 2019-03-03 draft-ietf-netmod-module-tags-07 Nancy Cam-Winget 2019-02-15 draft-ietf-rtcweb-security-11 Daniel Franke 2019-03-18 draft-ietf-sidrops-https-tal-07 Daniel Gillmor 2018-03-19 draft-gutmann-scep-13 Charlie Kaufman 2019-03-14 draft-ietf-trans-rfc6962-bis-31 Catherine Meadows 2019-04-12 draft-ietf-mmusic-rfc4566bis-34 Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 Magnus Nystrom 2019-04-10 draft-ietf-avtcore-multiplex-guidelines-08 Tim Polk 2019-04-17 draft-ietf-isis-segment-routing-extensions-24 Vincent Roca R2019-02-13 draft-ietf-perc-private-media-framework-09 Stefan Santesson 2019-05-08 draft-ietf-lamps-rfc6844bis-05 Yaron Sheffer 2019-05-07 draft-ietf-softwire-iftunnel-04 Rifaat Shekh-Yusef 2019-05-03 draft-ietf-pce-applicability-actn-11 David Waltermire 2019-02-15 draft-ietf-rtcweb-ip-handling-11 Klaas Wierenga 2019-02-26 draft-ietf-mpls-sr-over-ip-04 Taylor Yu 2019-02-15 draft-ietf-rtcweb-security-arch-18 Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-11 Early review requests: Reviewer Due Draft Daniel Franke 2018-01-31 draft-ietf-intarea-provisioning-domains-00 Kathleen Moriarty 2019-04-08 draft-ietf-bmwg-ngfw-performance-00 Next in the reviewer rotation: Valery Smyslov Robert Sparks Takeshi Takahashi Tina Tsou Sean Turner Carl Wallace David Waltermire Samuel Weiler Brian Weis Klaas Wierenga From nobody Fri Apr 26 20:35:51 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 320EC120175 for ; Fri, 26 Apr 2019 20:35:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 kNjhS4BiEmzr for ; Fri, 26 Apr 2019 20:35:47 -0700 (PDT) Received: from mail-oi1-f170.google.com (mail-oi1-f170.google.com [209.85.167.170]) (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 17D5712011E for ; Fri, 26 Apr 2019 20:35:47 -0700 (PDT) Received: by mail-oi1-f170.google.com with SMTP id a6so4515056oie.5 for ; Fri, 26 Apr 2019 20:35:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yYidW2ERImxIdR1uBWzp64CBOWZayE8suAnGFnIU7pw=; b=bXdiUWsgbkytULIPUAFIKrQ50jPzmJOdDjiViTQkHErJVt9LNu70L8+AyKJ/ZdYPKV RqyoWrwc3lq4wWuvfOHgioFqBp2zZP0GhKFvDsY9g3Y4T2nlvUkSgzxZSgam6huldH5F LD/iYghIgrjLkl+Ou/vBStPGWNCLwCVF2P6jTXqBq67R0WO/oQ4+FKttRCzeKpMkotmZ u+Ait7dl8CZOZvIhpwFoQrDcgNh88IPwG2R5vwxJD11sKOt4X22mI0E+ce7gSyEYCP4G EGfRkzZXLwUcnj4ynIxsNrjpyTSXNoHpDez7gblxGwQ8qRTDUjwcfrc9cinxb81k7agc gOPA== X-Gm-Message-State: APjAAAUTybOzyplzKvj8Ex+pVOluzKuO7wW1SHistK2CELA/9gsa9f3R Grr7CxxA7bGzZ1CySI17KYBkcmoxvnQzdB3cQ/SGEQ== X-Google-Smtp-Source: APXvYqypFI7SKO4vARatf89SVStEmM+vKYgVgeQHXcQQR0GRS962ham+MJmeVAnsV2FifqY/5Y4UncU/Gt2/NodPXYY= X-Received: by 2002:aca:43d5:: with SMTP id q204mr9512789oia.100.1556336146087; Fri, 26 Apr 2019 20:35:46 -0700 (PDT) MIME-Version: 1.0 References: <155618781878.23454.9844389863110194782.idtracker@ietfa.amsl.com> In-Reply-To: <155618781878.23454.9844389863110194782.idtracker@ietfa.amsl.com> From: Phillip Hallam-Baker Date: Fri, 26 Apr 2019 23:35:36 -0400 Message-ID: To: secdir-secretary@mit.edu, Tero Kivinen Cc: secdir@ietf.org Content-Type: multipart/alternative; boundary="00000000000023849405877abf9c" Archived-At: Subject: Re: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2019 03:35:49 -0000 --00000000000023849405877abf9c Content-Type: text/plain; charset="UTF-8" Ooops. Just noticed that these have not been going into my action items folder and I missed one. My filter must have been relying on a feature that changed. Not really a tools team issue or critical. But it is a systemic problem with using SMTP mail for workflow. We have traditionally considered the killer app for S/MIME to be confidentiality. What if it was authentication and access control? Signing meeting requests, calendar entries, task items allows people to add things to my work queue. Trying to retrofit might be a case of trying to balance too many plates on the stack though. On Thu, Apr 25, 2019 at 6:23 AM Tero Kivinen via Datatracker < noreply@ietf.org> wrote: > Review instructions and related resources are at: > http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > > For telechat 2019-05-02 > > Reviewer LC end Draft > Shaun Cooley 2019-03-13 draft-ietf-dots-data-channel-28 > Alexey Melnikov 2019-04-11 draft-ietf-sidrops-lta-use-cases-05 > Matthew Miller 2019-04-08 draft-ietf-core-multipart-ct-03 > > Last calls: > > Reviewer LC end Draft > Derek Atkins 2019-03-03 draft-ietf-netmod-module-tags-07 > Nancy Cam-Winget 2019-02-15 draft-ietf-rtcweb-security-11 > Daniel Franke 2019-03-18 draft-ietf-sidrops-https-tal-07 > Daniel Gillmor 2018-03-19 draft-gutmann-scep-13 > Charlie Kaufman 2019-03-14 draft-ietf-trans-rfc6962-bis-31 > Catherine Meadows 2019-04-12 draft-ietf-mmusic-rfc4566bis-34 > Russ Mundy 2017-09-14 draft-spinosa-urn-lex-13 > Magnus Nystrom 2019-04-10 > draft-ietf-avtcore-multiplex-guidelines-08 > Tim Polk 2019-04-17 > draft-ietf-isis-segment-routing-extensions-24 > Vincent Roca R2019-02-13 > draft-ietf-perc-private-media-framework-09 > Stefan Santesson 2019-05-08 draft-ietf-lamps-rfc6844bis-05 > Yaron Sheffer 2019-05-07 draft-ietf-softwire-iftunnel-04 > Rifaat Shekh-Yusef 2019-05-03 draft-ietf-pce-applicability-actn-11 > David Waltermire 2019-02-15 draft-ietf-rtcweb-ip-handling-11 > Klaas Wierenga 2019-02-26 draft-ietf-mpls-sr-over-ip-04 > Taylor Yu 2019-02-15 draft-ietf-rtcweb-security-arch-18 > Taylor Yu 2018-11-28 draft-ietf-alto-cost-calendar-11 > > Early review requests: > > Reviewer Due Draft > Daniel Franke 2018-01-31 > draft-ietf-intarea-provisioning-domains-00 > Kathleen Moriarty 2019-04-08 draft-ietf-bmwg-ngfw-performance-00 > > Next in the reviewer rotation: > > Valery Smyslov > Robert Sparks > Takeshi Takahashi > Tina Tsou > Sean Turner > Carl Wallace > David Waltermire > Samuel Weiler > Brian Weis > Klaas Wierenga > > _______________________________________________ > secdir mailing list > secdir@ietf.org > https://www.ietf.org/mailman/listinfo/secdir > wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview > --00000000000023849405877abf9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ooo= ps. Just noticed that these have not been going into my action items folder= and I missed one. My filter must have been relying on a feature that chang= ed.

<= div class=3D"gmail_default" style=3D"font-size:small">Not really a tools te= am issue or critical. But it is a systemic problem with using SMTP mail for= workflow.

=
We have tradit= ionally considered the killer app for S/MIME to be confidentiality. What if= it was authentication and access control? Signing meeting requests, calend= ar entries, task items allows people to add things to my work queue.
<= div class=3D"gmail_default" style=3D"font-size:small">
Trying to retrofit might be a = case of trying to balance too many plates on the stack though.



On Thu, Apr 25, 2019 at 6:2= 3 AM Tero Kivinen via Datatracker <n= oreply@ietf.org> wrote:
Review instructions and related resources are at:
http://tools.ietf.org/area/sec/trac/wiki/SecDir= Review

For telechat 2019-05-02

Reviewer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0LC end=C2=A0= =C2=A0 =C2=A0Draft
Shaun Cooley=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02019-03-13 draft-ietf-= dots-data-channel-28
Alexey Melnikov=C2=A0 =C2=A0 =C2=A0 =C2=A0 2019-04-11 draft-ietf-sidrops-lt= a-use-cases-05
Matthew Miller=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02019-04-08 draft-ietf-core-= multipart-ct-03

Last calls:

Reviewer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0LC end=C2=A0= =C2=A0 =C2=A0Draft
Derek Atkins=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02019-03-03 draft-ietf-= netmod-module-tags-07
Nancy Cam-Winget=C2=A0 =C2=A0 =C2=A0 =C2=A02019-02-15 draft-ietf-rtcweb-sec= urity-11
Daniel Franke=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2019-03-18 draft-ietf-sidro= ps-https-tal-07
Daniel Gillmor=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02018-03-19 draft-gutmann-sc= ep-13
Charlie Kaufman=C2=A0 =C2=A0 =C2=A0 =C2=A0 2019-03-14 draft-ietf-trans-rfc6= 962-bis-31
Catherine Meadows=C2=A0 =C2=A0 =C2=A0 2019-04-12 draft-ietf-mmusic-rfc4566b= is-34
Russ Mundy=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02017-09-14 draft-= spinosa-urn-lex-13
Magnus Nystrom=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02019-04-10 draft-ietf-avtco= re-multiplex-guidelines-08
Tim Polk=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02019-04-17 d= raft-ietf-isis-segment-routing-extensions-24
Vincent Roca=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 R2019-02-13 draft-ietf-perc-= private-media-framework-09
Stefan Santesson=C2=A0 =C2=A0 =C2=A0 =C2=A02019-05-08 draft-ietf-lamps-rfc6= 844bis-05
Yaron Sheffer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2019-05-07 draft-ietf-softw= ire-iftunnel-04
Rifaat Shekh-Yusef=C2=A0 =C2=A0 =C2=A02019-05-03 draft-ietf-pce-applicabili= ty-actn-11
David Waltermire=C2=A0 =C2=A0 =C2=A0 =C2=A02019-02-15 draft-ietf-rtcweb-ip-= handling-11
Klaas Wierenga=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02019-02-26 draft-ietf-mpls-= sr-over-ip-04
Taylor Yu=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2019-02-15 draft-= ietf-rtcweb-security-arch-18
Taylor Yu=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2018-11-28 draft-= ietf-alto-cost-calendar-11

Early review requests:

Reviewer=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Due=C2=A0 = =C2=A0 =C2=A0 =C2=A0 Draft
Daniel Franke=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2018-01-31 draft-ietf-intar= ea-provisioning-domains-00
Kathleen Moriarty=C2=A0 =C2=A0 =C2=A0 2019-04-08 draft-ietf-bmwg-ngfw-perfo= rmance-00

Next in the reviewer rotation:

=C2=A0 Valery Smyslov
=C2=A0 Robert Sparks
=C2=A0 Takeshi Takahashi
=C2=A0 Tina Tsou
=C2=A0 Sean Turner
=C2=A0 Carl Wallace
=C2=A0 David Waltermire
=C2=A0 Samuel Weiler
=C2=A0 Brian Weis
=C2=A0 Klaas Wierenga

_______________________________________________
secdir mailing list
secdir@ietf.org https://www.ietf.org/mailman/listinfo/secdir
wiki: http://tools.ietf.org/area/sec/trac/wiki/= SecDirReview
--00000000000023849405877abf9c-- From nobody Sat Apr 27 08:24:12 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 585781201B1; Sat, 27 Apr 2019 08:24:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Yaron Sheffer via Datatracker To: Cc: softwires@ietf.org, ietf@ietf.org, draft-ietf-softwire-iftunnel.all@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Yaron Sheffer Message-ID: <155637864110.20002.13242546969290279888@ietfa.amsl.com> Date: Sat, 27 Apr 2019 08:24:01 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-softwire-iftunnel-04 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Apr 2019 15:24:05 -0000 Reviewer: Yaron Sheffer Review result: Ready The document basically restates a bunch of IANA constants (tunnel types) as a YANG module. I cannot see any security issues that could be associated with that. From nobody Sun Apr 28 16:31:36 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6493A1201B3; Sun, 28 Apr 2019 16:31:22 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Rifaat Shekh-Yusef via Datatracker To: Cc: draft-ietf-pce-applicability-actn.all@ietf.org, pce@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Rifaat Shekh-Yusef Message-ID: <155649428231.20950.16409989782111070284@ietfa.amsl.com> Date: Sun, 28 Apr 2019 16:31:22 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-pce-applicability-actn-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2019 23:31:23 -0000 Reviewer: Rifaat Shekh-Yusef 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. RFC8453 is an informational document that defines a Framework for Abstraction and Control of TE Networks (ACTN), with a well defined security considerations section. This is an informational document that examines the applicability of Path Computation Element (PCE) to the ACTN, by adding PCE to the PNC and MDSC controllers. The security considerations section seems to be aligned with the security of the ACTN framework, and the addition of PCE to the existing controllers does not introduce new security concerns beyond what is already covered by the framework. Regards, Rifaat From nobody Sun Apr 28 20:00:14 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5148120295; Sun, 28 Apr 2019 20:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGmeJKWRIDbl; Sun, 28 Apr 2019 20:00:11 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AFCD120294; Sun, 28 Apr 2019 20:00:10 -0700 (PDT) Received: from kduck.mit.edu (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.14.7/8.12.4) with ESMTP id x3T304G3025484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 28 Apr 2019 23:00:05 -0400 Date: Sun, 28 Apr 2019 22:00:03 -0500 From: Benjamin Kaduk To: "Reshad Rahman (rrahman)" Cc: Aanchal Malhotra , "secdir@ietf.org" , "ietf@ietf.org" , "draft-ietf-netconf-restconf-notif.all@ietf.org" , "netconf@ietf.org" Message-ID: <20190429030003.GJ60332@kduck.mit.edu> References: <155501965074.14152.2835369201856309773@ietfa.amsl.com> <20190420035612.GR51586@kduck.mit.edu> <7820A8E4-692B-43D2-9611-437CC440EBC7@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7820A8E4-692B-43D2-9611-437CC440EBC7@cisco.com> User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: Re: [secdir] [netconf] Secdir last call review of draft-ietf-netconf-restconf-notif-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 03:00:13 -0000 On Wed, Apr 24, 2019 at 05:53:02PM +0000, Reshad Rahman (rrahman) wrote: > On 2019-04-19, 11:56 PM, "Benjamin Kaduk" wrote: > > On Fri, Apr 12, 2019 at 09:29:35PM +0000, Reshad Rahman (rrahman) wrote: > > Hi Aanchal, > > > > Thanks for the review. Please see inline. > > > > On 2019-04-11, 5:54 PM, "netconf on behalf of Aanchal Malhotra via Datatracker" wrote: > > > > Reviewer: Aanchal Malhotra > > Review result: Ready > > > > The document is very clear and concise. I just have one minor clarification question. > > Section 3.4 Page 9 that says the following: > > "In addition to any required ........SHOULD only be allowed......". > > > > Is there a reason for using SHOULD instead of MUST? > > > > There may be reasons why an implementation decides not to enforce this restriction. Going by RFC2119 definitions, this is why we chose SHOULD instead of MUST. > > If you have some reasons in mind, it is often helpful to list them as > examples of when the recommended behavior would not be followed. > > What we had in mind is a "super-user" who could be given access to subscriptions of other users. Is this obvious or should I can add text to that effect at the end the bullet below? Something along the lines of "For example, a RESTCONF username with the required administrative permissions could be allowed to invoke RPCs modify-subscription, resync-subscription and delete-subscription on a subscription which was created by another username.". > > o In addition to any required access permissions (e.g., NACM), RPCs > modify-subscription, resync-subscription and delete-subscription > SHOULD only be allowed by the same RESTCONF username [RFC8040] > which invoked establish-subscription. I think it might help to have such text, though I would suggest a slightly pithier "Such a restriction generally serves to preserve users' privacy, but exceptions might be made for administrators that may need to modify or delete other users' subscriptions." Thanks, Ben From nobody Sun Apr 28 23:24:53 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 461A91200B7; Sun, 28 Apr 2019 23:24:37 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 uLK35GL45rTT; Sun, 28 Apr 2019 23:24:35 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 22196120025; Sun, 28 Apr 2019 23:24:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1556519074; x=1588055074; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=I+ONsYpL/eruPOCjENaEGEq7XQ7kDnxG3FTBAWIRDj4=; b=eKt28wgltG8ebVt2Myuwu0DQZWvW916zFzDIGhCZoe/okeiivJ2M3sop A+rjDdQaz5w2osu+GU6slpUPp+zQcs1PuiUZ1D9TtROCWLsUZ5dVMKnLq ZqP/gad7SKHHezTFt5HiBf/wK7qCj/jxRoDE5183LCrBC7+BMM8hRjxPj DuI1kmTrw6W8O55lmEMjHvS1EKlpXaOnd+nEB7z78eTOoEL75OF/YNVjM BMgVGNNvoSrTO2DWjZGNM8shpT84BMAaojfYpStxnilE5fJkRLuHxBkqf /aC5XK54PpvFomZRhJUb9FfVq4WdzubAExv1U8f4sBwPD1Po0XQhml8Pf A==; X-IronPort-AV: E=Sophos;i="5.60,408,1549882800"; d="scan'208";a="59220893" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.8 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-e.UoA.auckland.ac.nz) ([10.6.2.8]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 29 Apr 2019 18:24:27 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-e.UoA.auckland.ac.nz (10.6.2.8) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 29 Apr 2019 18:24:27 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Mon, 29 Apr 2019 18:24:26 +1200 From: Peter Gutmann To: Graham Leggett , "secdir@ietf.org" , "iesg@ietf.org" , "draft-gutmann-scep.all@ietf.org" Thread-Topic: [FORGED] draft-gutmann-scep-13: Bootstrapping SCEP from the web Thread-Index: AQHU/emPyZofV0g0h0+tpyUB4YxQjqZSrGpk Date: Mon, 29 Apr 2019 06:24:26 +0000 Message-ID: <1556519056597.26360@cs.auckland.ac.nz> References: In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [secdir] [FORGED] draft-gutmann-scep-13: Bootstrapping SCEP from the web X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 06:24:37 -0000 Graham Leggett writes:=0A= =0A= >One of the missing elements from the SCEP protocol (and it appears from th= e=0A= >EST protocol as well) is the ability to bootstrap the certificate generati= on=0A= >process from a web browser.=0A= =0A= The reason why it's not present in SCEP, CMC, CMP, EST, or anything else is= =0A= that no-one's ever requested that as a capability. If anyone wanted it, it= =0A= could be added as a new RFC. I think the best option would be to specify a= =0A= general-purpose capability where the browser could indicate what protocol(s= )=0A= it supports or prefers (SCEP, CMP, whatever) and the web site then tells it= to=0A= initiate that protocol to request a cert.=0A= =0A= Peter.=0A= From nobody Mon Apr 29 04:13:18 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6EC31200C3 for ; Mon, 29 Apr 2019 04:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.42 X-Spam-Level: X-Spam-Status: No, score=-3.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJSEzFWlROAs for ; Mon, 29 Apr 2019 04:13:15 -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 2975812008F for ; Mon, 29 Apr 2019 04:13:14 -0700 (PDT) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id x3TBD5ko011836 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 29 Apr 2019 14:13:05 +0300 (EEST) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id x3TBD5np003341; Mon, 29 Apr 2019 14:13:05 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23750.56385.220502.134039@fireball.acr.fi> Date: Mon, 29 Apr 2019 14:13:05 +0300 From: Tero Kivinen To: Phillip Hallam-Baker Cc: secdir-secretary@mit.edu, secdir@ietf.org In-Reply-To: References: <155618781878.23454.9844389863110194782.idtracker@ietfa.amsl.com> X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 13 min Archived-At: Subject: Re: [secdir] Assignments X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 11:13:18 -0000 Phillip Hallam-Baker writes: > Ooops. Just noticed that these have not been going into my action items folder > and I missed one. My filter must have been relying on a feature that changed. I switched to use emails sent from datatracker two and half years ago, i.e., end of 2016. Reply to, To and Subject should have been same. >From address field did change from kivinen@iki.fi to noreply@ietf.org in the beginning of March, because of some datatracker changes, so that is the one that most likely caused the issue. Anyways it is always better to use something else than From address for filtering as the secdir secretary might change :-) The reply-to address of secdir-secretary@mit.edu should stay same. > Not really a tools team issue or critical. But it is a systemic > problem with using SMTP mail for workflow. You can always see your review requests also in the datatracker by going to the https://datatracker.ietf.org/accounts/review/ page, and also the datatracker should send you automatic email when one is assigned to you in addition to my summary... One good thing about mail workflow is that I do get all the notifications in the same place, I hate the cases where I need to go and check through few dozen different web pages to see if there is anything new there for me to do... > We have traditionally considered the killer app for S/MIME to be > confidentiality. What if it was authentication and access control? Signing > meeting requests, calendar entries, task items allows people to add things to > my work queue. That would be nice, but the problem again is that you want to configure your systems to act on certain requests differently. Whether it is S/MIME authenticated does not really help there, you still do not want to accept random S/MIME authenticated request to add new entries to your calendar, so you are still left with whitelist of people who can add items to your calendar, and when things change then those will break... > Trying to retrofit might be a case of trying to balance too many > plates on the stack though. Adding generic code to the datatracker that signs emails with S/MIME, would actually be quite good enhancement, and I did make a new ticket #2716 about this... -- kivinen@iki.fi From nobody Mon Apr 29 13:04:18 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0128E1203D6; Mon, 29 Apr 2019 13:04:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=WZGbFsoN; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=QbBdaKx4 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 7m12pnPu3-x7; Mon, 29 Apr 2019 13:03:59 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44A30120142; Mon, 29 Apr 2019 13:03:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3486; q=dns/txt; s=iport; t=1556568239; x=1557777839; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Io0VrkoD9LFMD5OqGIBNKpBJVKBwdIC45BSId7eKYgc=; b=WZGbFsoNk/cRY42qYSjYTiKbk/on1XC/F5MRdDDi8/2H70fmC5DqVj6S D96DOBpF0auVhRcLMGA6dQ949ei8PWVq3CdSKYN7GGkm4qhAWq30KW4W7 0zTIEWEsmyuHHC6ORiuYDhVeaRkLndfBF0QnbKA8Mp1b/JN+wemK+TUHh s=; IronPort-PHdr: =?us-ascii?q?9a23=3Ax/XaMRM38KhgMF2ruyol6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu60/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjhNvfqaiU8NM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CjAAAmWMdc/4ENJK1mDg4BAQEEAQE?= =?us-ascii?q?HBAEBgVMFAQELAYE9UAOBPSAECyiEEINHA48PgjIllyKBLoEkA1QOAQEthEA?= =?us-ascii?q?CF4YbIzYHDgEDAQEEAQECAQJtHAyFSwEBBBIREQwBATcBDwIBCBgCAgkdAgI?= =?us-ascii?q?CMBUQAgQOBSKDAIFqAxwBo08CgTWIX3GBL4J5AQEFhQUYgg4JgQsnAYtJF4F?= =?us-ascii?q?AP4ERJwwTgkw+hFuCczKCJo0QLJhaZQkCggmOaoNJG4INhjSMZqBaAgQCBAU?= =?us-ascii?q?CDgEBBYFWAy6BVnAVOyoBgkGCDweDaIoYO3KBKZMXAQE?= X-IronPort-AV: E=Sophos;i="5.60,410,1549929600"; d="scan'208";a="266535598" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Apr 2019 20:03:58 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x3TK3wp3009274 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 29 Apr 2019 20:03:58 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 29 Apr 2019 15:03:57 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 29 Apr 2019 15:03:56 -0500 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 29 Apr 2019 15:03:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Io0VrkoD9LFMD5OqGIBNKpBJVKBwdIC45BSId7eKYgc=; b=QbBdaKx4BF5v1KCz1LNXXYncUatFfPZSI83c0qjv79dcB1tWQnIWVnbY9mOG05ZxUmR8hu9VUy38g3e7EjP5pRyxe6MmzDJw+D0mFbhsanrduohTKAvf8dGNL7ZZX4+pro1IvqO2jJLY1i64F//tQkQRMTw0ZppN/KZMHO65jkg= Received: from DM5PR1101MB2105.namprd11.prod.outlook.com (10.174.104.15) by DM5PR1101MB2188.namprd11.prod.outlook.com (10.174.104.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.13; Mon, 29 Apr 2019 20:03:55 +0000 Received: from DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::a113:a1ba:aae0:4a12]) by DM5PR1101MB2105.namprd11.prod.outlook.com ([fe80::a113:a1ba:aae0:4a12%6]) with mapi id 15.20.1835.010; Mon, 29 Apr 2019 20:03:55 +0000 From: "Reshad Rahman (rrahman)" To: Benjamin Kaduk CC: Aanchal Malhotra , "secdir@ietf.org" , "ietf@ietf.org" , "draft-ietf-netconf-restconf-notif.all@ietf.org" , "netconf@ietf.org" Thread-Topic: [netconf] Secdir last call review of draft-ietf-netconf-restconf-notif-13 Thread-Index: AQHU8LEm3/ufrU/2dEa8pjPJiNurYqY4yTOAgAuvaICABvAQgIAHJTqAgADbAgA= Date: Mon, 29 Apr 2019 20:03:55 +0000 Message-ID: <67A8986B-4406-4CF4-8F64-42AFAF48EC1B@cisco.com> References: <155501965074.14152.2835369201856309773@ietfa.amsl.com> <20190420035612.GR51586@kduck.mit.edu> <7820A8E4-692B-43D2-9611-437CC440EBC7@cisco.com> <20190429030003.GJ60332@kduck.mit.edu> In-Reply-To: <20190429030003.GJ60332@kduck.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.6.190114 authentication-results: spf=none (sender IP is ) smtp.mailfrom=rrahman@cisco.com; x-originating-ip: [2001:420:2840:1250:2421:2f0a:1dbc:638e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0e0d505c-4171-4200-bdcd-08d6ccddcefa x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(2017052603328)(7193020); SRVR:DM5PR1101MB2188; x-ms-traffictypediagnostic: DM5PR1101MB2188: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0022134A87 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(366004)(396003)(136003)(346002)(51914003)(189003)(199004)(71200400001)(2616005)(71190400001)(58126008)(6486002)(486006)(7736002)(476003)(305945005)(83716004)(6916009)(11346002)(5660300002)(316002)(81156014)(81166006)(8936002)(229853002)(86362001)(76176011)(6436002)(99286004)(91956017)(76116006)(73956011)(102836004)(66476007)(64756008)(66556008)(66946007)(66446008)(46003)(36756003)(82746002)(25786009)(54906003)(97736004)(68736007)(93886005)(6116002)(53546011)(2906002)(14444005)(6506007)(4326008)(53936002)(256004)(6512007)(33656002)(478600001)(6246003)(8676002)(2171002)(186003)(446003)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR1101MB2188; H:DM5PR1101MB2105.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: uXrrSe7MkyCdkpS2llxyuIjxueqN9hns110qnC+gE4GEr6iy4xpk+XDcAmJoQYVCk/nh1hbnhR4MxqxaWof+u9BZAm2Birn6j74q8oGUhPUuuamBUBVY85v3VRjj4W8Km7MtFvd/RvJkErWg6UaqR4HatdAf3+GVMtvekhc48kbF7J9OXGK23tGrzJhblZgT5d8W1ZlqkbzcWGXeIGnDjG/1uv2ceCPmufm98qilFBwUndzc0HjQic2AyCBVLooE4iVmwvweB8zLRO233FBtxt1zHw3dnD6e5j9XSyXHh8rvuKGMgu/EGEZhBAVPt4PV6z0LfWD9idy+Zm50U76q/H8zCJ5L9pt4lwI3NSRGYySHUo+Vqu2jLl7Z+8QB438rS8vXNKu497CpeQCpnIFdv23TKM0jXsyDjRSO6G6tDkg= Content-Type: text/plain; charset="utf-8" Content-ID: <343776AEE8F75E4D8D171FD2514360B5@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0e0d505c-4171-4200-bdcd-08d6ccddcefa X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Apr 2019 20:03:55.0650 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR1101MB2188 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [secdir] [netconf] Secdir last call review of draft-ietf-netconf-restconf-notif-13 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Apr 2019 20:04:01 -0000 T24gMjAxOS0wNC0yOCwgMTE6MDAgUE0sICJCZW5qYW1pbiBLYWR1ayIgPGthZHVrQG1pdC5lZHU+ IHdyb3RlOg0KDQogICAgT24gV2VkLCBBcHIgMjQsIDIwMTkgYXQgMDU6NTM6MDJQTSArMDAwMCwg UmVzaGFkIFJhaG1hbiAocnJhaG1hbikgd3JvdGU6DQogICAgPiBPbiAyMDE5LTA0LTE5LCAxMTo1 NiBQTSwgIkJlbmphbWluIEthZHVrIiA8a2FkdWtAbWl0LmVkdT4gd3JvdGU6DQogICAgPiANCiAg ICA+ICAgICBPbiBGcmksIEFwciAxMiwgMjAxOSBhdCAwOToyOTozNVBNICswMDAwLCBSZXNoYWQg UmFobWFuIChycmFobWFuKSB3cm90ZToNCiAgICA+ICAgICA+IEhpIEFhbmNoYWwsDQogICAgPiAg ICAgPiANCiAgICA+ICAgICA+IFRoYW5rcyBmb3IgdGhlIHJldmlldy4gUGxlYXNlIHNlZSBpbmxp bmUuDQogICAgPiAgICAgPiANCiAgICA+ICAgICA+IE9uIDIwMTktMDQtMTEsIDU6NTQgUE0sICJu ZXRjb25mIG9uIGJlaGFsZiBvZiBBYW5jaGFsIE1hbGhvdHJhIHZpYSBEYXRhdHJhY2tlciIgPG5l dGNvbmYtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygbm9yZXBseUBpZXRmLm9yZz4gd3Jv dGU6DQogICAgPiAgICAgPiANCiAgICA+ICAgICA+ICAgICBSZXZpZXdlcjogQWFuY2hhbCBNYWxo b3RyYQ0KICAgID4gICAgID4gICAgIFJldmlldyByZXN1bHQ6IFJlYWR5DQogICAgPiAgICAgPiAg ICAgDQogICAgPiAgICAgPiAgICAgVGhlIGRvY3VtZW50IGlzIHZlcnkgY2xlYXIgYW5kIGNvbmNp c2UuICBJIGp1c3QgaGF2ZSBvbmUgbWlub3IgY2xhcmlmaWNhdGlvbiBxdWVzdGlvbi4NCiAgICA+ ICAgICA+ICAgICBTZWN0aW9uIDMuNCBQYWdlIDkgdGhhdCBzYXlzIHRoZSBmb2xsb3dpbmc6DQog ICAgPiAgICAgPiAgICAgIkluIGFkZGl0aW9uIHRvIGFueSByZXF1aXJlZCAuLi4uLi4uLlNIT1VM RCBvbmx5IGJlIGFsbG93ZWQuLi4uLi4iLiAgDQogICAgPiAgICAgPiAgICAgDQogICAgPiAgICAg PiAgICAgSXMgdGhlcmUgYSByZWFzb24gZm9yIHVzaW5nIFNIT1VMRCBpbnN0ZWFkIG9mIE1VU1Q/ IA0KICAgID4gICAgID4gDQogICAgPiAgICAgPiBUaGVyZSBtYXkgYmUgcmVhc29ucyB3aHkgYW4g aW1wbGVtZW50YXRpb24gZGVjaWRlcyBub3QgdG8gZW5mb3JjZSB0aGlzIHJlc3RyaWN0aW9uLiBH b2luZyBieSBSRkMyMTE5IGRlZmluaXRpb25zLCB0aGlzIGlzIHdoeSB3ZSBjaG9zZSBTSE9VTEQg aW5zdGVhZCBvZiBNVVNULg0KICAgID4gICAgIA0KICAgID4gICAgIElmIHlvdSBoYXZlIHNvbWUg cmVhc29ucyBpbiBtaW5kLCBpdCBpcyBvZnRlbiBoZWxwZnVsIHRvIGxpc3QgdGhlbSBhcw0KICAg ID4gICAgIGV4YW1wbGVzIG9mIHdoZW4gdGhlIHJlY29tbWVuZGVkIGJlaGF2aW9yIHdvdWxkIG5v dCBiZSBmb2xsb3dlZC4NCiAgICA+IA0KICAgID4gV2hhdCB3ZSBoYWQgaW4gbWluZCBpcyBhICJz dXBlci11c2VyIiB3aG8gY291bGQgYmUgZ2l2ZW4gYWNjZXNzIHRvIHN1YnNjcmlwdGlvbnMgb2Yg b3RoZXIgdXNlcnMuIElzIHRoaXMgb2J2aW91cyBvciBzaG91bGQgSSBjYW4gYWRkIHRleHQgdG8g dGhhdCBlZmZlY3QgYXQgdGhlIGVuZCB0aGUgYnVsbGV0IGJlbG93PyBTb21ldGhpbmcgYWxvbmcg dGhlIGxpbmVzIG9mICJGb3IgZXhhbXBsZSwgYSBSRVNUQ09ORiB1c2VybmFtZSB3aXRoIHRoZSBy ZXF1aXJlZCBhZG1pbmlzdHJhdGl2ZSBwZXJtaXNzaW9ucyBjb3VsZCBiZSBhbGxvd2VkIHRvIGlu dm9rZSBSUENzIG1vZGlmeS1zdWJzY3JpcHRpb24sIHJlc3luYy1zdWJzY3JpcHRpb24gYW5kIGRl bGV0ZS1zdWJzY3JpcHRpb24gb24gYSBzdWJzY3JpcHRpb24gd2hpY2ggd2FzIGNyZWF0ZWQgYnkg YW5vdGhlciB1c2VybmFtZS4iLg0KICAgID4gDQogICAgPiAgICBvICBJbiBhZGRpdGlvbiB0byBh bnkgcmVxdWlyZWQgYWNjZXNzIHBlcm1pc3Npb25zIChlLmcuLCBOQUNNKSwgUlBDcw0KICAgID4g ICAgICAgbW9kaWZ5LXN1YnNjcmlwdGlvbiwgcmVzeW5jLXN1YnNjcmlwdGlvbiBhbmQgZGVsZXRl LXN1YnNjcmlwdGlvbg0KICAgID4gICAgICAgU0hPVUxEIG9ubHkgYmUgYWxsb3dlZCBieSB0aGUg c2FtZSBSRVNUQ09ORiB1c2VybmFtZSBbUkZDODA0MF0NCiAgICA+ICAgICAgIHdoaWNoIGludm9r ZWQgZXN0YWJsaXNoLXN1YnNjcmlwdGlvbi4NCiAgICANCiAgICBJIHRoaW5rIGl0IG1pZ2h0IGhl bHAgdG8gaGF2ZSBzdWNoIHRleHQsIHRob3VnaCBJIHdvdWxkIHN1Z2dlc3QgYSBzbGlnaHRseQ0K ICAgIHBpdGhpZXIgIlN1Y2ggYSByZXN0cmljdGlvbiBnZW5lcmFsbHkgc2VydmVzIHRvIHByZXNl cnZlIHVzZXJzJyBwcml2YWN5LCBidXQNCiAgICBleGNlcHRpb25zIG1pZ2h0IGJlIG1hZGUgZm9y IGFkbWluaXN0cmF0b3JzIHRoYXQgbWF5IG5lZWQgdG8gbW9kaWZ5IG9yDQogICAgZGVsZXRlIG90 aGVyIHVzZXJzJyBzdWJzY3JpcHRpb25zLiINCg0KR29vZCB3aXRoIG1lLCB0aGFua3MuIEknbGwg bWFrZSB0aGlzIGFkZGl0aW9uIGluIHRoZSBuZXh0IHJldi4NCg0KUmVnYXJkcywNClJlc2hhZC4N Cg0KICAgIFRoYW5rcywNCiAgICANCiAgICBCZW4NCiAgICANCg0K From nobody Tue Apr 30 11:05:28 2019 Return-Path: X-Original-To: secdir@ietf.org Delivered-To: secdir@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 515B21202F6; Tue, 30 Apr 2019 11:05:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Nancy Cam-Winget via Datatracker To: Cc: draft-ietf-rtcweb-security.all@ietf.org, rtcweb@ietf.org, ietf@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.95.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Nancy Cam-Winget Message-ID: <155664751524.7509.1436015996023149122@ietfa.amsl.com> Date: Tue, 30 Apr 2019 11:05:15 -0700 Archived-At: Subject: [secdir] Secdir last call review of draft-ietf-rtcweb-security-11 X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Apr 2019 18:05:16 -0000 Reviewer: Nancy Cam-Winget Review result: Has Nits SECDIR review of draft-ietf-rtcweb-security-11 Reviewer: Nancy Cam-Winget Review result: Ready with Nits I have reviewed this document as part of the security directorate'sÊ ongoing effort to review all IETF documents being processed by theÊ IESG.ÊÊThese comments were written primarily for the benefit of theÊ security area directors.ÊÊDocument editors and WG chairs should treatÊ these comments just like any other last call comments. This document defines the threat model and security analysis of WebRTC. There are a few normative clauses to suggest requirements, I think the document could benefit of having more normative requirements to make it a stronger standards track document. Otherwise, it reads more as an informational document. The following are general comments and suggestions (and editorial nits at the end): Section 3. Should it also be noted that as it (browser) has no purview to the actual application running, attacks from the application layer can still occur but is not in scope for WebRTC? Section 4.1 - The conceptual model is a bit confusing, as I think Entity can refer to both the webRTC server as well as the receiving client application? The notion is that the User is trusting the webRTC (client) application (Entity A) to send the media to another user, but really to the receiving application (Entity B). Perhaps model 1 has a typo where the Òtalk toÓ should be Entity B? - The paragraph following the conceptual models is a bit awkward. If I understand correctly, the intent is to state that the user believes Entity A when attempting to call Entity B, Entity A (the client app) could in fact also send it to Entity C? Which is valid, but the writing is awkward as the AÕs, BÕs and CÕs are not explicitly stated as such or at least from the end userÕs viewpoint. - ÒIn either case, all the browser is able to do is verify and check authorization for whoever is controlling where the media goesÓ Is ÒwhoeverÓ meant to be the webRTC application controlling media paths? That should be clarified - ÒÉconsent to access local devices is largely orthogonal to consent to transmitÉÓ It should be both consent to local devices and the deviceÕs resources, unless you mean Òlocal devicesÓ as in camera and microphone; but I think processes and stored or cached files (e.g. other resources) need to be considered too. § - Òconsent to send network traffic is about preventing the userÕs browser from being used to attack its local networkÓ This is true, though, I think you are inferring that the network traffic is enforced to be encrypted, which IÕm not sure is always the case; so I would think it is up to the browser to ensure that this is the case unless the browserÕs policy has made an exception Section 4.1.2.1 ÒÉbug my computerÓ should be clarified. I think there are at least two dimensions to the ÒbugÓ, being it has ÒfreeÓ access to my resources and it can actually potentially ÒlistenÓ to my calls; it could also potentially override the use of my resources. The last sentence on the paragraph ÒNote that question of consentÉ.Ó, the note makes sense, but I am not sure how the last clause ÒÉ.the site is not listening inÓ, can you clarify this? Section 4.1.2.2 ÒÉthe need for a second consentÓ, perhaps it is the need for a ÒdistinctÓ consent as there may not be a previous consent? By ÒdistinctÓ I mean that it is a different type of consent than what may have been granted to the car manuf (in your example) from getting my geolocationÉ.or perhaps I missed the ÒfirstÓ consent type. The last sentence of the paragraph is difficult to parse. I think it is asserting a requirement that the GUI used to launch the call must show the call status (active, continuing, stopped)? This section eludes to granting ÒcallÓ access only for the duration of the call and the access should be limited (Òjust because I want some information on a car doesnÕt meanÉ.Ó); the attack vector should be better highlighted. As I also believe that the browser can only grant the full client application access, so for the duration of the call, it can very well be that the app can get access to my resources beyond just the call (audio only vs. audio + videoÉ.) Section 4.1.3 - The countermeasures can also be combined (e.g. consent is only given to a given user for each call, as well as also having the appropriate keying material). It is subtly eluded to in the 2nd to last paragraph but doesnÕt consider that it can be done for all calls. Section 4.1.4 - It should also be noted that weaknesses in the HTTPS stack can also be exploited (weak authentication or key establishment use) by an attackerÉ.and perhaps should be a MUST enforce strong mutual authentication and key management. Section 4.2.3 - As IÕm unfamiliar to ICE/STUN, IÕm not sure what checks are referred to in ÒÉunsafe to completely remove the requirement for some checkÓ, this should be clarified. Not sure (in the succeeding sentence) if there is a forward reference to proposed checks or if they are listed elsewhere? Section 4.3.1: since the draft is listing requirements, ÒÉ.exchange mechanism imperative forÉÓ The ÒimperativeÓ should be normative ÒMUSTÓ? Section 4.3.2: who is the Òremote endpointÓ? Editorial nits: Section 1. It may be useful to describe why it is Òimmediately apparentÓ that new security challenges resultÉ..suggest remove ÒimmediatelyÓ. Section 4.1.1 (last sentence in the 2nd to last paragraph) is missing a toÕ: Òsophisticated attack would be open up aÓ Section 4.1.3 : ÒNow that we have seen another use caseÓ Seems odd or superfluous. Suggest to just remove that clause or ÒWith the aforementioned use cases, we can startÉ.Ó Section 4.2.1: as it is a first reference, title should call out ÒInteractive Connectivity Establishment (ICE)Ó, same for STUN (and STUNÕs reference, RFC 5389) should be called out. Section 4.2.2 SRTP as a first reference should have its full reference to match the acronym and TURN TCP should have reference too Section 4.2.3 RTCP needs a reference? Section 4.3: is it Òa problem from the SIP worldÓ or Òa problem familiar to the SIP worldÓ? - Extra is Òcalling service is is non-maliciousÓ Section 4.3.1: ÒinÓ should be removed ÒÉ.if end-to-end keying is in usedÓ Section 4.3.2.1: ÒOne natural approach is to use É.Ó, natural approach to what? I think it is to mitigate the during-call attack only? From nobody Tue Apr 30 22:01:16 2019 Return-Path: X-Original-To: secdir@ietfa.amsl.com Delivered-To: secdir@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA9E81200B1; Tue, 30 Apr 2019 22:01:06 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=packetizer.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 XiZoAxtuIxsr; Tue, 30 Apr 2019 22:01:02 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [IPv6:2600:1f18:24d6:2e01:e842:9b2b:72a2:d2c6]) (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 661AC12027E; Tue, 30 Apr 2019 22:01:02 -0700 (PDT) Received: from authuser (localhost [127.0.0.1]) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=packetizer.com; s=dublin; t=1556686858; bh=ltGw5eqAVq1w+FiMnspIlb6YXfHnBvKMvN3agE2WSSI=; h=From:To:Subject:Cc:Date:In-Reply-To:References:Reply-To; b=C1B1KtXtTaMeebrAt3NMiXq0YiSXvosuCncSso9L/fgla8OnnaT6evFRaVuw3iezL bjBrlsA8qKqYFo8rqEtdrethuM8ISk5dPIf4K7YQpdGhY/TNfLb/CM/mlai2dH7N7w YMkDhSKm9Qyx+xzGyObv2uijUqb+VQ6NEGI2oVWg= From: "Paul E. Jones" To: "Vincent Roca" , "David Benham" Cc: secdir@ietf.org, draft-ietf-perc-private-media-framework.all@ietf.org, "The IESG" , aamelnikov@fastmail.fm Date: Wed, 01 May 2019 05:00:55 +0000 Message-Id: In-Reply-To: References: <155014077570.26619.9407568904769535504@ietfa.amsl.com> <6882A552-80DF-4322-9683-13D8E655F2DB@inria.fr> Reply-To: "Paul E. Jones" User-Agent: eM_Client/7.2.34711.0 Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------=_MB68F8FC6C-889A-4BB4-89FE-A532229564CD" Archived-At: Subject: Re: [secdir] Secdir last call review of draft-ietf-perc-private-media-framework X-BeenThere: secdir@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Directorate List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 May 2019 05:01:07 -0000 --------=_MB68F8FC6C-889A-4BB4-89FE-A532229564CD Content-Type: text/plain; format=flowed; charset=utf-8 Content-Transfer-Encoding: quoted-printable Vincent, I was finally able to get back to this and prepare an updated draft. I=20 make changes as outlined below that should appear in -10 shortly. Section 8.1: Will add an introductory sentence. Section 8.1: Good point. That's confusing, as mutual authentication is=20 required in DTLS-SRTP. The value goes beyond cascading, too, and is=20 really a tool to help mitigate against DoS. I'll re-word this paragraph=20 substantially. Section 8.2.2: You're right. I'll make a clear requirement statement on=20 replay protection earlier in the body of the document and update that=20 text. Section 8.2.3: Good point. And there is a limited mitigation for this,=20 which is to re-key the conference periodically. I'll add another=20 paragraph about that, since it might not be obvious. Thanks! Paul ------ Original Message ------ From: "Vincent Roca" To: "David Benham" ; "Paul E. Jones"=20 Cc: "Vincent Roca" ; secdir@ietf.org;=20 draft-ietf-perc-private-media-framework.all@ietf.org; "The IESG"=20 Sent: 3/4/2019 9:02:16 AM Subject: Re: Secdir last call review of=20 draft-ietf-perc-private-media-framework >Hello David, Paul, all, > >I gave a look at version -09 of your I-D, here are a few comments. > >Summary: Almost ready > >** Section 8.1 > There is a sentence introducing section 8.2, but none for section 8.1.= =20 >For instance it is not explicitely >explained what is meant by =C2=AB 3rd party attack =C2=BB. I suggest addin= g a=20 >sentence. > >** Section 8.1 >You=E2=80=99re saying that "If mutual DTLS authentication is not employed= =E2=80=A6 =C2=BB.=20 >Is it really an optional mechanism? >I must admit I haven=E2=80=99t read the rest of your I-D where this is pro= bably=20 >explained, I=E2=80=99m just a bit surprised here. > >** Section 8.2.2 >It is suggested but not clearly said that the replay protection of=20 >Section 3.3.2/[RFC3711] MUST be used. >The sentence can be understood as replay protection is mandatory,=20 >Section 3.3.2 of [RFC3711] is an example >of such a mechanism. >I don't think this is what you mean. > >** Section 8.2.3 >Saying that "The delayed playout attack is a variant of the replay=20 >attack" is IMHO misleading. >Delaying and re-sending a packet already sent are two different attacks=20 >(and the fact that replay >protection is of no help against delayed packets is a good sign of=20 >these differences). >I'd remove this sentence altogether. > > >Otherwise, concerning your previous comment: > > >>Follow up question regarding your general comments on sect 8.1 and 8.2=20 >>which we have not yet addressed in -09 ; >> >> > Attacks of section 8.1 seems more realistic to me than attacks of=20 >>section 8.2 >> > because of a weaker attacker model: the attacker is outside of the=20 >>systems, >> > and not necessarily on the path. >> > Therefore I would have liked to see more details in section 8.1,=20 >>that=E2=80=99s all. >> >>You're asking for greater detail in sect 8.1 precisely because you=20 >>estimate that third-party attacks (aka outsiders to a given=20 >>conference) are more likely/common than the attacks we covered in the=20 >>subsequent 8.2 section. Is that correct? >> >>If so, I think we could restate some of what we have in sect 8.1 to=20 >>make it flow better and/or be clearer. But it is not clear to us=20 >>what we left out detail-wise, or if we left out other attack examples. >> >>With PERC's HBH integrity checks, authentication as well as HBH and=20 >>E2E encryption, we can quickly describe in text the=20 >>prevention/mitigation of attacks on the confidentiality of the=20 >>media/content - PERCs reason to be - to explain some of the brevity. >> >>Could you help point us in the right direction with an example or two=20 >>of the things we should do to detail/elaborate sect 8.1. > >[VR] I was surprised to see for instance 8 lines of text in section=20 >8.2.2 or 8.2.4 to describe attacks >that cannot take place because of the PERC design. That being said, I=20 >see that version -09 has a >more detailed section 8.1 which is fine. > >Cheers, > > Vincent --------=_MB68F8FC6C-889A-4BB4-89FE-A532229564CD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Vincent,

I was finally able to get back to thi= s and prepare an updated draft. =C2=A0I make changes as outlined below that = should appear in -10 shortly.

Section 8.1: Will = add an introductory sentence.
Section 8.1:=C2=A0Good point. That= 's confusing, as mutual authentication is required in DTLS-SRTP. The value= goes beyond cascading, too, and is really a tool to help mitigate against D= oS. =C2=A0I'll re-word this paragraph substantially.
Section 8.2.= 2: You're right. I'll make a clear requirement statement on replay protecti= on earlier in the body of the document and update that text.
Sect= ion 8.2.3: Good point. And there is a limited mitigation for this, which is = to re-key the conference periodically. =C2=A0I'll add another paragraph ab= out that, since it might not be obvious.

Thanks!=
Paul

------ Original Message ------
From: "Vincent Roca" <vinc= ent.roca@inria.fr>
To: "David Benham" <dabenham@= gmail.com>; "Paul E. Jones" <paulej@packetizer.com>
Sent: 3/4/2019 9:02:16 AM
Subject: Re: Secdir last call review of draft-ietf-perc-private-media-= framework

Hello David, Paul, all,

I gave a look at version -09 of your I-D, here are a few comments.
=

Summary:=C2=A0Almost ready

** Section 8.1
=C2= =A0There is a sentence introducing section 8.2, but none for section 8.1. F= or instance it is not explicitely
explained what is me= ant by =C2=AB=C2=A03rd party attack=C2=A0=C2=BB. I suggest adding a sentenc= e.

** Sec= tion 8.1
You=E2=80=99re saying that "If mutual DTLS au= thentication is not employed=E2=80=A6=C2=A0=C2=BB. Is it really an optional = mechanism?
I must admit I haven=E2=80=99t read the re= st of your I-D where this is probably explained, I=E2=80=99m just a bit sur= prised here.

** Section 8.2.2
It is suggested but not = clearly said that the replay protection of Section 3.3.2/[RFC3711] MUST be = used.
The sentence can be understood as replay protec= tion is mandatory, Section 3.3.2 of [RFC3711] is an example
of such a mechanism.
I don't think this is what= you mean.

** Se= ction 8.2.3
Saying that "The delayed playout attack is = a variant of the replay attack" is IMHO misleading.
D= elaying and re-sending a packet already sent are two different attacks (and = the fact that replay
protection is of no help against = delayed packets is a good sign of these differences).
I'd remove this sentence altogether.


Otherw= ise, concerning your previous comment:


<= div dir=3D"ltr" class=3D"">
Foll= ow up question regarding your general comments on sect 8.1 and 8.2 which we = have not yet addressed in -09 ;

> Attacks of section 8.1 seems more realistic to me th= an attacks of section 8.2
> because of a weaker attacker = model: the attacker is outside of the systems,
> and n= ot necessarily on the path.=C2=A0=C2=A0
> Therefore I would have liked to see more details in section 8.1, th= at=E2=80=99s all.

<= div class=3D"">You're asking for greater detail in sect 8.1 precisely becau= se you estimate that third-party attacks (aka outsiders to a given conferen= ce) are more likely/common than the attacks we covered in the subsequent 8.= 2 section.=C2=A0 =C2=A0Is that=C2=A0correct?

If so, I think we could restate some of what= we have in sect 8.1 to make it flow better and/or be clearer.=C2=A0 =C2=A0B= ut it is not clear to us what we left out detail-wise, or if we left out ot= her attack examples.

With PERC's HBH=C2=A0integrity checks,=C2=A0authentication as well as HBH and E2E encryption, we can quickly desc= ribe in text the prevention/mitigation of attacks on the=C2=A0confidentiali= ty of the media/content - PERCs reason to be - to explain some of the brevi= ty.=C2=A0

Could you help point us in the right direct= ion with an example or two of the things we should do to detail/elaborate s= ect 8.1.

[VR] I was surprised to see for instance 8 lines of text in = section 8.2.2 or 8.2.4 to describe attacks
that cannot take plac= e because of the PERC design. That being said, I see that version -09 has a=
more detailed section 8.1 which is fine.

Cheers,

=C2=A0 =C2=A0V= incent
--------=_MB68F8FC6C-889A-4BB4-89FE-A532229564CD--