From nobody Fri Nov 3 06:07:26 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB2D13FE2B for ; Fri, 3 Nov 2017 06:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.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 tWsu-r6L20BM for ; Fri, 3 Nov 2017 06:07:21 -0700 (PDT) Received: from mail1.protonmail.ch (mail1.protonmail.ch [185.70.40.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 4A98113FE27 for ; Fri, 3 Nov 2017 06:07:20 -0700 (PDT) Date: Fri, 03 Nov 2017 09:07:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1509714434; bh=YmIkRADmSVWsxxA+wuKmEF8V0YDI3UwB5dQkH7Eksk8=; h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: From; b=b0GgLWgUCD6YP+mh5h9DhzcOakpFh9cFC0LI22Uh0qKKht+0LoZ/PBOcrpxsWI42U /DGpkvopqs2vcs/pP3jfGsNeVGohKePQd6lVKYlbs+ROvrA6RikTXon7uc3DHDP1kP sJ9cZnhD26EEhOMhL5ZMWIX6dQPNlxf0UTq32N3g= To: SAAG From: Bob Reply-To: Bob Message-ID: In-Reply-To: References: Feedback-ID: vEY7k4yIhKH60ezyh_ewYb5cBh9lM6d5hXuAKmMcj-2yeFvumZUf2Q6AIaPs9viRuOL95Jg0-5_mTgpMVWHl3Q==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_4a98e7935a5c8876bf37bef6d70e1f0d" Archived-At: Subject: [saag] Fw: [internet-draft-draft] ParrotTalk: Anonymous P2P encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Nov 2017 13:07:24 -0000 This is a multi-part message in MIME format. --b1_4a98e7935a5c8876bf37bef6d70e1f0d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 R29vZCBtb3JuaW5nLAoKSSBhbSBmb3J3YXJkaW5nIHRoaXMgYW5ub3VuY2VtZW50IG9mIHRoZSBQ YXJyb3RUYWxrIHYzLjYgc3BlY2lmaWNhdGlvbiBhbmQgMiByZWZlcmVuY2UgaW1wbGVtZW50YXRp b25zLCBpbiBTcXVlYWsvUGhhcm8gYW5kIEphdmEsIHRvIHRoZSBTQUFHIGxpc3QuIEkgd2FzIGFk dmlzZWQgdGhhdCB0aGlzIG1haWxpbmcgbGlzdCByZWdhcmRpbmcgdGhlIFNlY3VyaXR5IEFyZWEg aXMgdGhlIGNvcnJlY3QgaG9tZSBmb3IgdGhpcyBhbm5vdW5jZW1lbnQuIEJlbG93LCBJIGNvcnJl Y3RlZCB0aGUgdmVyc2lvbiBvZiB0aGUgU3F1ZWFrL1BoYXJvIFBhcnJvdFRhbGsgY29kZSB0byB2 ZXJzaW9uIDExLCBpbnRlcm9wZXJhYmxlIHdpdGggdGhlIEphdmEgdmVyc2lvbi4gSSBhbSBwcm9j ZWVkaW5nIHRvIHdvcmsgb24gdGhlIEludGVybmV0LURyYWZ0IGFuZCBJIGhvcGUgc29tZSBkaXNj dXNzaW9uIGJ1aWxkcyBhcm91bmQgdGhpcyB3b3JrLgoKVGhhbmsgeW91LgotLS0KUm9iZXJ0Cgo+ IC0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS0KPiBTdWJqZWN0OiBbaW50ZXJuZXQt ZHJhZnQtZHJhZnRdIFBhcnJvdFRhbGs6IEFub255bW91cyBQMlAgZW5jcnlwdGlvbgo+IExvY2Fs IFRpbWU6IE5vdmVtYmVyIDIsIDIwMTcgOToxOSBQTQo+IFVUQyBUaW1lOiBOb3ZlbWJlciAzLCAy MDE3IDE6MTkgQU0KPiBGcm9tOiBoZW5yeUBjYWxsaXN0b2hvdXNlLmNsdWIKPiBUbzogSUVURiA8 aWV0ZkBpZXRmLm9yZz4KPgo+IEkgaGF2ZSBkZXZlbG9wZWQgdGhlIFBhcnJvdFRhbGsgUHJvdG9j b2wsIGFuZCBhbSBzdGFydGluZyBhbiBpbnRlcm5ldCBkcmFmdCBkb2N1bWVudFsxXSBmb3Igc3Vi bWlzc2lvbiB0byB0aGUgcHJvY2VzcyBhdCBJRVRGLgo+Cj4gUGFycm90VGFsayBQcm90b2NvbCBp cyBkb2N1bWVudGVkIGluIHBhcnQgaGVyZVsyXSwgd2hpbGUgSSBoYXZlIHR3byBpbXBsZW1lbnRh dGlvbnM6IDEgaW4gU3F1ZWFrL1BoYXJvWzMgYS9iXSBhbmQgdGhlIG90aGVyIGluIEphdmFbNCBh L2JdLiBUaGUgcGFydGljdWxhcnMgb2YgTUFDIGtleSBhbmQgaXZTZXF1ZW5jZSBkZXJpdmF0aW9u LCBhcyB3ZWxsIGFzIGNvbnN0cmFpbmVkIHRyYWZmaWMgc2lnbmluZywgYXJlIHRoZSBpbXBsZW1l bnRhdGlvbnMsIHlldCBtaXNzaW5nIGZyb20gdGhlIHNwZWNpZmljYXRpb24uIFRoZXkgd2lsbCBi ZSBhZGRlZCB0byB0aGUgaW50ZXJuZXQtZHJhZnQuCj4KPiBIb3cgZG8gSSBnbyBhYm91dCBzdWJt aXR0aW5nIGEgc3BlY2lmaWNhdGlvbiBmb3IgUGFycm90VGFsayBmb3IgSUVURiByZXZpZXcgYW5k IGNvbnNpZGVyYXRpb24/Cj4KPiBUaGFuayB5b3UuCj4KPiAtIFJvYmVydAo+Cj4gWzFdIElFVEYg SS1EIGRyYWZ0IC0gaHR0cDovL2ptcC5zaC9WUmVqUzJnCj4KPiBbMl0gUGFycm90VGFsayBGcmFt ZSBEZXNpZ24gLSBodHRwOi8vam1wLnNoL09xbFlweWcKPgo+IFszIGFdIFNxdWVhay9QaGFybyBD cnlwdG9ncmFwaHkgbGlicmFyeSAtIGh0dHA6Ly93d3cuc3F1ZWFrc291cmNlLmNvbS9DcnlwdG9n cmFwaHkvQ3J5cHRvZ3JhcGh5LUhlbnJ5SG91c2UuMTEzLm1jego+IFszIGJdIFNxdWVhay9QaGFy byBQYXJyb3RUYWxrIHYzLjYgLSBbaHR0cDovL3d3dy5zcXVlYWtzb3VyY2UuY29tL0NyeXB0b2dy YXBoeS9QYXJyb3RUYWxrLUhlbnJ5SG91c2UuMTEubWN6XShodHRwOi8vd3d3LnNxdWVha3NvdXJj ZS5jb20vQ3J5cHRvZ3JhcGh5L1BhcnJvdFRhbGstSGVucnlIb3VzZS45Lm1jeikKPgo+IFs0IGFd IEphdmEgQVNOMSBmcmFtZXdvcmsgLSBodHRwczovL2dpdGh1Yi5jb20vWmlyb1ppbWJhcnJhL0FT TjEKPiBbNCBiXSBKYXZhIFBhcnJvdFRhbGsgdjMuNiAtIGh0dHBzOi8vZ2l0aHViLmNvbS9aaXJv WmltYmFycmEvUGFycm90VGFsaw== --b1_4a98e7935a5c8876bf37bef6d70e1f0d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdj5Hb29kIG1vcm5pbmcsPGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+SSBhbSBmb3J3 YXJkaW5nIHRoaXMgYW5ub3VuY2VtZW50IG9mIHRoZSBQYXJyb3RUYWxrIHYzLjYgc3BlY2lmaWNh dGlvbiBhbmQgMiByZWZlcmVuY2UgaW1wbGVtZW50YXRpb25zLCBpbiBTcXVlYWsvUGhhcm8gYW5k IEphdmEsIHRvIHRoZSBTQUFHIGxpc3QuIEkgd2FzIGFkdmlzZWQgdGhhdCB0aGlzIG1haWxpbmcg bGlzdCByZWdhcmRpbmcgdGhlIFNlY3VyaXR5IEFyZWEgaXMgdGhlIGNvcnJlY3QgaG9tZSBmb3Ig dGhpcyBhbm5vdW5jZW1lbnQuIEJlbG93LCBJIGNvcnJlY3RlZCB0aGUgdmVyc2lvbiBvZiB0aGUg U3F1ZWFrL1BoYXJvIFBhcnJvdFRhbGsgY29kZSB0byB2ZXJzaW9uIDExLCBpbnRlcm9wZXJhYmxl IHdpdGggdGhlIEphdmEgdmVyc2lvbi4gSSBhbSBwcm9jZWVkaW5nIHRvIHdvcmsgb24gdGhlIElu dGVybmV0LURyYWZ0IGFuZCBJIGhvcGUgc29tZSBkaXNjdXNzaW9uIGJ1aWxkcyBhcm91bmQgdGhp cyB3b3JrLjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoYW5rIHlvdS48YnI+PC9kaXY+ PGRpdiBjbGFzcz0icHJvdG9ubWFpbF9zaWduYXR1cmVfYmxvY2siPjxkaXYgY2xhc3M9InByb3Rv bm1haWxfc2lnbmF0dXJlX2Jsb2NrLXVzZXIiPjxkaXY+LS0tPGJyPjwvZGl2PjxkaXY+Um9iZXJ0 PGJyPjwvZGl2PjwvZGl2PjxkaXYgY2xhc3M9InByb3Rvbm1haWxfc2lnbmF0dXJlX2Jsb2NrLXBy b3RvbiBwcm90b25tYWlsX3NpZ25hdHVyZV9ibG9jay1lbXB0eSI+PGJyPjwvZGl2PjwvZGl2Pjxk aXY+PGJyPjwvZGl2PjxibG9ja3F1b3RlIGNsYXNzPSJwcm90b25tYWlsX3F1b3RlIiB0eXBlPSJj aXRlIj48ZGl2Pi0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS08YnI+PC9kaXY+PGRp dj5TdWJqZWN0OiBbaW50ZXJuZXQtZHJhZnQtZHJhZnRdIFBhcnJvdFRhbGs6IEFub255bW91cyBQ MlAgZW5jcnlwdGlvbjxicj48L2Rpdj48ZGl2PkxvY2FsIFRpbWU6IE5vdmVtYmVyIDIsIDIwMTcg OToxOSBQTTxicj48L2Rpdj48ZGl2PlVUQyBUaW1lOiBOb3ZlbWJlciAzLCAyMDE3IDE6MTkgQU08 YnI+PC9kaXY+PGRpdj5Gcm9tOiBoZW5yeUBjYWxsaXN0b2hvdXNlLmNsdWI8YnI+PC9kaXY+PGRp dj5UbzogSUVURiAmbHQ7aWV0ZkBpZXRmLm9yZyZndDs8YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+ PGRpdj48ZGl2PkkKIGhhdmUgZGV2ZWxvcGVkIHRoZSBQYXJyb3RUYWxrIFByb3RvY29sLCBhbmQg YW0gc3RhcnRpbmcgYW4gaW50ZXJuZXQgZHJhZnQgZG9jdW1lbnRbMV0gZm9yIHN1Ym1pc3Npb24g dG8gdGhlIHByb2Nlc3MgYXQgSUVURi48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5QYXJy b3RUYWxrIFByb3RvY29sIGlzIGRvY3VtZW50ZWQgaW4gcGFydCBoZXJlWzJdLCAKd2hpbGUgSSBo YXZlIHR3byBpbXBsZW1lbnRhdGlvbnM6IDEgaW4gU3F1ZWFrL1BoYXJvWzMgYS9iXSZuYnNwO2Fu ZCB0aGUgCm90aGVyIGluIEphdmFbNCBhL2JdLiBUaGUgcGFydGljdWxhcnMgb2YgTUFDIGtleSBh bmQgaXZTZXF1ZW5jZSBkZXJpdmF0aW9uLAogYXMgd2VsbCBhcyBjb25zdHJhaW5lZCZuYnNwO3Ry YWZmaWMKICAgIHNpZ25pbmcsIGFyZSB0aGUgaW1wbGVtZW50YXRpb25zLCB5ZXQgbWlzc2luZyBm cm9tIHRoZSBzcGVjaWZpY2F0aW9uLiBUaGV5IHdpbGwgYmUgYWRkZWQgdG8gdGhlIGludGVybmV0 LWRyYWZ0Ljxicj48L2Rpdj48L2Rpdj48ZGl2IGNsYXNzPSJmcmFtZSBtZXNzYWdlLWZyYW1lIiBk YXRhLWVtYmVkZGVkLWltZy1sb2FkZXI9IiIgZGF0YS1pbmplY3QtbWVzc2FnZS1tZWRpYT0iIj48 ZGl2IGNsYXNzPSJib2R5RGVjcnlwdGVkIGVtYWlsIG1lc3NhZ2UtYm9keS1jb250YWluZXIiPjxk aXY+PGJyPjwvZGl2PjxkaXY+SG93IGRvIEkgZ28gYWJvdXQgc3VibWl0dGluZyBhIHNwZWNpZmlj YXRpb24gZm9yIFBhcnJvdFRhbGsgZm9yIElFVEYgcmV2aWV3IGFuZCBjb25zaWRlcmF0aW9uPzxi cj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoYW5rIHlvdS48YnI+PC9kaXY+PGRpdj48YnI+ PC9kaXY+PGRpdiBjbGFzcz0icHJvdG9ubWFpbF9zaWduYXR1cmVfYmxvY2siPi0gUm9iZXJ0PGJy PjwvZGl2PjxkaXYgY2xhc3M9InByb3Rvbm1haWxfc2lnbmF0dXJlX2Jsb2NrIj48YnI+PC9kaXY+ PGRpdiBjbGFzcz0icHJvdG9ubWFpbF9zaWduYXR1cmVfYmxvY2siPlsxXSBJRVRGIEktRCBkcmFm dCAtIDxhIGhyZWY9Imh0dHA6Ly9qbXAuc2gvVlJlalMyZyI+aHR0cDovL2ptcC5zaC9WUmVqUzJn PC9hPjxicj48L2Rpdj48ZGl2IGNsYXNzPSJwcm90b25tYWlsX3NpZ25hdHVyZV9ibG9jayI+PGRp dj48YnI+PC9kaXY+PGRpdj5bMl0gUGFycm90VGFsayBGcmFtZSBEZXNpZ24gLSZuYnNwOzxhIHJl bD0ibm9yZWZlcnJlciBub2ZvbGxvdyBub29wZW5lciIgaHJlZj0iaHR0cDovL2ptcC5zaC9PcWxZ cHlnIiBzdHlsZT0iZm9udC1zaXplOiAxZW07Ij5odHRwOi8vam1wLnNoL09xbFlweWc8L2E+PGJy PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+WzMgYV0gU3F1ZWFrL1BoYXJvIENyeXB0b2dyYXBo eSBsaWJyYXJ5IC0mbmJzcDs8YSBzdHlsZT0iZm9udC1zaXplOiAxZW07IiBocmVmPSJodHRwOi8v d3d3LnNxdWVha3NvdXJjZS5jb20vQ3J5cHRvZ3JhcGh5L0NyeXB0b2dyYXBoeS1IZW5yeUhvdXNl LjExMy5tY3oiIHJlbD0ibm9yZWZlcnJlciBub2ZvbGxvdyBub29wZW5lciI+aHR0cDovL3d3dy5z cXVlYWtzb3VyY2UuY29tL0NyeXB0b2dyYXBoeS9DcnlwdG9ncmFwaHktSGVucnlIb3VzZS4xMTMu bWN6PC9hPjxicj48L2Rpdj48L2Rpdj48ZGl2IGNsYXNzPSJwcm90b25tYWlsX3NpZ25hdHVyZV9i bG9jayI+WzMgYl0gU3F1ZWFrL1BoYXJvIFBhcnJvdFRhbGsgdjMuNiAtJm5ic3A7PGEgc3R5bGU9 ImZvbnQtc2l6ZTogMWVtOyIgaHJlZj0iaHR0cDovL3d3dy5zcXVlYWtzb3VyY2UuY29tL0NyeXB0 b2dyYXBoeS9QYXJyb3RUYWxrLUhlbnJ5SG91c2UuOS5tY3oiIHJlbD0ibm9yZWZlcnJlciBub2Zv bGxvdyBub29wZW5lciI+aHR0cDovL3d3dy5zcXVlYWtzb3VyY2UuY29tL0NyeXB0b2dyYXBoeS9Q YXJyb3RUYWxrLUhlbnJ5SG91c2UuMTEubWN6PC9hPjxicj48L2Rpdj48ZGl2IGNsYXNzPSJwcm90 b25tYWlsX3NpZ25hdHVyZV9ibG9jayI+PGJyPjwvZGl2PjxkaXYgY2xhc3M9InByb3Rvbm1haWxf c2lnbmF0dXJlX2Jsb2NrIj5bNCBhXSBKYXZhIEFTTjEgZnJhbWV3b3JrIC0mbmJzcDs8YSBzdHls ZT0iZm9udC1zaXplOiAxZW07IiBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vWmlyb1ppbWJhcnJh L0FTTjEiIHJlbD0ibm9yZWZlcnJlciBub2ZvbGxvdyBub29wZW5lciI+aHR0cHM6Ly9naXRodWIu Y29tL1ppcm9aaW1iYXJyYS9BU04xPC9hPjxicj48L2Rpdj48ZGl2IGNsYXNzPSJwcm90b25tYWls X3NpZ25hdHVyZV9ibG9jayI+WzQgYl0gSmF2YSBQYXJyb3RUYWxrIHYzLjYgLSZuYnNwOzxhIHN0 eWxlPSJmb250LXNpemU6IDFlbTsiIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9aaXJvWmltYmFy cmEvUGFycm90VGFsayIgcmVsPSJub3JlZmVycmVyIG5vZm9sbG93IG5vb3BlbmVyIj5odHRwczov L2dpdGh1Yi5jb20vWmlyb1ppbWJhcnJhL1BhcnJvdFRhbGs8L2E+PGJyPjwvZGl2PjwvZGl2Pjwv ZGl2PjxkaXY+PGJyPjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj4= --b1_4a98e7935a5c8876bf37bef6d70e1f0d-- From nobody Sat Nov 4 10:56:52 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A72C513FBB8 for ; Sat, 4 Nov 2017 10:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, TO_EQ_FM_DIRECT_MX=0.622] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.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 c2ibEXeIQCBX for ; Sat, 4 Nov 2017 10:56:46 -0700 (PDT) Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.22]) (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 4642D13FBC2 for ; Sat, 4 Nov 2017 10:56:45 -0700 (PDT) Date: Sat, 04 Nov 2017 13:56:36 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1509818199; bh=unb+z/tEZo4bY9zoSYPVIVil/wVMeoyPNU4hTmvLnnk=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=r5478uuGu2E7y83MN1DS/tGStUIidKoPMRN988TJ/GivelERalZNLAG4HthkIXCwf dJbQttSGF+WqNpIrU3lpfgl131nuEA01xNDSYglFhqHsT2DAJfy7P4R5gq2TVU/s3R nvb4jh+sNOqE8nGp+Wq9cKI1HKUFsvcPP0QrvMO0= To: Bob From: Bob Cc: SAAG Reply-To: Bob Message-ID: In-Reply-To: References: Feedback-ID: vEY7k4yIhKH60ezyh_ewYb5cBh9lM6d5hXuAKmMcj-2yeFvumZUf2Q6AIaPs9viRuOL95Jg0-5_mTgpMVWHl3Q==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="b1_e5f255c23e4c2e3641205beb8ff9291b" Archived-At: Subject: Re: [saag] Fw: [internet-draft-draft] ParrotTalk: Anonymous P2P encryption X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Nov 2017 17:56:51 -0000 This is a multi-part message in MIME format. --b1_e5f255c23e4c2e3641205beb8ff9291b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SSB1cGRhdGVkIHRoZSBJLUQgbG9jYXRlZCBoZXJlOiBodHRwOi8vam1wLnNoL1ZSZWpTMmcKClRo YW5rIHlvdSBmb3IgeW91ciBjb25zaWRlcmF0aW9uLAotLS0KUm9iZXJ0Cgo+IC0tLS0tLS0tIE9y aWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS0KPiBTdWJqZWN0OiBbc2FhZ10gRnc6IFtpbnRlcm5ldC1k cmFmdC1kcmFmdF0gUGFycm90VGFsazogQW5vbnltb3VzIFAyUCBlbmNyeXB0aW9uCj4gTG9jYWwg VGltZTogTm92ZW1iZXIgMywgMjAxNyA5OjA3IEFNCj4gVVRDIFRpbWU6IE5vdmVtYmVyIDMsIDIw MTcgMTowNyBQTQo+IEZyb206IHJvYmVydC53aXRoZXJzQHByb3Rvbm1haWwuY29tCj4gVG86IFNB QUcgPHNhYWdAaWV0Zi5vcmc+Cj4KPiBHb29kIG1vcm5pbmcsCj4KPiBJIGFtIGZvcndhcmRpbmcg dGhpcyBhbm5vdW5jZW1lbnQgb2YgdGhlIFBhcnJvdFRhbGsgdjMuNiBzcGVjaWZpY2F0aW9uIGFu ZCAyIHJlZmVyZW5jZSBpbXBsZW1lbnRhdGlvbnMsIGluIFNxdWVhay9QaGFybyBhbmQgSmF2YSwg dG8gdGhlIFNBQUcgbGlzdC4gSSB3YXMgYWR2aXNlZCB0aGF0IHRoaXMgbWFpbGluZyBsaXN0IHJl Z2FyZGluZyB0aGUgU2VjdXJpdHkgQXJlYSBpcyB0aGUgY29ycmVjdCBob21lIGZvciB0aGlzIGFu bm91bmNlbWVudC4gQmVsb3csIEkgY29ycmVjdGVkIHRoZSB2ZXJzaW9uIG9mIHRoZSBTcXVlYWsv UGhhcm8gUGFycm90VGFsayBjb2RlIHRvIHZlcnNpb24gMTEsIGludGVyb3BlcmFibGUgd2l0aCB0 aGUgSmF2YSB2ZXJzaW9uLiBJIGFtIHByb2NlZWRpbmcgdG8gd29yayBvbiB0aGUgSW50ZXJuZXQt RHJhZnQgYW5kIEkgaG9wZSBzb21lIGRpc2N1c3Npb24gYnVpbGRzIGFyb3VuZCB0aGlzIHdvcmsu Cj4KPiBUaGFuayB5b3UuCj4gLS0tCj4gUm9iZXJ0Cj4KPj4gLS0tLS0tLS0gT3JpZ2luYWwgTWVz c2FnZSAtLS0tLS0tLQo+PiBTdWJqZWN0OiBbaW50ZXJuZXQtZHJhZnQtZHJhZnRdIFBhcnJvdFRh bGs6IEFub255bW91cyBQMlAgZW5jcnlwdGlvbgo+PiBMb2NhbCBUaW1lOiBOb3ZlbWJlciAyLCAy MDE3IDk6MTkgUE0KPj4gVVRDIFRpbWU6IE5vdmVtYmVyIDMsIDIwMTcgMToxOSBBTQo+PiBGcm9t OiBoZW5yeUBjYWxsaXN0b2hvdXNlLmNsdWIKPj4gVG86IElFVEYgPGlldGZAaWV0Zi5vcmc+Cj4+ Cj4+IEkgaGF2ZSBkZXZlbG9wZWQgdGhlIFBhcnJvdFRhbGsgUHJvdG9jb2wsIGFuZCBhbSBzdGFy dGluZyBhbiBpbnRlcm5ldCBkcmFmdCBkb2N1bWVudFsxXSBmb3Igc3VibWlzc2lvbiB0byB0aGUg cHJvY2VzcyBhdCBJRVRGLgo+Pgo+PiBQYXJyb3RUYWxrIFByb3RvY29sIGlzIGRvY3VtZW50ZWQg aW4gcGFydCBoZXJlWzJdLCB3aGlsZSBJIGhhdmUgdHdvIGltcGxlbWVudGF0aW9uczogMSBpbiBT cXVlYWsvUGhhcm9bMyBhL2JdIGFuZCB0aGUgb3RoZXIgaW4gSmF2YVs0IGEvYl0uIFRoZSBwYXJ0 aWN1bGFycyBvZiBNQUMga2V5IGFuZCBpdlNlcXVlbmNlIGRlcml2YXRpb24sIGFzIHdlbGwgYXMg Y29uc3RyYWluZWQgdHJhZmZpYyBzaWduaW5nLCBhcmUgdGhlIGltcGxlbWVudGF0aW9ucywgeWV0 IG1pc3NpbmcgZnJvbSB0aGUgc3BlY2lmaWNhdGlvbi4gVGhleSB3aWxsIGJlIGFkZGVkIHRvIHRo ZSBpbnRlcm5ldC1kcmFmdC4KPj4KPj4gSG93IGRvIEkgZ28gYWJvdXQgc3VibWl0dGluZyBhIHNw ZWNpZmljYXRpb24gZm9yIFBhcnJvdFRhbGsgZm9yIElFVEYgcmV2aWV3IGFuZCBjb25zaWRlcmF0 aW9uPwo+Pgo+PiBUaGFuayB5b3UuCj4+Cj4+IC0gUm9iZXJ0Cj4+Cj4+IFsxXSBJRVRGIEktRCBk cmFmdCAtIGh0dHA6Ly9qbXAuc2gvVlJlalMyZwo+Pgo+PiBbMl0gUGFycm90VGFsayBGcmFtZSBE ZXNpZ24gLSBodHRwOi8vam1wLnNoL09xbFlweWcKPj4KPj4gWzMgYV0gU3F1ZWFrL1BoYXJvIENy eXB0b2dyYXBoeSBsaWJyYXJ5IC0gaHR0cDovL3d3dy5zcXVlYWtzb3VyY2UuY29tL0NyeXB0b2dy YXBoeS9DcnlwdG9ncmFwaHktSGVucnlIb3VzZS4xMTMubWN6Cj4+IFszIGJdIFNxdWVhay9QaGFy byBQYXJyb3RUYWxrIHYzLjYgLSBbaHR0cDovL3d3dy5zcXVlYWtzb3VyY2UuY29tL0NyeXB0b2dy YXBoeS9QYXJyb3RUYWxrLUhlbnJ5SG91c2UuMTEubWN6XShodHRwOi8vd3d3LnNxdWVha3NvdXJj ZS5jb20vQ3J5cHRvZ3JhcGh5L1BhcnJvdFRhbGstSGVucnlIb3VzZS45Lm1jeikKPj4KPj4gWzQg YV0gSmF2YSBBU04xIGZyYW1ld29yayAtIGh0dHBzOi8vZ2l0aHViLmNvbS9aaXJvWmltYmFycmEv QVNOMQo+PiBbNCBiXSBKYXZhIFBhcnJvdFRhbGsgdjMuNiAtIGh0dHBzOi8vZ2l0aHViLmNvbS9a aXJvWmltYmFycmEvUGFycm90VGFsaw== --b1_e5f255c23e4c2e3641205beb8ff9291b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdj5JIHVwZGF0ZWQgdGhlIEktRCBsb2NhdGVkIGhlcmU6IDxhIGhyZWY9Imh0dHA6Ly9qbXAu c2gvVlJlalMyZyI+aHR0cDovL2ptcC5zaC9WUmVqUzJnPC9hPjxicj48L2Rpdj48ZGl2Pjxicj48 L2Rpdj48ZGl2PlRoYW5rIHlvdSBmb3IgeW91ciBjb25zaWRlcmF0aW9uLDxicj48L2Rpdj48ZGl2 IGNsYXNzPSJwcm90b25tYWlsX3NpZ25hdHVyZV9ibG9jayI+PGRpdiBjbGFzcz0icHJvdG9ubWFp bF9zaWduYXR1cmVfYmxvY2stdXNlciI+PGRpdj4tLS08YnI+PC9kaXY+PGRpdj5Sb2JlcnQ8YnI+ PC9kaXY+PC9kaXY+PGRpdiBjbGFzcz0icHJvdG9ubWFpbF9zaWduYXR1cmVfYmxvY2stcHJvdG9u IHByb3Rvbm1haWxfc2lnbmF0dXJlX2Jsb2NrLWVtcHR5Ij48YnI+PC9kaXY+PC9kaXY+PGRpdj48 YnI+PC9kaXY+PGJsb2NrcXVvdGUgY2xhc3M9InByb3Rvbm1haWxfcXVvdGUiIHR5cGU9ImNpdGUi PjxkaXY+LS0tLS0tLS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLS0tLTxicj48L2Rpdj48ZGl2PlN1 YmplY3Q6IFtzYWFnXSBGdzogW2ludGVybmV0LWRyYWZ0LWRyYWZ0XSBQYXJyb3RUYWxrOiBBbm9u eW1vdXMgUDJQIGVuY3J5cHRpb248YnI+PC9kaXY+PGRpdj5Mb2NhbCBUaW1lOiBOb3ZlbWJlciAz LCAyMDE3IDk6MDcgQU08YnI+PC9kaXY+PGRpdj5VVEMgVGltZTogTm92ZW1iZXIgMywgMjAxNyAx OjA3IFBNPGJyPjwvZGl2PjxkaXY+RnJvbTogcm9iZXJ0LndpdGhlcnNAcHJvdG9ubWFpbC5jb208 YnI+PC9kaXY+PGRpdj5UbzogU0FBRyAmbHQ7c2FhZ0BpZXRmLm9yZyZndDs8YnI+PC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdj5Hb29kIG1vcm5pbmcsPGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2Pjxk aXY+SSBhbSBmb3J3YXJkaW5nIHRoaXMgYW5ub3VuY2VtZW50IG9mIHRoZSBQYXJyb3RUYWxrIHYz LjYgc3BlY2lmaWNhdGlvbiBhbmQgMiByZWZlcmVuY2UgaW1wbGVtZW50YXRpb25zLCBpbiBTcXVl YWsvUGhhcm8gYW5kIEphdmEsIHRvIHRoZSBTQUFHIGxpc3QuIEkgd2FzIGFkdmlzZWQgdGhhdCB0 aGlzIG1haWxpbmcgbGlzdCByZWdhcmRpbmcgdGhlIFNlY3VyaXR5IEFyZWEgaXMgdGhlIGNvcnJl Y3QgaG9tZSBmb3IgdGhpcyBhbm5vdW5jZW1lbnQuIEJlbG93LCBJIGNvcnJlY3RlZCB0aGUgdmVy c2lvbiBvZiB0aGUgU3F1ZWFrL1BoYXJvIFBhcnJvdFRhbGsgY29kZSB0byB2ZXJzaW9uIDExLCBp bnRlcm9wZXJhYmxlIHdpdGggdGhlIEphdmEgdmVyc2lvbi4gSSBhbSBwcm9jZWVkaW5nIHRvIHdv cmsgb24gdGhlIEludGVybmV0LURyYWZ0IGFuZCBJIGhvcGUgc29tZSBkaXNjdXNzaW9uIGJ1aWxk cyBhcm91bmQgdGhpcyB3b3JrLjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoYW5rIHlv dS48YnI+PC9kaXY+PGRpdiBjbGFzcz0icHJvdG9ubWFpbF9zaWduYXR1cmVfYmxvY2siPjxkaXYg Y2xhc3M9InByb3Rvbm1haWxfc2lnbmF0dXJlX2Jsb2NrLXVzZXIiPjxkaXY+LS0tPGJyPjwvZGl2 PjxkaXY+Um9iZXJ0PGJyPjwvZGl2PjwvZGl2PjxkaXYgY2xhc3M9InByb3Rvbm1haWxfc2lnbmF0 dXJlX2Jsb2NrLXByb3RvbiBwcm90b25tYWlsX3NpZ25hdHVyZV9ibG9jay1lbXB0eSI+PGJyPjwv ZGl2PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNsYXNzPSJw cm90b25tYWlsX3F1b3RlIj48ZGl2Pi0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS08 YnI+PC9kaXY+PGRpdj5TdWJqZWN0OiBbaW50ZXJuZXQtZHJhZnQtZHJhZnRdIFBhcnJvdFRhbGs6 IEFub255bW91cyBQMlAgZW5jcnlwdGlvbjxicj48L2Rpdj48ZGl2PkxvY2FsIFRpbWU6IE5vdmVt YmVyIDIsIDIwMTcgOToxOSBQTTxicj48L2Rpdj48ZGl2PlVUQyBUaW1lOiBOb3ZlbWJlciAzLCAy MDE3IDE6MTkgQU08YnI+PC9kaXY+PGRpdj5Gcm9tOiBoZW5yeUBjYWxsaXN0b2hvdXNlLmNsdWI8 YnI+PC9kaXY+PGRpdj5UbzogSUVURiAmbHQ7aWV0ZkBpZXRmLm9yZyZndDs8YnI+PC9kaXY+PGRp dj48YnI+PC9kaXY+PGRpdj48ZGl2PkkKIGhhdmUgZGV2ZWxvcGVkIHRoZSBQYXJyb3RUYWxrIFBy b3RvY29sLCBhbmQgYW0gc3RhcnRpbmcgYW4gaW50ZXJuZXQgZHJhZnQgZG9jdW1lbnRbMV0gZm9y IHN1Ym1pc3Npb24gdG8gdGhlIHByb2Nlc3MgYXQgSUVURi48YnI+PC9kaXY+PGRpdj48YnI+PC9k aXY+PGRpdj5QYXJyb3RUYWxrIFByb3RvY29sIGlzIGRvY3VtZW50ZWQgaW4gcGFydCBoZXJlWzJd LCAKd2hpbGUgSSBoYXZlIHR3byBpbXBsZW1lbnRhdGlvbnM6IDEgaW4gU3F1ZWFrL1BoYXJvWzMg YS9iXSZuYnNwO2FuZCB0aGUgCm90aGVyIGluIEphdmFbNCBhL2JdLiBUaGUgcGFydGljdWxhcnMg b2YgTUFDIGtleSBhbmQgaXZTZXF1ZW5jZSBkZXJpdmF0aW9uLAogYXMgd2VsbCBhcyBjb25zdHJh aW5lZCZuYnNwO3RyYWZmaWMKICAgIHNpZ25pbmcsIGFyZSB0aGUgaW1wbGVtZW50YXRpb25zLCB5 ZXQgbWlzc2luZyBmcm9tIHRoZSBzcGVjaWZpY2F0aW9uLiBUaGV5IHdpbGwgYmUgYWRkZWQgdG8g dGhlIGludGVybmV0LWRyYWZ0Ljxicj48L2Rpdj48L2Rpdj48ZGl2IGRhdGEtaW5qZWN0LW1lc3Nh Z2UtbWVkaWE9IiIgZGF0YS1lbWJlZGRlZC1pbWctbG9hZGVyPSIiIGNsYXNzPSJmcmFtZSBtZXNz YWdlLWZyYW1lIj48ZGl2IGNsYXNzPSJib2R5RGVjcnlwdGVkIGVtYWlsIG1lc3NhZ2UtYm9keS1j b250YWluZXIiPjxkaXY+PGJyPjwvZGl2PjxkaXY+SG93IGRvIEkgZ28gYWJvdXQgc3VibWl0dGlu ZyBhIHNwZWNpZmljYXRpb24gZm9yIFBhcnJvdFRhbGsgZm9yIElFVEYgcmV2aWV3IGFuZCBjb25z aWRlcmF0aW9uPzxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoYW5rIHlvdS48YnI+PC9k aXY+PGRpdj48YnI+PC9kaXY+PGRpdiBjbGFzcz0icHJvdG9ubWFpbF9zaWduYXR1cmVfYmxvY2si Pi0gUm9iZXJ0PGJyPjwvZGl2PjxkaXYgY2xhc3M9InByb3Rvbm1haWxfc2lnbmF0dXJlX2Jsb2Nr Ij48YnI+PC9kaXY+PGRpdiBjbGFzcz0icHJvdG9ubWFpbF9zaWduYXR1cmVfYmxvY2siPlsxXSBJ RVRGIEktRCBkcmFmdCAtIDxhIGhyZWY9Imh0dHA6Ly9qbXAuc2gvVlJlalMyZyI+aHR0cDovL2pt cC5zaC9WUmVqUzJnPC9hPjxicj48L2Rpdj48ZGl2IGNsYXNzPSJwcm90b25tYWlsX3NpZ25hdHVy ZV9ibG9jayI+PGRpdj48YnI+PC9kaXY+PGRpdj5bMl0gUGFycm90VGFsayBGcmFtZSBEZXNpZ24g LSZuYnNwOzxhIHN0eWxlPSJmb250LXNpemU6IDFlbTsiIGhyZWY9Imh0dHA6Ly9qbXAuc2gvT3Fs WXB5ZyIgcmVsPSJub3JlZmVycmVyIG5vZm9sbG93IG5vb3BlbmVyIj5odHRwOi8vam1wLnNoL09x bFlweWc8L2E+PGJyPjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+WzMgYV0gU3F1ZWFrL1BoYXJv IENyeXB0b2dyYXBoeSBsaWJyYXJ5IC0mbmJzcDs8YSByZWw9Im5vcmVmZXJyZXIgbm9mb2xsb3cg bm9vcGVuZXIiIGhyZWY9Imh0dHA6Ly93d3cuc3F1ZWFrc291cmNlLmNvbS9DcnlwdG9ncmFwaHkv Q3J5cHRvZ3JhcGh5LUhlbnJ5SG91c2UuMTEzLm1jeiIgc3R5bGU9ImZvbnQtc2l6ZTogMWVtOyI+ aHR0cDovL3d3dy5zcXVlYWtzb3VyY2UuY29tL0NyeXB0b2dyYXBoeS9DcnlwdG9ncmFwaHktSGVu cnlIb3VzZS4xMTMubWN6PC9hPjxicj48L2Rpdj48L2Rpdj48ZGl2IGNsYXNzPSJwcm90b25tYWls X3NpZ25hdHVyZV9ibG9jayI+WzMgYl0gU3F1ZWFrL1BoYXJvIFBhcnJvdFRhbGsgdjMuNiAtJm5i c3A7PGEgcmVsPSJub3JlZmVycmVyIG5vZm9sbG93IG5vb3BlbmVyIiBocmVmPSJodHRwOi8vd3d3 LnNxdWVha3NvdXJjZS5jb20vQ3J5cHRvZ3JhcGh5L1BhcnJvdFRhbGstSGVucnlIb3VzZS45Lm1j eiIgc3R5bGU9ImZvbnQtc2l6ZTogMWVtOyI+aHR0cDovL3d3dy5zcXVlYWtzb3VyY2UuY29tL0Ny eXB0b2dyYXBoeS9QYXJyb3RUYWxrLUhlbnJ5SG91c2UuMTEubWN6PC9hPjxicj48L2Rpdj48ZGl2 IGNsYXNzPSJwcm90b25tYWlsX3NpZ25hdHVyZV9ibG9jayI+PGJyPjwvZGl2PjxkaXYgY2xhc3M9 InByb3Rvbm1haWxfc2lnbmF0dXJlX2Jsb2NrIj5bNCBhXSBKYXZhIEFTTjEgZnJhbWV3b3JrIC0m bmJzcDs8YSByZWw9Im5vcmVmZXJyZXIgbm9mb2xsb3cgbm9vcGVuZXIiIGhyZWY9Imh0dHBzOi8v Z2l0aHViLmNvbS9aaXJvWmltYmFycmEvQVNOMSIgc3R5bGU9ImZvbnQtc2l6ZTogMWVtOyI+aHR0 cHM6Ly9naXRodWIuY29tL1ppcm9aaW1iYXJyYS9BU04xPC9hPjxicj48L2Rpdj48ZGl2IGNsYXNz PSJwcm90b25tYWlsX3NpZ25hdHVyZV9ibG9jayI+WzQgYl0gSmF2YSBQYXJyb3RUYWxrIHYzLjYg LSZuYnNwOzxhIHJlbD0ibm9yZWZlcnJlciBub2ZvbGxvdyBub29wZW5lciIgaHJlZj0iaHR0cHM6 Ly9naXRodWIuY29tL1ppcm9aaW1iYXJyYS9QYXJyb3RUYWxrIiBzdHlsZT0iZm9udC1zaXplOiAx ZW07Ij5odHRwczovL2dpdGh1Yi5jb20vWmlyb1ppbWJhcnJhL1BhcnJvdFRhbGs8L2E+PGJyPjwv ZGl2PjwvZGl2PjwvZGl2PjxkaXY+PGJyPjwvZGl2PjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rp dj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+ --b1_e5f255c23e4c2e3641205beb8ff9291b-- From nobody Mon Nov 6 07:55:43 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 357F913292A for ; Wed, 18 Oct 2017 14:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=nightwatchcybersecurity-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 AFDnf7J0AOqy for ; Wed, 18 Oct 2017 14:42:16 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (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 33E7F1320DC for ; Wed, 18 Oct 2017 14:42:16 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id m198so11405292oig.5 for ; Wed, 18 Oct 2017 14:42:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nightwatchcybersecurity-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=pDwDXtBu/599R5ZYznN3iE60gMBc+Ryo8FI3mSmZDB0=; b=lY8JepfBPLZ1VdAm50whZhc4BDAoiuAyaoq+LbNvS9euV7mO9Toi2vSE14g+Xv3SdM MGWdxyO0yCPv54Bo/ZXmAO9vF4U91PG/UijyFiLMsrL8T5PJK/O/F0TX9tOu92Kp1ev1 MvlqnXH/veL1LyaslxdFhQubUhsOO0Qrfn/8Q8pw9lTgiJgpi++o31evTBHarnrDOmCd M4SJ2w3kCU1/6qN2k/E5uZ6oRz0VuG8U4l5i47HANDg3p+Nw2fZbMxNCv84e6qq68J02 u9pfqv2sQeYsSYPB4GLGCx7AUtdPbXckn6Zj/2m/BzitSTVSVK07RBQJflrrpS+cLru6 9UIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=pDwDXtBu/599R5ZYznN3iE60gMBc+Ryo8FI3mSmZDB0=; b=YU4ReScBeUhxiqzVbeuUDYTOxKk2wddhFOvLLvG8Hq5HNZk1B8n757iu+yTm7eXIAP FWpMyIG5X6P6eUZ/Rva2qPDR1StM/2MBr6/H23hbItQHNXS6z1iVTOM7yJszPLXxBj5s 76VwfpiVuhm+AA3eMR0ApW8UXCVvqWoe5F/c7atNhb4WKVCFOQKrKtgnbRx8zUay3AeD mJrmz+biPdPS4ZeS1Cpktp1i6ujzdwL+p1LvyB1Qa1LRyjsuViyBLtrdq/yh8NYK2r3O 2CZ/fUfRABGfmcYEaSbcgr2BIVJ1xKLdhB5A8lJMWUvNTcwyTtL0e2d9Fr5kjuXlC2F8 EojA== X-Gm-Message-State: AMCzsaX2Mg9UbjefsVrL8SmgmRIj9BE0b+340qBO62Zc4ZMtH1jH40BG Ekt/ViXQwz6gKlHOVN+MK2QcdlaRPY16pISH3svjfsv/gso= X-Google-Smtp-Source: ABhQp+SWZU+6yeQesycBp7/BHaEfQk1NnGi2ZHm/Hez2pSgh4GZPrkF0znCRWFHY53vbR1a7iOZ1KxYFguEXCclUqlw= X-Received: by 10.157.15.209 with SMTP id m17mr4787147otd.389.1508362935520; Wed, 18 Oct 2017 14:42:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.84.27 with HTTP; Wed, 18 Oct 2017 14:41:35 -0700 (PDT) In-Reply-To: <1A8D136E-D99D-4944-B9AA-BAA4D1765514@tzi.org> References: <1A8D136E-D99D-4944-B9AA-BAA4D1765514@tzi.org> From: Yakov Shafranovich Message-ID: To: Carsten Bormann Cc: saag@ietf.org, Ed Overflow Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-Mailman-Approved-At: Mon, 06 Nov 2017 07:55:41 -0800 Subject: Re: [saag] Proposal for "security.txt" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Wed, 18 Oct 2017 21:42:18 -0000 X-Original-Date: Wed, 18 Oct 2017 17:41:35 -0400 X-List-Received-Date: Wed, 18 Oct 2017 21:42:18 -0000 This issue has been raised via Github and the consensus is that this file should be under .well-known. That change will be reflected in the next draft. See: https://github.com/securitytxt/security-txt/issues/3 Thanks On Wed, Oct 18, 2017 at 5:04 PM, Carsten Bormann wrote: > Surely, this needs to be under /.well-known? > (RFC 5785) > > Gr=C3=BC=C3=9Fe, Carsten > >> On Oct 16, 2017, at 03:59, Yakov Shafranovich wrote: >> >> [I am posting this as per my emails with the sec ADs] >> >> Ed Foudil and others within the security community are working on an >> Internet draft proposing a new standard for providing security contact >> information via a standard file, similar to robots.txt. The draft can >> be found here: >> https://tools.ietf.org/html/draft-foudil-securitytxt-00 >> >> Additional resources here: >> https://securitytxt.org/ >> https://github.com/securitytxt/security-txt >> >> Nevil Brownlee (the Independent Submissions Editor) has indicated that >> this document is not a good candidate for the independent stream, so >> the question now is whether this can be something that fall under the >> security area. >> >> EKR has suggested that this may be a good topic to add to the upcoming >> SEC-DISPATCH meeting at IETF 100 in Singapore. >> >> Thanks, >> Yakov >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >> > From davidm@circularnetworks.com Thu Oct 26 07:45:20 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93549138BD6; Thu, 26 Oct 2017 07:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.8 X-Spam-Level: X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 971zu-kBQELv; Thu, 26 Oct 2017 07:45:18 -0700 (PDT) Received: from caracal.maple.relay.mailchannels.net (caracal.maple.relay.mailchannels.net [23.83.214.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BDFB138A4C; Thu, 26 Oct 2017 07:45:18 -0700 (PDT) X-Sender-Id: fastwebhost|x-authuser|davidm@circularnetworks.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 519DD12A5FD; Thu, 26 Oct 2017 14:45:12 +0000 (UTC) Received: from svr166.edns1.com (unknown [100.96.126.244]) (Authenticated sender: fastwebhost) by relay.mailchannels.net (Postfix) with ESMTPA id 2CBEC12A54B; Thu, 26 Oct 2017 14:45:04 +0000 (UTC) X-Sender-Id: fastwebhost|x-authuser|davidm@circularnetworks.com Received: from svr166.edns1.com (svr166.edns1.com [172.20.112.111]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.9.14); Thu, 26 Oct 2017 14:45:12 +0000 X-MC-Relay: Neutral X-MailChannels-SenderId: fastwebhost|x-authuser|davidm@circularnetworks.com X-MailChannels-Auth-Id: fastwebhost X-Fearful-Daffy: 43b14458639f7fc4_1509029104485_3582956654 X-MC-Loop-Signature: 1509029104485:2927937819 X-MC-Ingress-Time: 1509029104484 Received: from c-24-147-100-255.hsd1.ma.comcast.net ([24.147.100.255]:50979 helo=[IPv6:::ffff:192.168.2.34]) by svr166.edns1.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1e7jP4-0005ga-A3; Thu, 26 Oct 2017 07:45:02 -0700 MIME-Version: 1.0 To: Mohit Sethi , "saag@ietf.org" , "reap@ietf.org" From: David Mitton Date: Thu, 26 Oct 2017 10:45:02 -0400 Importance: normal X-Priority: 3 In-Reply-To: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com> References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com> Content-Type: multipart/alternative; boundary="_2DC240DB-E97A-42DE-AE72-1D9D98563392_" X-Antivirus: Avast (VPS 171026-0, 10/26/2017), Outbound message X-Antivirus-Status: Clean X-AuthUser: davidm@circularnetworks.com Message-Id: <20171026144512.519DD12A5FD@relay.mailchannels.net> Archived-At: X-Mailman-Approved-At: Mon, 06 Nov 2017 07:55:41 -0800 Subject: Re: [saag] PSA: New list for discussing EAP related methods X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Oct 2017 15:02:53 -0000 --_2DC240DB-E97A-42DE-AE72-1D9D98563392_ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" I=E2=80=99m sorry, it=E2=80=99s been a while since I paid attention. So EMU has been closed, and you didn=E2=80=99t want to recycle the acronym?= It might be useful to review the progress of the methods that came out of E= MU. Dave. Sent from Mail for Windows 10 From: Mohit Sethi Sent: Thursday, October 26, 2017 9:04 AM To: saag@ietf.org; reap@ietf.org Subject: [saag] PSA: New list for discussing EAP related methods Dear all, We have started a mailing list for discussing new EAP related work that currently has no obvious home. The mailing list is called REAP (Renew EAP) reap@ietf.org and you can subscribe here: https://www.ietf.org/mailman/listinfo/reap Recently several new EAP methods have been proposed. These include for example: EAP-TLS 1.3: https://tools.ietf.org/html/draft-mattsson-eap-tls13-00 EAP-NOOB: https://tools.ietf.org/html/draft-aura-eap-noob-02 EAP-SASL: https://tools.ietf.org/html/draft-vanrein-eap-sasl-00 The list serves as a venue for discussion of these and other EAP related drafts that will be submitted in the near future. As courtesy, we will post any new draft to SAAG, but we plan to continue the discussion only on the REAP mailing list. We have also asked for a short presentation slot during SECDISPATCH at IETF 100 in Singapore. Comments, early feedback, and discussion on existing or new work is more than welcome. --Mohit _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus --_2DC240DB-E97A-42DE-AE72-1D9D98563392_ Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="utf-8"

I=E2=80=99m sorry, it=E2=80=99s been= a while since I paid attention.

So EMU has been cl= osed, and you didn=E2=80=99t want to recycle the acronym?

It might be useful to review the progress of the methods that came o= ut of EMU.

 

Dave.

 

<= o:p> 

Sent from Mail for Windows 10

 

From: Mohit Sethi
Sent: Thursday, O= ctober 26, 2017 9:04 AM
To: saag= @ietf.org; reap@ietf.org
Sub= ject: [saag] PSA: New list for discussing EAP related methods

=

 

Dear all,

 

We have sta= rted a mailing list for discussing new EAP related work that

currently has no obvious home. The mailing list is called REAP= (Renew

EAP) reap@ietf.org and you can subscribe h= ere:

https://www.ietf.org/mailman/listinfo/reap

=

 

Recently sev= eral new EAP methods have been proposed. These include for

example:

 

EAP-TLS 1.3: https://tools.ietf.org/html/draft-mattsson-eap-tls13-= 00

 

EAP-NO= OB: https://tools.ietf.org/html/draft-aura-eap-noob-02

 

EAP-SASL: https://tools.ietf.= org/html/draft-vanrein-eap-sasl-00

 

The list serves as a venue for discussion of thes= e and other EAP related

drafts that will be submit= ted in the near future. As courtesy, we will

post = any new draft to SAAG, but we plan to continue the discussion only

on the REAP mailing list. We have also asked for a short p= resentation

slot during SECDISPATCH at IETF 100 in= Singapore.

 

Comments, early feedback, and discussion on existing or new work is more=

than welcome.

 =

--Mohit

 <= /o:p>

_____________________________________________= __

saag mailing list

saag@i= etf.org

https://www.ietf.org/mailman/listinfo/saag<= /p>

 


3D"" Virus-= free. www.avast.com
--_2DC240DB-E97A-42DE-AE72-1D9D98563392_-- From nobody Tue Nov 7 07:05:12 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B8113FF70 for ; Tue, 7 Nov 2017 07:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 r_W5_8RKHMNO for ; Tue, 7 Nov 2017 07:05:08 -0800 (PST) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 198B913FF2A for ; Tue, 7 Nov 2017 07:03:01 -0800 (PST) Received: by mail-pg0-x236.google.com with SMTP id v78so11238167pgb.5 for ; Tue, 07 Nov 2017 07:03:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=R8tHXoL5Wx/1Ep3Nzn8ThmX2yKTr5yxomVHrEaxEyb8=; b=L6JXaEym3s3hU0/elQDuignQd7rYpg9uIWXmuCumyNBh+CGmgOTkIcbkjk/KKejj2K iNcLACjoDnEHztSKCHHi0+e1NF+zRyxtjwowYk6a17p8U8BGcCjdWpN0JEubLRMMBcif EsqKzpqYEIoYIVXXXU2ItTNB2uyg3A4T/9b9ywEcEFikHlzpd4dBhFx6b2k7Sxc7JgAG 5M0DgvNfvKcCQaIrLkBwgm1oXB37Z0Gi67F9J9Piw+7PB5/rF2Xanhuah2BmDCFcWF34 Vwo1J5o2dJ1Dk9wF1xO4puyAQUty9+2QJo2N2qWkzUCsy8V6J7Yi+FWYZmVxI7WszkVZ VVYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=R8tHXoL5Wx/1Ep3Nzn8ThmX2yKTr5yxomVHrEaxEyb8=; b=mcQTkO0qVDnZDybfxZXNO99mLBHsKvndT3Zb40TujLfFoT29QPIAQkzEEpS5rbHfP3 QWNtWsa/ALjn/vwha4a3YDJyvTPMfqu/qpIM8CqjJnagE4sWoKBuzD2eBKjDdHH38g9A TBRTVWDX6AqusQkELAPpb4K7SwJtw9h8IoTxHNxsrwqjGx0B4V+SAnbUqf1TKgD1uGlK kR011lXKw8l4NARblYN9y8M+9tRDSZFuk5vCmzsgS9MHfiYwhndzbqGbE1isRdL3sN9S SN3Vrefxo/sSnRO8LouBsiyA1klvXIIoQ8nMdM9PxorMe3NDSsXfRDa4uiNUZESwZhdw Nh8A== X-Gm-Message-State: AMCzsaUhOrHvQP98xOG2IWaXT6XU0+kLItycxZPHhUGyFpTNWYmxmXs1 BJIQz8HsMHVq8QxeHDJYj6VxDFEZCvOS8pqG6rwz7Q== X-Google-Smtp-Source: ABhQp+SJXqZz6AM+Nuo9xQ7Fs/SoGriLXyvj/8VYQGSatSTM8qXPwwg0eG1TIUa6KzB25vwRvhVHknB1z6nFDJ1N1RM= X-Received: by 10.101.99.144 with SMTP id h16mr18865344pgv.13.1510066980995; Tue, 07 Nov 2017 07:03:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.186.194 with HTTP; Tue, 7 Nov 2017 07:02:20 -0800 (PST) From: Kathleen Moriarty Date: Tue, 7 Nov 2017 10:02:20 -0500 Message-ID: To: "saag@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [saag] SAAG IETF 100 Agenda X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 15:05:11 -0000 Hello, The SAAG agenda has been posted. Since SecDispatch will follow SAAG in the same session, SAAG will be shorter then normal and we have one invited speaker, Min Suk KANG. Agenda: https://datatracker.ietf.org/meeting/100/materials/agenda-100-saag/ Abstract for invited talk: Title: Inter-domain DDoS mitigations: potentials, challenges, and solutions Abstract: Distributed denial-of-service (DDoS) attacks have plagued the Internet for a few decades. Particularly, volumetric DDoS attacks have shown a tremendous increase in volume in the past few years, often flooding one or more upstream ASes of a target network. Academic community also has warned about new volumetric attack vectors (e.g., link-flooding attacks [Studer and Perrig, 2009] [Kang et al. 2013]); yet, it has been shown that single-domain mitigations have limited defense capability [Kang et al. 2016]. To that end, ASes in practice have begun to collaborate and outsource packet filtering to neighboring ASes (see the recent inter-domain packet filtering system between AT&T and CenturyLink [Levy et al., 2017]) and an IETF standard working group, called DDoS Open Threat Signaling or DOTS, has been formed. Although collaborative packet filtering between two ASes has great potentials and often is necessary for DDoS mitigations, there exist several fundamental concerns for designing a secure collaborative packet filtering between mutually distrusting ASes. In this talk, we argue that three security properties are desired for secure inter-domain packet filtering: (1) fairness guarantees (i.e., both ASes can equally contribute to filtering operations); (2) privacy guarantees (i.e., one AS cannot learn the other AS=E2=80=99s filtering poli= cy beyond what is already known); and (3) accountable packet filtering (i.e., collaborating ASes can prove if a packet has been dropped as a result of the collaborative packet filtering). We present a prototype for an ongoing project on a secure inter-domain collaborative packet filtering system that exploits a trusted hardware commodity server platform (i.e., Intel SGX) and supports line-rate (e.g., 10 Gbps) rate-limiting operations. [Studer and Perrig, 2009] Ahren Studer and Adrian Perrig. "The Coremelt Attack." ESORICS. 2009. [Kang et al., 2013] Min Suk Kang, Soo Bum Lee, and Virgil D. Gligor. "The crossfire attack." IEEE Symposium on Security and Privacy (SP), 2013. [Kang et al., 2016] Min Suk Kang, Virgil D. Gligor, and Vyas Sekar. "SPIFFY: Inducing Cost-Detectability Tradeoffs for Persistent Link-Flooding Attacks." NDSS. 2016. [Levy et al., 2017] Nimrod Levy, Don Smith, and John Schiel. =E2=80=9COperationalizing ISP cooperation during DDoS attacks.=E2=80=9D NAN= OG 71, October 3, 2017. --=20 Best regards, Kathleen From nobody Tue Nov 7 07:50:55 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B66132620 for ; Tue, 7 Nov 2017 07:50:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 u3qngqk2l2lv for ; Tue, 7 Nov 2017 07:50:50 -0800 (PST) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1014132705 for ; Tue, 7 Nov 2017 07:44:41 -0800 (PST) Received: by mail-wr0-x232.google.com with SMTP id p96so12237186wrb.7 for ; Tue, 07 Nov 2017 07:44:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=VDzY195bJbCewas7yBR7OFwMRdhocRjn02rReYJnLa4=; b=jUadPnFKgWc1VdDnGAs4ciF300HGv7VCfyONxYHpC6yJhy27LuvVD2MBaMYIA/j/wF OOyCqzhiXxPyUuT03M9tL+vAauuNrZnLZDGDPuvTDqG+e2/igsk/DHYQfJO8TWzqr5HT 7+/0NMhr0cxt9lz/SPA0ppwfvUI0K3PK4d+Fbd8GS3k2tcyqneA8mTZu9D2Jrmr+MfUY LJqF08FcY1zgw1fiiIpB6iI7j7YgaszgDgqE1xr8YYmB33hO+XzlA6pfq6QbScKHvfTX 6bBbAEe7UM46Jnm1b+XHEpEtogLo7TlyQap9d2uQ+WJXd1gly5XFmQDpJpQZ3zS8axVg 4/KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=VDzY195bJbCewas7yBR7OFwMRdhocRjn02rReYJnLa4=; b=LxFxcMEvAXVa8sOftnehCrOwowfZ/PfG1pjoUU/rkH5qAdCUsi7UQLmebDO2uPzME4 IrLy0KhAvt3KopuGI69uoDcN/ba+0BhW8KocfNck+U6ahD5P5LISogqd4WD3L3ORMkEM 7oxwsx5BGPhHisYoABitAFZBpIxiPOR26uARM+F6TLI8E3iwj40IU30v/34xe1g9vRMK Pw1uAebHzA0w7UuYgAte8Fv/Pd7uV1zH9hsnWzHCwdNHFLfxJz0kJfCX6mMxgBkvzUfk j7Kn7w+Aw1oxWPe89ipX/5oQJgAs4G3Dp7gtNqbjPDgtvIT6pzJCrv+4y25Xd5qEpV9q y54g== X-Gm-Message-State: AMCzsaXZVBYHF+pj0fNIZxHF6IYeKz7HaMiY1TCW2W5f4zgnljPV2QaE GFVddI1GOxBmkc/pAycf5sQ= X-Google-Smtp-Source: ABhQp+TBblsOgsTs2fM4iFn1VOKoS0Pd/NATnb0K8ozJJi0PLTi2RTY6K/WZ7mazNybwbwk+uzLvGQ== X-Received: by 10.223.177.143 with SMTP id q15mr17562397wra.269.1510069163703; Tue, 07 Nov 2017 07:39:23 -0800 (PST) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id k30sm1749945wrf.52.2017.11.07.07.39.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Nov 2017 07:39:23 -0800 (PST) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_C6710DF4-5383-4E5F-85E0-E30ECE8CE6C5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Tue, 7 Nov 2017 17:39:21 +0200 In-Reply-To: Cc: Security Area Advisory Group To: Kathleen Moriarty References: X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [saag] SAAG IETF 100 Agenda X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 15:50:53 -0000 --Apple-Mail=_C6710DF4-5383-4E5F-85E0-E30ECE8CE6C5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, Kathleen. I notice that SecDispatch does not appear in the agenda, and also that = no agenda has been posted for that session. Yoav > On 7 Nov 2017, at 17:02, Kathleen Moriarty = wrote: >=20 > Hello, >=20 > The SAAG agenda has been posted. Since SecDispatch will follow SAAG > in the same session, SAAG will be shorter then normal and we have one > invited speaker, Min Suk KANG. >=20 > Agenda: > https://datatracker.ietf.org/meeting/100/materials/agenda-100-saag/ >=20 > Abstract for invited talk: > Title: Inter-domain DDoS mitigations: potentials, challenges, and = solutions >=20 > Abstract: Distributed denial-of-service (DDoS) attacks have plagued > the Internet for a few decades. Particularly, volumetric DDoS attacks > have shown a tremendous increase in volume in the past few years, > often flooding one or more upstream ASes of a target network. Academic > community also has warned about new volumetric attack vectors (e.g., > link-flooding attacks [Studer and Perrig, 2009] [Kang et al. 2013]); > yet, it has been shown that single-domain mitigations have limited > defense capability [Kang et al. 2016]. To that end, ASes in practice > have begun to collaborate and outsource packet filtering to > neighboring ASes (see the recent inter-domain packet filtering system > between AT&T and CenturyLink [Levy et al., 2017]) and an IETF standard > working group, called DDoS Open Threat Signaling or DOTS, has been > formed. >=20 > Although collaborative packet filtering between two ASes has great > potentials and often is necessary for DDoS mitigations, there exist > several fundamental concerns for designing a secure collaborative > packet filtering between mutually distrusting ASes. In this talk, we > argue that three security properties are desired for secure > inter-domain packet filtering: (1) fairness guarantees (i.e., both > ASes can equally contribute to filtering operations); (2) privacy > guarantees (i.e., one AS cannot learn the other AS=E2=80=99s filtering = policy > beyond what is already known); and (3) accountable packet filtering > (i.e., collaborating ASes can prove if a packet has been dropped as a > result of the collaborative packet filtering). We present a prototype > for an ongoing project on a secure inter-domain collaborative packet > filtering system that exploits a trusted hardware commodity server > platform (i.e., Intel SGX) and supports line-rate (e.g., 10 Gbps) > rate-limiting operations. >=20 > [Studer and Perrig, 2009] Ahren Studer and Adrian Perrig. "The > Coremelt Attack." ESORICS. 2009. > [Kang et al., 2013] Min Suk Kang, Soo Bum Lee, and Virgil D. Gligor. > "The crossfire attack." IEEE Symposium on Security and Privacy (SP), > 2013. > [Kang et al., 2016] Min Suk Kang, Virgil D. Gligor, and Vyas Sekar. > "SPIFFY: Inducing Cost-Detectability Tradeoffs for Persistent > Link-Flooding Attacks." NDSS. 2016. > [Levy et al., 2017] Nimrod Levy, Don Smith, and John Schiel. > =E2=80=9COperationalizing ISP cooperation during DDoS attacks.=E2=80=9D = NANOG 71, > October 3, 2017. >=20 > -- >=20 > Best regards, > Kathleen >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --Apple-Mail=_C6710DF4-5383-4E5F-85E0-E30ECE8CE6C5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAloB06kACgkQuEkLFQpY zJl2qwgAmNASK3kc481X6EzBcZRe2yAwkscUGisSw7bjb+n/LcsUtSyVLnOExWir miQF33ws3BFjs//iqsuOpgsRHdMFl0o3b58dMExLfxQAvPf3kUUEBQk3JuH5k9j3 MHXrjbG4XPCjdvKAjO3/e3GioSjzCcuWwl9ymCVU6dC5lHhK/1kWLBJb8ZZMunGY n6RiZfClQud02ulvr+bzZ5R6TkeQmzegQn7kptamvsbZx4WEO/QNH9rR+gOe/77Y mJKQ0i6/CEmzsURfwuQ/KdepX5f5yH71qPEIwnTOnwmaVrPNh8UbZyoOivZwLP8k VPnu16tD7tHPRyQTbgLHlx5BrphJNQ== =ch0K -----END PGP SIGNATURE----- --Apple-Mail=_C6710DF4-5383-4E5F-85E0-E30ECE8CE6C5-- From nobody Tue Nov 7 08:13:25 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C02F133805 for ; Tue, 7 Nov 2017 08:13:24 -0800 (PST) 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 UiclP2hXJnpE for ; Tue, 7 Nov 2017 08:13:23 -0800 (PST) Received: from mahimahi.ripe.net (mahimahi.ripe.net [IPv6:2001:67c:2e8:11::c100:1372]) (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 BE1D0133B11 for ; Tue, 7 Nov 2017 08:03:46 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by mahimahi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1eC6Ln-0001wq-F9 for saag@ietf.org; Tue, 07 Nov 2017 17:03:44 +0100 Received: from sslvpn.ripe.net ([193.0.20.230] helo=[193.0.22.122]) by titi.ripe.net with esmtps (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89) (envelope-from ) id 1eC6Ln-0007Gb-CN for saag@ietf.org; Tue, 07 Nov 2017 17:03:43 +0100 References: To: saag From: Robert Kisteleki Organization: RIPE NCC Message-ID: <347a387f-a3bb-7f77-c1d6-f99d5abe36ad@ripe.net> Date: Tue, 7 Nov 2017 17:03:43 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-ACL-Warn: Delaying message X-RIPE-Spam-Level: ------- X-RIPE-Spam-Report: Spam Total Points: -7.5 points pts rule name description ---- ---------------------- ------------------------------------ -7.5 ALL_TRUSTED Passed through trusted hosts only via SMTP X-RIPE-Signature: 72e00e6d7601fa19264e98abc238a2740c93496a683663958c3db6e9f4e3dbea Archived-At: Subject: Re: [saag] Proposal for "security.txt" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 16:13:25 -0000 Maybe a silly question, but the way I see it there's no such thing (sec dispatch) on the agenda. Am I doing it wrong? Also: there's a draft, there's a github page and there's also a separate domain for this proposal. At least two of them are not in sync with each other. So I'm a bit confused about where discussion is taking place and what is the current authoritative version. Robert On 2017-10-19 00:45, Martin Thomson wrote: > On Mon, Oct 16, 2017 at 12:59 PM, Yakov Shafranovich > wrote: >> EKR has suggested that this may be a good topic to add to the upcoming >> SEC-DISPATCH meeting at IETF 100 in Singapore. > > Yes, this seems appropriate. Going through this process will ensure > that comments like Carsten's - a view I share - are considered and > addressed. > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > From nobody Tue Nov 7 08:29:57 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4E3A13321E for ; Tue, 7 Nov 2017 08:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 9nym5njVPfdU for ; Tue, 7 Nov 2017 08:29:54 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20DEC133211 for ; Tue, 7 Nov 2017 08:26:36 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id f8so15921261qta.5 for ; Tue, 07 Nov 2017 08:26:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3ue2lgi6oUMIE+7UNogR/uSYySICF/9Lz9P1r8gFNvw=; b=bB2axmEPIbedG1Qzx2urATQ55Ohi/txLIubhSsdJYfxLvZhgs0Wmsp3iZZYpbjNQEG vyJBQmJNxTpP4esT9BCkR9WjWb6QhYdTvzvhK9Zt0nOk1Ak6pG44psgMyjkKNug+KWyG G6qDVt3+pvAuJ4KIKTWWDt00eGKT5tFXyEUYiZc3C80Mr7fXgZlhwas8P8xoO1nNkH7r r7OLQzMHOTtRn9QlJvYsGmwm6yUZJLIDGK7u/7Ke5GPsavsEKeEwV5Vde6+RiL/bRuiO oUQ1MpBoAAhRnI5Q+j9pNX4ItusafKyLl7uh8RzuUIC76LXdtkL0ra9rwYzJlTC1LfuR gk6A== 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=3ue2lgi6oUMIE+7UNogR/uSYySICF/9Lz9P1r8gFNvw=; b=abb/wqZ4+C6sTdPIUw4voEPVr3gw2SCNA6ADSjlXkjJH6uA58dnadBGFliDyJnFrVl XwBE6X+GGs/9TLMPMAmbj9M4sMqOfbYPH+okGdQhiTH47y7T52coxrZhU47imL0+/Bk8 0ZLH0ux4J95prL/gvdGjkMn/yf9+0CjighTQGIr3L3uZ2zf7YKUEiJ7OTQDcVvv2AgnE LEjQMTdTIYQMyJcEh5r+7V8uiE3uMzL+VOjNbbbhxUZB57DSk5DIkarJgeF0z18pq+fR xiElXQNBBwAYBiR5RGiLSxls4/8gRlzPpEy4438pzjBhhdYGSzSkpC4N2Xd0ySPfL14i E6yg== X-Gm-Message-State: AMCzsaUGGowhRZrRbKIslPRgKQdiuX59+F3mwqIwsvkLk++KKwStTJBW JzJQ6yhEJMosfpfMoGTXpOZtIlkq X-Google-Smtp-Source: ABhQp+S1xYRNqQLwcF9u+MHMA5M3ciTApIiblnu30WOf7VSmhq1uvq6jZuV/e9/ZTohcZXL2UiUvVw== X-Received: by 10.237.59.90 with SMTP id q26mr27749255qte.153.1510071994039; Tue, 07 Nov 2017 08:26:34 -0800 (PST) Received: from [192.168.1.186] (209-6-112-84.s338.c3-0.arl-ubr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.112.84]) by smtp.gmail.com with ESMTPSA id w20sm1096537qkb.95.2017.11.07.08.26.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Nov 2017 08:26:33 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (14F89) In-Reply-To: <347a387f-a3bb-7f77-c1d6-f99d5abe36ad@ripe.net> Date: Tue, 7 Nov 2017 11:26:32 -0500 Cc: saag Content-Transfer-Encoding: quoted-printable Message-Id: References: <347a387f-a3bb-7f77-c1d6-f99d5abe36ad@ripe.net> To: Robert Kisteleki Archived-At: Subject: Re: [saag] Proposal for "security.txt" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 16:29:56 -0000 Sent from my mobile device > On Nov 7, 2017, at 11:03 AM, Robert Kisteleki wrote: >=20 > Maybe a silly question, but the way I see it there's no such thing (sec > dispatch) on the agenda. Am I doing it wrong? No, I can add in the agenda from the SecDispatch chairs into the overall SAA= G agenda. SAAG should take about 50 minutes and then will switch to SecDisp= atch. We are running SecDispatch as an experiment at this meeting. Best, Kathleen=20 >=20 > Also: there's a draft, there's a github page and there's also a separate > domain for this proposal. At least two of them are not in sync with each > other. So I'm a bit confused about where discussion is taking place and > what is the current authoritative version. >=20 > Robert >=20 >=20 >> On 2017-10-19 00:45, Martin Thomson wrote: >> On Mon, Oct 16, 2017 at 12:59 PM, Yakov Shafranovich >> wrote: >>> EKR has suggested that this may be a good topic to add to the upcoming >>> SEC-DISPATCH meeting at IETF 100 in Singapore. >>=20 >> Yes, this seems appropriate. Going through this process will ensure >> that comments like Carsten's - a view I share - are considered and >> addressed. >>=20 >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >>=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Tue Nov 7 08:31:51 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09C8D133443 for ; Tue, 7 Nov 2017 08:31:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gnuYHrtWb_Kq for ; Tue, 7 Nov 2017 08:31:48 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4F511335FA for ; Tue, 7 Nov 2017 08:28:18 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id b15so15959672qkg.9 for ; Tue, 07 Nov 2017 08:28:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=m1UxYGw5lzpfu5VFjMk6/iQrMlSIrnaxMLEA8hc2Yfc=; b=Ew2h3Tr2TUMcUduA1trkyu6SDw/k2nfa+0IkB+7S1ZBcRttIIvRdSfdYoY9FGFg86/ ovfC8bEqbNMWTwg4HqdEqCstMrdCP+ZZ5olr3wY8/ZdtLDy5Sa1tgLV3s6b16Vq6bRKk Pq4fuBdltqXnAz1h8noyNQONWmkaizPANcH8CBmgBjFxdG0J4k52ekRxN82wfNiEdgjM 8sigatOP2cOriKeg4jViRKBJo6F5fpw3VPu8SQNr21LbrqHmEahoiNfBgpssgfwrNvsn BF/u6fdo+hJDUi3YD92wM7THXZeYGDACcnaNe+Krl4j9fl+EEBEhMU7tbsPrigKVdv2U QHpQ== 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=m1UxYGw5lzpfu5VFjMk6/iQrMlSIrnaxMLEA8hc2Yfc=; b=oX9qBrIgSCSdV4eWX/OIT8kNGF7+2Rj4B+XJ1PxgUSl3SwHIU32b3/ovBuBW/+LEFw x2i4POyLNgFvpAmLYodQ0aQGkEw3w7UqAmdruOXb5XrVDlVXveSVAxy/P2IHKivEFUAT QGlfY4tatoSr182SesziPHWAHNlt5cYlCk+sQ66IBCIpsbIXZPX6qfNVZgpf9sLgjqiP VAogzFk2GadeqsfGoVcxeexy9aFjeT6MHQ1hi8nFjfOw912TXUTry/7Ty8cldbZuRBKM Z5GvbXJ1uZFY5bfRHm4k1HwcPnoHgrmZsp/XOXKcZVYB9JjCXeK2obBBlKdxb3fokcdW gtJA== X-Gm-Message-State: AMCzsaXuVPaB1sJjylyJwfW8AcC2ylca4+T3iy5XMRpx73+5HtgBlLlv JHIfRWWSFNjF9MMVhpYsLu//2NHh X-Google-Smtp-Source: ABhQp+QFLqvsd5d45SxW/4NjaUfxGDqoiXRPQxMHYH0ASp2S6RX1mrr36iLuhNdskQf/CbNeC2C1kQ== X-Received: by 10.55.110.196 with SMTP id j187mr28380244qkc.192.1510072097702; Tue, 07 Nov 2017 08:28:17 -0800 (PST) Received: from [192.168.1.186] (209-6-112-84.s338.c3-0.arl-ubr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.112.84]) by smtp.gmail.com with ESMTPSA id h36sm1109378qtd.69.2017.11.07.08.28.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Nov 2017 08:28:16 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (14F89) In-Reply-To: Date: Tue, 7 Nov 2017 11:28:16 -0500 Cc: Security Area Advisory Group Content-Transfer-Encoding: quoted-printable Message-Id: <912DA4BE-0F6A-4566-8736-6AC2C7CC4A78@gmail.com> References: To: Yoav Nir Archived-At: Subject: Re: [saag] SAAG IETF 100 Agenda X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Nov 2017 16:31:50 -0000 Sent from my mobile device > On Nov 7, 2017, at 10:39 AM, Yoav Nir wrote: >=20 > Hi, Kathleen. >=20 > I notice that SecDispatch does not appear in the agenda, and also that no a= genda has been posted for that session. Yes, I'll fix that. I have the agenda from the chairs and think there's jus= t one text agenda file for each session, so I'll add it to the SAAG session a= nd notify the list when that's been done. Best, Kathleen=20 >=20 > Yoav >=20 >=20 >> On 7 Nov 2017, at 17:02, Kathleen Moriarty wrote: >>=20 >> Hello, >>=20 >> The SAAG agenda has been posted. Since SecDispatch will follow SAAG >> in the same session, SAAG will be shorter then normal and we have one >> invited speaker, Min Suk KANG. >>=20 >> Agenda: >> https://datatracker.ietf.org/meeting/100/materials/agenda-100-saag/ >>=20 >> Abstract for invited talk: >> Title: Inter-domain DDoS mitigations: potentials, challenges, and solutio= ns >>=20 >> Abstract: Distributed denial-of-service (DDoS) attacks have plagued >> the Internet for a few decades. Particularly, volumetric DDoS attacks >> have shown a tremendous increase in volume in the past few years, >> often flooding one or more upstream ASes of a target network. Academic >> community also has warned about new volumetric attack vectors (e.g., >> link-flooding attacks [Studer and Perrig, 2009] [Kang et al. 2013]); >> yet, it has been shown that single-domain mitigations have limited >> defense capability [Kang et al. 2016]. To that end, ASes in practice >> have begun to collaborate and outsource packet filtering to >> neighboring ASes (see the recent inter-domain packet filtering system >> between AT&T and CenturyLink [Levy et al., 2017]) and an IETF standard >> working group, called DDoS Open Threat Signaling or DOTS, has been >> formed. >>=20 >> Although collaborative packet filtering between two ASes has great >> potentials and often is necessary for DDoS mitigations, there exist >> several fundamental concerns for designing a secure collaborative >> packet filtering between mutually distrusting ASes. In this talk, we >> argue that three security properties are desired for secure >> inter-domain packet filtering: (1) fairness guarantees (i.e., both >> ASes can equally contribute to filtering operations); (2) privacy >> guarantees (i.e., one AS cannot learn the other AS=E2=80=99s filtering po= licy >> beyond what is already known); and (3) accountable packet filtering >> (i.e., collaborating ASes can prove if a packet has been dropped as a >> result of the collaborative packet filtering). We present a prototype >> for an ongoing project on a secure inter-domain collaborative packet >> filtering system that exploits a trusted hardware commodity server >> platform (i.e., Intel SGX) and supports line-rate (e.g., 10 Gbps) >> rate-limiting operations. >>=20 >> [Studer and Perrig, 2009] Ahren Studer and Adrian Perrig. "The >> Coremelt Attack." ESORICS. 2009. >> [Kang et al., 2013] Min Suk Kang, Soo Bum Lee, and Virgil D. Gligor. >> "The crossfire attack." IEEE Symposium on Security and Privacy (SP), >> 2013. >> [Kang et al., 2016] Min Suk Kang, Virgil D. Gligor, and Vyas Sekar. >> "SPIFFY: Inducing Cost-Detectability Tradeoffs for Persistent >> Link-Flooding Attacks." NDSS. 2016. >> [Levy et al., 2017] Nimrod Levy, Don Smith, and John Schiel. >> =E2=80=9COperationalizing ISP cooperation during DDoS attacks.=E2=80=9D N= ANOG 71, >> October 3, 2017. >>=20 >> -- >>=20 >> Best regards, >> Kathleen >>=20 >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >=20 From nobody Wed Nov 8 06:18:35 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06D31126FDC for ; Wed, 8 Nov 2017 06:18:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=symc.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jZCNqpo2E5ka for ; Wed, 8 Nov 2017 06:18:31 -0800 (PST) Received: from asbsmtoutape02.symantec.com (asbsmtoutape02.symantec.com [155.64.138.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F62A126CD6 for ; Wed, 8 Nov 2017 06:18:30 -0800 (PST) Received: from asbsmtmtaapi02.symc.symantec.com (asb1-f5-symc-ext-prd-snat8.net.symantec.com [10.90.75.8]) by asbsmtoutape02.symantec.com (Symantec Messaging Gateway) with SMTP id D3.8A.62423.532130A5; Wed, 8 Nov 2017 14:18:29 +0000 (GMT) X-AuditID: 0a5af81a-bccd09c00000f3d7-2d-5a0312351f72 Received: from TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (asb1-f5-symc-ext-prd-snat9.net.symantec.com [10.90.75.9]) by asbsmtmtaapi02.symc.symantec.com (Symantec Messaging Gateway) with SMTP id FF.B4.04178.532130A5; Wed, 8 Nov 2017 14:18:29 +0000 (GMT) Received: from TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (10.44.91.33) by TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 8 Nov 2017 06:18:27 -0800 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.44.128.9) by TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (10.44.91.33) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Wed, 8 Nov 2017 06:18:27 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symc.onmicrosoft.com; s=selector1-symantec-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wCAJRSQxwZ+3g8E0yrAyd9+qdTjtSFYn+1SCV6qkk1s=; b=HrTh41Atc2h8AASRsrGocMeyBKlfHYbgUub05RJb5HtIcEwjLhUtY9IGJqoy1xLeov6EVwd3e160HZFLX0T/0cUVfvyrz1hyVqBv9fpA2Mx8yCzdTLnoGM9k2wHlpvOV4USuskHZHx4gvV9YUp39qGIsnyN25ulfaQWgxboJ8Wc= Received: from MWHPR16MB1488.namprd16.prod.outlook.com (10.175.4.146) by MWHPR16MB1488.namprd16.prod.outlook.com (10.175.4.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.13; Wed, 8 Nov 2017 14:18:25 +0000 Received: from MWHPR16MB1488.namprd16.prod.outlook.com ([10.175.4.146]) by MWHPR16MB1488.namprd16.prod.outlook.com ([10.175.4.146]) with mapi id 15.20.0197.022; Wed, 8 Nov 2017 14:18:25 +0000 From: Brian Witten To: "saag@ietf.org" Thread-Topic: Announcing the PATIENT mailing list & meeting in Singapore Thread-Index: AQHTWJxwTxYMfgYkNUOWtTaS8CQsbg== Date: Wed, 8 Nov 2017 14:18:25 +0000 Message-ID: <656F31A9-9208-4EA8-B9A7-7D3518AF542B@symantec.com> References: , In-Reply-To: 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=brian_witten@symantec.com; x-originating-ip: [2600:387:8:9::77] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR16MB1488; 6:SiPmIf5oqjJBKlETBfeWfJjQ2iGGI8OVohhCNPfNSxwo/vCUi9n6GHuVVx/I5hcbHEzBgaojdm5JuoHl0xsfP7vCoo9uQtPXLb9uNc4lJf4/Ns0fPMgJUJYUwThGY/Yehxmtm9Ah3zfMrzr+eEc4T+11VU73l5DjHwZmGu1/MAbn/FL6eAX1hqYq5jdWAN5asD4Y0VLgcbL+o3K0t7GC51QUCLWgZDIH0CdL7AzcUzUQ9lkVO229/BCJeVein1kGuimSFJv2rM22ZSDP4LX8E7E6I9pMfaGhGyiWks4PKZHizFWwDva9Kaa966p+tPi/RSkikoZspR5VDmh9ap36MuQYCPDiVxwG/Au/+e+AC/Y=; 5:g6eNdIxa7c5OiIx7nWFw/G98v6kzdGBllWFnInuRcUvwjMd7U+0ucbdeM25AF0egwJe1SX5Uv8R2SA8k1Hk3ILkHLHOEZBBuUZDw3mc1ZYYUIjDLJLVI8JFq4HvmlJZ+wieW7G2MlszcWKEutW9fks4cEeu7S+UpU7t3hDBatzw=; 24:bne26BDYhRrdJTKq2Yw5i8q16EKKyApDV3dKgAAYJ9FoQuBqvufy9dJZ7Q/XmIzaAXHIph/X+FJruAJiBcmb4td38JlUdPxSrn2p0Giu/g4=; 7:v1OGb63m7TJeIqbUfPpez6yphL8X1QOVj9UNL5fuM/+RioraHqppTWJNU/HyjhNacKr1mqDqcR7Z41gl3eL0/Q2wLizsARB7KBwCyXU9HQ2t9eVxXAJYAfv4cyhIqHZmy6ImaMLtQFAPRDerABzIzLvJPLM1beU+0NW/3hFBssj6r8pAyqzs7fPmGNAG71uCiDHxiZcWAFcYkZeUepVZp1djgEa1ALSGmvJYDFgBzy2ev5YXw8rc/ZYxS/4c5XyX x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9e5ec7e7-60ab-4ee2-6bca-08d526b39389 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:MWHPR16MB1488; x-ms-traffictypediagnostic: MWHPR16MB1488: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(100405760836317); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3231021)(93006095)(93001095)(10201501046)(3002001)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR16MB1488; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR16MB1488; x-forefront-prvs: 0485417665 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(69224002)(189002)(52254002)(199003)(316002)(2501003)(2351001)(81166006)(105586002)(14454004)(8676002)(1730700003)(2900100001)(106356001)(81156014)(8936002)(7736002)(36756003)(2906002)(50986999)(3280700002)(101416001)(3660700001)(33656002)(83716003)(76176999)(54356999)(6116002)(102836003)(6512007)(10290500003)(68736007)(99286004)(54896002)(478600001)(236005)(82746002)(86362001)(6436002)(53546010)(97736004)(5640700003)(413944005)(53936002)(6916009)(77096006)(25786009)(6506006)(2950100002)(6486002)(5660300001)(189998001)(223123001); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR16MB1488; H:MWHPR16MB1488.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: symantec.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_656F31A992084EA8B9A77D3518AF542Bsymanteccom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9e5ec7e7-60ab-4ee2-6bca-08d526b39389 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2017 14:18:25.7488 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3b217a9b-6c58-428b-b022-5ad741ce2016 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR16MB1488 X-OriginatorOrg: symantec.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTYRTGe++9266jwW1pHhTFloFazQ8UIqJCI4RSjL5wKXmbFz+mbmzT 1CiGS2qTSHHkd5qtZrrhkhkximBRpGSRlOFnhIthpak1nZWR253hPy8/nvOc93nPyyFxoZkT QhaUqBllCV0k4vIJvuQouSdJiEviJl3hew03dNghlGo0rmAZSMLfn8sUFZQxytgDOfz8Gm0r ptD0YuWdLUOEBl0zYXoUQAKVCF0PBgk94pNCagHBXFU/Z71wp8eJvCyklhDcbFGzpmcIZm7r cLbgQvDWetjLBKXDoed9HmsyYNB9y83736G5byW8Li4lhuerE76IQGoHmP64eF7eSqWAq7+a x+qpYLOO+1kMAy4tl02IhM+rT333CKiDcHfpIcYGWBBMd9f7BgqgsqH2yS9fA6K2wfKg2afj VDCMOdv9Q1NgfPwGZzkIZqb/clh/Fgxavvj1SPAsuxHLYTDcXoO8YUA5eLDY1ef/JDH01836 TWkwOa/3m5oQdC39INhCDJiqDFyWs2Hlis6fIIN37u9ELYpv3vBAlqVg6hj3sYDaAgNNTqIZ kWt6NPTaY1nLdjDUfOKxHAXVrW28jXoH4nWjCFp1XlWslpeqaQUTlyBWVRRLvQe9tkFSsVRe 3Id8O+QJeYScE8cciCKRaLPAg3CJkEOXrTkdCEhcFCh4PYRJhIJcuqKSUcrPKUuLGJUDhZKE KFhQWe7OFFJ5tJqRMYyCUa5XMTIgRIPqXuBTo5yTp1ca0kcsy/axZFvjvdTmXfNJhYva6lyL M7Mz/aqGnFg8krJPav6QkvbygiJh2K7zJC80hhuZj71DbZu+6i7OHdc2/Lz8Kktmi5q91Nkx YFNNhcp36+sjZsyYLCPoTGF0TvZOrlJuOhU2Ql63Jn7Tikb5v0+cldpFhCqfjo/BlSr6Hyyk KRg/AwAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42LhivLm1DUVYo4y2LpD0mJKfyeTA6PHkiU/ mQIYo7hsUlJzMstSi/TtErgyupvnMBU0rGeqWDT7LEsDY8dypi5GTg4JAROJxaufMILYQgLf GCWmzS7pYuQCsg8zSrxc2MkMkXjOKHFxgwuIzSLQySyx+mo6RNEUJolV876yw3U0rNzAAlLF JqAncfTvHVYQW0RAWWL5n+fsILawgLPE862t7BBxD4ktG25D2XoSJ583s0FsUJF4+nc/2Bxe AXuJpd+2MUEsWMso8XjVZLC7OQViJSbs/QXWwCggJvH91BqwOLOAuMStJ/OhfhOQWLLnPDOE LSrx8vE/Voj6GIlTa19BxVUkfnz/yghhy0pcmt/NCLJMQuAQu8SnFZtYIRJ6ElsnvoUq8pW4 +6ELqmgmo8SKb59ZIBJaEsubprBB2LESP1s6oTZkS1z5+h6q5gqrxIIZkV2MHEC2jET/i6QJ jLqzkNwNYSdLLF9wG8zmFRCUODnzCcssoA5mAU2J9bv0IUoUJaZ0P2SHsDUkWufMZUcWX8DI vopRIbE4qTi3JLckMbEg08BIr7gyNxlEJALTT7Jecn7uJkZwCvotvoPx3B+fQ4wCHIxKPLwX 5JiihFgTy4AqDzFKc7AoifM+1gAKCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYNz24cY84Yv1 EnNWf11ZbNZzbjnf066bX08wFgZ7HVhj/sDxt+Q2X672zx/mFwbwpPDO3/5A/2cgi9kp6b+N 5e3Pekt+M6QGep1iEYyfP+vY8simXOdT8ddYVVQ5X/q17Nutc2LfeieX7f+s70r+0Z+3OTj+ 5tmI8/IbPh7tqf5YmbHtcL9TQJESS3FGoqEWc1FxIgADg1MpIgMAAA== X-CFilter-Loop: ASB02 Archived-At: Subject: [saag] Announcing the PATIENT mailing list & meeting in Singapore X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 14:18:34 -0000 --_000_656F31A992084EA8B9A77D3518AF542Bsymanteccom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBBbGwsDQoNCkZvciBhbnlvbmUgaW50ZXJlc3RlZCBpbiBQcm90ZWN0aW5nIGFnYWluc3Qg QXR0YWNrcyBUdW5uZWxpbmcgSW4gRW5jcnlwdGVkIE5ldHdvcmsgVHJhZmZpYyAoUEFUSUVOVCks IEnigJltIGFubm91bmNpbmcgYm90aCBhIG1lZXRpbmcgYmVsb3csIGFuZCBtYWlsaW5nIGxpc3Qs IGZ1cnRoZXIgYmVsb3cuICBJbnRlbnQgb2YgUEFUSUVOVCBpcyB0byBjcmVhdGUgYSBzZWN1cmUg bXVsdGktcGFydHkgcHJvdG9jb2wgZm9yIG1ha2luZyBzdWNoIHByb3RlY3Rpb24gZmFyIHNhZmVy IHdpdGhvdXQgbW9kaWZ5aW5nLCBjb25zdHJhaW5pbmcsIG9yIGJyZWFraW5nIFRMUyBpbiBhbnkg d2F5LCBhIHByb3RvY29sIGNvbXBsaW1lbnRpbmcgY3VycmVudCBUTFMgaW5jbHVkaW5nIFRMUyAx LjMuDQoNCkludGVudCBvZiBQQVRJRU5UIGlzIHRvIGRvIHNvIGluIGxpZ2h0IG9mIGJvdGggKGEp IHZ1bG5lcmFiaWxpdGllcyBpbiB0b2RheeKAmXMgY29tbW9uIGFwcHJvYWNoZXMsIGFuZCAoYikg aHVnZSBncm93aW5nIG51bWJlciBvZiBhdHRhY2tzIHR1bm5lbGluZyBpbiBlbmNyeXB0ZWQgdHJh ZmZpYywgYWxyZWFkeSBodXJ0aW5nIGJpbGxpb25zIG9mIHBlb3BsZSwgc29tZXRpbWVzIHdpdGgg ZGlyZSBjb25zZXF1ZW5jZXMgZm9yIHRoZWlyIHByaXZhY3ksIGZyZWVkb20sICYgcGh5c2ljYWwg d2VsbCBiZWluZy4NCg0KVGhlIG1lZXRpbmcgd2lsbCBiZToNCioqIFdoZW46IFdlZG5lc2RheSwg Tm92ZW1iZXIgMTUsIDhwbTx4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzOi8vMD4sIHNob3J0bHkgZm9s bG93aW5nIHRoZSBwbGVuYXJ5Lg0KKiogV2hlcmU6IE9yY2hhcmQgUm9vbSBvZiB0aGUgQ29udmVu dGlvbiBDZW50ZXIgd2hlcmUgdGhlIElFVEYgTWVldGluZ3MgYXJlIGJlaW5nIGhlbGQuDQoNCkkg bm90ZSB0aGF0IHByZS1jb25jZXB0aW9ucyBoYXZlIHNldmVyZWx5IHBvbGFyaXplZCBhIG51bWJl ciBvZiBwYXN0IGF0dGVtcHRzIGF0IHNvbHZpbmcgcHJvYmxlbXMgc2ltaWxhciB0byB0aGlzLCBh bmQgd2l0aG91dCBiZXR0ZXIgc3RhbmRhcmRzIGZvciBzdWNoIHByb3RlY3Rpb24sIHNlY3VyaXR5 IHN1ZmZlcnMgaW4gbWFueSB3YXlzLCBpbmNsdWRpbmcgY2hhbGxlbmdlcyBzYWZlbHkgcm9sbGlu ZyBvdXQgaW1wb3J0YW50IG5ldyBwcm90b2NvbHMgbGlrZSBUTFMgMS4zIGFzIHF1aWNrbHkgYW5k IGFzIHdpZGVseSBhcyB3ZeKAmWQgYWxsIGxpa2UuICBXZSBzZWVrIGEg4oCcbWlkZGxl4oCdIGdy b3VuZCB0aGF0IGlzIG5vdCBhIHNhY3JpZmljZSBieSBlaXRoZXIgc2lkZSBidXQgcmF0aGVyIGhv cGVmdWxseSBhIGJlc3Qgb2YgYm90aCB3b3JsZHMuDQoNCklmIHlvdSBhcmUgd2FudGluZyB0byBw cm90ZWN0IGFnYWluc3QgYXR0YWNrcyB0dW5uZWxpbmcgaW4gZW5jcnlwdGVkIHRyYWZmaWMsIGFu ZCB3YW50aW5nIHRvIG1ha2Ugc3VjaCBwcm90ZWN0aW9uIGZhciBzYWZlciBmcm9tIGJvdGggc2Vj dXJpdHkgYW5kIHByaXZhY3kgcGVyc3BlY3RpdmVzLCBwbGVhc2Ugam9pbiB1cyBmb3IgdGhpcyBt ZWV0aW5nLCBhbmQgcGxlYXNlIGpvaW4gdXMgaW4gaGVscGluZyBrZWVwIGRpc2N1c3Npb24gY29u c3RydWN0aXZlIGFuZCByZXNwZWN0ZnVsIG9mIHBlb3BsZSB3aXRoIHdpZGVseSBkaWZmZXJpbmcg dmlld3MuICBJIGJlbGlldmUgd2UgYWxsIHdhbnQgdG8gbWFrZSB0aGUgSW50ZXJuZXQgYW5kIHdv cmxkIHNhZmVyLg0KDQpXaXRoIE15IERlZXBlc3QgVGhhbmtzIEZvciBBbGwgVGhhdCBZb3UgRG8g Rm9yIFRoZSBJRVRGLCBBbmQgRm9yIFRoZSBXb3JsZCBUaHJvdWdoIFRoZSBJRVRGLA0KQnJpYW4N Cg0KYndpdHRlbkBzeW1hbnRlYy5jb208bWFpbHRvOmJ3aXR0ZW5Ac3ltYW50ZWMuY29tPg0KDQoN CkJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOg0KDQpGcm9tOiBCcmlhbiBXaXR0ZW4gPGJyaWFuX3dp dHRlbkBzeW1hbnRlYy5jb208bWFpbHRvOmJyaWFuX3dpdHRlbkBzeW1hbnRlYy5jb20+Pg0KRGF0 ZTogTm92ZW1iZXIgOCwgMjAxNyBhdCAxMjo1OTo1NSBBTSBQU1QNClRvOiAicGF0aWVudEBpZXRm Lm9yZzxtYWlsdG86cGF0aWVudEBpZXRmLm9yZz4iIDxwYXRpZW50QGlldGYub3JnPG1haWx0bzpw YXRpZW50QGlldGYub3JnPj4NClN1YmplY3Q6IEFubm91bmNpbmcgdGhlIFBBVElFTlQgbWVldGlu ZyBpbiBTaW5nYXBvcmUNCg0KRGVhciBBbGwsDQoNCkZvciBhbnlvbmUgaW50ZXJlc3RlZCBpbiBQ cm90ZWN0aW5nIGFnYWluc3QgQXR0YWNrcyBUdW5uZWxpbmcgSW4gRW5jcnlwdGVkIE5ldHdvcmsg VHJhZmZpYyAoUEFUSUVOVCksIHdlJ2xsIGJlIGhhdmluZyBhIG1lZXRpbmcgaW4gU2luZ2Fwb3Jl Lg0KKiogV2hlbjogV2VkbmVzZGF5LCBOb3ZlbWJlciAxNSwgOHBtLCBzaG9ydGx5IGZvbGxvd2lu ZyB0aGUgcGxlbmFyeS4NCioqIFdoZXJlOiBPcmNoYXJkIFJvb20gb2YgdGhlIENvbnZlbnRpb24g Q2VudGVyIHdoZXJlIHRoZSBJRVRGIE1lZXRpbmdzIGFyZSBiZWluZyBoZWxkLg0KDQpUaGlzIHNp ZGUgbWVldGluZyBpcyBha2luIHRvICJiYXIgQk9GIiBpbiBwcmVwYXJhdGlvbiBmb3IgaG9wZWZ1 bGx5IGhvc3RpbmcgYSBmdWxsIEJpcmRzIG9mIGEgRmVhdGhlciAoQk9GKSBtZWV0aW5nIGF0IElF VEYgMTAxIGluIExvbmRvbiBpbiBhIGZldyBtb250aHMuICBQbGVhc2UgZmVlbCBmcmVlIHRvIGRp cmVjdGx5IGxldCBtZSBrbm93IGFueSBxdWVzdGlvbnMgb3IgY29uY2VybnMuDQoNCldpdGggTXkg RGVlcGVzdCBUaGFua3MgRm9yIEFsbCBUaGF0IFlvdSBEbyBGb3IgVGhlIElFVEYsIEFuZCBGb3Ig VGhlIFdvcmxkIFRocm91Z2ggVGhlIElFVEYsDQpCcmlhbg0KDQpid2l0dGVuQHN5bWFudGVjLmNv bTxtYWlsdG86YndpdHRlbkBzeW1hbnRlYy5jb20+DQoNCkZyb206IFBBVElFTlQgPHBhdGllbnQt Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86cGF0aWVudC1ib3VuY2VzQGlldGYub3JnPj4gb24gYmVo YWxmIG9mIEJyaWFuIFdpdHRlbiA8YnJpYW5fd2l0dGVuQHN5bWFudGVjLmNvbTxtYWlsdG86YnJp YW5fd2l0dGVuQHN5bWFudGVjLmNvbT4+DQpTZW50OiBNb25kYXksIE5vdmVtYmVyIDYsIDIwMTcg NDoyNiBQTQ0KVG86IHBhdGllbnRAaWV0Zi5vcmc8bWFpbHRvOnBhdGllbnRAaWV0Zi5vcmc+DQpT dWJqZWN0OiBbRVhUXSBbUGF0aWVudF0gV2VsY29tZSB0byB0aGUgUEFUSUVOVCBNYWlsaW5nIExp c3QNCg0KDQpEZWFyIEFsbCwNCg0KV2VsY29tZSB0byB0aGUgbWFpbGluZyBsaXN0IGZvciBQcm90 ZWN0aW5nIGFnYWluc3QgQXR0YWNrcyBUdW5uZWxpbmcgSW4gRW5jcnlwdGVkIE5ldHdvcmsgVHJh ZmZpYyAoUEFUSUVOVCkuDQoNCldlIGFyZSB0aHJpbGxlZCB0byBzZWUgb3ZlciBoYWxmIG9mIHRo ZSB3b3JsZOKAmXMgd2ViIGNvbm5lY3Rpb25zIGVuY3J5cHRlZCwgYW5kIHdlIGRvIG5vdCB3YW50 IHRvIHdlYWtlbiBjcnlwdG8gb3IgVExTIGluIGFueSB3YXkuICBBdCB0aGUgc2FtZSB0aW1lLCBo YWxmIG9mIHRoZSB3b3JsZOKAmXMgYXR0YWNrcyBhcmUgbm93IHR1bm5lbGluZyB0aHJvdWdoIGVu Y3J5cHRlZCBzZXNzaW9ucywgYW5kIG1hbnkgZW5kcG9pbnRzIG5lZWQgaGVscCBwcm90ZWN0aW5n ICB0aGVtc2VsdmVzIGFnYWluc3QgdGhlc2UgYXR0YWNrcy4gIE9mdGVuIHRoZXkgY2FuIG9ubHkg Z2V0IHRoYXQgaGVscCBmcm9tIHRoZSBuZXR3b3JrLiAgRm9ydHVuYXRlbHksIHRoZXJlIGFyZSBp biBmYWN0IHdheXMgZm9yIG5ldHdvcmsgZGV2aWNlcyB0byBoZWxwIHByb3RlY3QgYWdhaW5zdCB0 aGUgZnVsbCByYW5nZSBvZiBhdHRhY2tzIHRoYXQgbWlnaHQgYmUgdHVubmVsaW5nIHRocm91Z2gg ZW5jcnlwdGVkIHNlc3Npb25zLiAgU3RpbGwsIGZvciAgZW5kcG9pbnRzIHRvIGdldCBzdWNoIGhl bHAgb2YgY291cnNlIHRoZXkgbmVlZCB0byBUcnVzdCBzb21lIGVudGl0eSBvciBzZXJ2aWNlIGlu IHRoZSBuZXR3b3JrIHRvIGhlbHAgcHJvdGVjdCB0aGVtLiAgVGhhdCBlbnRpdHkgb3Igc2Vydmlj ZSBoZWxwaW5nIHByb3RlY3QgdGhlbSBtaWdodCBiZSBvcGVyYXRpbmcgb24gdGhlaXIgYmVoYWxm LCBvciBvbiBiZWhhbGYgb2YgdGhlaXIgZW1wbG95ZXIsIG9yIHNvbWUgb3RoZXIgZW50aXR5IHRo ZXkgY2hvb3NlICB0byB0cnVzdC4gIEhvd2V2ZXIsIHRoZXkgaGF2ZSBhIHJpZ2h0IHRvIGNob29z ZSB3aG8gdGhleSB0cnVzdCB0byBwcm90ZWN0IHRoZW0uICBGb3IgdGhlc2UgcmVhc29ucywgd2Ug d2FudCB0byBjb2xsZWN0aXZlbHkgZW5naW5lZXIgYSBzZWN1cmUgbXVsdGktcGFydHkgcHJvdG9j b2wgd2hpY2g6DQoNCihhKSBIZWxwcyBlYWNoIGVuZHBvaW50IGNvbnRyb2wgd2hpY2ggcGFydGll cyBhbmQgbmV0d29yayBkZXZpY2VzIGFyZSBlbXBvd2VyZWQgdG8gZGVjcnlwdCB0cmFmZmljIHRv IGhlbHAgcHJvdGVjdCB0aGVtLA0KKGIpIEhlbHBzIGVhY2ggZW5kcG9pbnQgc2VlIHdoZW4gb25l IG9mIHRob3NlIHBhcnRpZXMgb3IgZGV2aWNlcyBtb2RpZmllcyBjb250ZW50IGNvbWluZyBmcm9t IHRoZSBvdGhlciBlbmRwb2ludCwgc3VjaCBhcyByZW1vdmluZyBhdHRhY2tzLCBhbmQgc2VlIHRo YXQgd2l0aCBhIGNyeXB0b2dyYXBoaWMgYXVkaXQgdHJhaWwgb2Ygd2hvIGNoYW5nZWQgd2hhdCB3 aGVyZSB3aGVuIGFuZCB3aHksIHN1Y2ggYXMgcmVtb3ZpbmcgYXR0YWNrcywNCihjKSBBbmQgZG9l cyBhbGwgb2YgdGhlIGFib3ZlIHdpdGhvdXQgYnJlYWtpbmcgb3Igd2Vha2VuaW5nIGFueSBvZiB0 aGUgY3J5cHRvZ3JhcGh5IG9yIGNyeXB0b2dyYXBoaWMgcHJvdG9jb2xzIGluIGFueSB3YXksIGlu Y2x1ZGluZyBub3QgYnJlYWtpbmcgb3IgY2hhbmdpbmcgVExTLg0KDQpJdCBpcyBpbXBvcnRhbnQg dG8gY29uc2lkZXIgdGhlIOKAnGRlbGVnYXRlZCBwcm90ZWN0aW9u4oCdIG1vZGVsLiAgSW4gc3Vj aCBhIG1vZGVsLCB1bmF1dGhvcml6ZWQgZWF2ZXNkcm9wcGVycyByZXByZXNlbnQgb25lIG9mIGF0 IGxlYXN0IHR3byBjcnVjaWFsIHRocmVhdHMgd2hpY2ggbXVzdCBiZSBtaXRpZ2F0ZWQuICBJbiBz dWNoIGEgbW9kZWwsIHRoZSByZW1vdGUgZW5kcG9pbnQgcmVwcmVzZW50cyBhbm90aGVyIGNydWNp YWwgdGhyZWF0IHdoaWNoIG11c3QgIGJlIG1pdGlnYXRlZCBhcyB0aGF0IHJlbW90ZSBlbmRwb2lu dCBtaWdodCBiZSBtYWxpY2lvdXMgZXZlbiB0aG91Z2ggdGhlIGVuZHBvaW50IG9mIG91ciBjYXJl IHdhbnRzIG9yIG5lZWRzIHRvIGNvbW11bmljYXRlIHdpdGggdGhhdCByZW1vdGUgZW5kcG9pbnQu ICBUaGlzIG1vZGVsIGlzIHN1cnByaXNpbmdseSBjb21tb24gdG9kYXkuICBGb3IgaW5zdGFuY2Us IHNlcnZlciB0byBjbGllbnQgd2ViIGF0dGFja3MgYXJlIGluY3JlYXNpbmdseSBjb21tb24gIGJ5 IG1hbGljaW91cyBvciBjb21wcm9taXNlZCB3ZWJzaXRlcy4gIE9mIGNvdXJzZSwgY2xpZW50IHRv IHNlcnZlciBhdHRhY2tzIGhhdmUgYmVlbiBjb21tb24gZm9yIHllYXJzLiAgTW9yZSByZWNlbnRs eSwgaXTigJlzIGJlY29tZSBpbmNyZWFzaW5nbHkgY29tbW9uIGZvciBzZXJ2ZXJzIHRvIHN1cnZl aWwgYW5kIHByb2ZpbGUgY2xpZW50cywgYSBwcml2YWN5IHRocmVhdCBjb21wb3VuZGVkIGJ5IHNl cnZlcnMgY29sbGFib3JhdGluZyB0aHJvdWdoICBtYXNzaXZlIGFkdmVydGlzaW5nIChhZCkgbmV0 d29ya3MgZm9yIHRyYWNraW5nIHVzZXIgYWN0aXZpdGllcy4gIFN1Y2ggc3VydmVpbGxhbmNlIHRo cm91Z2ggcHJvZmlsaW5nIGFuZCB0cmFja2luZyByZXByZXNlbnRzIGEgcHJpdmFjeSB0aHJlYXQg bWFueSBwZW9wbGUgd291bGQgbGlrZSB0byBzZWUgYmV0dGVyIG1pdGlnYXRlZC4gIEluIGZhY3Qs IGl0IGlzIGFsc28gYSBwcml2YWN5IHRocmVhdCB0aGF0IGNhbiBiZSBwb3RlbnRpYWxseSBtaXRp Z2F0ZWQgIGJ5IHByb3RlY3Rpb24gc2VydmljZXMgcnVubmluZyBpbiB0aGUgbmV0d29yay4gIElu IGFsbCBzdWNoIGNhc2VzLCBpdOKAmXMgcmVhc29uYWJsZSBmb3IgbGltaXRlZCBlbmRwb2ludHMg dG8gY2hvb3NlIG1vcmUgcG93ZXJmdWwgbmV0d29yayBzZXJ2aWNlcyB0byBwcm90ZWN0IHRoZW0g YWdhaW5zdCBzdWNoIHRocmVhdHMuDQoNCkZvcnR1bmF0ZWx5LCBzZXZlcmFsIHN0YXJ0aW5nIHBs YWNlcyBleGlzdCBmb3IgcHJvdG9jb2xzIHRvIGFjaGlldmUgcmVxdWlyZW1lbnRzIChhKSwgKGIp LCBhbmQgKGMpIGFib3ZlLiAgRm9yIGluc3RhbmNlLCB3aXRoIHNvbWUgbW9kaWZpY2F0aW9ucywg aXQgd291bGQgYmUgZ29vZCB0byB1c2UgdGhlIFN0aWNrbGVyIHByb3RvY29sIHByb3Bvc2VkIGJ5 IEEuDQpMZXZ5LCBILiBDb3JyaWdhbi1HaWJicywgYW5kIEQuIEJvbmVoIGluIGNvbmp1bmN0aW9u IHdpdGggbW9kaWZpZWQgdmFyaWFudHMgb2YgdW5mb3J0dW5hdGVseSBuYW1lZCBwcm90b2NvbHMg c3VjaCBhcyBtYlRMUyBhbmQvb3IgVExTLVJBUi4gIE91ciB2aXNpb24gaXMgZm9yIHN1Y2ggYSBw cm90b2NvbCB0byBydW4gaW4gcGFyYWxsZWwgdG8gVExTLCBjb21wbGltZW50aW5nIGl0LCB3aXRo b3V0IG1vZGlmeWluZyBvciBjb25zdHJhaW5pbmcgVExTICB3aGlsZSBoZWxwaW5nIGNvb3JkaW5h dGUgbmV0d29yayBwcm90ZWN0aW9uIG9mIGVuZHBvaW50cy4gIFRvIGRvIHNvLCBzdWNoIGEgcHJv dG9jb2wgc2hvdWxkIGFsc28gYmV0dGVyIGluZm9ybSBlbmRwb2ludHMgb2YgdGhlIHNwZWNpZmlj cyBvZiBuZXR3b3JrIGRldmljZXMgYXZhaWxhYmxlIGZvciBwcm90ZWN0aW9uLCBzcGVjaWZpY3Mg d2hpY2ggdGhlIGVuZHBvaW50IG1pZ2h0IGNhcmUgYWJvdXQgYmVmb3JlIGVtcG93ZXJpbmcgc3Vj aCBuZXR3b3JrICBkZXZpY2VzIGJ5IHRydXN0aW5nIHRoZW0gdG8gaGVscCBwcm92aWRlIHN1Y2gg cHJvdGVjdGlvbi4NCg0KV2l0aCBzdWNoIHZhbHVhYmxlIHJlc2VhcmNoIGFjY29tcGxpc2hlZCB0 byBkYXRlIGluIHRoaXMgc3BhY2UgcHJvcG9zaW5nIGEgdmFyaWV0eSBvZiBwb3RlbnRpYWwgcHJv dG9jb2xzIGFzIHN0YXJ0aW5nIHBvaW50cywgaXTigJlzIGltcG9ydGFudCB0byBzb29uIGVuZ2lu ZWVyIGEgc3RhbmRhcmRpemVkIHByb3RvY29sIHRvIG1lZXQgdGhlIHJvdWdoIGNvbnNlbnN1cyBv ZiB0aGUgSUVURiBmb3IgcHJvdmlkaW5nIHN1Y2ggcHJvdGVjdGlvbiBtb3JlICBzYWZlbHkgdGhh biB0b2RheeKAmXMgY29tbW9uIHByYWN0aWNlcy4gIFRvZGF54oCZcyBjb21tb24gcHJhY3RpY2Vz IG5vdCBvbmx5IGZhaWwgdG8gbWVldCB0aGUgdGhyZWUgcmVxdWlyZW1lbnRzIG91dGxpbmVkIGFi b3ZlLCBidXQgdG9kYXnigJlzIGNvbW1vbiBwcmFjdGljZXMgYWxzbyAoMSkgYWxsb3cgbWlkZGxl Ym94ZXMgdG8gbmVnb3RpYXRlIHdlYWtlciBUTFMgc2Vzc2lvbnMgd2l0aG91dCBhZHZpc2luZyB0 aGUgZW5kcG9pbnQgb2YgdGhlIHJpc2tzICBvZiB0aGUgd2Vha2VyIHNlc3Npb24gb24gdGhlIGZh ciBzaWRlIG9mIHRoZSBtaWRkbGVib3gsICgyKSBmYWlsIHRvIGluZm9ybSB0aGUgZW5kcG9pbnRz IG9mIGhvdyBzZWN1cmUgdGhlIG1pZGRsZWJveCBtaWdodCBvciBtaWdodCBub3QgYmUsIHRoZSBt YW5uZXIgaW4gd2hpY2ggdGhlIG1pZGRsZWJveCBpdHNlbGYgaXMgc2FmZWd1YXJkZWQsIGFuZCAo MykgZmFpbCB0byBpbmZvcm0gdGhlIGVuZHBvaW50cyBvZiB0aGUgaW5mb3JtYXRpb24gcmV0ZW50 aW9uICBhbmQgZGlzY2xvc3VyZSBwb2xpY2llcyB1bmRlciB3aGljaCB0aGUgbWlkZGxlYm94IGlz IG9wZXJhdGluZy4NCg0KQ2xlYXJseSBhIGJldHRlciBhcHByb2FjaCBpcyBuZWVkZWQsIGFuZCB1 cmdlbnRseS4gIE5ldHdvcmsgbWVkaWF0aW9uIGNhbiBwbGF5IGEgY3J1Y2lhbCByb2xlIGluIHBy b3RlY3RpbmcgcGVvcGxlIGZyb20gdGhlIHNlcnZlciB0byBjbGllbnQgYXR0YWNrcyB0aGF0IGhh dmUgYmVlbiB1c2VkIHRvIHVubWFzayB0aGUgYW5vbnltaXR5IG9mIGRpc3NpZGVudHMgc3BlYWtp bmcgdXAgYWdhaW5zdCByZXByZXNzaXZlIHJlZ2ltZXMsIGRpc3NpZGVudHMgIHdobyB3ZXJlIHRo ZW4gZGlzYXBwZWFyZWQgYWZ0ZXIgdGhlIHNlcnZlciB0byBjbGllbnQgYXR0YWNrcyB3ZXJlIHVz ZWQgdG8gdW5tYXNrIHRoZW0gYnkgY29tcHJvbWlzaW5nIHRoZWlyIG1vYmlsZSBlbmRwb2ludC4g IFRydXN0d29ydGh5IG5ldHdvcmsgbWVkaWF0aW9uIGNhbiBwbGF5IGEgY3J1Y2lhbCByb2xlIGlu IHByb3RlY3RpbmcgcGVvcGxlIGFnYWluc3Qgc3VjaCBhdHRhY2tzLCBidXQgdG9kYXksIHdoZXJl IGVuZHBvaW50cyB0cnVzdCAgbWlkZGxlYm94ZXMsIHRoZXJlIGlzIG5vdCB5ZXQgYSBzdGFuZGFy ZGl6ZWQgcHJvdG9jb2wgZm9yIGVuZHBvaW50cyB0byB1bmRlcnN0YW5kIHdoZW4gdGhvc2UgbWlk ZGxlYm94ZXMgYXJlIHdlYWtlbmluZyB0aGUgY3J5cHRvLCBjaGFuZ2luZyB0aGUgY29udGVudCwg dHJ1c3Rpbmcgb3RoZXIgbWlkZGxlYm94ZXMsIGFuZCBkb2luZyBvdGhlciB0aGluZ3MgdGhhdCBt aWdodCBjYXVzZSB0aGUgZW5kcG9pbnQgdG8gbm90IHRydXN0IHRoZSBtaWRkbGVib3guDQoNClN0 aWxsLCBlbmdpbmVlcmluZyBzdWNoIGEgcHJvdG9jb2wgaXMgbm90IGVhc3kuICBTdWNoIHByb3Rv Y29scyB3b3VsZCBuZWVkIHRvIGFkZHJlc3MgYSByYW5nZSBvZiB1c2UgY2FzZXMgaW5jbHVkaW5n IGJvdGggcmVhbC10aW1lIGFuZCBwb3N0LWZhY3RvLCBhbG9uZyB3aXRoIGJvdGggd2lkZS1hcmVh IGFuZCBkYXRhY2VudGVyIHVzZSBjYXNlcy4gIEFzIGluaXRpYWwgd29ya2luZyBkaWZmZXJlbnRp YXRpb24gb2YgdGhlc2UgdGVybXMsIHdl4oCZZCAgcHJvcG9zZSByZWFsLXRpbWUgdG8gaW5jbHVk ZSBibG9ja2luZyBvZiBhdHRhY2tzLiBQb3N0LWZhY3RvIGluY2x1ZGVzIGJvdGggZm9yZW5zaWMg aW52ZXN0aWdhdGlvbiBvZiBzb3BoaXN0aWNhdGVkIGF0dGFja3MgYW5kIGFsc28gYXVkaXQgY29t cGxpYW5jZSBha2Egb3V0LW9mLWJhbmQgZGVjcnlwdGlvbi4gV2lkZS1hcmVhIHVzZSBjYXNlcyBp bmNsdWRlIHNoYXJlZCBuZXR3b3JrcyB3aGVyZSB0aGUgZGV2aWNlIG9yIGVudGl0eSBoZWxwaW5n ICBwcm92aWRlIHByb3RlY3Rpb24gaXMgb25seSByZWFjaGVkIGFjcm9zcyBhIG5ldHdvcmsgb3Bl cmF0ZWQgYnkgYW5kL29yIHNoYXJlZCB3aXRoIG90aGVyIHVudHJ1c3RlZCBwYXJ0aWVzLiAgVGhl IGRhdGFjZW50ZXIgdXNlIGNhc2UgaW5jbHVkZXMgbmV0d29ya3MgYWRqYWNlbnQgdG8gdGhlIGVu ZHBvaW50IGFuZCBvd25lZCBieSB0aGUgc2FtZSBwYXJ0eSBhcyBvd25pbmcgdGhlIGVuZHBvaW50 Lg0KDQpJbiBlbmdpbmVlcmluZyBzdWNoIGEgcHJvdG9jb2wsIGl04oCZcyBpbXBvcnRhbnQgdG8g cmVzcGVjdCBmdW5kYW1lbnRhbCBwcmluY2lwbGVzIG9mIGVuZC10by1lbmQgZW5jcnlwdGlvbiBh bmQsIGF0IHRpbWVzLCBzaW1pbGFyIGVuZC10by1lbmQgZmxleGliaWxpdHkgaW4gcm91dGUgb3B0 aW1pemF0aW9uLiAgT24gZW5kLXRvLWVuZCBlbmNyeXB0aW9uLCBzb21lIG9mIHRoZSBhcHByb2Fj aGVzIHRoYXQgaGF2ZSBiZWVuIHByb3Bvc2VkIGluY2x1ZGUgIGxldmVyYWdpbmcgdGhlIHN5bW1l dHJpYyBrZXkgZGV0ZXJtaW5lZCBzdHJpY3RseSBiZXR3ZWVuIHRoZSBzZXJ2ZXIgYW5kIGNsaWVu dCwgYW5kIHRoZW4gaGF2aW5nIHRoZSBlbmRwb2ludCBzaGFyZSB0aGF0IHN5bW1ldHJpYyBrZXkg b25seSB3aXRoIGEgbmV0d29yayBkZXZpY2Ugb3Igc2VydmljZSB3aGljaCBpdCB0cnVzdHMgdG8g aGVscCB3aXRoIHByb3RlY3Rpb24gYWdhaW5zdCB0aGUgcmVtb3RlIGVuZHBvaW50LiAgSW4gYWRk aXRpb24gdG8gIHByZXNlcnZpbmcgZW5kLXRvLWVuZCBlbmNyeXB0aW9uIGFuZCBhY2NlbGVyYXRp bmcgZGVwbG95bWVudCBvZiBzdHJvbmdlciBjcnlwdG8sIGl04oCZcyBhbHNvIGltcG9ydGFudCB0 byBwcmVzZXJ2ZSBlbmQtdG8tZW5kIGZsZXhpYmlsaXR5IGluIHJvdXRpbmcgd2hlbmV2ZXIgcG9z c2libGUuICBDdXJyZW50bHksIGZvciBhdHRhY2tzIHR1bm5lbGluZyB0aHJvdWdoIGVuY3J5cHRl ZCBuZXR3b3JrIHNlc3Npb25zLCBuZXR3b3JrIGJhc2VkIHByb3RlY3Rpb24gIGlzIG9mdGVuIHBy b3ZpZGVkIHRocm91Z2ggcHJveGllcyBhbmQgdGhlIGxpa2UgZWl0aGVyIGVtYmVkZGVkIGluIG5l dHdvcmsgZ2F0ZXdheXMgb3IgZGF0YWNlbnRlcnMgaG9zdGluZyBwZXJzb25hbC1WUE4gdHlwZSBj bG91ZCBiYXNlZCBzZXJ2aWNlcyB0aHJvdWdoIHdoaWNoIGFsbCBvZiBhIGNsaWVudOKAmXMgdHJh ZmZpYyBpcyByb3V0ZWQuICBIb3dldmVyLCBsb25nZXIgdGVybSwgc3VjaCBwcm90ZWN0aW9uIGNv dWxkIGJlIGFjaGlldmVkIGJ5ICBoYXZpbmcgc3VjaCDigJxwcm90ZWN0aW9uIHNlcnZpY2Vz4oCd IHJ1bm5pbmcgbW9yZSBmbGV4aWJseSBpbiBhIGRpc3RyaWJ1dGVkIG1hbm5lciwgaW4gaGFyZHdh cmUgcHJvdGVjdGVkIGVuY2xhdmVzIGFuZC9vciBUcnVzdGVkIEV4ZWN1dGlvbiBFbnZpcm9ubWVu dHMgbWlncmF0aW5nIHRoZSBmdW5jdGlvbmFsaXR5IGFtb25nIFNvZnR3YXJlIERlZmluZWQgTmV0 d29ya2luZyAoU0ROKSBhbmQvb3IgTmV0d29yayBGdW5jdGlvbiBWaXJ0dWFsaXphdGlvbiAgKE5G VikgZW5hYmxlZCBlcXVpcG1lbnQuDQoNCkZyb20gZGlzY3Vzc2lvbnMgd2l0aGluIG5vdCBvbmx5 IElFVEYgcGFydGljaXBhbnRzLCBidXQgYWxzbyBwZW9wbGUgZW5nYWdlZCBpbiByZWxhdGVkIGRp c2N1c3Npb25zIGluIElFRUUsIFVOL0lUVSwgRVRTSSwgYW5kIG90aGVycyBpbiB0aGlzIGFyZWEg ZWFnZXIgdG8gcGFydGljaXBhdGUgaW4gYW4gSUVURiBwcm9jZXNzIGluIHRoaXMgYXJlYSwgd2Ug YmVsaWV2ZSB0aGF0IHRoZXJlIGlzIGEgY3JpdGljYWwgbWFzcyBvZiBwYXJ0aWNpcGFudHMgIHdp bGxpbmcgdG8gd29yayBvbiB0aGUgcHJvYmxlbSAoZS5nLiwgd3JpdGUgZHJhZnRzLCByZXZpZXcg ZHJhZnRzLCBldGMuKSBmb3IgbWVldGluZyByZXF1aXJlbWVudHMgKGEpLCAoYiksIGFuZCAoYykg ZGVzY3JpYmVkIGFib3ZlLiAgTWFueSBvZiB1cyBwZXJzb25hbGx5IGJlbGlldmUgdGhhdCB0aGUg SUVURiBpcyB0aGUgcmlnaHQgYmVzdCBwbGFjZSBmb3Igc3VjaCB3b3JrIGZvciBjb3VudGxlc3Mg cmVhc29ucy4gV2UgYXJlIG9mIGNvdXJzZSAgdmVyeSBmYW1pbGlhciB3aXRoIHByZXZpb3VzIGF0 dGVtcHRzIHdpdGhpbiB0aGUgSUVURiwgaW5jbHVkaW5nIEV4cGxpY2l0bHkgVHJ1c3RlZCBQcm94 eSBhbmQgVExTIFByb3h5IHNlcnZlciBhbW9uZyBvdGhlcnMuDQoNCldlIGFyZSBhbHNvIGF3YXJl IG9mIHRoZSBuZWVkIGZvciBjb29yZGluYXRpb24gb2Ygc3VjaCB3b3JrIG5vdCBvbmx5IHdpdGgg dGhlIFRMUyB3b3JraW5nIGdyb3VwLCBidXQgYWxzbyBEUFJJVkUsIFFVSUMsIEkyTlNGLCBhbmQg b3RoZXIgSUVURiBlZmZvcnRzLCBhbmQgd2UgYmVsaWV2ZSB0aGF0IGFuIGluZGVwZW5kZW50IFdH IGNvdWxkIGJlIG1vcmUgaGVscGZ1bCB0aGFuIHRyeWluZyB0byBkbyBhbGwgb2YgdGhpcyB3b3Jr IGluIGFueSBleGlzdGluZyAgd29ya2luZyBncm91cCBzdWNoIGFzIHRoZSBUTFMgV0csIHBhcnRp Y3VsYXJseSBzaW5jZSB0aGUgYmVzdCBzb2x1dGlvbiBtaWdodCBiZSBhIG5ldyBwcm90b2NvbCB0 aGF0IGNvbXBsaW1lbnRzIFRMUywgcnVubmluZyBpbiBjb25qdW5jdGlvbiB3aXRoIFRMUywgd2l0 aG91dCBleHRlbmRpbmcsIGNoYW5naW5nLCByZWZpbmluZywgb3IgYnJlYWtpbmcgaXQsIG9yIGFu eSBvdGhlciBleGlzdGluZyBwcm90b2NvbHMgYWxyZWFkeSBzbyBpbXBvcnRhbnQgIHRvIHNlY3Vy aXR5IGFuZCBwcm9wZXIgZnVuY3Rpb25pbmcgb2YgdGhlIG5ldHdvcmsuDQoNCkluIHRoYXQgdGhl IHdvcmxkIGhhcyBhbHJlYWR5IHNlZW4gYW5vbnltb3VzIGRpc3NpZGVudHMgZGlzYXBwZWFyZWQg YWZ0ZXIgd2hhdCBtYW55IHdvdWxkIGNvbnNpZGVyIHJlcHJlc3NpdmUgcmVnaW1lcyB1c2VkIHNv cGhpc3RpY2F0ZWQgc2VydmVyLXRvLWNsaWVudCBhdHRhY2tzIHRvIHVubWFzayB0aGVpciBhbm9u eW1pdHksIEkgYmVsaWV2ZSB0aGF0IHdlIG5lZWQgYSB3b3JsZCB3aGVyZSBib3RoICgxKSB0aGUg Y29ubmVjdGlvbnMgYXJlIHNlY3VyZSAgYSBsYSBncmVhdCBUTFMsIGFuZCAoMikgdGhlIHRyYWZm aWMgaXMgc2FmZSB0byByZWNlaXZlLCBhcyB2ZXR0ZWQgYnkgc29tZXRoaW5nIG9yIHNvbWVvbmUg dGhlIGVuZHBvaW50IGNob29zZXMgZm9yIHByb3RlY3Rpb24gYWdhaW5zdCByZW1vdGUgZW5kcG9p bnRzLg0KDQpJbiB0aGF0IGNvbnRleHQsIHdlIGFyZSBkZWVwbHkgZ3JhdGVmdWwgdGhhdCBJRVRG IGhhcyBhbGxvd2VkIGNyZWF0aW9uIG9mIHRoaXMgbWFpbGluZyBsaXN0IGZvciBkaXNjdXNzaW9u IG9mIHRoZXNlIGltcG9ydGFudCB0b3BpY3MuICBQbGVhc2UgbGV0IG1lIGtub3cgYW55dGhpbmcg dGhhdCBJIGNhbiBkbyB0byBoZWxwIHlvdSBvciB0aGUgSUVURiBvbiB0aGlzLg0KDQpXaXRoIE15 IERlZXBlc3QgVGhhbmtzIEZvciBBbGwgVGhhdCBZb3UgRG8gRm9yIFRoZSBJRVRGLCBBbmQgRm9y IFRoZSBXb3JsZCBUaHJvdWdoIFRoZSBJRVRGLA0KQnJpYW4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpQQVRJRU5UIG1haWxpbmcgbGlzdA0KUEFUSUVO VEBpZXRmLm9yZzxtYWlsdG86UEFUSUVOVEBpZXRmLm9yZz4NCg== --_000_656F31A992084EA8B9A77D3518AF542Bsymanteccom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8 ZGl2PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kLWNvbG9yOiByZ2JhKDI1NSwgMjU1LCAyNTUsIDAp OyI+RGVhciBBbGwsPGJyPg0KPGJyPg0KRm9yIGFueW9uZSBpbnRlcmVzdGVkIGluIFByb3RlY3Rp bmcgYWdhaW5zdCBBdHRhY2tzIFR1bm5lbGluZyBJbiBFbmNyeXB0ZWQgTmV0d29yayBUcmFmZmlj IChQQVRJRU5UKSwgSeKAmW0gYW5ub3VuY2luZyBib3RoIGEgbWVldGluZyBiZWxvdywgYW5kIG1h aWxpbmcgbGlzdCwgZnVydGhlciBiZWxvdy4gJm5ic3A7SW50ZW50IG9mIFBBVElFTlQgaXMgdG8g Y3JlYXRlIGEgc2VjdXJlIG11bHRpLXBhcnR5IHByb3RvY29sIGZvciBtYWtpbmcgc3VjaCBwcm90 ZWN0aW9uDQogZmFyIHNhZmVyIHdpdGhvdXQgbW9kaWZ5aW5nLCBjb25zdHJhaW5pbmcsIG9yIGJy ZWFraW5nIFRMUyBpbiBhbnkgd2F5LCBhIHByb3RvY29sIGNvbXBsaW1lbnRpbmcgY3VycmVudCBU TFMgaW5jbHVkaW5nIFRMUyAxLjMuPC9zcGFuPjwvZGl2Pg0KPGRpdj48c3BhbiBzdHlsZT0iYmFj a2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPjxicj4NCjwvc3Bhbj48L2Rp dj4NCjxkaXY+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6IHJnYmEoMjU1LCAyNTUsIDI1 NSwgMCk7Ij5JbnRlbnQgb2YgUEFUSUVOVCBpcyB0byBkbyBzbyZuYnNwOzwvc3Bhbj48c3BhbiBz dHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsiPmluIGxpZ2h0 IG9mIGJvdGggKGEpIHZ1bG5lcmFiaWxpdGllcyBpbiZuYnNwO3RvZGF54oCZcyZuYnNwO2NvbW1v biBhcHByb2FjaGVzLCBhbmQgKGIpIGh1Z2UgZ3Jvd2luZyBudW1iZXIgb2YgYXR0YWNrcw0KIHR1 bm5lbGluZyBpbiBlbmNyeXB0ZWQgdHJhZmZpYywgYWxyZWFkeSBodXJ0aW5nIGJpbGxpb25zIG9m IHBlb3BsZSwgc29tZXRpbWVzIHdpdGggZGlyZSBjb25zZXF1ZW5jZXMgZm9yIHRoZWlyIHByaXZh Y3ksIGZyZWVkb20sICZhbXA7IHBoeXNpY2FsIHdlbGwgYmVpbmcuPC9zcGFuPjwvZGl2Pg0KPGRp dj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZC1jb2xvcjogcmdiYSgyNTUsIDI1NSwgMjU1LCAwKTsi Pjxicj4NCjwvc3Bhbj48L2Rpdj4NCjxkaXY+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQtY29sb3I6 IHJnYmEoMjU1LCAyNTUsIDI1NSwgMCk7Ij5UaGUgbWVldGluZyB3aWxsIGJlOjxicj4NCioqIFdo ZW46Jm5ic3A7PGEgaHJlZj0ieC1hcHBsZS1kYXRhLWRldGVjdG9yczovLzAiIGRpcj0ibHRyIiB4 LWFwcGxlLWRhdGEtZGV0ZWN0b3JzPSJ0cnVlIiB4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzLXR5cGU9 ImNhbGVuZGFyLWV2ZW50IiB4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzLXJlc3VsdD0iMCIgc3R5bGU9 Ii13ZWJraXQtdGV4dC1kZWNvcmF0aW9uLWNvbG9yOiByZ2JhKDAsIDAsIDAsIDAuMjU4ODI0KTsi PldlZG5lc2RheSwgTm92ZW1iZXIgMTUsIDhwbTwvYT4sDQogc2hvcnRseSBmb2xsb3dpbmcgdGhl IHBsZW5hcnkuPGJyPg0KKiogV2hlcmU6IE9yY2hhcmQgUm9vbSBvZiB0aGUgQ29udmVudGlvbiBD ZW50ZXIgd2hlcmUgdGhlIElFVEYgTWVldGluZ3MgYXJlIGJlaW5nIGhlbGQuPGJyPg0KPGJyPg0K SSBub3RlIHRoYXQmbmJzcDtwcmUtY29uY2VwdGlvbnMmbmJzcDtoYXZlIHNldmVyZWx5IHBvbGFy aXplZCZuYnNwO2EgbnVtYmVyIG9mIHBhc3QgYXR0ZW1wdHMgYXQgc29sdmluZyBwcm9ibGVtcyBz aW1pbGFyIHRvIHRoaXMsIGFuZCB3aXRob3V0IGJldHRlciBzdGFuZGFyZHMgZm9yIHN1Y2ggcHJv dGVjdGlvbiwgc2VjdXJpdHkgc3VmZmVycyBpbiBtYW55IHdheXMsIGluY2x1ZGluZyBjaGFsbGVu Z2VzIHNhZmVseSByb2xsaW5nIG91dCBpbXBvcnRhbnQgbmV3IHByb3RvY29scw0KIGxpa2UgVExT IDEuMyBhcyBxdWlja2x5IGFuZCBhcyB3aWRlbHkgYXMgd2XigJlkIGFsbCBsaWtlLiAmbmJzcDtX ZSBzZWVrIGEg4oCcbWlkZGxl4oCdIGdyb3VuZCB0aGF0IGlzIG5vdCBhIHNhY3JpZmljZSBieSBl aXRoZXIgc2lkZSBidXQgcmF0aGVyIGhvcGVmdWxseSBhIGJlc3Qgb2YgYm90aCB3b3JsZHMuPGJy Pg0KPGJyPg0KSWYgeW91IGFyZSB3YW50aW5nIHRvIHByb3RlY3QgYWdhaW5zdCBhdHRhY2tzIHR1 bm5lbGluZyBpbiBlbmNyeXB0ZWQgdHJhZmZpYywgYW5kIHdhbnRpbmcgdG8gbWFrZSBzdWNoIHBy b3RlY3Rpb24gZmFyIHNhZmVyIGZyb20gYm90aCBzZWN1cml0eSBhbmQgcHJpdmFjeSBwZXJzcGVj dGl2ZXMsIHBsZWFzZSBqb2luIHVzIGZvciB0aGlzIG1lZXRpbmcsIGFuZCBwbGVhc2Ugam9pbiB1 cyBpbiBoZWxwaW5nIGtlZXAgZGlzY3Vzc2lvbiBjb25zdHJ1Y3RpdmUNCiBhbmQgcmVzcGVjdGZ1 bCBvZiBwZW9wbGUgd2l0aCB3aWRlbHkgZGlmZmVyaW5nIHZpZXdzLiAmbmJzcDtJIGJlbGlldmUg d2UgYWxsIHdhbnQgdG8gbWFrZSB0aGUgSW50ZXJuZXQgYW5kIHdvcmxkIHNhZmVyLjxicj4NCjxi cj4NCldpdGggTXkgRGVlcGVzdCBUaGFua3MgRm9yIEFsbCBUaGF0IFlvdSBEbyBGb3IgVGhlIElF VEYsIEFuZCBGb3IgVGhlIFdvcmxkIFRocm91Z2ggVGhlIElFVEYsPGJyPg0KQnJpYW48YnI+DQo8 YnI+DQo8YSBocmVmPSJtYWlsdG86YndpdHRlbkBzeW1hbnRlYy5jb20iIGRpcj0ibHRyIiB4LWFw cGxlLWRhdGEtZGV0ZWN0b3JzPSJ0cnVlIiB4LWFwcGxlLWRhdGEtZGV0ZWN0b3JzLXR5cGU9Imxp bmsiIHgtYXBwbGUtZGF0YS1kZXRlY3RvcnMtcmVzdWx0PSIxIj5id2l0dGVuQHN5bWFudGVjLmNv bTwvYT48L3NwYW4+PGJyIHN0eWxlPSItd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87Ij4N CjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KQmVnaW4gZm9yd2FyZGVkIG1l c3NhZ2U6PGJyPg0KPGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+ PGI+RnJvbTo8L2I+IEJyaWFuIFdpdHRlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmJyaWFuX3dpdHRl bkBzeW1hbnRlYy5jb20iPmJyaWFuX3dpdHRlbkBzeW1hbnRlYy5jb208L2E+Jmd0Ozxicj4NCjxi PkRhdGU6PC9iPiBOb3ZlbWJlciA4LCAyMDE3IGF0IDEyOjU5OjU1IEFNIFBTVDxicj4NCjxiPlRv OjwvYj4gJnF1b3Q7PGEgaHJlZj0ibWFpbHRvOnBhdGllbnRAaWV0Zi5vcmciPnBhdGllbnRAaWV0 Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86cGF0aWVudEBpZXRmLm9yZyI+cGF0 aWVudEBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IDxiPkFubm91bmNpbmcg dGhlIFBBVElFTlQgbWVldGluZyBpbiBTaW5nYXBvcmU8L2I+PGJyPg0KPGJyPg0KPC9kaXY+DQo8 L2Jsb2NrcXVvdGU+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+PHNwYW4+RGVhciBB bGwsPC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj5Gb3IgYW55b25lIGludGVy ZXN0ZWQgaW4gUHJvdGVjdGluZyBhZ2FpbnN0IEF0dGFja3MgVHVubmVsaW5nIEluIEVuY3J5cHRl ZCBOZXR3b3JrIFRyYWZmaWMgKFBBVElFTlQpLCB3ZSdsbCBiZSBoYXZpbmcgYSBtZWV0aW5nIGlu IFNpbmdhcG9yZS48L3NwYW4+PGJyPg0KPHNwYW4+KiogV2hlbjogV2VkbmVzZGF5LCBOb3ZlbWJl ciAxNSwgOHBtLCBzaG9ydGx5IGZvbGxvd2luZyB0aGUgcGxlbmFyeS48L3NwYW4+PGJyPg0KPHNw YW4+KiogV2hlcmU6IE9yY2hhcmQgUm9vbSBvZiB0aGUgQ29udmVudGlvbiBDZW50ZXIgd2hlcmUg dGhlIElFVEYgTWVldGluZ3MgYXJlIGJlaW5nIGhlbGQuPC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bh bj48YnI+DQo8c3Bhbj5UaGlzIHNpZGUgbWVldGluZyBpcyBha2luIHRvICZxdW90O2JhciBCT0Ym cXVvdDsgaW4gcHJlcGFyYXRpb24gZm9yIGhvcGVmdWxseSBob3N0aW5nIGEgZnVsbCBCaXJkcyBv ZiBhIEZlYXRoZXIgKEJPRikgbWVldGluZyBhdCBJRVRGIDEwMSBpbiBMb25kb24gaW4gYSBmZXcg bW9udGhzLiAmbmJzcDtQbGVhc2UgZmVlbCBmcmVlIHRvIGRpcmVjdGx5IGxldCBtZSBrbm93IGFu eSBxdWVzdGlvbnMgb3IgY29uY2VybnMuPC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8 c3Bhbj5XaXRoIE15IERlZXBlc3QgVGhhbmtzIEZvciBBbGwgVGhhdCBZb3UgRG8gRm9yIFRoZSBJ RVRGLCBBbmQgRm9yIFRoZSBXb3JsZCBUaHJvdWdoIFRoZSBJRVRGLDwvc3Bhbj48YnI+DQo8c3Bh bj5Ccmlhbjwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0ibWFp bHRvOmJ3aXR0ZW5Ac3ltYW50ZWMuY29tIj5id2l0dGVuQHN5bWFudGVjLmNvbTwvYT48L3NwYW4+ PGJyPg0KPHNwYW4+PC9zcGFuPjxicj4NCjxzcGFuPkZyb206IFBBVElFTlQgJmx0OzxhIGhyZWY9 Im1haWx0bzpwYXRpZW50LWJvdW5jZXNAaWV0Zi5vcmciPnBhdGllbnQtYm91bmNlc0BpZXRmLm9y ZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBCcmlhbiBXaXR0ZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpi cmlhbl93aXR0ZW5Ac3ltYW50ZWMuY29tIj5icmlhbl93aXR0ZW5Ac3ltYW50ZWMuY29tPC9hPiZn dDs8L3NwYW4+PGJyPg0KPHNwYW4+U2VudDogTW9uZGF5LCBOb3ZlbWJlciA2LCAyMDE3IDQ6MjYg UE08L3NwYW4+PGJyPg0KPHNwYW4+VG86IDxhIGhyZWY9Im1haWx0bzpwYXRpZW50QGlldGYub3Jn Ij5wYXRpZW50QGlldGYub3JnPC9hPjwvc3Bhbj48YnI+DQo8c3Bhbj5TdWJqZWN0OiBbRVhUXSBb UGF0aWVudF0gV2VsY29tZSB0byB0aGUgUEFUSUVOVCBNYWlsaW5nIExpc3Q8L3NwYW4+PGJyPg0K PHNwYW4+Jm5ic3A7IDwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+RGVhciBB bGwsPC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bhbj5XZWxjb21lIHRvIHRoZSBt YWlsaW5nIGxpc3QgZm9yIFByb3RlY3RpbmcgYWdhaW5zdCBBdHRhY2tzIFR1bm5lbGluZyBJbiBF bmNyeXB0ZWQgTmV0d29yayBUcmFmZmljIChQQVRJRU5UKS48L3NwYW4+PGJyPg0KPHNwYW4+PC9z cGFuPjxicj4NCjxzcGFuPldlIGFyZSB0aHJpbGxlZCB0byBzZWUgb3ZlciBoYWxmIG9mIHRoZSB3 b3JsZOKAmXMgd2ViIGNvbm5lY3Rpb25zIGVuY3J5cHRlZCwgYW5kIHdlIGRvIG5vdCB3YW50IHRv IHdlYWtlbiBjcnlwdG8gb3IgVExTIGluIGFueSB3YXkuJm5ic3A7IEF0IHRoZSBzYW1lIHRpbWUs IGhhbGYgb2YgdGhlIHdvcmxk4oCZcyBhdHRhY2tzIGFyZSBub3cgdHVubmVsaW5nIHRocm91Z2gg ZW5jcnlwdGVkIHNlc3Npb25zLCBhbmQgbWFueSBlbmRwb2ludHMgbmVlZCBoZWxwDQogcHJvdGVj dGluZyAmbmJzcDt0aGVtc2VsdmVzIGFnYWluc3QgdGhlc2UgYXR0YWNrcy4mbmJzcDsgT2Z0ZW4g dGhleSBjYW4gb25seSBnZXQgdGhhdCBoZWxwIGZyb20gdGhlIG5ldHdvcmsuJm5ic3A7IEZvcnR1 bmF0ZWx5LCB0aGVyZSBhcmUgaW4gZmFjdCB3YXlzIGZvciBuZXR3b3JrIGRldmljZXMgdG8gaGVs cCBwcm90ZWN0IGFnYWluc3QgdGhlIGZ1bGwgcmFuZ2Ugb2YgYXR0YWNrcyB0aGF0IG1pZ2h0IGJl IHR1bm5lbGluZyB0aHJvdWdoIGVuY3J5cHRlZCBzZXNzaW9ucy4mbmJzcDsNCiBTdGlsbCwgZm9y ICZuYnNwO2VuZHBvaW50cyB0byBnZXQgc3VjaCBoZWxwIG9mIGNvdXJzZSB0aGV5IG5lZWQgdG8g VHJ1c3Qgc29tZSBlbnRpdHkgb3Igc2VydmljZSBpbiB0aGUgbmV0d29yayB0byBoZWxwIHByb3Rl Y3QgdGhlbS4mbmJzcDsgVGhhdCBlbnRpdHkgb3Igc2VydmljZSBoZWxwaW5nIHByb3RlY3QgdGhl bSBtaWdodCBiZSBvcGVyYXRpbmcgb24gdGhlaXIgYmVoYWxmLCBvciBvbiBiZWhhbGYgb2YgdGhl aXIgZW1wbG95ZXIsIG9yIHNvbWUgb3RoZXIgZW50aXR5DQogdGhleSBjaG9vc2UgJm5ic3A7dG8g dHJ1c3QuJm5ic3A7IEhvd2V2ZXIsIHRoZXkgaGF2ZSBhIHJpZ2h0IHRvIGNob29zZSB3aG8gdGhl eSB0cnVzdCB0byBwcm90ZWN0IHRoZW0uJm5ic3A7IEZvciB0aGVzZSByZWFzb25zLCB3ZSB3YW50 IHRvIGNvbGxlY3RpdmVseSBlbmdpbmVlciBhIHNlY3VyZSBtdWx0aS1wYXJ0eSBwcm90b2NvbCB3 aGljaDo8L3NwYW4+PGJyPg0KPHNwYW4+PC9zcGFuPjxicj4NCjxzcGFuPihhKSBIZWxwcyBlYWNo IGVuZHBvaW50IGNvbnRyb2wgd2hpY2ggcGFydGllcyBhbmQgbmV0d29yayBkZXZpY2VzIGFyZSBl bXBvd2VyZWQgdG8gZGVjcnlwdCB0cmFmZmljIHRvIGhlbHAgcHJvdGVjdCB0aGVtLDwvc3Bhbj48 YnI+DQo8c3Bhbj4oYikgSGVscHMgZWFjaCBlbmRwb2ludCBzZWUgd2hlbiBvbmUgb2YgdGhvc2Ug cGFydGllcyBvciBkZXZpY2VzIG1vZGlmaWVzIGNvbnRlbnQgY29taW5nIGZyb20gdGhlIG90aGVy IGVuZHBvaW50LCBzdWNoIGFzIHJlbW92aW5nIGF0dGFja3MsIGFuZCBzZWUgdGhhdCB3aXRoIGEg Y3J5cHRvZ3JhcGhpYyBhdWRpdCB0cmFpbCBvZiB3aG8gY2hhbmdlZCB3aGF0IHdoZXJlIHdoZW4g YW5kIHdoeSwgc3VjaCBhcyByZW1vdmluZyBhdHRhY2tzLDwvc3Bhbj48YnI+DQo8c3Bhbj4oYykg QW5kIGRvZXMgYWxsIG9mIHRoZSBhYm92ZSB3aXRob3V0IGJyZWFraW5nIG9yIHdlYWtlbmluZyBh bnkgb2YgdGhlIGNyeXB0b2dyYXBoeSBvciBjcnlwdG9ncmFwaGljIHByb3RvY29scyBpbiBhbnkg d2F5LCBpbmNsdWRpbmcgbm90IGJyZWFraW5nIG9yIGNoYW5naW5nIFRMUy48L3NwYW4+PGJyPg0K PHNwYW4+PC9zcGFuPjxicj4NCjxzcGFuPkl0IGlzIGltcG9ydGFudCB0byBjb25zaWRlciB0aGUg 4oCcZGVsZWdhdGVkIHByb3RlY3Rpb27igJ0gbW9kZWwuJm5ic3A7IEluIHN1Y2ggYSBtb2RlbCwg dW5hdXRob3JpemVkIGVhdmVzZHJvcHBlcnMgcmVwcmVzZW50IG9uZSBvZiBhdCBsZWFzdCB0d28g Y3J1Y2lhbCB0aHJlYXRzIHdoaWNoIG11c3QgYmUgbWl0aWdhdGVkLiZuYnNwOyBJbiBzdWNoIGEg bW9kZWwsIHRoZSByZW1vdGUgZW5kcG9pbnQgcmVwcmVzZW50cyBhbm90aGVyIGNydWNpYWwgdGhy ZWF0IHdoaWNoDQogbXVzdCAmbmJzcDtiZSBtaXRpZ2F0ZWQgYXMgdGhhdCByZW1vdGUgZW5kcG9p bnQgbWlnaHQgYmUgbWFsaWNpb3VzIGV2ZW4gdGhvdWdoIHRoZSBlbmRwb2ludCBvZiBvdXIgY2Fy ZSB3YW50cyBvciBuZWVkcyB0byBjb21tdW5pY2F0ZSB3aXRoIHRoYXQgcmVtb3RlIGVuZHBvaW50 LiZuYnNwOyBUaGlzIG1vZGVsIGlzIHN1cnByaXNpbmdseSBjb21tb24gdG9kYXkuJm5ic3A7IEZv ciBpbnN0YW5jZSwgc2VydmVyIHRvIGNsaWVudCB3ZWIgYXR0YWNrcyBhcmUgaW5jcmVhc2luZ2x5 DQogY29tbW9uICZuYnNwO2J5IG1hbGljaW91cyBvciBjb21wcm9taXNlZCB3ZWJzaXRlcy4mbmJz cDsgT2YgY291cnNlLCBjbGllbnQgdG8gc2VydmVyIGF0dGFja3MgaGF2ZSBiZWVuIGNvbW1vbiBm b3IgeWVhcnMuJm5ic3A7IE1vcmUgcmVjZW50bHksIGl04oCZcyBiZWNvbWUgaW5jcmVhc2luZ2x5 IGNvbW1vbiBmb3Igc2VydmVycyB0byBzdXJ2ZWlsIGFuZCBwcm9maWxlIGNsaWVudHMsIGEgcHJp dmFjeSB0aHJlYXQgY29tcG91bmRlZCBieSBzZXJ2ZXJzIGNvbGxhYm9yYXRpbmcNCiB0aHJvdWdo ICZuYnNwO21hc3NpdmUgYWR2ZXJ0aXNpbmcgKGFkKSBuZXR3b3JrcyBmb3IgdHJhY2tpbmcgdXNl ciBhY3Rpdml0aWVzLiZuYnNwOyBTdWNoIHN1cnZlaWxsYW5jZSB0aHJvdWdoIHByb2ZpbGluZyBh bmQgdHJhY2tpbmcgcmVwcmVzZW50cyBhIHByaXZhY3kgdGhyZWF0IG1hbnkgcGVvcGxlIHdvdWxk IGxpa2UgdG8gc2VlIGJldHRlciBtaXRpZ2F0ZWQuJm5ic3A7IEluIGZhY3QsIGl0IGlzIGFsc28g YSBwcml2YWN5IHRocmVhdCB0aGF0IGNhbiBiZSBwb3RlbnRpYWxseQ0KIG1pdGlnYXRlZCAmbmJz cDtieSBwcm90ZWN0aW9uIHNlcnZpY2VzIHJ1bm5pbmcgaW4gdGhlIG5ldHdvcmsuJm5ic3A7IElu IGFsbCBzdWNoIGNhc2VzLCBpdOKAmXMgcmVhc29uYWJsZSBmb3IgbGltaXRlZCBlbmRwb2ludHMg dG8gY2hvb3NlIG1vcmUgcG93ZXJmdWwgbmV0d29yayBzZXJ2aWNlcyB0byBwcm90ZWN0IHRoZW0g YWdhaW5zdCBzdWNoIHRocmVhdHMuPC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bh bj5Gb3J0dW5hdGVseSwgc2V2ZXJhbCBzdGFydGluZyBwbGFjZXMgZXhpc3QgZm9yIHByb3RvY29s cyB0byBhY2hpZXZlIHJlcXVpcmVtZW50cyAoYSksIChiKSwgYW5kIChjKSBhYm92ZS4mbmJzcDsg Rm9yIGluc3RhbmNlLCB3aXRoIHNvbWUgbW9kaWZpY2F0aW9ucywgaXQgd291bGQgYmUgZ29vZCB0 byB1c2UgdGhlIFN0aWNrbGVyIHByb3RvY29sIHByb3Bvc2VkIGJ5IEEuPC9zcGFuPjxicj4NCjxz cGFuPkxldnksIEguIENvcnJpZ2FuLUdpYmJzLCBhbmQgRC4gQm9uZWggaW4gY29uanVuY3Rpb24g d2l0aCBtb2RpZmllZCB2YXJpYW50cyBvZiB1bmZvcnR1bmF0ZWx5IG5hbWVkIHByb3RvY29scyBz dWNoIGFzIG1iVExTIGFuZC9vciBUTFMtUkFSLiZuYnNwOyBPdXIgdmlzaW9uIGlzIGZvciBzdWNo IGEgcHJvdG9jb2wgdG8gcnVuIGluIHBhcmFsbGVsIHRvIFRMUywgY29tcGxpbWVudGluZyBpdCwg d2l0aG91dCBtb2RpZnlpbmcgb3IgY29uc3RyYWluaW5nDQogVExTICZuYnNwO3doaWxlIGhlbHBp bmcgY29vcmRpbmF0ZSBuZXR3b3JrIHByb3RlY3Rpb24gb2YgZW5kcG9pbnRzLiZuYnNwOyBUbyBk byBzbywgc3VjaCBhIHByb3RvY29sIHNob3VsZCBhbHNvIGJldHRlciBpbmZvcm0gZW5kcG9pbnRz IG9mIHRoZSBzcGVjaWZpY3Mgb2YgbmV0d29yayBkZXZpY2VzIGF2YWlsYWJsZSBmb3IgcHJvdGVj dGlvbiwgc3BlY2lmaWNzIHdoaWNoIHRoZSBlbmRwb2ludCBtaWdodCBjYXJlIGFib3V0IGJlZm9y ZSBlbXBvd2VyaW5nIHN1Y2gNCiBuZXR3b3JrICZuYnNwO2RldmljZXMgYnkgdHJ1c3RpbmcgdGhl bSB0byBoZWxwIHByb3ZpZGUgc3VjaCBwcm90ZWN0aW9uLjwvc3Bhbj48YnI+DQo8c3Bhbj48L3Nw YW4+PGJyPg0KPHNwYW4+V2l0aCBzdWNoIHZhbHVhYmxlIHJlc2VhcmNoIGFjY29tcGxpc2hlZCB0 byBkYXRlIGluIHRoaXMgc3BhY2UgcHJvcG9zaW5nIGEgdmFyaWV0eSBvZiBwb3RlbnRpYWwgcHJv dG9jb2xzIGFzIHN0YXJ0aW5nIHBvaW50cywgaXTigJlzIGltcG9ydGFudCB0byBzb29uIGVuZ2lu ZWVyIGEgc3RhbmRhcmRpemVkIHByb3RvY29sIHRvIG1lZXQgdGhlIHJvdWdoIGNvbnNlbnN1cyBv ZiB0aGUgSUVURiBmb3IgcHJvdmlkaW5nIHN1Y2ggcHJvdGVjdGlvbg0KIG1vcmUgJm5ic3A7c2Fm ZWx5IHRoYW4gdG9kYXnigJlzIGNvbW1vbiBwcmFjdGljZXMuJm5ic3A7IFRvZGF54oCZcyBjb21t b24gcHJhY3RpY2VzIG5vdCBvbmx5IGZhaWwgdG8gbWVldCB0aGUgdGhyZWUgcmVxdWlyZW1lbnRz IG91dGxpbmVkIGFib3ZlLCBidXQgdG9kYXnigJlzIGNvbW1vbiBwcmFjdGljZXMgYWxzbyAoMSkg YWxsb3cgbWlkZGxlYm94ZXMgdG8gbmVnb3RpYXRlIHdlYWtlciBUTFMgc2Vzc2lvbnMgd2l0aG91 dCBhZHZpc2luZyB0aGUgZW5kcG9pbnQgb2YgdGhlDQogcmlza3MgJm5ic3A7b2YgdGhlIHdlYWtl ciBzZXNzaW9uIG9uIHRoZSBmYXIgc2lkZSBvZiB0aGUgbWlkZGxlYm94LCAoMikgZmFpbCB0byBp bmZvcm0gdGhlIGVuZHBvaW50cyBvZiBob3cgc2VjdXJlIHRoZSBtaWRkbGVib3ggbWlnaHQgb3Ig bWlnaHQgbm90IGJlLCB0aGUgbWFubmVyIGluIHdoaWNoIHRoZSBtaWRkbGVib3ggaXRzZWxmIGlz IHNhZmVndWFyZGVkLCBhbmQgKDMpIGZhaWwgdG8gaW5mb3JtIHRoZSBlbmRwb2ludHMgb2YgdGhl IGluZm9ybWF0aW9uDQogcmV0ZW50aW9uICZuYnNwO2FuZCBkaXNjbG9zdXJlIHBvbGljaWVzIHVu ZGVyIHdoaWNoIHRoZSBtaWRkbGVib3ggaXMgb3BlcmF0aW5nLjwvc3Bhbj48YnI+DQo8c3Bhbj48 L3NwYW4+PGJyPg0KPHNwYW4+Q2xlYXJseSBhIGJldHRlciBhcHByb2FjaCBpcyBuZWVkZWQsIGFu ZCB1cmdlbnRseS4mbmJzcDsgTmV0d29yayBtZWRpYXRpb24gY2FuIHBsYXkgYSBjcnVjaWFsIHJv bGUgaW4gcHJvdGVjdGluZyBwZW9wbGUgZnJvbSB0aGUgc2VydmVyIHRvIGNsaWVudCBhdHRhY2tz IHRoYXQgaGF2ZSBiZWVuIHVzZWQgdG8gdW5tYXNrIHRoZSBhbm9ueW1pdHkgb2YgZGlzc2lkZW50 cyBzcGVha2luZyB1cCBhZ2FpbnN0IHJlcHJlc3NpdmUgcmVnaW1lcywgZGlzc2lkZW50cw0KICZu YnNwO3dobyB3ZXJlIHRoZW4gZGlzYXBwZWFyZWQgYWZ0ZXIgdGhlIHNlcnZlciB0byBjbGllbnQg YXR0YWNrcyB3ZXJlIHVzZWQgdG8gdW5tYXNrIHRoZW0gYnkgY29tcHJvbWlzaW5nIHRoZWlyIG1v YmlsZSBlbmRwb2ludC4mbmJzcDsgVHJ1c3R3b3J0aHkgbmV0d29yayBtZWRpYXRpb24gY2FuIHBs YXkgYSBjcnVjaWFsIHJvbGUgaW4gcHJvdGVjdGluZyBwZW9wbGUgYWdhaW5zdCBzdWNoIGF0dGFj a3MsIGJ1dCB0b2RheSwgd2hlcmUgZW5kcG9pbnRzIHRydXN0DQogJm5ic3A7bWlkZGxlYm94ZXMs IHRoZXJlIGlzIG5vdCB5ZXQgYSBzdGFuZGFyZGl6ZWQgcHJvdG9jb2wgZm9yIGVuZHBvaW50cyB0 byB1bmRlcnN0YW5kIHdoZW4gdGhvc2UgbWlkZGxlYm94ZXMgYXJlIHdlYWtlbmluZyB0aGUgY3J5 cHRvLCBjaGFuZ2luZyB0aGUgY29udGVudCwgdHJ1c3Rpbmcgb3RoZXIgbWlkZGxlYm94ZXMsIGFu ZCBkb2luZyBvdGhlciB0aGluZ3MgdGhhdCBtaWdodCBjYXVzZSB0aGUgZW5kcG9pbnQgdG8gbm90 IHRydXN0IHRoZSBtaWRkbGVib3guPC9zcGFuPjxicj4NCjxzcGFuPjwvc3Bhbj48YnI+DQo8c3Bh bj5TdGlsbCwgZW5naW5lZXJpbmcgc3VjaCBhIHByb3RvY29sIGlzIG5vdCBlYXN5LiZuYnNwOyBT dWNoIHByb3RvY29scyB3b3VsZCBuZWVkIHRvIGFkZHJlc3MgYSByYW5nZSBvZiB1c2UgY2FzZXMg aW5jbHVkaW5nIGJvdGggcmVhbC10aW1lIGFuZCBwb3N0LWZhY3RvLCBhbG9uZyB3aXRoIGJvdGgg d2lkZS1hcmVhIGFuZCBkYXRhY2VudGVyIHVzZSBjYXNlcy4mbmJzcDsgQXMgaW5pdGlhbCB3b3Jr aW5nIGRpZmZlcmVudGlhdGlvbiBvZiB0aGVzZSB0ZXJtcywNCiB3ZeKAmWQgJm5ic3A7cHJvcG9z ZSByZWFsLXRpbWUgdG8gaW5jbHVkZSBibG9ja2luZyBvZiBhdHRhY2tzLiBQb3N0LWZhY3RvIGlu Y2x1ZGVzIGJvdGggZm9yZW5zaWMgaW52ZXN0aWdhdGlvbiBvZiBzb3BoaXN0aWNhdGVkIGF0dGFj a3MgYW5kIGFsc28gYXVkaXQgY29tcGxpYW5jZSBha2Egb3V0LW9mLWJhbmQgZGVjcnlwdGlvbi4g V2lkZS1hcmVhIHVzZSBjYXNlcyBpbmNsdWRlIHNoYXJlZCBuZXR3b3JrcyB3aGVyZSB0aGUgZGV2 aWNlIG9yIGVudGl0eSBoZWxwaW5nDQogJm5ic3A7cHJvdmlkZSBwcm90ZWN0aW9uIGlzIG9ubHkg cmVhY2hlZCBhY3Jvc3MgYSBuZXR3b3JrIG9wZXJhdGVkIGJ5IGFuZC9vciBzaGFyZWQgd2l0aCBv dGhlciB1bnRydXN0ZWQgcGFydGllcy4mbmJzcDsgVGhlIGRhdGFjZW50ZXIgdXNlIGNhc2UgaW5j bHVkZXMgbmV0d29ya3MgYWRqYWNlbnQgdG8gdGhlIGVuZHBvaW50IGFuZCBvd25lZCBieSB0aGUg c2FtZSBwYXJ0eSBhcyBvd25pbmcgdGhlIGVuZHBvaW50Ljwvc3Bhbj48YnI+DQo8c3Bhbj48L3Nw YW4+PGJyPg0KPHNwYW4+SW4gZW5naW5lZXJpbmcgc3VjaCBhIHByb3RvY29sLCBpdOKAmXMgaW1w b3J0YW50IHRvIHJlc3BlY3QgZnVuZGFtZW50YWwgcHJpbmNpcGxlcyBvZiBlbmQtdG8tZW5kIGVu Y3J5cHRpb24gYW5kLCBhdCB0aW1lcywgc2ltaWxhciBlbmQtdG8tZW5kIGZsZXhpYmlsaXR5IGlu IHJvdXRlIG9wdGltaXphdGlvbi4mbmJzcDsgT24gZW5kLXRvLWVuZCBlbmNyeXB0aW9uLCBzb21l IG9mIHRoZSBhcHByb2FjaGVzIHRoYXQgaGF2ZSBiZWVuIHByb3Bvc2VkIGluY2x1ZGUNCiAmbmJz cDtsZXZlcmFnaW5nIHRoZSBzeW1tZXRyaWMga2V5IGRldGVybWluZWQgc3RyaWN0bHkgYmV0d2Vl biB0aGUgc2VydmVyIGFuZCBjbGllbnQsIGFuZCB0aGVuIGhhdmluZyB0aGUgZW5kcG9pbnQgc2hh cmUgdGhhdCBzeW1tZXRyaWMga2V5IG9ubHkgd2l0aCBhIG5ldHdvcmsgZGV2aWNlIG9yIHNlcnZp Y2Ugd2hpY2ggaXQgdHJ1c3RzIHRvIGhlbHAgd2l0aCBwcm90ZWN0aW9uIGFnYWluc3QgdGhlIHJl bW90ZSBlbmRwb2ludC4mbmJzcDsgSW4gYWRkaXRpb24gdG8NCiAmbmJzcDtwcmVzZXJ2aW5nIGVu ZC10by1lbmQgZW5jcnlwdGlvbiBhbmQgYWNjZWxlcmF0aW5nIGRlcGxveW1lbnQgb2Ygc3Ryb25n ZXIgY3J5cHRvLCBpdOKAmXMgYWxzbyBpbXBvcnRhbnQgdG8gcHJlc2VydmUgZW5kLXRvLWVuZCBm bGV4aWJpbGl0eSBpbiByb3V0aW5nIHdoZW5ldmVyIHBvc3NpYmxlLiZuYnNwOyBDdXJyZW50bHks IGZvciBhdHRhY2tzIHR1bm5lbGluZyB0aHJvdWdoIGVuY3J5cHRlZCBuZXR3b3JrIHNlc3Npb25z LCBuZXR3b3JrIGJhc2VkIHByb3RlY3Rpb24NCiAmbmJzcDtpcyBvZnRlbiBwcm92aWRlZCB0aHJv dWdoIHByb3hpZXMgYW5kIHRoZSBsaWtlIGVpdGhlciBlbWJlZGRlZCBpbiBuZXR3b3JrIGdhdGV3 YXlzIG9yIGRhdGFjZW50ZXJzIGhvc3RpbmcgcGVyc29uYWwtVlBOIHR5cGUgY2xvdWQgYmFzZWQg c2VydmljZXMgdGhyb3VnaCB3aGljaCBhbGwgb2YgYSBjbGllbnTigJlzIHRyYWZmaWMgaXMgcm91 dGVkLiZuYnNwOyBIb3dldmVyLCBsb25nZXIgdGVybSwgc3VjaCBwcm90ZWN0aW9uIGNvdWxkIGJl IGFjaGlldmVkIGJ5DQogJm5ic3A7aGF2aW5nIHN1Y2gg4oCccHJvdGVjdGlvbiBzZXJ2aWNlc+KA nSBydW5uaW5nIG1vcmUgZmxleGlibHkgaW4gYSBkaXN0cmlidXRlZCBtYW5uZXIsIGluIGhhcmR3 YXJlIHByb3RlY3RlZCBlbmNsYXZlcyBhbmQvb3IgVHJ1c3RlZCBFeGVjdXRpb24gRW52aXJvbm1l bnRzIG1pZ3JhdGluZyB0aGUgZnVuY3Rpb25hbGl0eSBhbW9uZyBTb2Z0d2FyZSBEZWZpbmVkIE5l dHdvcmtpbmcgKFNETikgYW5kL29yIE5ldHdvcmsgRnVuY3Rpb24gVmlydHVhbGl6YXRpb24NCiAm bmJzcDsoTkZWKSBlbmFibGVkIGVxdWlwbWVudC48L3NwYW4+PGJyPg0KPHNwYW4+PC9zcGFuPjxi cj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPGRpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPkZyb20gZGlzY3Vz c2lvbnMgd2l0aGluIG5vdCBvbmx5IElFVEYgcGFydGljaXBhbnRzLCBidXQgYWxzbyBwZW9wbGUg ZW5nYWdlZCBpbiByZWxhdGVkIGRpc2N1c3Npb25zIGluIElFRUUsIFVOL0lUVSwgRVRTSSwgYW5k IG90aGVycyBpbiB0aGlzIGFyZWEgZWFnZXIgdG8gcGFydGljaXBhdGUgaW4gYW4gSUVURiBwcm9j ZXNzIGluIHRoaXMgYXJlYSwgd2UgYmVsaWV2ZSB0aGF0IHRoZXJlIGlzIGENCiBjcml0aWNhbCBt YXNzIG9mIHBhcnRpY2lwYW50cyAmbmJzcDt3aWxsaW5nIHRvIHdvcmsgb24gdGhlIHByb2JsZW0g KGUuZy4sIHdyaXRlIGRyYWZ0cywgcmV2aWV3IGRyYWZ0cywgZXRjLikgZm9yIG1lZXRpbmcgcmVx dWlyZW1lbnRzIChhKSwgKGIpLCBhbmQgKGMpIGRlc2NyaWJlZCBhYm92ZS4mbmJzcDsgTWFueSBv ZiB1cyBwZXJzb25hbGx5IGJlbGlldmUgdGhhdCB0aGUgSUVURiBpcyB0aGUgcmlnaHQgYmVzdCBw bGFjZSBmb3Igc3VjaCB3b3JrIGZvciBjb3VudGxlc3MNCiByZWFzb25zLiBXZSBhcmUgb2YgY291 cnNlICZuYnNwO3ZlcnkgZmFtaWxpYXIgd2l0aCBwcmV2aW91cyBhdHRlbXB0cyB3aXRoaW4gdGhl IElFVEYsIGluY2x1ZGluZyBFeHBsaWNpdGx5IFRydXN0ZWQgUHJveHkgYW5kIFRMUyBQcm94eSBz ZXJ2ZXIgYW1vbmcgb3RoZXJzLjwvc3Bhbj48YnI+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdj48c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+V2Ug YXJlIGFsc28gYXdhcmUgb2YgdGhlIG5lZWQgZm9yIGNvb3JkaW5hdGlvbiBvZiBzdWNoIHdvcmsg bm90IG9ubHkgd2l0aCB0aGUgVExTIHdvcmtpbmcgZ3JvdXAsIGJ1dCBhbHNvIERQUklWRSwgUVVJ QywgSTJOU0YsIGFuZCBvdGhlciBJRVRGIGVmZm9ydHMsIGFuZCB3ZSBiZWxpZXZlIHRoYXQgYW4g aW5kZXBlbmRlbnQgV0cgY291bGQgYmUgbW9yZSBoZWxwZnVsIHRoYW4gdHJ5aW5nIHRvIGRvIGFs bCBvZiB0aGlzIHdvcmsgaW4gYW55DQogZXhpc3RpbmcgJm5ic3A7d29ya2luZyBncm91cCBzdWNo IGFzIHRoZSBUTFMgV0csIHBhcnRpY3VsYXJseSBzaW5jZSB0aGUgYmVzdCBzb2x1dGlvbiBtaWdo dCBiZSBhIG5ldyBwcm90b2NvbCB0aGF0IGNvbXBsaW1lbnRzIFRMUywgcnVubmluZyBpbiBjb25q dW5jdGlvbiB3aXRoIFRMUywgd2l0aG91dCBleHRlbmRpbmcsIGNoYW5naW5nLCByZWZpbmluZywg b3IgYnJlYWtpbmcgaXQsIG9yIGFueSBvdGhlciBleGlzdGluZyBwcm90b2NvbHMgYWxyZWFkeSBz bw0KIGltcG9ydGFudCAmbmJzcDt0byBzZWN1cml0eSBhbmQgcHJvcGVyIGZ1bmN0aW9uaW5nIG9m IHRoZSBuZXR3b3JrLjwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+SW4gdGhh dCB0aGUgd29ybGQgaGFzIGFscmVhZHkgc2VlbiBhbm9ueW1vdXMgZGlzc2lkZW50cyBkaXNhcHBl YXJlZCBhZnRlciB3aGF0IG1hbnkgd291bGQgY29uc2lkZXIgcmVwcmVzc2l2ZSByZWdpbWVzIHVz ZWQgc29waGlzdGljYXRlZCBzZXJ2ZXItdG8tY2xpZW50IGF0dGFja3MgdG8gdW5tYXNrIHRoZWly IGFub255bWl0eSwgSSBiZWxpZXZlIHRoYXQgd2UgbmVlZCBhIHdvcmxkIHdoZXJlIGJvdGggKDEp IHRoZSBjb25uZWN0aW9ucw0KIGFyZSBzZWN1cmUgJm5ic3A7YSBsYSBncmVhdCBUTFMsIGFuZCAo MikgdGhlIHRyYWZmaWMgaXMgc2FmZSB0byByZWNlaXZlLCBhcyB2ZXR0ZWQgYnkgc29tZXRoaW5n IG9yIHNvbWVvbmUgdGhlIGVuZHBvaW50IGNob29zZXMgZm9yIHByb3RlY3Rpb24gYWdhaW5zdCBy ZW1vdGUgZW5kcG9pbnRzLjwvc3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+SW4g dGhhdCBjb250ZXh0LCB3ZSBhcmUgZGVlcGx5IGdyYXRlZnVsIHRoYXQgSUVURiBoYXMgYWxsb3dl ZCBjcmVhdGlvbiBvZiB0aGlzIG1haWxpbmcgbGlzdCBmb3IgZGlzY3Vzc2lvbiBvZiB0aGVzZSBp bXBvcnRhbnQgdG9waWNzLiZuYnNwOyBQbGVhc2UgbGV0IG1lIGtub3cgYW55dGhpbmcgdGhhdCBJ IGNhbiBkbyB0byBoZWxwIHlvdSBvciB0aGUgSUVURiBvbiB0aGlzLjwvc3Bhbj48YnI+DQo8c3Bh bj48L3NwYW4+PGJyPg0KPHNwYW4+V2l0aCBNeSBEZWVwZXN0IFRoYW5rcyBGb3IgQWxsIFRoYXQg WW91IERvIEZvciBUaGUgSUVURiwgQW5kIEZvciBUaGUgV29ybGQgVGhyb3VnaCBUaGUgSUVURiw8 L3NwYW4+PGJyPg0KPHNwYW4+QnJpYW48L3NwYW4+PGJyPg0KPHNwYW4+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PGJyPg0KPHNwYW4+UEFUSUVO VCBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPg0KPHNwYW4+PGEgaHJlZj0ibWFpbHRvOlBBVElFTlRA aWV0Zi5vcmciPlBBVElFTlRAaWV0Zi5vcmc8L2E+PC9zcGFuPjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_656F31A992084EA8B9A77D3518AF542Bsymanteccom_-- From nobody Wed Nov 8 06:44:27 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2554127137 for ; Wed, 8 Nov 2017 06:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiuNX228AHJL for ; Wed, 8 Nov 2017 06:44:22 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2A931270A7 for ; Wed, 8 Nov 2017 06:44:21 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id n74so18290170wmi.1 for ; Wed, 08 Nov 2017 06:44:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=mnP4iNQMjMC1OW/ND0c8RwPJ4kY/NwOCPLNVk1hq+6g=; b=UrRyZXMmDX9h7/CqSbYmmChL3PO2WEpyb/bA80hK5tiXbnn3loePCz1nRktIcW5/rN 3sLpolAQmYCo7vh7n8GILCrKWEbmEB8wckD0qoYxx28slfz+xZ4MYqGM5A6RX2RCA9BI +oHkzVTvsb0EiZvbE7M72dAP0NXxVm98ZLZUF5GEoNJEczDLDBLgIuaw5ePJH9uyDzxN Okk9ag+l5m0XgJboVWYOwORcNNclvRziM2roxiBXeQ4bdop5nGYn5BZ15CzvCRjuTVAI UIfNQaxFEy0Mw4xVxQ0rdV7FuRN3SZpc6LkjxGqivGnNnd+oMRuCbMpnfbEhSp9qUdjJ j2vQ== 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 :message-id:references:to; bh=mnP4iNQMjMC1OW/ND0c8RwPJ4kY/NwOCPLNVk1hq+6g=; b=c208vD+q6dDJHXEBdTtsK3EktuLXjRKg2yMYCh+W6/nxD7mk0b38K2Avz/LGI7r3EI CDkocQkfjPbCN4h7XZVyoqnghXkTluM4D9Q7gQmBmD6fmUfdLs/fcDBpYcBknUuFIV9d OTaq6UuBu2ypJ4veHfBmMVJ2e1fBOpwSvSgEf28g3TofTCiOjYWbq4q3ODRfDCfoLxif 9jnMsmTECmJfw7PefQK9OJvOEcmG1Ny6lkdxnQEOZYBU2+iy2T9kSfz+y9RPQYA+i+Or VEnyR2tQyQLKIeLjwa0AeTk5uK2Po30pf9Pd4mkSTvL+2gBZc/Ho9p5Fb4CpygGZTe2D EWIw== X-Gm-Message-State: AJaThX5UZrTFmngk+oA88uaCzPs96w4QMCAomZyVhKcwUc6/+fbH6Qca IwvRsK1G0UDWYS+Eyu8q038= X-Google-Smtp-Source: ABhQp+SYxyrx9XjmSFt/Z/BTmFP9thsmsI4e2ep+7ta1EbzzJBI9/M9i4NuyQXeJ+ocvYtUoIxexjA== X-Received: by 10.28.19.130 with SMTP id 124mr606774wmt.108.1510152260477; Wed, 08 Nov 2017 06:44:20 -0800 (PST) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id u33sm19058wrf.42.2017.11.08.06.44.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 08 Nov 2017 06:44:19 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_048689A0-146E-4945-90CB-641037016704"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) From: Yoav Nir X-Mail-Calendar-Part: Yes In-Reply-To: <656F31A9-9208-4EA8-B9A7-7D3518AF542B@symantec.com> Date: Wed, 8 Nov 2017 16:44:27 +0200 Cc: Security Area Advisory Group Message-Id: <10873AE3-94A9-4764-8CB2-E041133E40DE@gmail.com> References: <656F31A9-9208-4EA8-B9A7-7D3518AF542B@symantec.com> To: Brian Witten X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [saag] Announcing the PATIENT mailing list & meeting in Singapore X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Nov 2017 14:44:26 -0000 --Apple-Mail=_048689A0-146E-4945-90CB-641037016704 Content-Type: multipart/alternative; boundary="Apple-Mail=_60E801ED-C476-4434-AB46-183DD28C1E34" --Apple-Mail=_60E801ED-C476-4434-AB46-183DD28C1E34 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks, Brian For convenience, here=E2=80=99s an iCal event. Yoav > On 8 Nov 2017, at 16:18, Brian Witten = wrote: >=20 > Dear All, >=20 > For anyone interested in Protecting against Attacks Tunneling In = Encrypted Network Traffic (PATIENT), I=E2=80=99m announcing both a = meeting below, and mailing list, further below. Intent of PATIENT is to = create a secure multi-party protocol for making such protection far = safer without modifying, constraining, or breaking TLS in any way, a = protocol complimenting current TLS including TLS 1.3. >=20 > Intent of PATIENT is to do so in light of both (a) vulnerabilities in = today=E2=80=99s common approaches, and (b) huge growing number of = attacks tunneling in encrypted traffic, already hurting billions of = people, sometimes with dire consequences for their privacy, freedom, & = physical well being. >=20 > The meeting will be: > ** When: Wednesday, November 15, 8pm , = shortly following the plenary. > ** Where: Orchard Room of the Convention Center where the IETF = Meetings are being held. >=20 > I note that pre-conceptions have severely polarized a number of past = attempts at solving problems similar to this, and without better = standards for such protection, security suffers in many ways, including = challenges safely rolling out important new protocols like TLS 1.3 as = quickly and as widely as we=E2=80=99d all like. We seek a =E2=80=9Cmiddle= =E2=80=9D ground that is not a sacrifice by either side but rather = hopefully a best of both worlds. >=20 > If you are wanting to protect against attacks tunneling in encrypted = traffic, and wanting to make such protection far safer from both = security and privacy perspectives, please join us for this meeting, and = please join us in helping keep discussion constructive and respectful of = people with widely differing views. I believe we all want to make the = Internet and world safer. >=20 > With My Deepest Thanks For All That You Do For The IETF, And For The = World Through The IETF, > Brian >=20 > bwitten@symantec.com >=20 >=20 > Begin forwarded message: >=20 >> From: Brian Witten > >> Date: November 8, 2017 at 12:59:55 AM PST >> To: "patient@ietf.org " > >> Subject: Announcing the PATIENT meeting in Singapore >>=20 >> Dear All, >>=20 >> For anyone interested in Protecting against Attacks Tunneling In = Encrypted Network Traffic (PATIENT), we'll be having a meeting in = Singapore. >> ** When: Wednesday, November 15, 8pm, shortly following the plenary. >> ** Where: Orchard Room of the Convention Center where the IETF = Meetings are being held. >>=20 >> This side meeting is akin to "bar BOF" in preparation for hopefully = hosting a full Birds of a Feather (BOF) meeting at IETF 101 in London in = a few months. Please feel free to directly let me know any questions or = concerns. >>=20 >> With My Deepest Thanks For All That You Do For The IETF, And For The = World Through The IETF, >> Brian >>=20 >> bwitten@symantec.com >>=20 >> From: PATIENT > on behalf of Brian Witten = > >> Sent: Monday, November 6, 2017 4:26 PM >> To: patient@ietf.org >> Subject: [EXT] [Patient] Welcome to the PATIENT Mailing List >>=20 >>=20 >> Dear All, >>=20 >> Welcome to the mailing list for Protecting against Attacks Tunneling = In Encrypted Network Traffic (PATIENT). >>=20 >> We are thrilled to see over half of the world=E2=80=99s web = connections encrypted, and we do not want to weaken crypto or TLS in any = way. At the same time, half of the world=E2=80=99s attacks are now = tunneling through encrypted sessions, and many endpoints need help = protecting themselves against these attacks. Often they can only get = that help from the network. Fortunately, there are in fact ways for = network devices to help protect against the full range of attacks that = might be tunneling through encrypted sessions. Still, for endpoints to = get such help of course they need to Trust some entity or service in the = network to help protect them. That entity or service helping protect = them might be operating on their behalf, or on behalf of their employer, = or some other entity they choose to trust. However, they have a right = to choose who they trust to protect them. For these reasons, we want to = collectively engineer a secure multi-party protocol which: >>=20 >> (a) Helps each endpoint control which parties and network devices are = empowered to decrypt traffic to help protect them, >> (b) Helps each endpoint see when one of those parties or devices = modifies content coming from the other endpoint, such as removing = attacks, and see that with a cryptographic audit trail of who changed = what where when and why, such as removing attacks, >> (c) And does all of the above without breaking or weakening any of = the cryptography or cryptographic protocols in any way, including not = breaking or changing TLS. >>=20 >> It is important to consider the =E2=80=9Cdelegated protection=E2=80=9D = model. In such a model, unauthorized eavesdroppers represent one of at = least two crucial threats which must be mitigated. In such a model, the = remote endpoint represents another crucial threat which must be = mitigated as that remote endpoint might be malicious even though the = endpoint of our care wants or needs to communicate with that remote = endpoint. This model is surprisingly common today. For instance, = server to client web attacks are increasingly common by malicious or = compromised websites. Of course, client to server attacks have been = common for years. More recently, it=E2=80=99s become increasingly = common for servers to surveil and profile clients, a privacy threat = compounded by servers collaborating through massive advertising (ad) = networks for tracking user activities. Such surveillance through = profiling and tracking represents a privacy threat many people would = like to see better mitigated. In fact, it is also a privacy threat that = can be potentially mitigated by protection services running in the = network. In all such cases, it=E2=80=99s reasonable for limited = endpoints to choose more powerful network services to protect them = against such threats. >>=20 >> Fortunately, several starting places exist for protocols to achieve = requirements (a), (b), and (c) above. For instance, with some = modifications, it would be good to use the Stickler protocol proposed by = A. >> Levy, H. Corrigan-Gibbs, and D. Boneh in conjunction with modified = variants of unfortunately named protocols such as mbTLS and/or TLS-RAR. = Our vision is for such a protocol to run in parallel to TLS, = complimenting it, without modifying or constraining TLS while helping = coordinate network protection of endpoints. To do so, such a protocol = should also better inform endpoints of the specifics of network devices = available for protection, specifics which the endpoint might care about = before empowering such network devices by trusting them to help provide = such protection. >>=20 >> With such valuable research accomplished to date in this space = proposing a variety of potential protocols as starting points, it=E2=80=99= s important to soon engineer a standardized protocol to meet the rough = consensus of the IETF for providing such protection more safely than = today=E2=80=99s common practices. Today=E2=80=99s common practices not = only fail to meet the three requirements outlined above, but today=E2=80=99= s common practices also (1) allow middleboxes to negotiate weaker TLS = sessions without advising the endpoint of the risks of the weaker = session on the far side of the middlebox, (2) fail to inform the = endpoints of how secure the middlebox might or might not be, the manner = in which the middlebox itself is safeguarded, and (3) fail to inform the = endpoints of the information retention and disclosure policies under = which the middlebox is operating. >>=20 >> Clearly a better approach is needed, and urgently. Network mediation = can play a crucial role in protecting people from the server to client = attacks that have been used to unmask the anonymity of dissidents = speaking up against repressive regimes, dissidents who were then = disappeared after the server to client attacks were used to unmask them = by compromising their mobile endpoint. Trustworthy network mediation = can play a crucial role in protecting people against such attacks, but = today, where endpoints trust middleboxes, there is not yet a = standardized protocol for endpoints to understand when those middleboxes = are weakening the crypto, changing the content, trusting other = middleboxes, and doing other things that might cause the endpoint to not = trust the middlebox. >>=20 >> Still, engineering such a protocol is not easy. Such protocols would = need to address a range of use cases including both real-time and = post-facto, along with both wide-area and datacenter use cases. As = initial working differentiation of these terms, we=E2=80=99d propose = real-time to include blocking of attacks. Post-facto includes both = forensic investigation of sophisticated attacks and also audit = compliance aka out-of-band decryption. Wide-area use cases include = shared networks where the device or entity helping provide protection = is only reached across a network operated by and/or shared with other = untrusted parties. The datacenter use case includes networks adjacent = to the endpoint and owned by the same party as owning the endpoint. >>=20 >> In engineering such a protocol, it=E2=80=99s important to respect = fundamental principles of end-to-end encryption and, at times, similar = end-to-end flexibility in route optimization. On end-to-end encryption, = some of the approaches that have been proposed include leveraging the = symmetric key determined strictly between the server and client, and = then having the endpoint share that symmetric key only with a network = device or service which it trusts to help with protection against the = remote endpoint. In addition to preserving end-to-end encryption and = accelerating deployment of stronger crypto, it=E2=80=99s also important = to preserve end-to-end flexibility in routing whenever possible. = Currently, for attacks tunneling through encrypted network sessions, = network based protection is often provided through proxies and the like = either embedded in network gateways or datacenters hosting personal-VPN = type cloud based services through which all of a client=E2=80=99s = traffic is routed. However, longer term, such protection could be = achieved by having such =E2=80=9Cprotection services=E2=80=9D running = more flexibly in a distributed manner, in hardware protected enclaves = and/or Trusted Execution Environments migrating the functionality among = Software Defined Networking (SDN) and/or Network Function Virtualization = (NFV) enabled equipment. >>=20 >> =46rom discussions within not only IETF participants, but also people = engaged in related discussions in IEEE, UN/ITU, ETSI, and others in this = area eager to participate in an IETF process in this area, we believe = that there is a critical mass of participants willing to work on the = problem (e.g., write drafts, review drafts, etc.) for meeting = requirements (a), (b), and (c) described above. Many of us personally = believe that the IETF is the right best place for such work for = countless reasons. We are of course very familiar with previous = attempts within the IETF, including Explicitly Trusted Proxy and TLS = Proxy server among others. >>=20 >> We are also aware of the need for coordination of such work not only = with the TLS working group, but also DPRIVE, QUIC, I2NSF, and other IETF = efforts, and we believe that an independent WG could be more helpful = than trying to do all of this work in any existing working group such = as the TLS WG, particularly since the best solution might be a new = protocol that compliments TLS, running in conjunction with TLS, without = extending, changing, refining, or breaking it, or any other existing = protocols already so important to security and proper functioning of = the network. >>=20 >> In that the world has already seen anonymous dissidents disappeared = after what many would consider repressive regimes used sophisticated = server-to-client attacks to unmask their anonymity, I believe that we = need a world where both (1) the connections are secure a la great TLS, = and (2) the traffic is safe to receive, as vetted by something or = someone the endpoint chooses for protection against remote endpoints. >>=20 >> In that context, we are deeply grateful that IETF has allowed = creation of this mailing list for discussion of these important topics. = Please let me know anything that I can do to help you or the IETF on = this. >>=20 >> With My Deepest Thanks For All That You Do For The IETF, And For The = World Through The IETF, >> Brian >> _______________________________________________ >> PATIENT mailing list >> PATIENT@ietf.org = _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --Apple-Mail=_60E801ED-C476-4434-AB46-183DD28C1E34 Content-Type: multipart/mixed; boundary="Apple-Mail=_33007D84-68C1-4C47-B589-6E08C5EDFE02" --Apple-Mail=_33007D84-68C1-4C47-B589-6E08C5EDFE02 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks, Brian

For convenience, here=E2=80=99s an iCal event.

Yoav
= --Apple-Mail=_33007D84-68C1-4C47-B589-6E08C5EDFE02 Content-Disposition: attachment; filename=patient.ics Content-Type: text/calendar; x-unix-mode=0644; name="patient.ics" Content-Transfer-Encoding: quoted-printable BEGIN:VCALENDAR=0D=0ACALSCALE:GREGORIAN=0D=0AVERSION:2.0=0D=0A= X-WR-CALNAME:Protecting=20against=20Attacks=20Tunneling=20In=20Encrypted=20= Network=20T=0D=0A=20raffic=20(PATIENT)=0D=0AMETHOD:PUBLISH=0D=0A= PRODID:-//Apple=20Inc.//Mac=20OS=20X=2010.13.1//EN=0D=0ABEGIN:VEVENT=0D=0A= TRANSP:OPAQUE=0D=0ADTEND:20171115T133000Z=0D=0A= UID:262D576E-B077-4BAA-A6F9-FBE6BAE0B47E=0D=0ADTSTAMP:20171108T144213Z=0D= =0ALOCATION:Orchard=20room=0D=0ADESCRIPTION:=0D=0ASTATUS:CONFIRMED=0D=0A= SEQUENCE:0=0D=0AX-APPLE-TRAVEL-ADVISORY-BEHAVIOR:AUTOMATIC=0D=0A= SUMMARY:Protecting=20against=20Attacks=20Tunneling=20In=20Encrypted=20= Network=20Traffi=0D=0A=20c=20(PATIENT)=0D=0ADTSTART:20171115T120000Z=0D=0A= CREATED:20171108T144113Z=0D=0ALAST-MODIFIED:20171108T144213Z=0D=0A= END:VEVENT=0D=0AEND:VCALENDAR=0D=0A= --Apple-Mail=_33007D84-68C1-4C47-B589-6E08C5EDFE02 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


On 8 Nov 2017, at 16:18, Brian Witten <brian_witten@symantec.com> wrote:

Dear All,

For anyone interested in Protecting against Attacks Tunneling In = Encrypted Network Traffic (PATIENT), I=E2=80=99m announcing both a = meeting below, and mailing list, further below.  Intent of PATIENT = is to create a secure multi-party protocol for making such protection far safer without modifying, constraining, or breaking TLS in any way, = a protocol complimenting current TLS including TLS 1.3.

Intent of PATIENT is to do so in light = of both (a) vulnerabilities in today=E2=80=99s common = approaches, and (b) huge growing number of attacks tunneling in encrypted traffic, already hurting billions of people, = sometimes with dire consequences for their privacy, freedom, & = physical well being.

The meeting will be:
** When: Wednesday, November 15, 8pm, shortly following the plenary.
** Where: Orchard Room of the Convention Center where the IETF Meetings = are being held.

I note that pre-conceptions have severely polarized a = number of past attempts at solving problems similar to this, and without = better standards for such protection, security suffers in many ways, = including challenges safely rolling out important new protocols like TLS 1.3 as quickly and as widely as we=E2=80=99d all like. =  We seek a =E2=80=9Cmiddle=E2=80=9D ground that is not a sacrifice = by either side but rather hopefully a best of both worlds.

If you are wanting to protect against attacks tunneling in encrypted = traffic, and wanting to make such protection far safer from both = security and privacy perspectives, please join us for this meeting, and = please join us in helping keep discussion constructive and respectful of people with widely differing views.  I believe = we all want to make the Internet and world safer.

With My Deepest Thanks For All That You Do For The IETF, And For The = World Through The IETF,
Brian

bwitten@symantec.com


Begin forwarded message:

From: Brian Witten <brian_witten@symantec.com>
Date: November 8, 2017 at 12:59:55 AM PST
= To: "patient@ietf.org" <patient@ietf.org>
Subject: Announcing the PATIENT meeting = in Singapore

Dear All,

For anyone interested in Protecting against Attacks = Tunneling In Encrypted Network Traffic (PATIENT), we'll be having a = meeting in Singapore.
** When: Wednesday, November 15, 8pm, shortly following = the plenary.
** Where: Orchard Room of the Convention Center where = the IETF Meetings are being held.

This side meeting is akin to "bar BOF" in preparation = for hopefully hosting a full Birds of a Feather (BOF) meeting at IETF = 101 in London in a few months.  Please feel free to directly let me = know any questions or concerns.

With My Deepest Thanks For All That You Do For The = IETF, And For The World Through The IETF,
Brian

bwitten@symantec.com

From: PATIENT <patient-bounces@ietf.org> on behalf of Brian Witten = <brian_witten@symantec.com>
Sent: Monday, November 6, 2017 4:26 PM
To: patient@ietf.org
Subject: [EXT] [Patient] Welcome to the PATIENT Mailing = List
 

Dear All,

Welcome to the mailing list for Protecting against = Attacks Tunneling In Encrypted Network Traffic (PATIENT).

We are thrilled to see over half of the world=E2=80=99s = web connections encrypted, and we do not want to weaken crypto or TLS in = any way.  At the same time, half of the world=E2=80=99s attacks are = now tunneling through encrypted sessions, and many endpoints need help protecting  themselves against these attacks.  Often they can = only get that help from the network.  Fortunately, there are in = fact ways for network devices to help protect against the full range of = attacks that might be tunneling through encrypted sessions.  Still, for  endpoints to get such help of course they need to = Trust some entity or service in the network to help protect them.  = That entity or service helping protect them might be operating on their = behalf, or on behalf of their employer, or some other entity they choose  to trust.  However, they have a right to choose = who they trust to protect them.  For these reasons, we want to = collectively engineer a secure multi-party protocol which:

(a) Helps each endpoint control which parties and = network devices are empowered to decrypt traffic to help protect = them,
(b) Helps each endpoint see when one of those parties = or devices modifies content coming from the other endpoint, such as = removing attacks, and see that with a cryptographic audit trail of who = changed what where when and why, such as removing attacks,
(c) And does all of the above without breaking or = weakening any of the cryptography or cryptographic protocols in any way, = including not breaking or changing TLS.

It is important to consider the =E2=80=9Cdelegated = protection=E2=80=9D model.  In such a model, unauthorized = eavesdroppers represent one of at least two crucial threats which must = be mitigated.  In such a model, the remote endpoint represents = another crucial threat which must  be mitigated as that remote endpoint might be malicious even = though the endpoint of our care wants or needs to communicate with that = remote endpoint.  This model is surprisingly common today.  = For instance, server to client web attacks are increasingly common  by malicious or compromised websites.  Of course, = client to server attacks have been common for years.  More = recently, it=E2=80=99s become increasingly common for servers to surveil = and profile clients, a privacy threat compounded by servers = collaborating through  massive advertising (ad) networks for tracking user = activities.  Such surveillance through profiling and tracking = represents a privacy threat many people would like to see better = mitigated.  In fact, it is also a privacy threat that can be = potentially mitigated  by protection services running in the network.  In = all such cases, it=E2=80=99s reasonable for limited endpoints to choose = more powerful network services to protect them against such = threats.

Fortunately, several starting places exist for = protocols to achieve requirements (a), (b), and (c) above.  For = instance, with some modifications, it would be good to use the Stickler = protocol proposed by A.
Levy, H. Corrigan-Gibbs, and D. Boneh in conjunction = with modified variants of unfortunately named protocols such as mbTLS = and/or TLS-RAR.  Our vision is for such a protocol to run in = parallel to TLS, complimenting it, without modifying or constraining TLS  while helping coordinate network protection of = endpoints.  To do so, such a protocol should also better inform = endpoints of the specifics of network devices available for protection, = specifics which the endpoint might care about before empowering such network  devices by trusting them to help provide such = protection.

With such valuable research accomplished to date in = this space proposing a variety of potential protocols as starting = points, it=E2=80=99s important to soon engineer a standardized protocol = to meet the rough consensus of the IETF for providing such protection more  safely than today=E2=80=99s common practices.  = Today=E2=80=99s common practices not only fail to meet the three = requirements outlined above, but today=E2=80=99s common practices also = (1) allow middleboxes to negotiate weaker TLS sessions without advising = the endpoint of the risks  of the weaker session on the far side of the middlebox, (2) = fail to inform the endpoints of how secure the middlebox might or might = not be, the manner in which the middlebox itself is safeguarded, and (3) = fail to inform the endpoints of the information retention  and disclosure policies under which the middlebox is = operating.

Clearly a better approach is needed, and = urgently.  Network mediation can play a crucial role in protecting = people from the server to client attacks that have been used to unmask = the anonymity of dissidents speaking up against repressive regimes, = dissidents  who were then disappeared after the server to client attacks were = used to unmask them by compromising their mobile endpoint.  = Trustworthy network mediation can play a crucial role in protecting = people against such attacks, but today, where endpoints trust  middleboxes, there is not yet a standardized protocol for = endpoints to understand when those middleboxes are weakening the crypto, = changing the content, trusting other middleboxes, and doing other things = that might cause the endpoint to not trust the middlebox.

Still, engineering such a protocol is not easy.  = Such protocols would need to address a range of use cases including both = real-time and post-facto, along with both wide-area and datacenter use = cases.  As initial working differentiation of these terms, we=E2=80=99d  propose real-time to include blocking of attacks. = Post-facto includes both forensic investigation of sophisticated attacks = and also audit compliance aka out-of-band decryption. Wide-area use = cases include shared networks where the device or entity helping  provide protection is only reached across a network operated by = and/or shared with other untrusted parties.  The datacenter use = case includes networks adjacent to the endpoint and owned by the same = party as owning the endpoint.

In engineering such a protocol, it=E2=80=99s important = to respect fundamental principles of end-to-end encryption and, at = times, similar end-to-end flexibility in route optimization.  On = end-to-end encryption, some of the approaches that have been proposed = include  leveraging the symmetric key determined strictly between the = server and client, and then having the endpoint share that symmetric key = only with a network device or service which it trusts to help with = protection against the remote endpoint.  In addition to  preserving end-to-end encryption and accelerating deployment of = stronger crypto, it=E2=80=99s also important to preserve end-to-end = flexibility in routing whenever possible.  Currently, for attacks = tunneling through encrypted network sessions, network based protection  is often provided through proxies and the like either embedded in = network gateways or datacenters hosting personal-VPN type cloud based = services through which all of a client=E2=80=99s traffic is = routed.  However, longer term, such protection could be achieved by  having such =E2=80=9Cprotection services=E2=80=9D running more = flexibly in a distributed manner, in hardware protected enclaves and/or = Trusted Execution Environments migrating the functionality among = Software Defined Networking (SDN) and/or Network Function Virtualization  (NFV) enabled equipment.

=46rom discussions = within not only IETF participants, but also people engaged in related = discussions in IEEE, UN/ITU, ETSI, and others in this area eager to = participate in an IETF process in this area, we believe that there is a critical mass of participants  willing to work on the problem = (e.g., write drafts, review drafts, etc.) for meeting requirements (a), = (b), and (c) described above.  Many of us personally believe that = the IETF is the right best place for such work for countless reasons. We are of course  very familiar with previous attempts = within the IETF, including Explicitly Trusted Proxy and TLS Proxy server = among others.

We are also aware of the need for coordination of such = work not only with the TLS working group, but also DPRIVE, QUIC, I2NSF, = and other IETF efforts, and we believe that an independent WG could be = more helpful than trying to do all of this work in any existing  working group such as the TLS WG, particularly since the = best solution might be a new protocol that compliments TLS, running in = conjunction with TLS, without extending, changing, refining, or breaking = it, or any other existing protocols already so important  to security and proper functioning of the = network.

In that the world has already seen anonymous dissidents = disappeared after what many would consider repressive regimes used = sophisticated server-to-client attacks to unmask their anonymity, I = believe that we need a world where both (1) the connections are secure  a la great TLS, and (2) the traffic is safe to = receive, as vetted by something or someone the endpoint chooses for = protection against remote endpoints.

In that context, we are deeply grateful that IETF has = allowed creation of this mailing list for discussion of these important = topics.  Please let me know anything that I can do to help you or = the IETF on this.

With My Deepest Thanks For All That You Do For The = IETF, And For The World Through The IETF,
Brian
_______________________________________________ PATIENT mailing list
PATIENT@ietf.org
_______________________________________________
saag = mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag

= --Apple-Mail=_33007D84-68C1-4C47-B589-6E08C5EDFE02-- --Apple-Mail=_60E801ED-C476-4434-AB46-183DD28C1E34-- --Apple-Mail=_048689A0-146E-4945-90CB-641037016704 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAloDGEsACgkQuEkLFQpY zJkq2gf/XenNA1pafByEWFnoVv48CtH6GqU7wncvjI2lxmnnKWOYp4tykj1/K6Kh min1TwfUj1hG4Qvq744KhoowwaY+rL+HRntuzz+Wj+Wl73Vthk8C3ALa3Gx+1IuO wTOAR07xLkPBhuUsOEV9g8WT7y9+GApQuvZouLCIew3aeVyJgqO3fN1sMOVlB0Ww 1x5qYR9josbftQQHVfAfHpgM+ue9wNgpmnlXwQBEHertEmR4bhVNsoY/Kixl1ph9 ttgMcv8iC4LBZ+MKWI0A78Cne4aa0rBsSnRc/+Bs6/mDAgrbKoFbgle11chF5jdD gcZXmL9QPY76ZI6fXyCAjzKGIDGjDg== =7hpe -----END PGP SIGNATURE----- --Apple-Mail=_048689A0-146E-4945-90CB-641037016704-- From nobody Sun Nov 12 18:35:05 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1331C127698 for ; Sun, 12 Nov 2017 18:34:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WlF5vMqBk87N for ; Sun, 12 Nov 2017 18:34:57 -0800 (PST) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03205127A90 for ; Sun, 12 Nov 2017 18:34:57 -0800 (PST) Received: by mail-pg0-x22b.google.com with SMTP id g6so11629844pgn.6 for ; Sun, 12 Nov 2017 18:34:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=t+MyRK/Vk/dkqXK2cJvQJhvtzhDNGypTuqzgpTDiaWk=; b=k3Wj94/9OZ9hbyMUhqApKcV8V6oQwY4Mts5ghL3s51gAYNOXdmp/G63ImEcS4s3Ee1 xlUYxDkln5s/CWb4KwUUvuPIM1o5FMg7WNNaj3Ccohs15vakK953xBIe/pjReFBLhNYT v8UhyD8ppzN049busHm8khbKmBNgJePoNT9T1JnpmwyaiwA6vMib6VtTwhz9ncxCOmlc QCxuVRas9S2HYHjDAnussUoOSHKtx3Qapoxj5dnl+rRX8xeetCeCH/21ujYXX/QyDPru QEhlbzqNikiqpsXuuHzevW46NAg0fLfopaUH+52FZG4enhoCR28gMQ7IoqnV/frewM3Z lHKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=t+MyRK/Vk/dkqXK2cJvQJhvtzhDNGypTuqzgpTDiaWk=; b=UwV7N/hPRFstjx4lKRp3qA0XCx3iDYPN8jQpfkikgK/YVq/cZ4pazMHHjd5KXg0ANX 2ts1QiDEt4bJWx3gy2aSBu/UVIUdPuq5sCzkHz4O037lT9cpj9ymgy9teeFxHf+wMYe8 sP1L14zjx9Q4FJFAPHr2jChOIXTe7/zMFntWVZE7JnzQhKijqmDbFfGVxZNS5SoyhkNM w2aZOJuOQwWMnbqHUIdDh84A4xrHvida7emMKe6J9F/SH6MwJLyg/I2VP95KvhYMY5Ja wbcj6NnSTwXXsBh12oBSJ2c3d/0DNYxT8k0Mk76Ek4/7XnIkAJF29ERmBuWLtxNhF35p Fu9w== X-Gm-Message-State: AJaThX5D4P++/8kLrweYnuonmKXOk8YaxFxm8ZI9EkYeTWTK1KUXbltx TTIdwCBxwDWMJn6pC6LbGg89/JzGTH2F6mYvDyI= X-Google-Smtp-Source: AGs4zMZ+8deN3hnC2gCBcsp+jTA07u1J+7z3dUNsPrc+eV7/ZgYsVhvZRnQzFMGU2q+iWOX/CwWT8xYumG4lPgRoKSg= X-Received: by 10.84.132.76 with SMTP id 70mr7664479ple.135.1510540496534; Sun, 12 Nov 2017 18:34:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.155.9 with HTTP; Sun, 12 Nov 2017 18:34:16 -0800 (PST) From: Kathleen Moriarty Date: Sun, 12 Nov 2017 21:34:16 -0500 Message-ID: To: "saag@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [saag] Minutes and Jabber volunteers X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 02:34:58 -0000 Hello, Could we get two volunteers to do minutes for the full SAAG/SecDispatch session? Also, one volunteer to be jabber scribe would be very helpful. It'd be good to get this settled in advance of the meeting as our timing will be very tight. Thank you! -- Best regards, Kathleen & Eric From nobody Sun Nov 12 18:50:35 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6B2127077 for ; Sun, 12 Nov 2017 18:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xlIpK8OEhM-U for ; Sun, 12 Nov 2017 18:50:30 -0800 (PST) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CEDD1241F5 for ; Sun, 12 Nov 2017 18:50:30 -0800 (PST) Received: by mail-pg0-x22b.google.com with SMTP id l19so9090148pgo.2 for ; Sun, 12 Nov 2017 18:50:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=FZJ28E+eEZd1l3Ba4wJhnczTR2fOJug+/hik+klNWQs=; b=H//l7xTOufQno0qnnxJndtgAeNOKw1Sqi6Yb/bIDx74/PZakAoywJFsb9oxT7ucPfU uJKs7mri0ewVSyhW1TICyZ96OUFsqkMnnAsoDrlIiZtbVLTmXt9U00DsHJbS0AMNOXz2 Wci9G5HtdgbjiFw/nlIximvTvbKhEvfYO0nY7L2UoN8XLmxr88td+GrmywbJqk8YFDil n+1LbRMFAu9C3VHSiVp6/Jg6OrMDlDCdFPPqBQYw2CDteaztXPJ4Ut1SX+5E4/IduA50 GgehNONBA4VF6CFgpByeKzGU2Q1HIN2hc3rY8+dbB84E1c0QCsEfNor/EwPVADp2RmiS Sh2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=FZJ28E+eEZd1l3Ba4wJhnczTR2fOJug+/hik+klNWQs=; b=bSeOT/aUZSdB38UnAx2g6QB7lBwvrEewfH3d3YBA2jsJrj0TweQxm8af4nv16Sa3XJ yliVioLD5Ea4NODdme+GKh0D6PDWTsHaOzJBA2j/6MbcHpOzBPP/yZ5+uEZiKtNp82ZV HFQdg5OBUOYM4P1IbcZq6NeD0fZ38xkiyC8VOoKm18X6Ryxvh9GuBxnUk33HQiw6S78V TYNUmmgVDnP9Zggo6POswEcffGrkT5wdZgFIofk98e5Vyv1sBdmY4+nfKf779buAcb9i 3LRoU528SfCVMlCif15uIJwG3D7PSTEYuCWvraEdNcbO6zqssx1wVkJju5B1aHpOMXd9 pHQA== X-Gm-Message-State: AJaThX4y2wtJCSN0ir3vl9SfShkZWDp7JGx9ovcDxi6aMu2DdV1E1gbK NASbjieZxvcJPUjDJVpLARGhVkDA39W8pzmJe5c= X-Google-Smtp-Source: AGs4zMZtZHidoY51GPb6TcurfPq5MuUc6ed4RAcdCk/Y48yt4AQXhWOvpHkzSJ9IZvaDDF/HrKZywVNXtX7+vedb9h0= X-Received: by 10.84.132.76 with SMTP id 70mr7695930ple.135.1510541429821; Sun, 12 Nov 2017 18:50:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.155.9 with HTTP; Sun, 12 Nov 2017 18:49:49 -0800 (PST) In-Reply-To: References: From: Kathleen Moriarty Date: Sun, 12 Nov 2017 21:49:49 -0500 Message-ID: To: "saag@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] Minutes and Jabber volunteers X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 02:50:33 -0000 We have a jabber scribe, thank you Yoav! Now, we just need two minute takers. Thanks, Kathleen On Sun, Nov 12, 2017 at 9:34 PM, Kathleen Moriarty wrote: > Hello, > > Could we get two volunteers to do minutes for the full SAAG/SecDispatch session? > > Also, one volunteer to be jabber scribe would be very helpful. It'd > be good to get this settled in advance of the meeting as our timing > will be very tight. > > Thank you! > > -- > > Best regards, > Kathleen & Eric -- Best regards, Kathleen From nobody Sun Nov 12 20:55:44 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDB11293F2 for ; Sun, 12 Nov 2017 20:55:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 D1K3E9ImI5df for ; Sun, 12 Nov 2017 20:55:38 -0800 (PST) Received: from dragon.pibit.ch (dragon.pibit.ch [94.231.81.244]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E60B124B0A for ; Sun, 12 Nov 2017 20:55:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by dragon.pibit.ch (Postfix) with ESMTP id CFC02171C055 for ; Mon, 13 Nov 2017 05:55:35 +0100 (CET) Received: from dragon.pibit.ch ([127.0.0.1]) by localhost (dragon.pibit.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umExb5w_9UKn for ; Mon, 13 Nov 2017 05:55:18 +0100 (CET) Received: from [192.168.43.90] (amx-tls3.starhub.net.sg [203.116.164.13]) by dragon.pibit.ch (Postfix) with ESMTPSA id B91F7171C035 for ; Mon, 13 Nov 2017 05:55:16 +0100 (CET) To: saag@ietf.org References: <20170717141000.335aase56ug7m76q@pep-project.org> From: =?UTF-8?B?SGVybsOibmkgTWFycXVlcyAocOKJoXAgZm91bmRhdGlvbik=?= Openpgp: id=31733E0C598D3A1CF70955D6CB5738652768F7E9 Message-ID: <8fa36c13-7e47-78c9-2e10-3b215c3a80c5@pep.foundation> Date: Mon, 13 Nov 2017 05:55:13 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <20170717141000.335aase56ug7m76q@pep-project.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1NiXBodFuOXQpL4EreaoO47UgcmDt8MDp" Archived-At: Subject: [saag] =?utf-8?q?=5BNew_invitation_for_IETF-100=5D_Re=3A__BarBoF?= =?utf-8?q?=3A_opportunistic_encryption_with_p=E2=89=A1p_on_Thu_2017-07-20?= =?utf-8?q?_19=3A30_CEST_starting_room_Tyrolka=2C_ending_in_a_bar_=3B-=29?= X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 04:55:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1NiXBodFuOXQpL4EreaoO47UgcmDt8MDp Content-Type: multipart/mixed; boundary="oh1GlB1EoR6biUPkE1Gf3altUDjSjWQor"; protected-headers="v1" From: =?UTF-8?B?SGVybsOibmkgTWFycXVlcyAocOKJoXAgZm91bmRhdGlvbik=?= To: saag@ietf.org Message-ID: <8fa36c13-7e47-78c9-2e10-3b215c3a80c5@pep.foundation> Subject: =?UTF-8?Q?[New_invitation_for_IETF-100]_Re:_[saag]_BarBoF:_opportun?= =?UTF-8?Q?istic_encryption_with_p=e2=89=a1p_on_Thu_2017-07-20_19:30_CEST_st?= =?UTF-8?Q?arting_room_Tyrolka=2c_ending_in_a_bar_;-=29?= References: <20170717141000.335aase56ug7m76q@pep-project.org> In-Reply-To: <20170717141000.335aase56ug7m76q@pep-project.org> --oh1GlB1EoR6biUPkE1Gf3altUDjSjWQor Content-Type: multipart/mixed; boundary="------------5D6814548B7AE700D3397ED2" Content-Language: de-CH This is a multi-part message in MIME format. --------------5D6814548B7AE700D3397ED2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear folks As this didn't work out well last time (foods & drinks en mass as concurrent event xD) we retry it at IETF-100 now: * * * Side Meeting / BarBoF at IETF-100 For tomorrow, Tue 14th, 4pm+ we reserved a room (Butterworth Room): https://www.ietf.org/registration/MeetingWiki/wiki/doku.php?id=3D100sidem= eetings2 We propose the following (tentative) agenda: 4-4:40pm: Intro to pEp and proposed protocols to automatize email encrypt= ion 4:40-5pm: Demo of running code 5pm+: Q&A * * * Original invitation went out to ART, as I heard interest in secure messaging is high there these days: https://mailarchive.ietf.org/arch/msg/art/QfnwBqXJ663xbOsFGb47SUxvme4 Greets Hernani PS: For any comms, if you don't have time to attend, I'm also available through Jabber: hernani@jabber.ccc.de (Or physically until Thu.) On 17.07.2017 16:10, Volker Birk wrote: > Hi, >=20 > following the intro being delivered in the SAAG Open Meeting starting > 13:30: >=20 > https://www.ietf.org/proceedings/99/agenda/agenda-99-saag-02.txt >=20 > for people being interested in oportunistic encryption of email and > instant messaging p=E2=89=A1p is offering a short workshop in room Tyro= lka on > Mezzanine level on Thursday, 20th of July 2017 19:30 CEST for all > pre-beer questions. Post-beer questions (and beer) will be served in a > bar nearby subsequently ;-) >=20 > We're happy to receive all people being interested in this topic and > all surrounding technical fields. However, personally I would be most > happy to have people delivering strong opinions and frank critics ;-) >=20 > Yours, > VB. >=20 >=20 >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 --=20 p=E2=89=A1p foundation: https://pep.foundation/ --------------5D6814548B7AE700D3397ED2 Content-Type: application/pgp-keys; name="0x2768F7E9.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x2768F7E9.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFWozlEBEADAIFgjylzzPH7JKRJPbiEGoSsrSaCrbWLdy4sNGD4fS7GsuZ9f o/E9iYzC7WwGhN8rB4jsLv/ZfGVbAsmpypvZdReVs/BPidR8Vo1WMOK3lww1L6j8 7UV7TwUzG72u0zMXCUWMtX3+7kWZVlohXPCzDe7xyLu5tdfPWIAxDrI3h/+a4qAR ySVo8RwzILDwjbLF8at0w52oTRIWcr9CAus8ktRKBhc3MiUsSXHGgZLujUsXKAYg Vmh53uEVsjigeHZh6XPrzQPTnQ/VDcqNSRl4n+fQ2e/sZV7CQttcqb9zfj8P6Lyk jG3pe1AUSm9A0o75bi8PUluPWyH0wdt4D29xabFFyBANyYqKiLyZvnBqGSkqswnW 00QoYtMaEBh7nyuoUCa0bTMCRn8NaXRCnuINx+E2llqJqeQ0sMJ5WSQe4RbkWRsF PJOdiouLyHEZUpyQlMFesu/mN565eZsw3a7u9hxnoFgX0tF0hoONMRSAU1y3aZeb a+DvwXDQcSaHmBARQ2v8qWdql16Zhvf7KFo5Cris9jNknInzs2L6pHVZN8AY2ESO 2UXQJ+Fyy5BEHXS4LzEnWRPLYkAE5eVi+ZDcRMQeO2L3ZenqhcRRcQUAaRObho0L WzE+EE8ZvQxlA5hn/4/lHQLk8ZiEgenl+y/mtL8TeXB1HO4DrqahXvlu2QARAQAB tDxIZXJuw6JuaSBNYXJxdWVzIChw4omhcCBmb3VuZGF0aW9uKSA8aGVybmFuaUBw ZXAuZm91bmRhdGlvbj6JAjwEEwEIACYCGyMHCwkIBwMCAQYVCAIJCgsEFgIDAQIe AQIXgAUCVyc6XQIZAQAKCRDLVzhlJ2j36ZLSD/4kywpRTvMvijdNM+3B8W4rLQSo 5BZUvkOEczZl0F4FzGgfaTLyGwj+hZtdatdxhk9jC5uYKaCAR+dP3wl8VjxmnjEc ir796Tw20sJuye4Qz+R9sghnJZM7NDZ7YmV2zpi4RXWY7CIYthpzUq1L3ujDlDNf KdKYd39PiGtyotx2lESw+LBlCddooPLSyPNp7fjWsRCgmg+2+yrVdl7TEO0QFcGs fLaNpjwVs2UXl+JzJql/CzV4Z9QxZAkhgpeObpiu4t/RJuPjmKS8lst7zJirhlwO rlXp5VkGyrmsPkXq/jFDkzNrAAX5uX34jTBgTveCRBr4MElVApq6sgbGfOOqvhU5 SZ2qWPw+t2yHiDbl9tE2Mac2UiodFPbFSlOnHd5KHh+ghWDyxCAkAcwxWexk4PTC WwGxqcvz95JcHXx6PAHDOkCB+zCHX65JOVpYxdb89xb1nBpqKphkXax7fyQbA8Pe Kf3ehp/x1gF94Cb6xevgUw1GeqZoURV65O9fzO0M+xSNjcyL+V1ps2IcZEOfKJtW nQYcfz0GZghSXl5KdKSAUlmt77nGuizsLL4qUaDIV0pvVAmBZmLbJ8vO9XSBDFnw 2mIrFZgUikcNpmZwKP7IwEcY6qz1BACG8xiS93j58qo9D9Ji2DqohIvsMTBFM2KQ p/VmXK9SPyVkNQa4vokCOQQTAQgAIwUCVyc6NQIbIwcLCQgHAwIBBhUIAgkKCwQW AgMBAh4BAheAAAoJEMtXOGUnaPfpJJAQALsvRmAU1dkCxdTMMiPtlzIbjWNwhoWg HP5XIjP/vbOyvu1Hjr1ur1C6WcR2GvlnFr6xlq5P62S2Z6GlCmTABlFdviMdrBIx UbDOywp6FR76w32uuQgq8Vsowdwv9lSJoUo0vR1f+1u0D+VkbAxIaUT3HUFY8pcm uqIpSm+TbvyMXCQ5/H6bNVK64hwifajbkEzqfjDFCcOLNwRLZn2dfJjNIFqC9bS/ Yuw4Rq1iAIWhPG47fu48dcvc2WGKlHHl18jEqNfnOvYM7EpxLtI+Kj1wYnxnmAGN 8LcHKhl9BWatHSV8jFlW0VPNHybL584sOEvlT7dFVsYccePMlljTdrxFSlxawyv6 WyiBIfiHnPxCCTB+FPIEBQhx7AdTnXbx1Ebyb7B9NMedAUKmZ3RCXdt5FsCE397F DHlomrzWs8Pt26dC0oHuLKIOkeMtYnbZoGvvkaNJ8XTkavguAswWQBPOumeVfJG4 u1nRNNRFbD6nGKYsm79KafkIpQKUlrIY6CnxrpuY2XGfqWLpJlWjK79L1EJRZMHP Z2y/6IOOT8truBwvHCu2R/bAXG9q5prHkGNegSc4CwPXbAXdKevrKYBGHrmtn4L8 dqJGlRehQUhZSHSBGckdr4Q7FerbAoEm6Xm2hOU4SKor3e9XAouU+COIRjk0cRTv OkTuySRdioqEiQIcBBIBCAAGBQJXe+cuAAoJEH+zxRJjw92vLy8P/1xWquKLJ1E6 n0aDRPLRKV3dcdTS1CzXLbGOp1IkPrg35hAJtiqhlYDWqY7Ff/oHzYFwi1iClHwq FCTx3U2nGAU6O7/TVR99c9FTV4UdbO/et3J+rb6dRm3e+DoqCgBq/uvCrg7I8Gcw vTLOnIxXeL9N7ZIzV7Ac5rdowvzCMhGClRrT3im3fBpbe4EbHPfrTtBclZhL52rg 2EYrfwu8b3OeNgNzEfS+T0GM9O9ZeTVU6xqtqCfyYYzTSOTL0nLxabl5QjSq+Xn1 9Ye7tDGDIE47Tt1XCMQANwpfQzDYbJhYeXhX9fUw1oDIX0EbGJI/X7aHhDPn+bFY RsBUS7x/tuD6STnbDLanNjRvyBpttMkMwW9udO0QmMwApZ1PqyB+xGoKQCQhnN6y 6RQDUjMBD180J0i6f9K5zezwrAqWjQo8fU7S5Q02d91iRk3msZtbNR6nM+ulVX8s 8iKhHDBiJdzW8WT/wc2R06ch8LQ20sNscU4ZrdcC5IOL5uadCT0NTCr85vC47Qgw 2Ywe7lYwvamkU9GeM0xIs5ZaLkC9PpWOGnQbrpFDod0nL+mot+/bdtI8fX+p99aC xmHAG9GIt4V0unAVvFo6HQUKN5h49sfLQk5nZqAfhrxFgoKPeL5IvTxls+D1+/1W UHBc9FkdnBLYOQz+IXKfpjf6Gus5u2dTtERIZXJuw6JuaSBNYXJxdWVzIChw4omh cCBmb3VuZGF0aW9uKSA8aGVybmFuaS5tYXJxdWVzQHBlcC5mb3VuZGF0aW9uPokC OQQTAQgAIwUCVyc6TgIbIwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEMtX OGUnaPfpn3gP/1V3n9Xt8ha1juDe11jq0y0g1jQr1JMhZOoBOp6ttSpYCe9HCoJw VyvO1iGLex6XHSe8zrWvP38aihFoK7jQBc8xwYht1DcpTM7HFyXJ5/Pch8BNS4ds c8eozvm96pBPPmFDcm+igG6dkO81/9oLqP8+Bagz8G58BktcFhvnjmLrkJftJAJQ 4LyP5KlXgmUIxu9l//Wa8AMkty+feHTIIbrQGDTM44a9N+uHwJ4OQjHNvvOprg4U ZAhehLAzCk+gi68uHfhH0AtKwZ/v/lag7OYle0KZelxFsHnVE+Dhe8HlyKqtCCOC vkWGtz5CBJDO/V/xUQXBSJxJd4Q4w9Gyf0mJ+Ljr8iu1fyaEor68u1ZGkaWbzQSF 8Ycx7o6MWV1fAyFpUNUs3M3vpmJpwrWQdNeCpQaczexnNcrzrYdFDLx8z7MMHEy8 6QSmjmaDSA+VgAHzV3oo4R3Wu3wZKDwm4eFDBj8N5IBxMMfjfinnJb01WkAeRtAq K9KdXeWGs6eO6OBm8OSpao2V/lw3IZIiCdowPaEFzw96DwmES/zTAis74mENrhnb vDrzFVFkNOUdf2Sn9x81FJ7X13TEjENUhJJI87W+Ttk9eKUarkjtKdHfVpEMnO3L g6NJiAvwpcYfarzfmorrwp1pscLZBEFGiAuHVgNzY1YwXMirPVnY7MnziQIcBBIB CAAGBQJXe+cvAAoJEH+zxRJjw92v9lAP/2LhBOb9ztjDKSNJMn1IXJK9ALYor7wG 3JrQvwJGdfKRj8b3p8nlGCtFpo32h/7t/9lNxPJmONJcc76Y+fqviseRNk05iGCO IycL8Q+2bLvzQP1w3exvo2imgJGgtZFZqQR6K/D70TrTwcyzpW6h+lN3ZmZu4Izv 2pdtJMh83PZus0A1cHQUhIjCl46+uNT0BaEAdDpqcC59EWFFwPj+zEhZgTtrAU9c hSXj6s4254WMKa3BIuy90bWqyMuJt8+mLYTfnpNxaYrMX/puC5hs1WQi0BQVXdLR ooSOgYDaip0mXiOyqXHS0V94fuiONqzYYBjQBkpheorVuMDZL49bh2c2VyANxAaf cZSN82isbQG1anl6LJRRiGm6BYC+Ew8OWmVkCEWOK43G6IQ+Nl5Bmv+FyIoBQzaZ 4ioR987nC82cLCbtaMMs9ib5cTZBEIAeDaD0THl08pCLkfR4nPLG/u+dTE5zxSrC P4o7OKLLnYTcOkU9WdhfZV/6a6iBJy3uvuFDoeoJG3Zv037gHFsmd83mo6xm9qls RyY3vOTtxJRxsn6mn4/RetutDxJxvubNZaxxL33coGm8GcMM3BaOdZiRgPOR9E5S MUrlnpaMwWno/mO9ivifW/BFSetfGN37wGeOcoMwwSCfj4OK9WVhfJFqFweL4StM BCQ6OZLcxWb3tDpIZXJuw6JuaSBNYXJxdWVzIChw4omhcCBwcm9qZWN0KSA8aGVy bmFuaUBwZXAtcHJvamVjdC5vcmc+iQI5BBMBCAAjBQJXJzp2AhsjBwsJCAcDAgEG FQgCCQoLBBYCAwECHgECF4AACgkQy1c4ZSdo9+kEng//VY+l7xtGPe9q/FwmZ4Zy APJn/hnwDjGhPeuEgsT4IgX220NB3UEXFAx8tCSuGY85862dC/AGQeGnzoM5u7rl TRFGuv92EtE2n/2Lfbte6yb5MRmzTgdR7cP1aNpvjCN+kEp4FfmHl1XPBFyX6WLE QG+ZnUDFIyHt2I7dehdN8UogJHdIfZ9y3IEhwPqAYq4CRkf7P8Zkk2km2Jh8Xjjg L5dsjCQKuNAnyktDpxUM3N/ifsOfrNulEIKlDA2yW3kcGL3CPj2ugwXgkSykeXaB zVoqbqRcPOO8/J7mVEOoLVjPwYq8f5NGWq2U0rbJnRTHX4benaxw7rCi+6nbAEHT j0zbpx6FH8fezuzx86dWlFngqzQDOkiZWzc7ql/eb7pzHXuQ3QC1D+zzNn9TSTSD AjRFpgIuPWkAb/7/WyRfwqd0XzqinisA78I+E+0MOhjpQab/i9hoQRB2LfGaI+gB taRX3aRotXNT1E5R1fq67r890Sjt3XTzADK9B6RqpMa6T0LDe4zS2CYnDbUBjljs YGR5WZ7K03Qx2p9qfCFBTt2wvy2J0b526b0yCRINc6TWDs/SlRqSs/ATaPSbOKfV UhXI8k0k2SV6FSBEPwIY0cUSRPSoANfv+IXjiW3RBbjNkvpbVtu98CDSbMBefAc3 X8oVtrZ+rigZzd41QAhaOp2JAhwEEgEIAAYFAld75y8ACgkQf7PFEmPD3a8pNw// fQnOl3/RamWxLz3Vs2Righ3M1kZg+NjQ48mIqmSZLzwu9MQTn71nOUdyBnkmEm+b sYviNPQha93wYx4i2ioLKNSXyDa1dBbQloidQm0b3TkeU+5a/CN7r2OauReNvc4V gVupxaeUyEToFW/RnQihbu17zZkwqTmKolQ3hd//1P9nFGccYU/G4DQUonuBzCV6 uOIKZ43KBA8vm4nk8uAW0PNLJHOaVM+vuDgLqx/r703RE1YaebvNC3IuXTfXpQHC GMa/gJQpxGmqLjlKDC63k1lYAk5gApkfj36+RPAiWYpGvo3i0EXTrXlwehqRJoYA 8lNswk7LcvSFXfKugomMtCtH4vJUNL1sgE8tpWhQD73K8q3cHXLPIC3Tk0If+7h3 xdnZArLLQrXEWFsIoRcQDLGVmJhy0Bynl+uNuTwmJRTvMUfXZk0PDu+UdjaK2rDv t38i/K9DkOa5lT39M0yV/RX1W286cjXnKdrHRp4lC9QN9soFuEuCzgjiSKYl+xKa oLGaJwvoxNAmduuLmuVitsriNFf+bi1PSEfDBBHq521Q9D5u3jhGZofGu2HOazCO GhZs041SQ/OP1P8+LjjxwSEpGsQJFdET87oqApCkMy43IEOB0DtOIKSVrdE46QBZ MAGA1KyssNkVozEKH0NU/gGOmjzkt7nS8qWvYIvcKN60Qkhlcm7Dom5pIE1hcnF1 ZXMgKHDiiaFwIHByb2plY3QpIDxoZXJuYW5pLm1hcnF1ZXNAcGVwLXByb2plY3Qu b3JnPokCOQQTAQgAIwUCVyc6hgIbIwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheA AAoJEMtXOGUnaPfprZcQAL4wyuQHrMUb56gfvipTZNAV0YQopEeUtJlNPT3MDYTy D4AiTDmsDZwYaPI7O5m2bNSeLOmhAdqkUXhUOvEIWI0ABqkWVHL93nSEzFiI5HYI bmh0UqpYf0myXQdWE1qjN6n1xnqk1mmZ7RSuIJ/9zwliiX5Qyr/RVfxOVU3iBskn 5iwGNs0N2anU6oA6EoD3VsuV650aIJN1c1e7bOd0QT4Z+FuYHPqsuZ/gnbD7AKJI rpO/DoWMG/Ayzw3M746Ff6GKlQFaCmMja6pkfX8NqylbPY+lDlznu9LYXK3z/7gc NSZL3y53d1G5DvbK33sDXpHEpQOVbl6cAR6cgN0jyjh5Pg4VXKWTntAMlK9E/f+3 HmH7EILxF6x9kl/TJet94igOvAU3v6Ktd3CPhc2XLvp6oik7NbE4hOFmkgJYq1pW 9hffzh9NGzF5l10r9Z4j0bvxbbqXZCsn2/WvK4FhidZhyHgceM/kbH6jZdOEZPw+ Kxxlfsy4CeNDexas2OO1coz68lBiO6uD9+QgoV207hy4D5txTRF3YnR3TDdPbxiX nA8T/xNKOfMvWzfT4pmsuQdK9+DLmDPHDCZli3/5fLh2B2tb/r/SxLRNEaJjLEzb gPxxH53G5FOvjGR4isUbsZz0n2K2KZSxzVAEpkG1qmMhtGM4KZB2l+KTHBpxzElR iQIcBBIBCAAGBQJXe+cvAAoJEH+zxRJjw92vLwsP/RnUNo/RJim4FlBbQ9l5sbcp aCMyEKRMv0YYLT6QpoNziseauPxpQ1ITLeruwuq4C7ZkTNy+sj9NsC4R360YR0Dl 10rLmYEM49gPOO5RQXpJFQsmpwZRFqFN0Ct2lIFYD3XhMyH8/yV+DPJ9EafZQlC9 L6+Q+up9iK1JdnqisdPGHduXK9sApujb6lkS8kF3PV2BitdLTgsVk0tGrs182Fkg Q68rMpubCB/IUkTuuU58VWKGfsXhrndxRb9g7l2/6S+1MWUXochI5Bl3D/XtemP9 aIL21EApXj32/rfczx/y34okbs1ePPGJDTC2Qwprkcna5VPQWOE0Aq+Ic/Dy3GPW T67IfblVV3/iar7z01L8nKkCBWx3VVLOFgVpOeGKEjttHlqK+xaamIgHKRi4blqX GXIT19RQ8o/krDV3U1EOC/vLQn168vGJ3iOI/zISEG6Va0hYAV10ebhGi7S9VIrZ 9qM4gA26RhP0i4JtxPo0gjdbtUMosTxBrDKLZyAqgRn2eNOaRz/aO0xtj/HrUbUV yDZANaVf69rn03yejq1/pNrDHfPwPma3TmEBM1ieZ1ciGT9uwnIQOde5pNsYGk6B 5M85ZgDgj9YaPrKobL1lDcq7KddAks/L+SHWI9o1jj799FJJwukwTUsPe4LRmxny dcdD3O0O7RzdwurQV1jjtC9IZXJuYW5pIE1hcnF1ZXMgKHBFcCkgPGhlcm5hbmlA cGVwLXByb2plY3Qub3JnPohGBBMRAgAGBQJV7/dAAAoJEHuDbkH3q5zl2OgAn12X bKVf0usg/exDv8tOxOzPTr8eAJ9b4QFCS/Bayw5zE3Fy650owknfJIkCHAQQAQIA BgUCVfCW0wAKCRA9g02NGPgJNGo+D/0ew5kut7hDw8dADIPpHaaSHfCu+7TskdQx Usbrg/4wvmiQ5lZvFBDtbqvtBHXVQ1Oj2xtPRRdlL5wuiBqf6hpnR8dQclggnALa kVi8D+c38AKQFFBpAPTraa6bCRawSS74+nOyrSpR/hUsYXmDyOvQCBxKpwS7Qi/O b/JpfVZpLwD+297Z+ILNFixbYlYuA7V8z+ErQdkhSpkgtBoeB20gbw/FmqyQKvtM 0ul43mINJpNzYP4yvU4YsDCNClGOYWLLPFLcnvVowmhRmMO7rM0eF6FfhLOGhbb3 1H8akl2Op2C7EiMv2D8DGiZtV5QtVt9r/PCdl9LLEnw1kjULA50yCD0F4eXFLPLU 1S6APqKFtSv9esSINLjo0q1b4S5ekmUEqhBMRHvREPwGmsWjodp7pe1QPNPqb7pr NAOwBxyKveXWIbL0TaYbPhBQ4az7cUsWmlW9Bgn08zu9Jl9t9SdoEp6BV8qk7y6V mimMLYe2pST5dZjweb7+u4Sfnfttxlt6kwu+hyz/c1RX9VdvgkzaJ+8i+pWvHyij miStQTiHtJEcKbzhgHcEDfOkvFMGmNpHlVuB8skUnb9HeGheb6QZ2mRmCwZlKQQI MDYHE6xOIw8RJBHiIhvXOr73mXcORAsBvEAkGKQRldjtuQpb2dWEaL8oz3p4TA6v I/8y4qj7mYkCHAQQAQgABgUCVe/3TgAKCRBLSiQj0EHGPcmQD/9ngwa9R8nsM0CT CMioJEbWJ4INnaDND8uvnPzRT+vyUkTJzM+RCvVOoGgrmCFeqOeCQhdf20ExsANs qtv9XQEyDDI7PvnAnprJLSYozfpYscPe7N2MSwTBiPz70t03L5j6YfJhooCok921 U0+xCNUl3LXzfIkXTxMC0z77VxSqEiHiPgQH4owqnDuEhRPte/ZtzvMgCRIk8L8+ 9UZazl8hF4r9XPP+h8EFVJW0MB2ANICvmHcspiVd6QJdPTYHZIwZ2LMrb5Dt1Qwy NkTDKvoImgR6qiaR06GDyMhis6l8seu6GuAtOZGh2RGsGGPDPozcTi1kdytFmGC0 W2J+bMoYeEMiAH4Ip4o4KvLwvEIhU1RTMWg3Qo172w1Y2FLQSQLar5kVvjHfAdpg AeZMliPl7+ydziDF+EYP2p4d6kw6aPZNoB7uD1mhdgxts0lBuU3iRQwhOQTcrrJj /2DtUPdoFGoR5OTVDrmb1lodw5WWzI8FtTZ7C6ZyGPjj+V7COTSHGP4R7YLXKrPF K+5AjxzozK+cIgvYSZol8ZfAusxzz5mHXeTZqpHkQNdfCCHWCJ7og2W5baprUgkQ n2O9AqEMSLQW9hpMGbzKIVh6ZFl6n2is/dZubS5aCH9+bNJqEi8Vd/pMsW9MMEet eGKc1WoGtDFFDM0YocgvF1CsSfGfMIkCOQQTAQgAIwUCVajOUQIbIwcLCQgHAwIB BhUIAgkKCwQWAgMBAh4BAheAAAoJEMtXOGUnaPfpw2sP/3YEftsFv83sPLBclsA5 HFNRr4FsXzbRv9F7grDsqnvecgD8ItwUJ0G/Z/0uqXCPKecnq6mNhRZiX+AtNkGi Mle6xcWI2kacAi/L61GPyXWohsy7d42ej+FK2/lyKScTg979XBAXGJCCfyGoaVU0 Rt9zlHyOOB3091YC4gSYkMJ2i7jsdp7lqqvTwM6oPnEQkS75XliTDKesvYdrK87M TcF5tlBNVq0ycGmpGDOY5+d5HvkaJyhfUeJcknvMPIcObsH674vyhTejXabQg2uU hiWyOFEz4T2Xw72XdvtXhB8eIGNJOrGP8HqG0fhejoyXV7m2n0X9taYB+VqFrRnT 9WeoStaMHzLhEAvOgLIXGe5bDPVkE0fV6SASvClAATtgsrunsYIuhQ5qHmcAxofC r0D4CA4YDhnRQbdbRaEKrHPFKkdtw9W8D2HO8X0xq6FmykYNuKI9k7w5oPgzuGnf tBX/8VpKEaSAOaIX4q4MrelsbyaJ8Ujx4fUFaGHQW2s1rmmJf8BnEEntyDSi3Tq7 JABSeA0O5/JUJS9a4rSMvvssdtYSSAtBD0N8yZTtdjdhaFffPbpv0PKmuNbjX1Fs 0NOJDPWKwrSohXDWqr36ott5ap3/3wf/5upgKNR8AKoqjCF0hmPS2L3S+LNnqlZY 8eomhf9YA1gSN49yR+2hAje7iQI8BBMBCAAmAhsjBwsJCAcDAgEGFQgCCQoLBBYC AwECHgECF4AFAlZfiokCGQEACgkQy1c4ZSdo9+lrTg/9FOyKWzceXttk0a3cnUpo p7AQkQC9FfE9QQzFOW4VHk1ZKTlH7V1QrOrzU5fadd8C71oHbf75fVTlmNtcl9OE 0fnx0T6G+FKvTyJV+W9LIRbsNe8+q7eRRtf/HsjQdblEIqkdUlAhVRgCjBI6K/re MYVoz5FxSGoIMjfxds1K3kQICxS+uu+zRm6ff8VuWHMSESC34IxlIvfBf3vbPYnU Phu4Cn0UTxH3pmHmk+teJ1uFWiX98HAxDpv0ZobKNa9imcSCKhYTqdm89XBXND01 bUd44w3RCmSqgzEQoRi0Jj+ieg4XSn98lOItIBPE2pi92NskdSJr7C5++0fO9xrz URZjqGiEPmiegW+OMvnI6X9O2SBzXYU7GBiqpprWsa/y0WKRJ8O+kEVzGUI1Bnge qvZ52QHGN9v5Wnho0gvAWgiAmDVn6n3yfcnI+SBJHmvy+Im6TI8aNSX4G9xQjVuk M/iWyjsNzAyxjtdkbuOBiKAOADDqTC39HwsGoHXuKIzEZMGTFx7vA1yutogtg8Mf UsqX18Ilt8p6v+dtJJY14MzF9fyVIfVr83Fc0IPuv3f59+7VQPY4AO9rUN+bcjgg dKY9peLGizcT1msWew4byIIjU39EfCx1ojfYkDFmV6fQOMOLWT62RgIiyORRKI0M a2LnrHUqPDU6kWM78skVH+eJAhwEEgEIAAYFAld75y8ACgkQf7PFEmPD3a8koxAA joGdnDNipBywNv9l5QW0pdKesUwSKNA4lxfIuSwDLw7ZTabmMHH6WBZjNmcbw7ro kvuSV5+njrkFG1qTumy+JXtniT7dboEr/lXkibu2EEB8z0QNShMxm3Cf68HRsGQR lAwglnqDnZEOkv5AGWYjxqOfRRCKCIGCGHZkKYVK3K8DU+09ifaAxuR2KLJuPMzY wD8moZkBlyEzT5FhOb6hVCG9uHBeCZcayrMsTFhOKU4Y5GKTNgsE4x6FbZoGCFhT wx1MGkoCvzScPhxmes5kpr/AUZgwaseHWfsaC5XgDqji3Hhu21e6Ez4NkH3Z1CUH LEHzGodxpKJ2EkWVi5ofSzD+19MI3A0qwUgDdGVNMDP0k9SvwMPngA5s6hht7sD+ 6mtSnuHwiNLNZk39Qt7sHUYg4AQRCIwzUrQuJ0PUtFIzox+pMQcVIgVM5rwxnNbq U+iWgSBeadc3PfAr6yF3gJy8U7pN7JSjiEuhNWu83cPm3zuIIVhDwjJKQzs+rNun M4PtithYloEgpoG5tMtbK5qIGIQixddlqXcUQtoiA3gFXO6xQjeqKWJMnxp9q+cB +LhKromZENljj8M0UCtzB4UGu4UIeDGKAPsZUCHjwL3LThyK+9EtLH97oz/Q9IgX H9cEW4Ksisct3MAscra29MPACt2xTRKUiXzNVBlhcAa0Pkhlcm5hbmkgTWFycXVl cyAocEVwIENvdW5jaWwpIDxoZXJuYW5pLm1hcnF1ZXNAcGVwLmZvdW5kYXRpb24+ iQI5BBMBCAAjBQJWX4p+AhsjBwsJCAcDAgEGFQgCCQoLBBYCAwECHgECF4AACgkQ y1c4ZSdo9+lsdw/9Ea0y2n0Indyhw8RaC7u/Lu+OV5a03ATiWuV16vyYFXiJaVTC ildscXCRpSRHrT84zk4eYf6ysRuzlXZUcg009nF6lajuzDm6E66ZJXkoInGpwEcG Mx5odUeSKxcaZ5IQveEWyJahLbHf4FgQts2r8BsChkoSEvhxojBhHQT5FYxdYNcK nrNj63UZw+xwTbg/79PWOjB141OEwNOT4rggXSZ67w8O1JtMtMGYAgI2KiHIxUPr uEudiJI8DvXUakX9LJRTpJnqSacgkC/ahL8m5//7ePriUO2FR6ZeDkGp5z6g59+l iruJhOcmbjpr7wAo6hVzdkpLT8qu4uuoaWM/kRayEKfhlUj0SCcG751ucTE+yH9H MRBDUV/8fhVuoLsEHnq49/J/cVx7qr1y4EfDDaN8zW8ILe4vcZwGgbD0lI5r6tey 2YyvwVEKDEe1vIiarbRsHa+6haX885SAyooIfdqKDcn6NGM12AVAPOIe2+2Q7GZV 6AACD+j7GWX/jiNaV4HwJ2/SsNBFPw2/lDowsHnhFdvwEROynRlGG3FbHMGJ5HrN hQJWWZDPF40hDpuJpQRUuc5uzOzQUptag9m5gfxCQNQXCtlIpIJ3CdlJJjPzndIH ktV6/eo2xiAn24b2yBeiBnKjET6OE5iswAd4DO3BjAKTBYYmqD2OMC+QCzSJAhwE EgEIAAYFAld75y8ACgkQf7PFEmPD3a9w/hAAnMSIrMoIVgk/o7Xlyh/9TR3WTRsm cxM3Vmz+KI4hzCXde9JK8a+vrZMhSH/ZBBanFPQolu7zRbj7+MeY/g4cJZDsuHBM 1+vhwjxwFPWXRBWdNZFJIzz14PF1TVGbsaQw2r9q6cg6u64pZYA3G/scfcRxPMsb QnVBz0Lg7f2Jrav3TkuwvjnKpnZc0iZ6QuIyAwUdth8TY7y3hXY56VwT1rrtOHXX E0RKaDfCoyep8rRG/+qhiZT1WGzq7LDAIeCR5DdleCaT+bXMsK1N6Xk2il6vXjed vGOtl12I9IgqC30tqqJMpWrRb1KFX60l6oCOYqrAqysajf1BFJeDmiZgpxLcePLD 9XrzNHqKrK7ZRVGmc7aKSvxIyWRrorYDh42MEtw8b/k6ZkXdH2yk+PZUPDMNXGVk 6o4kNhV0g0xL8lIqCk+Oo823F0jTYcasf3vRe1OxsKPJuH+INOJMAkmYUvi/QOKz /pycJLPadN/PVuLD/yTkdfnPP9rcj73uQpjgwTfG8N7XVgmYrbYmT21PWU4cHprU AVexEBMaQtaz7k37rgfqjZyIfGFzrBAVBRmnDm/+KZid4SnHvIMQqC5UaZFImxfY ZcgSY5sqLjNJmiaTKpKBcE/vss7hyZvsmwvlxT652CNvdtYSehDO/F9LZBlIZojv 5RO7TalIRpTCERS5Ag0EVajOUQEQALy+1UBEbXWX5iE1YezJ1qHy2DtT+0JUHiEM bY2iGO/cV4qXOwC5+w6ASp2Udoy52iHznW6AcktoQF/bf8JCxXGGISJMI0tS+1b6 1NuKW+vkXDiSgYn5X5V+mjqS4fFmTMoqo5ig4jqIunmEuwLlJxkP30s8tUeGMRzc WSF5MvSKqQu0yXqg7N4MhEzMt4M4dV+I59HyoORJ805VBOFhr8jCtlg4ug0HrySl LqRp20hhKL8lBUA5opyQkMNSbA+I0S5gFq9sZz31lLVC7sYm6ckap6FBziAwcfnT fnFL4YFfTH4CIdkDFElCZ9318/cSnqbbhilRzvXh8aZfZl5wGntS6cIMJYbbKKGw dsPTkA5IR5yEVH1RbvD/m1d4cu5jqGfTeeRNMIngVirIa7W1Z49x/tTKykUM6/mh eqnzEqbbJsXLrnKN6Y+eu6mJLQgQhj/HNfk09j/wtgo1aRQgL/UVZDVTcuP0MuG9 tTeZ39nt6dFaI3+IsTa4QhnDcO1dJ+eYsuCJmVY3CtuZ5Sh3GcNGk6sX+eeEMkfZ 0jN9uwIWqhva5dqvetoO0VMfQyZiAauNxB0cjo2Cpl+xv+vQHEqPfFcYdY3QCay5 Alsn3ttd6Ht+S2IB/BukcO9N+EmYT1HgJkS1c4UR6x512b0NTGRC6yMFAGSshsx3 z9DInGvRABEBAAGJAh8EGAEIAAkFAlWozlECGwwACgkQy1c4ZSdo9+kphw//Sw7J i9eTyfJHdzRXNa1cA335dY1QYKq9/6eGhSjcyRGz4bHyHUDt5G5dmKwmaYrPGS3H r2H1+Z3w9BD5X/V1ZVgsKYYVM18N0CsnarJdcugdwC1difyMzo2NJGz6btuFey6Z iMZo6EQKgsH/0sLChHSLM5sjBgdmWswkWh7L8oNrFv/p091FVj6rFeda/e7g3xK2 NjPSk3+oX5aLgcCrUSeWJCZflyEL6NEf3EOAahzzoqUfN9D6aTjZWPSmTVTO21t8 s86XeSPuYBVGGODyIkCXWJxkm2WXY5AoPLYJWmmm9TwOJE0FgM/nTj04cBNW91q8 tCCaCx//2dGfW+EdAMew/G8aa2cJgbF7iJs5IWpMRUxujMM7rWJdxXjAh6Y3FiVc 5UtYO87HmthC953QiJntDTa/72Oi7HrGw/wUtSRm2S9G/jdpXZ7WBaPD0R4/QcXS 9590nMfFahWfQs6cdAOtLBJzCL6JMX4sHqaycwxErzd0jvtohCGJW0Ksc8GjTxWt mgBpCVzkTidkWgXICzd7EKE36z5Ir6jvN7NLe4qbPQF+uDWmxQqAK92/Iwt/NBAL Q2oWAiHN5j8v2/ObJDuZH5Q4DGzzVmXYAeKjVMyH9Upsutnu8iYrvghKyC1RKKPP jqzJvcZkDO24NIw8RM1VxPH/3UxXFg+hWD+7KMw=3D =3DxgZB -----END PGP PUBLIC KEY BLOCK----- --------------5D6814548B7AE700D3397ED2-- --oh1GlB1EoR6biUPkE1Gf3altUDjSjWQor-- --1NiXBodFuOXQpL4EreaoO47UgcmDt8MDp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEMXM+DFmNOhz3CVXWy1c4ZSdo9+kFAloJJbEACgkQy1c4ZSdo 9+mZJw/+KTqVtSE4+6Yxtrf6iGdnACzsl099Ezce92T/+qpyTw7Crq3hukLp4ZGz UzqrIIN5AsNEQQaOEgwZU0XmoCh2wOe/XYwawGpaSMjh1aiOkdfuakynaubOlPug 48+jcBiiW71qY8/xNmQr9ZcwZVdQ1spA1FJ745LYzpOCkxKV1zsxZWpsKkiSPhao 0r9v7jwxoJDXA8Fq+oBeszDrivNB2MhxOdNrwqKQ9wd7CLeJMKsD9UJXUQP+I2rz hgA6uYZtbOU9l3r5KXnf140CvQX+s32n+OMoxWd8bvQtYnog1Ql0+l/lM1gS/Bi9 GZjmKVop38kRwclX6dm/3hoxdgzbUaHwKIZ543U70oE81uQKYviSfbLPjv9MiLeC 56//mjZqpey8NEXcOEzxaHF19/H5LGPrqfOOH9vnOiQvxUqyDsBC273Sfqa9q66l Iqn9LhPd0Y7pInzrS2HEulZ+q576xuZcSzAXhJVnenRnrAJtRlYJwdWTQOxZuepp COafNyOBp5wiPeFbqdZLL/aRMjVyphQmxYROdtS1w0etUq/y1m6Cd3PqYYpqxV3K GuES+Y1I9PVbMgcDtvwGo+Pt8Is+K4ebuAF9wNzEhaynDCTzbnuZxiEsv4/eanzb UKYKP+hIZMiLxt3+0JoAZ/y7M9Bm8r8WyTLG+izNol0R1IrTpAM= =ZTUf -----END PGP SIGNATURE----- --1NiXBodFuOXQpL4EreaoO47UgcmDt8MDp-- From nobody Mon Nov 13 08:14:13 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4AA6127843; Mon, 13 Nov 2017 08:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.111 X-Spam-Level: *** X-Spam-Status: No, score=3.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vAM9QE3wXBj; Mon, 13 Nov 2017 08:14:09 -0800 (PST) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id C34DF120454; Mon, 13 Nov 2017 08:14:05 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 9DAEA3741029; Mon, 13 Nov 2017 16:14:05 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GhK6gTkdwD0h; Mon, 13 Nov 2017 11:14:04 -0500 (EST) Received: from dhcp-98fb.meeting.ietf.org (dhcp-98fb.meeting.ietf.org [31.133.152.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 0E57E3740F6A; Mon, 13 Nov 2017 11:14:01 -0500 (EST) To: saag@ietf.org References: <150809609468.12209.18375712195993239092.idtracker@ietfa.amsl.com> <0192EB1D-B216-402E-8685-4D3A312C4EF9@gmail.com> From: "Dr. Pala" Cc: draft-nir-saag-star@ietf.org Organization: OpenCA Labs Message-ID: <469ff957-0623-d292-2fe4-8b4e335c3cae@openca.org> Date: Tue, 14 Nov 2017 00:13:59 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <0192EB1D-B216-402E-8685-4D3A312C4EF9@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030902040501020000010509" Archived-At: Subject: Re: [saag] Using short term certificates (instead of revocation) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Nov 2017 16:14:12 -0000 This is a cryptographically signed message in MIME format. --------------ms030902040501020000010509 Content-Type: multipart/alternative; boundary="------------1FF3AD3A3A8D90F26FDDC9E4" Content-Language: en-US This is a multi-part message in MIME format. --------------1FF3AD3A3A8D90F26FDDC9E4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Yoav, all, I quickly read the submitted draft, and I have few comments on that. In=20 general, I am quite scared by the current trend to use short-lived=20 certificates everywhere to avoid status checking and I would have liked=20 the document to provide a more skeptical (or at least less biased)=20 approach to it as it does break the trust model in PKIs and has serious=20 trust consequences (especially when things go wrong...). Here's my 2 cents... *General Considerations* First of all, it seems that the considerations are oriented to the use=20 of certificates for network communications - I would suggest to add=20 considerations about the use of short lived certificates for=20 authentication and encryption (eg., signing and encrypting) of data that = might out-live the certificate itself. What are the implications there?=20 If this is out-of-scope for the document, I would explicitly say so. Second, when describing the advantages for validating short-lived EE=20 certificates, there are no considerations about the fact that the EE=20 cert is only the leaf in a chain that needs to be validated up to a=20 trust anchor. Therefore, the support for revocation MUST still be=20 implemented to verify that CAs have not been compromised. A point that=20 people usually (or conveniently) omit when talking about short-lived=20 certs. IMHO, this along defeats most (if not all) the arguments related=20 to not supporting revocation (at least outside closed/ad-hoc enviroments)= =2E I also think that the I-D lacks considerations related to the fact that=20 issuing a certificate has economic costs (related to operations) that=20 the CA has cover - therefore the use of short-lived certificates might=20 actually increase the per-certificate cost when compared to long-lived=20 certificates over a comparable period of time. Operationally it requires = more bandwidth, more signing power, etc. For small CAs (few millions=20 certificates a year) this might not be a problem, however for larger CAs = going from few hundreds millions to billions certificates issued might=20 very well be. Another very important point that I think it should be made is that by=20 not having a revocation system in place, the CA (and any relying party)=20 have no way to know if a key is to be trusted or not (since it is=20 trusted by default). And just "stopping" the automatic renewal seems a=20 solution only in the case that the same key was used in all the renewed=20 certificates... If a new certificate will still use the same key, the CA = would have no record (well, it should have the record anyway) in its=20 system that would prevent issuing a certificate for an already=20 compromised key. The concept of revocation actually can be quite useful=20 for key management purposes at the CA level. Another point (related to the previous one) that I think is important to = make is that short-lived certificates SHOULD NOT allow for the same key=20 to be used. This is required because otherwise you artificially extend=20 the vulnerability period to the sum of the "short" validity periods of=20 all certificates issued for the same keypair. I think that this is very=20 dangerous and should always be avoided otherwise you end up with a=20 long-lived key that can not be revoked. The same reason can be given=20 also for long-lived certificates, however for long-lived certs the=20 practice of re-keying is usually the norm and keys/certificates can be=20 revoked. *More Specific Comments* It also seems to me that there are some wrong considerations about the=20 validity period of CRLs and OCSP responses. For the former, the=20 "nextUpdate" field indicates that the relying party should expect a new=20 CRL to be published BEFORE that date but it definitely does not say that = the information inside the CRL is valid until then (i.e., there have not = been revocations or new CRLs issued before that time). It is, in fact,=20 typical for CAs to provide a nextUpdate field that is few days after the = lastUpdate one, but issuing CRLs every few hours and at each revocation=20 event. For OCSP responses, instead, the situation is different. The=20 validity period represents the time for which that information is to be=20 considered valid. This is why, OCSP responses usually have quite short=20 validity periods (minutes, few hours, and sometimes days) when compared=20 to CRLs. I think this is an important distinction that the authors=20 should consider and that maybe would change some of the considerations=20 provided in the document. In Section 2.1, "In fact, a CA for STAR does not need to keep any record = of issued certificates" is definitely a wrong statement. CAs operations=20 need usually to follow rigorous procedures to issue certificates and=20 they MUST keep extensive records of the process to provide auditing=20 trails for regular auditing that they undertake and to make sure that=20 non-authorized issuing of certificates happens. I would suggest to=20 remove this statement as it is definitely misleading. In section 4, "The motivations for using short-term certificates are=20 operational" is, IMHO, not really the full story. I would say that=20 despite all the efforts from CSPs to provide solid and largely available = infrastructures, the main issue related to revocation is that=20 application developers (a) do not understand the technology and (b) they = do not want to do the right work to begin with (despite the extensive=20 support that today exists in crypto libraries like MS-CAPI or OpenSSL).=20 From the two subsequent arguments, the first one seems taken from "The=20 Book of Browsers" where displaying the cool website few milliseconds=20 faster is a good reason for not checking the revocation information (not = considering that techniques like pre-fetching could be implemented today = and that would solve that particular issue). This is definitely NOT a=20 major issue in=C2=A0 environments other than the Web - I would suggest th= e=20 authors to provide (a) evidence (data) that that is a problem, and (b)=20 to provide the context in which those statements have been made. For the = second argument (availability of the DP), I would argue that today CAs=20 already provide (with high-availability) revocation information for=20 certificates by leveraging large (and costly) CDNs deployments. If the=20 COSTS is the real issue here, that could be addressed by, without=20 dropping revocation support, leveraging some existing distributed system = (e.g., DNS) as an alternative transport and caching mechanism (OCSP over = DNS) [which also simplifies the query mechanism]. Section 4.1 tries to provide considerations about the balance between=20 when a certificate should be requested and the validity period of EE=20 certs. I really do not see why this would be any different than the=20 long-lived certificates case (renewal of certificates usually happens=20 way before the expiration date to avoid business-continuity issues). I=20 would like to see an explanation as to why this is specific for=20 short-lived certs and if it is not, I think this section should be remove= d. Section 4.2 seems to contain considerations that (although definitely=20 true) are not specific to short-lived certificates. Most ICAs provide=20 infrastructures that are highly available. I would remove this section=20 as it seems not specific to short-lived certificates or explain why=20 these considerations are different for short-lived than long-lived=20 certificates (given the status of today's ICAs). For Section 4.5, it is commonly understood that CAs that issue=20 short-lived certificates DO NOT publish those certificates in CT. This=20 is a known problem that has no solution today AFAIK. *Final Considerations *I do think that this document is a good idea and has some initial good=20 points, however it seems to me that it does not provide a complete=20 picture and I would suggest the authors to seek the review of the=20 document by some experts with practical experience in designing,=20 deploying, and running large CAs/PKIs. It also seems (from the text -=20 but it might just be a personal impression) that the authors do have a=20 quite clear position about revocation and that, I think, does not help=20 in providing a fair and complete description of the issue. Looking forward to further discuss these issues and hear your point of=20 view on these topics :-D I hope this helps the discussion, Cheers, Max On 10/18/17 3:03 AM, Yoav Nir wrote: > Hi all > > We=E2=80=99ve submitted this -00 draft for your consideration. It is st= ill very rough with several sections missing, but we feel it=E2=80=99s go= od enough for starting a conversation. > > There is quite a bit of interest in using short term certificates recen= tly. There is a draft at ACME, a proposed draft at STIR, and many use cas= es in IT, whether these certificates are exchanged with TLS or with IKE o= r SSH. Some of these use cases are web, but many others are not. The pur= pose of this draft is to list considerations, both operational and securi= ty, for using short term certificates without revocation. > > If this effort is successful, the resulting document should guide both = draft writers and IT people in answering two important questions: > 1. When is using short term certificates appropriate? > 2. What needs to be in place for a functional, reliable and secure de= ployment? > > Any comments will be greatly appreciated. > > Thanks > > Yoav on behalf of the authors. > --=20 Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------1FF3AD3A3A8D90F26FDDC9E4 Content-Type: multipart/related; boundary="------------1F661A2F0F1A2DA3E25B91B0" --------------1F661A2F0F1A2DA3E25B91B0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Yoav, all,

I quickly read the submitted draft, and I have few comments on that. In general, I am quite scared by the current trend to use short-lived certificates everywhere to avoid status checking and I would have liked the document to provide a more skeptical (or at least less biased) approach to it as it does break the trust model in PKIs and has serious trust consequences (especially when things go wrong...).

Here's my 2 cents...

General Considerations

First of all, it seems that the considerations are oriented to the use of certificates for network communications - I would suggest to add considerations about the use of short lived certificates for authentication and encryption (eg., signing and encrypting) of data that might out-live the certificate itself. What are the implications there? If this is out-of-scope for the document, I would explicitly say so.

Second, when describing the advantages for validating short-lived EE certificates, there are no considerations about the fact that the EE cert is only the leaf in a chain that needs to be validated up to a trust anchor. Therefore, the support for revocation MUST still be implemented to verify that CAs have not been compromised. A point that people usually (or conveniently) omit when talking about short-lived certs. IMHO, this along defeats most (if not all) the arguments related to not supporting revocation (at least outside closed/ad-hoc enviroments).

I also think that the I-D lacks considerations related to the fact that issuing a certificate has economic costs (related to operations) that the CA has cover - therefore the use of short-lived certificates might actually increase the per-certificate cost when compared to long-lived certificates over a comparable period of time. Operationally it requires more bandwidth, more signing power, etc. For small CAs (few millions certificates a year) this might not be a problem, however for larger CAs going from few hundreds millions to billions certificates issued might very well be.

Another very important point that I think it should be made is that by not having a revocation system in place, the CA (and any relying party) have no way to know if a key is to be trusted or not (since it is trusted by default). And just "stopping" the automatic renewal seems a solution only in the case that the same key was used in all the renewed certificates... If a new certificate will still use the same key, the CA would have no record (well, it should have the record anyway) in its system that would prevent issuing a certificate for an already compromised key. The concept of revocation actually can be quite useful for key management purposes at the CA level.

Another point (related to the previous one) that I think is important to make is that short-lived certificates SHOULD NOT allow for the same key to be used. This is required because otherwise you artificially extend the vulnerability period to the sum of the "short" validity periods of all certificates issued for the same keypair. I think that this is very dangerous and should always be avoided otherwise you end up with a long-lived key that can not be revoked. The same reason can be given also for long-lived certificates, however for long-lived certs the practice of re-keying is usually the norm and keys/certificates can be revoked.

More Specific Comments

It also seems to me that there are some wrong considerations about the validity period of CRLs and OCSP responses. For the former, the "nextUpdate" field indicates that the relying party should expect a new CRL to be published BEFORE that date but it definitely does not say that the information inside the CRL is valid until then (i.e., there have not been revocations or new CRLs issued before that time). It is, in fact, typical for CAs to provide a nextUpdate field that is few days after the lastUpdate one, but issuing CRLs every few hours and at each revocation event. For OCSP responses, instead, the situation is different. The validity period represents the time for which that information is to be considered valid. This is why, OCSP responses usually have quite short validity periods (minutes, few hours, and sometimes days) when compared to CRLs. I think this is an important distinction that the authors should consider and that maybe would change some of the considerations provided in the document.

In Section 2.1, "In fact, a CA for STAR does not need to keep any record of issued certificates" is definitely a wrong statement. CAs operations need usually to follow rigorous procedures to issue certificates and they MUST keep extensive records of the process to provide auditing trails for regular auditing that they undertake and to make sure that non-authorized issuing of certificates happens. I would suggest to remove this statement as it is definitely misleading.

In section 4, "The motivations for using short-term certificates are operational" is, IMHO, not really the full story. I would say that despite all the efforts from CSPs to provide solid and largely available infrastructures, the main issue related to revocation is that application developers (a) do not understand the technology and (b) they do not want to do the right work to begin with (despite the extensive support that today exists in crypto libraries like MS-CAPI or OpenSSL). From the two subsequent arguments, the first one seems taken from "The Book of Browsers" where displaying the cool website few milliseconds faster is a good reason for not checking the revocation information (not considering that techniques like pre-fetching could be implemented today and that would solve that particular issue). This is definitely NOT a major issue in=C2=A0 environments other than the W= eb - I would suggest the authors to provide (a) evidence (data) that that is a problem, and (b) to provide the context in which those statements have been made. For the second argument (availability of the DP), I would argue that today CAs already provide (with high-availability) revocation information for certificates by leveraging large (and costly) CDNs deployments. If the COSTS is the real issue here, that could be addressed by, without dropping revocation support, leveraging some existing distributed system (e.g., DNS) as an alternative transport and caching mechanism (OCSP over DNS) [which also simplifies the query mechanism].

Section 4.1 tries to provide considerations about the balance between when a certificate should be requested and the validity period of EE certs. I really do not see why this would be any different than the long-lived certificates case (renewal of certificates usually happens way before the expiration date to avoid business-continuity issues). I would like to see an explanation as to why this is specific for short-lived certs and if it is not, I think this section should be removed.

Section 4.2 seems to contain considerations that (although definitely true) are not specific to short-lived certificates. Most ICAs provide infrastructures that are highly available. I would remove this section as it seems not specific to short-lived certificates or explain why these considerations are different for short-lived than long-lived certificates (given the status of today's ICAs).

For Section 4.5, it is commonly understood that CAs that issue short-lived certificates DO NOT publish those certificates in CT. This is a known problem that has no solution today AFAIK.

Final Considerations

I do think that this document is a good idea and has some initial good points, however it seems to me that it does not provide a complete picture and I would suggest the authors to seek the review of the document by some experts with practical experience in designing, deploying, and running large CAs/PKIs. It also seems (from the text - but it might just be a personal impression) that the authors do have a quite clear position about revocation and that, I think, does not help in providing a fair and complete description of the issue.

Looking forward to further discuss these issues and hear your point of view on these topics :-D

I hope this helps the discussion,

Cheers,
Max


On 10/18/17 3:03 AM, Yoav Nir wrote: 
Hi all

We=E2=80=99ve submitted this -00 draft for your consideration. It is stil=
l very rough with several sections missing, but we feel it=E2=80=99s good=
 enough for starting a conversation.

There is quite a bit of interest in using short term certificates recentl=
y. There is a draft at ACME, a proposed draft at STIR, and many use cases=
 in IT, whether these certificates are exchanged with TLS or with IKE or =
SSH. Some of these use cases are web, but many others are not.  The purpo=
se of this draft is to list considerations, both operational and security=
, for using short term certificates without revocation.

If this effort is successful, the resulting document should guide both dr=
aft writers and IT people in answering two important questions:
 1. When is using short term certificates appropriate?
 2. What needs to be in place for a functional, reliable and secure deplo=
yment?

Any comments will be greatly appreciated.

Thanks

Yoav on behalf of the authors.

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA
--------------1F661A2F0F1A2DA3E25B91B0 Content-Type: image/png; name="ibngapcongckelip.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="ibngapcongckelip.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------1F661A2F0F1A2DA3E25B91B0-- --------------1FF3AD3A3A8D90F26FDDC9E4-- --------------ms030902040501020000010509 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfUwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU+MIIEJqADAgECAhEA/bu0LJsAKXVhEpPllE0lYzANBgkq hkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBMB4XDTE2MTEzMDAwMDAwMFoXDTE3MTEzMDIzNTk1OVowJDEiMCAGCSqGSIb3DQEJ ARYTZGlyZWN0b3JAb3BlbmNhLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AKnGg/GUuTjn0dKCEpRhVd+uiYbCjLQht+dbkvyRLm4aqlL7yHCe+21HQLIcU68ZCHT2ImpF CFFrxQMQh4KijAwkbLc8+xZZSwXeZt58qnPn5c4vcpYU5LFq1q9oDT8MXH33DhVUT/7/IDSi wRWM6FcgM6VrIjBmmvl9dW3gQaEd1bOAhO2X489fChRQYTaB6AEhqb8RSvWW7ZYzfNw8sPxV afMCzWBPpO5RmLqOciZBhAinAM9dXmP5ckg/HjJQYSjvTc7HDcg75mpr5wH8Tk/ChyIYk4CT zqONQV8HKCzZPTVmd2ZuMrliJwMFs3uEg0aBSzHjJTyAmZ89q5Mz3XsCAwEAAaOCAfEwggHt MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTGgh9JWBvcrak1 PhAWBLGrECNAjzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHgYDVR0RBBcwFYETZGlyZWN0b3JAb3Bl bmNhLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEAdIqtPcvA+g6VTYUpEo0I9Vtnrf9PiZ3OpkRL O7U78EaeUfvOotThqj74XyrIl6eYlg+EdGIIUVB1CI05wPMRlZN3/R/Tj28vWkwckLRIbpL4 A5ZQyKgA9vK15/EEBVFIpCtAI6xJX0zx6TySlIgjcca05L0JgO7nzLGD2MY/dVWEE+QBuNI+ NBci+c+9q6YDPoXOpo0Wwbe0Bq95jNNWmZwhGzc+N5rhOGZmQT4P7TnpzvMik8ugbkqWyyHa DQbLKYzM1RKS/mwcvFqjJCQgORnaCilSbfClwdWGI7vwcTR8eAzduvwG61u46Cgb57K5sMck RicpWRvEYxCCVTwnozGCBEQwggRAAgEBMIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCWCGSAFlAwQC AQUAoIICYzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEx MTMxNjEzNTlaMC8GCSqGSIb3DQEJBDEiBCCjmPd/F4K+jYL1OmA24noVThNAM2DwjOaa31BB CgyyiDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHCBgkrBgEEAYI3EAQxgbQwgbEwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAP27tCybACl1YRKT5ZRNJWMwgcQGCyqGSIb3DQEJ EAILMYG0oIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCSqGSIb3DQEBAQUABIIBAE8ZOqm5bTygrgao wwb9/Kk48M/2WclGJJrZyDdwQTnxSEf7vpQGHo7nJH2Y87NkEVJTs0s4ExPlpI7TpON/Hw8I aOrSNsaZ5ZBi6wAPpIbdMf3IwLLeOPpOYz9754DRNVWrXP0sAyvOdsKXizW6S3rJP6Sn3RbO yqJP/1yvqgNKR9NXtFCtkDfs31hB4ZIZkjtyDNqFUdfUu1qxLKXNHk6l04qNjOM2tWPu2oEu LdjodI/LbSuwI8PsykCXehwaWbjLM4waqP/BaDCSk1J5dm2fuz/Zrd15qci3oB6KMM7MpFIR MRQU94BvfeCnKGAIzp90lZ/YXzXPUN/BX5eYD1EAAAAAAAA= --------------ms030902040501020000010509-- From nobody Mon Nov 13 21:05:39 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5701712932A for ; Mon, 13 Nov 2017 21:05:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFxRGyrXiUsE for ; Mon, 13 Nov 2017 21:05:36 -0800 (PST) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E923127876 for ; Mon, 13 Nov 2017 21:05:36 -0800 (PST) Received: by mail-pg0-x22b.google.com with SMTP id z184so9085663pgd.13 for ; Mon, 13 Nov 2017 21:05:36 -0800 (PST) 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=97VUPmiwLhWKW/jrMbCudqnzoEdMGn1653Vzn/EcK4g=; b=pzna8Rn/+IysePUMDMBE97vXLwW4lH6Hq1ZeO6ntGBDvCrw5g7PxkigjDu37FXrjMV KuSzA79RxWHLYlKyYSnlG9Eld9jDUJDW0GkSBbN1gtaJKkApMHDG4VmAfKypOiFx2fw7 vyTKy+BnoB38tgf8Lu6+G0a4xfE/+dEcgQZBu3ZzMEK+EknD5bbz20RG/a7P/ZGapCQ6 SD5CRVOFW/30SkpwM9psM9EfhRvReGLHC93exA1ZCM4huEicE7DD4DrV1O0PjU9r3MUF mAXBC43javls+rtNvjc685JkWo1UyA1MnTkcGTVWxiNpSumBhUOYGhl+GNQeTBLqGVRF mNqw== 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=97VUPmiwLhWKW/jrMbCudqnzoEdMGn1653Vzn/EcK4g=; b=sAV/qu0hMoX0kt0Zd8itH3KEnW+OUoLfYkGsztKqyTQt8QwqtHWpwjqocLTaS7KmE9 T5ANwI4DktYr0So5dJj4neKfCo+KB/X2t6wUcprSkFV2qbTKiJLgE/UiFUoaXdmDo9g3 vrEyGxR3A9bm31dE8DDzBHQcYwptrPP8Alcie49LEyDaR1EWNDz3U1Ek8jkrHI/X/yne ii9AbCkasaoPAosfcn8i5BsmFNpsxzbLA4toVfhIKjNGtwJqTtBQ7+LPzA9FjjWMPI8G Re74e2QRl+n8hs4agW4xyNGZnzj7PEIxpPd6HfRhWqsC5PhQK+Qg+mMShX4Rwl8mjN1l 8CGQ== X-Gm-Message-State: AJaThX7r3VGun4auCRwPcHlkT52mh5JW/bHVuxh3rVTPxL8fGMKhoAP5 6+ktzuat6fRswZ5N7wfNDDqHPT/3 X-Google-Smtp-Source: AGs4zMZuYrY3I20jMkziaHrjn/wIrSWTfyC4KIFPyNHpWMmkiuD/bQP8cDm38/xd83Snz4G5b894/Q== X-Received: by 10.84.164.231 with SMTP id l36mr11034972plg.179.1510635935661; Mon, 13 Nov 2017 21:05:35 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:31ec:bdd0:d3f4:f84c? ([2001:67c:370:128:31ec:bdd0:d3f4:f84c]) by smtp.gmail.com with ESMTPSA id s14sm19180104pfe.36.2017.11.13.21.05.34 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 21:05:35 -0800 (PST) From: Yoav Nir Content-Type: multipart/signed; boundary="Apple-Mail=_4BFB2305-D91B-4D46-B0F5-7322EE85C5D5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Message-Id: <27EAFBCF-738C-41A6-91BB-067C3028C0D2@gmail.com> Date: Tue, 14 Nov 2017 13:05:49 +0800 To: Security Area Advisory Group X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: [saag] Side Meeting about Short-Term Certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Nov 2017 05:05:38 -0000 --Apple-Mail=_4BFB2305-D91B-4D46-B0F5-7322EE85C5D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi In recent years there=E2=80=99s been growing interest in short-term = automatically-renewed (STAR) certificates. The idea is to renew = certificates often and forego revocation checking. ACME has a draft for such certificate, and STIR has a candidate among = others. STAR certificates have somewhat different operational and security = properties compared to regular PKI. I'm trying to put together a draft = that will document these differences. We=E2=80=99re going to have a side meeting on Thursday evening at 6 PM = in the Hullet room. (Very) rough draft: https://tools.ietf.org/html/draft-nir-saag-star-00 Slides for the side meeting: = https://www.dropbox.com/s/yi9cn35dk8h14te/starcons.pdf See you there. Yoav --Apple-Mail=_4BFB2305-D91B-4D46-B0F5-7322EE85C5D5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAloKea0ACgkQuEkLFQpY zJkpiAf/Q62Q+jWicMwjzAyODU7V8dzeA7gOzcyZy6aYkV9KrtPNo6a0wopFFsI5 kQgfkgjypN9rV1xMF2o1vktA/bRl6plDpdX+YVjbYoxQugSPEQbq4eXQ6j09UmAf nHsI2z5vZBoLiriGLsSaXG4kC+NvGtQh26l3rBPB04SUyQAuqxhEZXkjRsK7AHBl 7mJUbm6p1ZmtUfUIC+oVz2LWojKaJQXoLLE1dw/KCPwh1TdPY1Q1iWdhSWLcJxXe JzhtwpXbgKnLx+HkwnZuJ7hou5bolSa5/PcpSqE5f9Dy/oH+dQwZaNMm0ooQI15v CW7pnhYwqsyOw8EO2AMih0C6TKtgBQ== =U8xF -----END PGP SIGNATURE----- --Apple-Mail=_4BFB2305-D91B-4D46-B0F5-7322EE85C5D5-- From nobody Tue Nov 14 18:15:34 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD3BC1294A1 for ; Tue, 14 Nov 2017 18:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ele1y06263A1 for ; Tue, 14 Nov 2017 18:15:30 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0136.outbound.protection.outlook.com [23.103.200.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E89B412949E for ; Tue, 14 Nov 2017 18:15:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bdoCiR5mptsVpJVpM+tiBp9V5ZYoVgf/6UODLI1chvQ=; b=X9y21hMGzmglra4BVTYu5Mh3sRdBVgAw8Vvx1HPUOaKP7jZaRLQLq2lh6TXz56hvl4MCNkloTpRYm5phd3lkjEevMVJi1ZW2GcM8LAGj25R8p1ehJ+64IuTyCvFxS3Xm6s4gkL6XYKvwTyz7UnHVbidqZqgiOddc0LQOudhxMUE= Received: from DM2PR09MB0559.namprd09.prod.outlook.com (10.161.252.17) by DM2PR09MB0559.namprd09.prod.outlook.com (10.161.252.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Wed, 15 Nov 2017 02:15:28 +0000 Received: from DM2PR09MB0559.namprd09.prod.outlook.com ([fe80::6da1:a841:ddf4:3981]) by DM2PR09MB0559.namprd09.prod.outlook.com ([fe80::6da1:a841:ddf4:3981%17]) with mapi id 15.20.0218.015; Wed, 15 Nov 2017 02:15:28 +0000 From: "Polk, Tim (Fed)" To: "saag@ietf.org" Thread-Topic: draft agenda for SecDisptach Thread-Index: AQHTXbWf8X+D8xBTJ0CjuoH46Pz3NA== Date: Wed, 15 Nov 2017 02:15:28 +0000 Message-ID: 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=william.polk@nist.gov; x-originating-ip: [2001:67c:370:128:8c8b:a26e:c2a9:a71d] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR09MB0559; 6:Me1r8XvAUG+ZCC23X5SfmcOf1YlHR2exQM479V/vXTcw8yFYtjXBX3YhmKAVtkRYWiSWjlw0HpdjntKPpXri8/TD9G7XF45NkXrW1+FtsDdA8x4RehdxCF5R+qwDX3mErpuLAwrj+X14OuaGhMOMuJ7CefaRd+gfI8zBnAHfiBAtDxWUH4ZvOpdfdVRe6DDSns8CbsOhizlR0lKMZFiKHGNqeWoHwzxy+UX8vN+hEZFGjD6NkDhL04Y0PQgQX4+memIdd8zE1SU6oMtzQLhaD8VMlFe0RwqgtC7K+x2DHt5rpxImNKtjCgTvtnI+MAiwaJD+5Ws8KLi2yMbuuQafMpJFlrDIo+kH9QQiUFyh4VM=; 5:cJonPnHOVcHIqZS+3qI+5t7xdin16jAvoHe+Fv67sAORvrtIjYrUtmjuVXJkOowojCm/GcyuPHdJw0MsdrZubsAJXFl/wsAQCij/uutFauFstfyKJDOEbFTVkoMcp9f5mhoE5IwsQVF0hLIcHeOm527v5um0/OVrMy5E5KY2LCY=; 24:uPJGTwzDDF28eUKCTAigFenJ5DIPuYkHz7kGbZzYB+YAkyMfTD3bXk7kj2QiiVCuH+Qu+o0yfeTNhrT+91MNVmrDf3VGfWt/N67MOvuol1c=; 7:oajeCoqI5W1kL7OaHno6eI7PCj+di5Zf2uPKxd95kORzOEhBpnqKb7NlVzQegP7nTcGJTF1pd4AgMs+r6cD3UMTJ7+jKkTHyyHhcf4Q/RbilaCmTpg9VudxzyVyU8r0laKZeU+OXq9fZbfe8iu3LcobW8WbWPBnXBN/l8Koy+v1HnHNVAKNDCuOthjSCgFHyWC4Mdn823wtQcdYqA+1yNP2SSHYddNVfvRPWeRhwygwRmAkZUNf/mjU2M/iMYZMq x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e3722db0-79d2-4808-36b0-08d52bcebd5b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603199); SRVR:DM2PR09MB0559; x-ms-traffictypediagnostic: DM2PR09MB0559: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(3231022)(10201501046)(6055026)(6041248)(20161123558100)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR09MB0559; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR09MB0559; x-forefront-prvs: 0492FD61DD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(376002)(346002)(189002)(199003)(189998001)(1730700003)(81166006)(33656002)(81156014)(74316002)(50986999)(7696004)(101416001)(68736007)(55016002)(6916009)(6506006)(8936002)(5660300001)(7736002)(8676002)(305945005)(478600001)(54356999)(2900100001)(2351001)(3660700001)(25786009)(3280700002)(106356001)(3480700004)(105586002)(9686003)(2906002)(14454004)(86362001)(102836003)(39060400002)(6116002)(53936002)(5640700003)(2501003)(4326008)(316002)(5250100002)(6436002)(99286004)(54906003)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0559; H:DM2PR09MB0559.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: e3722db0-79d2-4808-36b0-08d52bcebd5b X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2017 02:15:28.1984 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0559 Archived-At: Subject: [saag] draft agenda for SecDisptach X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 02:15:31 -0000 Folks, Please take a few minutes and review the=A0current agenda for the SecDispat= ch experiment that will follow SAAG (see below).=A0 Please note: We are sti= ll waiting=A0for slides from some presenters, so the ordering of presentati= ons may change. Since the agenda is very crowded, so we will only have ten minutes to "disp= atch" each work item.=A0 Nancy and I strongly encourage you to review draft= s and slides from proposals of interest before the meeting. Thanks, Tim Polk ------------ draft SecDisptach Agenda -------------- SecDispatch Agenda IETF 100, Singapore November 16, 2017 about 14:15 (following SAAG) =A0 1. Administrivia (5 minutes) 2. Agenda Bash and Process Discussion (10 minutes) 3. Security Dispatch Proposals (10 minutes each) a. OSCCA Extensions For OpenPGP, Ron Tse (remote) draft-openpgp-oscca-02 b. TLS Server Identity Pinning with Tickets, Daniel Migault draft-sheffer-tls-pinning-ticket-05 c. Randomness Improvements for Security Protocols, Nick Sullivan draft-sullivan-randomness-improvements-00=20 d. OCSP over DNS, Max Pala draft-pala-odin-03=A0=A0=20 =A0=A0=A0=A0=A0=20 e. EAP usage in 5G, Jari Arkko draft-arkko-eap-rfc5448bis-00 draft-arkko-eap-aka-pfs-00 =A0 If Time Allows f. On Implementing Time, Aanchal Malhotra draft-aanchal-time-implementation-guidance-00=A0 =A0=A0=20 =A0=A0=A0=A0g. A Method for Web Security Policies, Markus Mannevaara draft-foudil-securitytxt-00=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=20 =20 = From nobody Tue Nov 14 18:41:45 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA5BC120724 for ; Tue, 14 Nov 2017 18:41:44 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWBPTSCC2waC for ; Tue, 14 Nov 2017 18:41:43 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 573C01201F2 for ; Tue, 14 Nov 2017 18:41:43 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAF2ff4G009892; Wed, 15 Nov 2017 02:41:41 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=JKE0HWXgnohJvFt+WTeP0I/vwAlPNn+vNh/BKGfoJqE=; b=X4UclFmxcW5T4ZTuEN8SXEHbzZ7tqr8fMziQnYrlcdwZZG71wXGN1HWUWoKWdqBRhGno KDmqOKwpzT9bTpvON2Wk3m4xFIbWbQ78XboU/eJxdAFUn0Rju0xl4xpPmXlihKNzGriU sVU+SXh3/olFxqyR6Kstoi/RQoEluzsSDlT2sdpODVqia7xLvnBRhxFN04MMbNaClWLq 9w7LgnzGAZ/kfgdL7Z9ANaQDYo6MqU24zp0P7ljadHNAuxeQf9HGIZTaxqnK3HxKa00V dqzdKgxAYKsioGVZFTyfgX4d8q1Ags9zdSYeoYwEH7PYoCPr1TX00QRE0/hB6EQc/Ga8 OA== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050096.ppops.net-00190b01. with ESMTP id 2e7p3ykhph-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Nov 2017 02:41:41 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vAF2cRTU005444; Tue, 14 Nov 2017 21:41:36 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint3.akamai.com with ESMTP id 2e7p3yv0uv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 14 Nov 2017 21:41:36 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 14 Nov 2017 21:41:35 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 14 Nov 2017 21:41:35 -0500 From: "Salz, Rich" To: "Polk, Tim (Fed)" , "saag@ietf.org" Thread-Topic: [saag] draft agenda for SecDisptach Thread-Index: AQHTXbtAVccoeQgJi0e7paRT2ig/2A== Date: Wed, 15 Nov 2017 02:41:34 +0000 Message-ID: <0AB60319-DC0D-4527-8C18-D05BA9BA1BB5@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.147.119] Content-Type: text/plain; charset="utf-8" Content-ID: <2671CEB2D5333A4290E43C36C7DD2E24@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-14_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711150035 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-14_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711150036 Archived-At: Subject: Re: [saag] draft agenda for SecDisptach X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 02:41:45 -0000 PklmIFRpbWUgQWxsb3dzDQo+ICAgICAgICAgIGYuIE9uIEltcGxlbWVudGluZyBUaW1lLCBBYW5j aGFsIE1hbGhvdHJhDQo+ICAgICAgICAgICAgIGRyYWZ0LWFhbmNoYWwtdGltZS1pbXBsZW1lbnRh dGlvbi1ndWlkYW5jZS0wMCANCg0KVGhlIHRpbWUgV0cgaXMgZ29pbmcgdG8gdGFrZSB0aGlzIHVw IHNvIEkgZG9u4oCZdCB0aGluayB3ZSBuZWVkIHRvIGxvb2sgYXQgaXQuDQoNCg== From nobody Tue Nov 14 18:54:08 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F0E127863 for ; Tue, 14 Nov 2017 18:54:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6VU3nmyR4tqs for ; Tue, 14 Nov 2017 18:54:05 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0117.outbound.protection.outlook.com [23.103.201.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29B9012943B for ; Tue, 14 Nov 2017 18:54:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/kRKKn41sBw9VxxI/OVbLYuyck1x8tRoCKwnyxmbpHY=; b=Em3KM9misdoUUTPBW+1O5TTK2WG3rJLQLCZET+wLQ1ICCeOv//b2Vcn5J/JVmhcdA2rtOiz9Ut7E8TEeCKk5JKsNgsNyVewqGdf+0MTAZMKrj3iMpgQ/7ony27kIf461gnGoIAtE8tRX/ETHaffWQTWUBEeiEFxBjrSWgvHrkSU= Received: from DM2PR09MB0559.namprd09.prod.outlook.com (10.161.252.17) by DM2PR09MB0557.namprd09.prod.outlook.com (10.161.252.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Wed, 15 Nov 2017 02:54:03 +0000 Received: from DM2PR09MB0559.namprd09.prod.outlook.com ([fe80::6da1:a841:ddf4:3981]) by DM2PR09MB0559.namprd09.prod.outlook.com ([fe80::6da1:a841:ddf4:3981%17]) with mapi id 15.20.0218.015; Wed, 15 Nov 2017 02:54:03 +0000 From: "Polk, Tim (Fed)" To: "rsalz@akamai.com" , "saag@ietf.org" Thread-Topic: [saag] draft agenda for SecDisptach Thread-Index: AQHTXbtAVccoeQgJi0e7paRT2ig/2KMUvcDM Date: Wed, 15 Nov 2017 02:54:03 +0000 Message-ID: References: <0AB60319-DC0D-4527-8C18-D05BA9BA1BB5@akamai.com> In-Reply-To: <0AB60319-DC0D-4527-8C18-D05BA9BA1BB5@akamai.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=william.polk@nist.gov; x-originating-ip: [2001:67c:370:128:8c8b:a26e:c2a9:a71d] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR09MB0557; 6:LrjKUmAUS6ln0uB+YAxb1Z0z+lsvpMV+46LkvxwxS7Ik8WRfiUNysw7fUEQVStsfu/7WP/mJv6ZPYRciiqvIyK4G1itMF3PQ4IUXjZbp/rggFE5vbiwssqhCCu6M2FogZ77HSWJTeEMO07ZuBU6Kn0DCcpYfz4fVRzmINuXU1qJ2XrXeN9rhCj/Ii+bEXscOBvenZPn6/hZaMFlkHcliK8oJ6seD1evQqpefMme1xd41k/Z+3iz7j3HnSqHQNEaF3dfslVVVw2H8f+DQ4ijWfoLGMigJpU54WFUTYg1lcAsfYVcAF+hgA+fKzYWQ5GwA/LAnuI1542Em/sH2Uy5kL9vL3aX1ZZiN/B8sbRRkfOE=; 5:ax+7M215zKAWRQXaDBZhQaW31HsK/DKlUHOoUBAI4UfvgVXN2K/IqG+lNEJqJJ/ycbyP+I1P/vlJTWsOdOlVnMRwW7sderlKW2cyAYJSm73LIKRzwowoP72rNNz0klSUz8OagnPC4QWT2N7pG3JiQFMjKDaGiER0XqgsxPkhOTs=; 24:gSSIJbd62m1yegYDXJ8DKrFCxyDeVHdbSiezhqZQ5nsOcvXHwYS+VFsHJsOM4j8P0uphPrbGAF7xDfgF8Or8dkGP24WHV67T7/HOdy9/tVg=; 7:KGe2MN0gHq9GIuH2UrADi7us2s8eHIL5vCY5HFIE7F3Z7+F1d1s0cbC84gMDHmdOqkvRQH/PoGebQYhz+mk6JbwXD8kxw8XzcbD+M0gnWrEOsnMdihg5LPBTOtJrhLrDiVvlCgoLEVKBg3e5DYCbDytLhBkscyclMBAWwmDS3fWNzu3eyocwjHdtaMIZJuOa9wDOB6gkwlr/hkcvsscbErZEV6OZ/lydaIS6J/WXoNl9B61k2NN2B5P8zlpgQZT5 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2fb5c745-303e-4e8d-9f54-08d52bd42150 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603199); SRVR:DM2PR09MB0557; x-ms-traffictypediagnostic: DM2PR09MB0557: x-ld-processed: 2ab5d82f-d8fa-4797-a93e-054655c61dec,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(3231022)(6055026)(6041248)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR09MB0557; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR09MB0557; x-forefront-prvs: 0492FD61DD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(39860400002)(346002)(51914003)(189002)(199003)(106356001)(53936002)(105586002)(229853002)(2900100001)(25786009)(2950100002)(9686003)(3660700001)(6246003)(54896002)(55016002)(86362001)(101416001)(478600001)(14454004)(53546010)(99286004)(33656002)(74316002)(68736007)(7696004)(6436002)(6606003)(19627405001)(6506006)(7736002)(54356999)(316002)(81166006)(81156014)(6116002)(5660300001)(110136005)(97736004)(76176999)(8936002)(102836003)(2501003)(3280700002)(2906002)(50986999)(5250100002)(189998001)(8676002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0557; H:DM2PR09MB0559.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR09MB0559E4BB1373274342C5DAB5E7290DM2PR09MB0559namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 2fb5c745-303e-4e8d-9f54-08d52bd42150 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2017 02:54:03.3379 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0557 Archived-At: Subject: Re: [saag] draft agenda for SecDisptach X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 02:54:07 -0000 --_000_DM2PR09MB0559E4BB1373274342C5DAB5E7290DM2PR09MB0559namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Rich, Thanks for the heads up. If the time WG has already accepted this work, the= re is no decision to be made, so it will not contribute to the experiment. Tim ________________________________ From: Salz, Rich Sent: Tuesday, November 14, 2017 9:41:34 PM To: Polk, Tim (Fed); saag@ietf.org Subject: Re: [saag] draft agenda for SecDisptach >If Time Allows > f. On Implementing Time, Aanchal Malhotra > draft-aanchal-time-implementation-guidance-00 The time WG is going to take this up so I don=92t think we need to look at = it. --_000_DM2PR09MB0559E4BB1373274342C5DAB5E7290DM2PR09MB0559namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Rich,


Thanks for the heads up. If the time WG has already accepted this work, = there is no decision to be made, so it will not contribute to the expe= riment.  


Tim

From: Salz, Rich <rsalz@= akamai.com>
Sent: Tuesday, November 14, 2017 9:41:34 PM
To: Polk, Tim (Fed); saag@ietf.org
Subject: Re: [saag] draft agenda for SecDisptach
 
>If Time Allows
>          f. On Implementi= ng Time, Aanchal Malhotra
>            = ; draft-aanchal-time-implementation-guidance-00

The time WG is going to take this up so I don=92t think we need to look at = it.

--_000_DM2PR09MB0559E4BB1373274342C5DAB5E7290DM2PR09MB0559namp_-- From nobody Tue Nov 14 18:56:29 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 342DA127137 for ; Tue, 14 Nov 2017 18:56:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id feASMdeWXKz3 for ; Tue, 14 Nov 2017 18:56:25 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFAC1127863 for ; Tue, 14 Nov 2017 18:56:25 -0800 (PST) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAF2qi0i017839; Wed, 15 Nov 2017 02:56:22 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=HQGqxF7F4HUbF7MJwnh3hghsDInjMWy4TjsaXimLaow=; b=AjA+dEEVKiNGo0ioHvcNU+9IuXg1Bygi/iaAXAuBZUSNJosrksGkF5Djx0zOYlcKuPXM LMnlLLUVHqzqyCdzrSbBwgHAtN/aqg9phupZqNt6Yxq6DjoILbqaLWpuYvpkCx0eic+U IEbRrrx1xx9ND1ZB2picyKVDwSVOil73NMANt0qZkufmwZWl80+eOTPztPD8Hzy865sm ftYP5XxDjiSE9xXMDJqFo66xeOn3hVMFz2KA6lfVHEaf3wX5KL5wpGE23XEasgMZu99j JwGeyqJC5SKyV7C9co/bncQ6L3sjikqXAv71nFJkU5VOeYtFGVwIHoOMy+zX0EBa6zyi Gg== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050102.ppops.net-00190b01. with ESMTP id 2e8d5600ax-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Nov 2017 02:56:22 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vAF2piAR006324; Tue, 14 Nov 2017 21:56:21 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2e7p3wkrb2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 14 Nov 2017 21:56:21 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 14 Nov 2017 21:56:21 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 14 Nov 2017 21:56:20 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Tue, 14 Nov 2017 21:56:21 -0500 From: "Salz, Rich" To: "Polk, Tim (Fed)" , "saag@ietf.org" Thread-Topic: [saag] draft agenda for SecDisptach Thread-Index: AQHTXbtAVccoeQgJi0e7paRT2ig/2KMUvcDMgABVOwA= Date: Wed, 15 Nov 2017 02:56:20 +0000 Message-ID: References: <0AB60319-DC0D-4527-8C18-D05BA9BA1BB5@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.147.119] Content-Type: multipart/alternative; boundary="_000_DDF595AA537441C884649400ECDAD26Bakamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-14_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711150037 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-14_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711150038 Archived-At: Subject: Re: [saag] draft agenda for SecDisptach X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 02:56:27 -0000 --_000_DDF595AA537441C884649400ECDAD26Bakamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgaGFzbuKAmXQgYmVlbiBhY2NlcHRlZCwgYnV0IHdl4oCZcmUgdGFsa2luZyBhYm91dCBCQ1Ag b3IgSW5mbyBzbyBJ4oCZZCBzYXkgaXTigJlzIGltbWluZW50LiAgQW5kIHllcywgSSBkb27igJl0 IHJlY2FsbCBpZiBpdCB3YXMgbnRwIG9yIHRpY3RvYzsgd2hvIGNhcmVzPyAgKFRoZXkgc2hhcmUg YSBtYWlsaW5nIGxpc3QgYW5kIFdHIGNoYWlyIGFuZCBzY2hlZHVsaW5nIHNsb3TigKYuKQ0KDQo= --_000_DDF595AA537441C884649400ECDAD26Bakamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbWFyZ2luOjBpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29s b3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDEx LjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdj b2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgaGFz buKAmXQgYmVlbiBhY2NlcHRlZCwgYnV0IHdl4oCZcmUgdGFsa2luZyBhYm91dCBCQ1Agb3IgSW5m byBzbyBJ4oCZZCBzYXkgaXTigJlzIGltbWluZW50LiZuYnNwOyBBbmQgeWVzLCBJIGRvbuKAmXQg cmVjYWxsIGlmIGl0IHdhcyBudHAgb3IgdGljdG9jOyB3aG8gY2FyZXM/Jm5ic3A7IChUaGV5IHNo YXJlIGEgbWFpbGluZyBsaXN0IGFuZCBXRyBjaGFpciBhbmQgc2NoZWR1bGluZyBzbG904oCmLik8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DDF595AA537441C884649400ECDAD26Bakamaicom_-- From nobody Wed Nov 15 06:12:36 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88D57129484 for ; Wed, 15 Nov 2017 06:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FeY5P82EBMg for ; Wed, 15 Nov 2017 06:12:34 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57F28127775 for ; Wed, 15 Nov 2017 06:12:34 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id f187so1888534itb.1 for ; Wed, 15 Nov 2017 06:12:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=8CRA5dSaixEuBtlyvUuWCyWsSsGd1wVRN1ro/9Nr9MI=; b=kohpeqt6oztlNM+YZyElj7pBjGV+Y5kSyds4jGGL1N+kY5pylV6lZoreABSwqrj6ci J8uf6VzXGWFxtw0oX6egq3K7OncOPIyr3F4kMbSKTPNukpUjuZMYKBpc/tsxyH6rPVLL T1PWE2Am7elD6C2W0iMlFigXPFtjPdBmHSeT/0mHUQgiGloI6rDYP24RVcfubvkxlouq BBnoYdDzR52wn15TguOoiSTQXf60aK+NSET8XOWhhnzUUraeWHH7rfKE0i2cE65ksIWG hBD70378p+BtGEw4rsWnA6EP2o3MFbx56QGSbAKSZxQoLffaFwIjD0OsXBR3Z6l4VPfL tDpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=8CRA5dSaixEuBtlyvUuWCyWsSsGd1wVRN1ro/9Nr9MI=; b=dGZParkrP0nn/557MACMiEu7r7yVPmXgXKfXWCj6xoR8TFgpHJeew3BqNdibm9JqCv NIpc6XqaerbBpHO98ODWDNn7ZVh3VYABNiX19KOCsPPUm4Z0oXXWWJ+ZXQh2KaL3b+C3 1nGKO/zaTPAtCY0LrsM7hYor7r54tTnLup7POmm6KHVKNoTTxEpS5oY0CYy8/WnQj9ag +Otb7U+3983C0kPbX7oLEhuDN5sS0ICf+ovqLIoce93ildLlXbvtQD1OQD9R7exqzjH+ hza7ySxbbGR9hW7zo8g9ALakRxxqE0AaadG5Cz3y5IzAN4P3dCSlsXs9SEBuij8htCaT VzJA== X-Gm-Message-State: AJaThX61kRZLy6V57l/zga6wVhhsEC0PePwY7Syn951U2ChjlGb7lyiC G6nqG+3rkVu9ufM5n2rmtoVyW0S1I1/fcqIHCbfuiA== X-Google-Smtp-Source: AGs4zMY6h0n9L2nq/MX6/VJfD8VW5lah4K6/EvW7d2HkpWBItJ7jlrAGb/hW2QCP0Z7QGqTPNqHpzh0xq0uHK7YLoG0= X-Received: by 10.36.118.195 with SMTP id z186mr17342083itb.106.1510755153473; Wed, 15 Nov 2017 06:12:33 -0800 (PST) MIME-Version: 1.0 From: Adam Montville Date: Wed, 15 Nov 2017 14:12:23 +0000 Message-ID: To: saag Content-Type: multipart/alternative; boundary="001a11405cac43f6ac055e0618ab" Archived-At: Subject: [saag] SACM IETF 100 Report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2017 14:12:35 -0000 --001a11405cac43f6ac055e0618ab Content-Type: text/plain; charset="UTF-8" SACM met on Wednesday morning and discussed the working group's current status, a change in chairs, and a pending re-charter effort, among other topics. The group's immediate concern is ensuring we have sufficient and appropriate milestones supporting possible work items in our proposed re-charter. Kind regards, Adam, Karen, & Chris --001a11405cac43f6ac055e0618ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
SACM met on Wednesday morni= ng and discussed the working group's current status, a change in chairs= , and a pending re-charter effort, among other topics. The group's imme= diate concern is ensuring we have sufficient and appropriate milestones sup= porting possible work items in our proposed re-charter.

Kind regards,

Adam, Karen, & Chris
--001a11405cac43f6ac055e0618ab-- From nobody Wed Nov 15 18:08:18 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 177DD126CC4 for ; Wed, 15 Nov 2017 18:08:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lvNGmjoL6_8T for ; Wed, 15 Nov 2017 18:08:15 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [212.16.101.130]) (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 A0E39120227 for ; Wed, 15 Nov 2017 18:08:14 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.15.2) with ESMTPS id vAG289lh000187 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 16 Nov 2017 04:08:09 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id vAG289P9021995; Thu, 16 Nov 2017 04:08:09 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23052.62217.369134.821424@fireball.acr.fi> Date: Thu, 16 Nov 2017 04:08:09 +0200 From: Tero Kivinen To: saag@ietf.org X-Mailer: VM 8.2.0b under 25.1.1 (x86_64--netbsd) X-Edit-Time: 8 min X-Total-Time: 8 min Archived-At: Subject: [saag] IPsecME IETF 100 Report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 02:08:17 -0000 IPsecME met Monday morning for 1.5 hours. Since last IETF we have published 3 RFCs: RFC8221 (MTI algorithms for ESP/AH), RFC8247 (MTI algorithms for IKEv2) and RFC8229 (TCP Encapsulation of IKE and IPsec Packets). We have 4 work items, EdDSA is in the IETF LC; and Split DNS and Implicit IV are past WGLC or in WGLC. The Quantum resistance draft is progressing nicely. Majority of the session we discussed about new charter items. Our charter is valid until end of this year, so we need to re-charter before that. Items most likely to be added to the charter include: - Group DOI for IKEv2 - Postquantum cryptography for IKEv2 - Diet-ESP/IKE - Signature algorithm negotiation In addition to those we discussed - Reposnder MOBIKE - Address failure error codes - Labelled IPsec - Mitigating privacy concerns Work in progress charter is in the IPsecME Wiki [1], so if you want to know more about those work items check specific description there. [1] https://trac.ietf.org/trac/ipsecme/wiki/recharter2017 -- kivinen@iki.fi From nobody Wed Nov 15 18:12:31 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4054912940B for ; Wed, 15 Nov 2017 18:12:30 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UK-P9Pr1NqVJ for ; Wed, 15 Nov 2017 18:12:28 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 F30E0129405 for ; Wed, 15 Nov 2017 18:12:27 -0800 (PST) Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id vAG2CQFG030113 for ; Wed, 15 Nov 2017 21:12:26 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu vAG2CQFG030113 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1510798346; bh=CsYmKEtzApiwJUGlFAObuVyF0pf7CLlRTTBfok/9Gp0=; h=From:To:Subject:Date:From; b=mtCLIO5exyDwzK6+7X9FzIOJZARlnNv0+AkTYX2yBi9vxYHcfMB8pTHXsfw9Xo4RJ 6z0XFXuCJU4rK9pISV1bsAqgIr0QHIUGQgAyrsXD+3oYb1JRSashlD7ML8pqlmrfg8 9qNYP65mPxeaxAH/7KqAWny72/bctn4FCs9evkq8= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id vAG2CNcG014145 for ; Wed, 15 Nov 2017 21:12:23 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0361.001; Wed, 15 Nov 2017 21:12:23 -0500 From: Roman Danyliw To: "saag@ietf.org" Thread-Topic: DOTS IETF 100 Report Thread-Index: AdNegBL4uyKZilcFRvS0uBh0SAKZJQ== Date: Thu, 16 Nov 2017 02:12:22 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC010500739C@marathon> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [saag] DOTS IETF 100 Report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 02:12:30 -0000 DOTS met during the Afternoon I session on Tuesday [1]. The two protocol d= rafts [2] [3] have been advancing based on implementation feedback. Early = discussion has begun related server discovery work [4]. During the hackath= on earlier in the week, three implementations were improved; and interopera= bility testing was conducted between two implementations. The supporting use case [5], architecture [6], and requirements [7] drafts = are approaching WGLC. Regards, Roman and Tobias [1] https://datatracker.ietf.org/meeting/100/session/dots [2] draft-ietf-dots-signal-channel [3] draft-ietf-dots-data-channel [4] draft-boucadair-dots-server-discovery [5] draft-ietf-dots-use-cases [6] draft-ietf-dots-architecture [7] draft-ietf-dots-requirements From nobody Wed Nov 15 18:12:37 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1773E1293FF for ; Wed, 15 Nov 2017 18:12:32 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnMYm9OrIHHA for ; Wed, 15 Nov 2017 18:12:31 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6488126CC4 for ; Wed, 15 Nov 2017 18:12:29 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id 8so39186172qtv.1 for ; Wed, 15 Nov 2017 18:12:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=//6rwXDWnDZKWg3QCZKl7iXN1RaGpy/EEX+W6cbxZfI=; b=glxKxxNQof2hh8fIO3gsILTJ7SA5BJkj8iVjUFtlbR57hHiB6ABuhClLQy9sDMFvA7 o2aaaBUiN3lREosQSlZxqyilK9O49hs0y3kaOjxalGz/vOMzsYDIW3hIDhdxD6cfreCf KyR9jY9OQXFI5DBvFz8ZFqsK+HWE1KdDosdwM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=//6rwXDWnDZKWg3QCZKl7iXN1RaGpy/EEX+W6cbxZfI=; b=cr2cVguVK2yEAufXztgQhLpik+qTacmvn4RLNuauwKEhSaIFXLtYsEBeocltRJQEkZ AGeh4aFEaCFTl0hml4DRHw8mJLm4uBVNnmP+mfPyujsBPfhJDXLIfEWBfcoaLoThfU2V avQh8sjFeyam79HA2xEY8siFTcV09lJB7lNXKWA7QzeqjPX99WOziEjTeqaUBTeuE88E A5vKGx3f+sJrvuV3x9/6H3/PTbqb8DsGn8mBtB+wyJXliuqXycnXss005TrTtWM0b1cX XB3pnidQ58YHFgQ4KB5ZXfNZltRgzY+R0WIz8mIOKsdVJ3iiniUkfMxyrO8jsRpVKSsI H6lw== X-Gm-Message-State: AJaThX7VUPF9zQBosDxaS+E+G1usTE4dr5XlUIefjcL388nCPraf4WAD bNTW/5y5kkXRNa7C4bfEmwafM2GZ2vbPNgCGmMIgoNc9Ks0= X-Google-Smtp-Source: AGs4zMbX1lr10V3N0uu6pIQIdqoJfxxzfPZ24AYhvlVjVXMojgXXxgj1UYRLfR+cnILB4zwETK9iAcnFsNWWzA4OvOg= X-Received: by 10.55.23.68 with SMTP id i65mr130978qkh.179.1510798348719; Wed, 15 Nov 2017 18:12:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.204.17 with HTTP; Wed, 15 Nov 2017 18:12:28 -0800 (PST) X-Originating-IP: [2001:67c:370:128:b0f2:76d0:ab1f:787e] From: Kyle Rose Date: Thu, 16 Nov 2017 10:12:28 +0800 Message-ID: To: saag@ietf.org, tcpinc-chairs@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [saag] TCPINC report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 02:12:32 -0000 TCPINC did not meet at IETF 100. The two main drafts (TCP-ENO and tcpcrypt) are in IETF last call and are scheduled for the November 30, 2017 IESG telechat. The remaining milestone is to complete and request publication of an informational abstract API draft. Kyle From nobody Wed Nov 15 18:18:27 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BAC127775 for ; Wed, 15 Nov 2017 18:18:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9Sj7wdXK5Kx for ; Wed, 15 Nov 2017 18:18:24 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::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 86EEA127867 for ; Wed, 15 Nov 2017 18:18:22 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id s11so13995396pgc.5 for ; Wed, 15 Nov 2017 18:18:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version; bh=kOJ5Vu5idDnyWjjkcwP39Y6f8MIkcBjsY7WtB8rpgrs=; b=AwOTV2pYStdALTEA16T0PUcELbQX27q11ZwKVlCgYlwYsdp631OStPPTPn4qyxsbHu dvJYPNopVk2P9iePDYciClJFQsI876Xwm6oopvgvwKmaLYyOHiRkx8C4Qu9Ezb+rggyX dI2Y4fVNDiyf6MFg5q+77NJ03n/tOxJcJa6QFrpJiAXRWTColtYih2iSRXnrPkLlenDj XtfolzmnCS97bo47huLfQ+FjiLWdHieU2fr3fimdsyhr8OpGA9oe+nIKavDXxDSv3drd EtRbpDctXDRjtDCGcpr1AFEQG0S+xUeM/jVnrmVoqioizMqxV5vEXBtbqEknILRFdet9 5y1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version; bh=kOJ5Vu5idDnyWjjkcwP39Y6f8MIkcBjsY7WtB8rpgrs=; b=kd/bJOYmv1vA6tRl5lQi+MAydtGu75o15FMHKRtOFjHlMF4IV1kQ20nscCmbAm++r0 eYsuJmryjsmKU4/20xmU9dHhcF898nCJgf27nRRArkfUJ4HsOlKjwnSV1aH+FY1Zi+jT i4m5gQS64ukxFuigVgWpFYsYTlbmEnlHEy5irVy40mXCL42Nk+4LNxRez8cANpAU44iu c+1VW/hi92QBl/YNLdKKFMQVvkd+ar2TE4HMRJPDeJsgbZ7UVuVZahWX5vNnRUyG6Z8w T22Q+gkAFOPgKtN5SDvvf2IIO7AJU5VdSFsFy+IiyurgYmiwfUfV1H3NTFcO736e9wUt 9NfA== X-Gm-Message-State: AJaThX552N8WtBN+OFpqjKS2YPdbmekhFdejnnPYo/s2Y9jcp9QVP5fY AB5eEGCEplG37slBrPmydt+NmFmD X-Google-Smtp-Source: AGs4zMbSZmAZygtcRmMh3X+8tb1qHD0dwtbgyukpz6Y/A5blI+Ovc9ANOHukGD+X37wR/8G1UgT/kg== X-Received: by 10.84.197.35 with SMTP id m32mr126480pld.306.1510798701648; Wed, 15 Nov 2017 18:18:21 -0800 (PST) Received: from dhcp-815f.meeting.ietf.org ([2001:67c:370:128:1957:c7f5:248f:45c4]) by smtp.gmail.com with ESMTPSA id 15sm36593pfs.125.2017.11.15.18.18.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 18:18:20 -0800 (PST) To: saag@ietf.org From: Melinda Shore Message-ID: <213bee48-04df-1e0c-ad22-1a896ad45abb@gmail.com> Date: Thu, 16 Nov 2017 10:18:18 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="weMjkKDAVSWxBJKJKFPuVEWCClLhhLv9L" Archived-At: Subject: [saag] trans report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 02:18:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --weMjkKDAVSWxBJKJKFPuVEWCClLhhLv9L Content-Type: multipart/mixed; boundary="MpCs4rIjXARL639T5jImmtjeKuTEuKgN3"; protected-headers="v1" From: Melinda Shore To: saag@ietf.org Message-ID: <213bee48-04df-1e0c-ad22-1a896ad45abb@gmail.com> Subject: trans report --MpCs4rIjXARL639T5jImmtjeKuTEuKgN3 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable trans met Monday afternoon. Our three deliverables are nearing completion, with two having successfully completed wglc and one requiring a revision before restarting wglc. During the session we talked about label redaction in CT logs (still contentious) and problems around logging short-lived certificates. Over the coming months we'll be deciding whether to take on new work or to shut down. --MpCs4rIjXARL639T5jImmtjeKuTEuKgN3-- --weMjkKDAVSWxBJKJKFPuVEWCClLhhLv9L Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOwSIcj4Q6xsnay8FuIZGkzoegS4FAloM9WsACgkQuIZGkzoe gS5p4Q//ebf15jSTSKqnBosR5tVughr7VDK3hKr9/I2e9gLVp6YALuPzQ74K3WiD 0exQtjLm0TDkkF2znXfSpNaInqB7ba7y5OJRi6vurINE8dI7dw+FlJHSB2ki9CQ2 Y8+CL9V8x+TiufAWjeBsrH/UQckQ5HLxP8sU8pa0T8vkV8pO0eTGsGR+hfU0Z4YF F2sEpqstB6u0NZLLmR7bY6dk6A/gWDW7VGy5OVnjWiQXsqpWxyB6qt/sAfR9SYnZ hzAt6lCoBFzG5OVlfuftOzmd6XVI0IFafwHogH2QDsDE3GnyZdXNDc/QDx9TCQhE 6UNQfxG0S18Twh/AtWgQUBQfST2LGQJyJsKOevO9Tj7W0YQZG+V/3CFe89As6wN2 TizO3FKN7FjKWWUqyv/8GdLOLexIgsewAFF8XqhOpEmt+TaqxYCoOYbBFq+uoF97 3dvJeoANU4S+Nh/+pKyCZcHJEcEy02ByHy4VCRhvyvw8X8Etfb8Hv/RndNQDH7t6 L07jKPQ/MVYKdpZhRoHTI0N+TMmdKOf2We2Lb0Mg1BlKI+9akPeDkyNKnsoUXKSQ Uq9sqanpZj7mFpeRrybGE5uFAeW80T0dSL9EmlXWgitw90bHsubi/vVAJxKW/iY+ jGJqnwQayASXJIrsYhYwSN6/uZinfboIg5xWQjFj7uu/fVX0ksI= =LP06 -----END PGP SIGNATURE----- --weMjkKDAVSWxBJKJKFPuVEWCClLhhLv9L-- From nobody Wed Nov 15 18:25:35 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB82912894A for ; Wed, 15 Nov 2017 18:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqjEjHhauqep for ; Wed, 15 Nov 2017 18:25:33 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42962120227 for ; Wed, 15 Nov 2017 18:25:33 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAG2Onbl032269 for ; Thu, 16 Nov 2017 02:25:33 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=zCeOsQV9WxBJa8IBKLybGqq9oUqhKZ8F9bhNVSMz46Q=; b=GX0hX+ArLB7P6racdIKZ1Yk04IfmrigYiHElq8A46LGgwdp/JwzCpaeiII0taEf5Gx1f xtom9pCYcVOeQp85lpDfrmkg3IvxafR8leXRgnpJZhFhadX0X9lEw/JQ2HVPMK0xQwKz 0KYAVqS30ULXbEfD6x44R9rKt0nNZ/BSDrNr2JtC25zLh7BuCCxeujM2NXG5JcdRiDgJ PNW3NfOxCnR15hxq4zYwHyLZ6snaUcptyJ3eos7coOJ/oJaEWoZNI46JgENS6eFgLRhW GHouEkJzBqgX0+V7M/mzBQLs6Xz5T0SK9IbQnRE2DztBD4l70ppoV6aCnYeWtzlO4r84 Zg== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050095.ppops.net-00190b01. with ESMTP id 2e8d5kk947-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 16 Nov 2017 02:25:32 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vAG2LmnS029410 for ; Wed, 15 Nov 2017 21:25:31 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2e7p3wqsqv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Wed, 15 Nov 2017 21:25:31 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 15 Nov 2017 21:25:30 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 15 Nov 2017 21:25:31 -0500 From: "Salz, Rich" To: saag Thread-Topic: ACME prospective report Thread-Index: AQHTXoIsTyjkqSwat0+QuSmJ4OZtWQ== Date: Thu, 16 Nov 2017 02:25:30 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.147.53] Content-Type: multipart/alternative; boundary="_000_A07B8EFAA59B4B88830DE76B60BF0086akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-16_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711160030 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-16_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711160030 Archived-At: Subject: [saag] ACME prospective report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 02:25:35 -0000 --_000_A07B8EFAA59B4B88830DE76B60BF0086akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QUNNRSB3aWxsIGJlIG1lZXRpbmcgcmlnaHQgYWZ0ZXIgU0FBRy4gIFdl4oCZbGwgcG9zdCBhIHJl YWwgc3VtbWFyeSB0aGVuLg0K --_000_A07B8EFAA59B4B88830DE76B60BF0086akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <33BB3ED5D5B36843A1EE6E4EC1FEC9E7@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29t cG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0 ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1z dHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxi b2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5 NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5BQ01FIHdpbGwgYmUgbWVldGluZyByaWdo dCBhZnRlciBTQUFHLiZuYnNwOyBXZeKAmWxsIHBvc3QgYSByZWFsIHN1bW1hcnkgdGhlbi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_A07B8EFAA59B4B88830DE76B60BF0086akamaicom_-- From nobody Wed Nov 15 18:27:33 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF41126CC4 for ; Wed, 15 Nov 2017 18:27:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuYxnYV-LMIM for ; Wed, 15 Nov 2017 18:27:28 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0090.outbound.protection.outlook.com [23.103.201.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B72E9126D73 for ; Wed, 15 Nov 2017 18:27:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ds71HDL585x73ABaP86tnBF8tOwGWV/Miz2b3JCTkVw=; b=fcQXYSNBbdYzP4h3VfmPSxY8JJxorxCc1pqF0ukH/j4C/lEkIZUch4f2uGlcNz4rnKZXTEoW3XM3Lfaw/MDteHqZMiF0uTkF4q0gPB0jA9vHLTeH01uh28KV5SIC/5y3lH8eHnZRbnv3JHI2qZicoov84W/wOovExzKhqpsHRYk= Received: from CY4PR09MB1495.namprd09.prod.outlook.com (10.173.191.141) by CY4PR09MB1496.namprd09.prod.outlook.com (10.173.191.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Thu, 16 Nov 2017 02:27:27 +0000 Received: from CY4PR09MB1495.namprd09.prod.outlook.com ([10.173.191.141]) by CY4PR09MB1495.namprd09.prod.outlook.com ([10.173.191.141]) with mapi id 15.20.0239.005; Thu, 16 Nov 2017 02:27:27 +0000 From: "Waltermire, David A. (Fed)" To: "saag@ietf.org" Thread-Topic: IETF 100 SUIT BoF Report Thread-Index: AQHTXoJp1jt9JpwZakWao1F8c7Psfg== Date: Thu, 16 Nov 2017 02:27:27 +0000 Message-ID: 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=david.waltermire@nist.gov; x-originating-ip: [2001:67c:370:128:492f:5e7b:d94a:4946] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR09MB1496; 6:ZFg3/YpGPoYo0EYhp4OxPAS8FXLQKpRzgVTXg7mLhBwUAJb8e8qlEKpqeVEG7rys7sz3XUfLIPFh7D7z8Y4VAo34xLABHusOeetSq7mO6RPRO5emfYKP29pKUocq6696qw0yjqdND4MSNo4HPhzSVP9olf1tYyUmzRj9fumH7++AQg9i59BK7GP4npXqTh1vLH+U2Vj9OFGDGO/F3Bj0PomVklmq6XH5evjykgjmU2+JkAm3OQxWXdLdbIM5dU/R23PyFHPvdkkbBx8Z2z8mfAL/ntSIX9WdrnEwjeZKDJ6RTNNg252mdgNGNn8LbciOGM/bh2nU+4nJ9xBjKSvisYGGaBUUj0BfNlkOWWweuhs=; 5:fI0v177G2cSwpOJiamtFqrte87nDS1LqltZl7IdDrRsLID/HzgnJJj1SR85Emva5zLYxjXug1CtCd07sqr5jWBvNaq7aLTw18WiI2hBN79LNRf7KCLdNZcwHzwxGOcyN4nn0wbu8vw2FA8yJaeNMuMOYWAlghF5QhKZXF+fIJ0E=; 24:dOS6Xi6MxYCZhVHf6E4QbojjF0PzaxD0txaECN5RHkNGAe5Z3uemb2bEsECnVi+uM2vu1yLuhga46EspYtlWYv48nbLNujI5c1/Cs2aYxws=; 7:tRaKO+ATT5+b3Rf+mWowcbtsRbukiCuapBTwuIdQYZToyrNAcEzsxB3kpxYr/6GHIDzkRhyPxC/4z2QPIE2FKEZJ8sgA1qpaxDfeSKo9sqTRg6WFhMEJk/IhwrM0/LaU4ofbCPqlFspiLVe64xDK5tMfjh66atN0G53aqKDcXEJdSEgGPCj90zRT8GyQADWlokFIDDz9qQ2K2g0B9qYzmMgHA6TDBu4W1WkmxagjetXRzK/b70c/bC/ZW9PQp7c2 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 5106890c-945c-4228-c964-08d52c999470 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:CY4PR09MB1496; x-ms-traffictypediagnostic: CY4PR09MB1496: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(3231022)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123562025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR09MB1496; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR09MB1496; x-forefront-prvs: 0493852DA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(376002)(189002)(199003)(478600001)(14454004)(606006)(99286004)(8676002)(189998001)(6916009)(86362001)(7696004)(2906002)(6506006)(68736007)(1730700003)(7736002)(966005)(81156014)(81166006)(6436002)(5640700003)(74316002)(77096006)(97736004)(55016002)(53936002)(2351001)(19627405001)(106356001)(2900100001)(236005)(3660700001)(6306002)(105586002)(54896002)(6606003)(316002)(9686003)(33656002)(54356999)(2501003)(101416001)(50986999)(102836003)(6116002)(8936002)(5660300001)(3280700002)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1496; H:CY4PR09MB1495.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR09MB149515C4DFCA7B282762C891F02E0CY4PR09MB1495namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-Network-Message-Id: 5106890c-945c-4228-c964-08d52c999470 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2017 02:27:27.3893 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1496 Archived-At: Subject: [saag] IETF 100 SUIT BoF Report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 02:27:31 -0000 --_000_CY4PR09MB149515C4DFCA7B282762C891F02E0CY4PR09MB1495namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable The Software Updates for Internet of Things (SUIT) BoF was held on Monday d= uring the afternoon II session [1]. This proposed WG intends to focus on de= fining a firmware update solution that will be usable on Class 1 devices (a= s defined in RFC 7228), which may also apply to more capable devices as wel= l. The BoF was well attended both in-person and remotely. The discussion focus= ed on review of the charter, with a series of hums leading to some changes = to the charter text. The revised charter has been posted [2]. Comments to t= he SUIT list supporting the charter or focused on charter text changes are = appreciated. Thank you, Dave Waltermire, Dave Thaler, and Russ Housley [1] https://datatracker.ietf.org/meeting/100/materials/agenda-100-suit/ [2] https://datatracker.ietf.org/doc/charter-ietf-suit/ --_000_CY4PR09MB149515C4DFCA7B282762C891F02E0CY4PR09MB1495namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

The Software Updates for Internet of Things (SUIT) BoF was held on Monda= y during the afternoon II session [1]. This proposed WG intends to focus on defining a firmware update solution that will be usable on C= lass 1 devices (as defined in RFC 7228), which may also apply to more = capable devices as well.


The BoF was well attended both in-person and remotely. The discussi= on focused on review of the charter, with a series of hums leading to some = changes to the charter text. The revised charter has been posted [2]. = Comments to the SUIT list supporting the charter or focused on charter text changes are appreciated. 


Thank you,

Dave Waltermire, Dave Thaler, and Russ Housley


[1] https://datatracker.ietf.org/meeting/100/materials/agenda-100-suit/

[2] https://datatracker.ietf.org/doc/charter-ietf-suit/


--_000_CY4PR09MB149515C4DFCA7B282762C891F02E0CY4PR09MB1495namp_-- From nobody Wed Nov 15 18:52:44 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0874128954 for ; Wed, 15 Nov 2017 18:52:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnt-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8YTe-3S6x9P for ; Wed, 15 Nov 2017 18:52:41 -0800 (PST) Received: from mail-pg0-x235.google.com (mail-pg0-x235.google.com [IPv6:2607:f8b0:400e:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB1E0126CC4 for ; Wed, 15 Nov 2017 18:52:40 -0800 (PST) Received: by mail-pg0-x235.google.com with SMTP id 207so16710491pgc.12 for ; Wed, 15 Nov 2017 18:52:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnt-se.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:date:subject:message-id :to; bh=xQi4JFGhssCwMTWMJ9XuQd2Hzk/2LMJC8P1/uRTb5nU=; b=OLwZPhnfqzsxcq11LYTfAPu4sZ/yIATZ6mrqlNf3wCvIhQKaAH1jawNFzvqSjShFxB LwTJsiyWd+qNlJlctRoT4TJza1WG8+zn9kqXvHCuKgd6ir6qMhMkG17CDp9KRwgc3lLO sOqHCPgCeboXydx2fNU6AE06buPWUBJCcf0y+8z7vRdyKy/JYCqRIKDv0xZW4a7BFy4/ 4tNvkEvbu5xkOxo4K2zZu3r9gloL1RcRGWILy2mlrI+eucFgy+OHspkGOdC07ocLNeb1 n3v9nhnqEap8E4uyFyo/Mp6SAHKT+NKq08cYHg08rQmdGtxvJ9JlQCEytYK9lOu9w5HT zA4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:to; bh=xQi4JFGhssCwMTWMJ9XuQd2Hzk/2LMJC8P1/uRTb5nU=; b=uMRb5hNky/M6Ko6/0YXpfCvmCSC3VGQ9PMm5dTfUtsmENpA80h70s4RKHqjX8Ypg4j xjgzIkv+PkPN6Ynu5qSp3eOusdQMpH6Ily7O7iu9ck1sX5YzmrpYrlbFAvsdOz7XooUY piadLeudFd1DoF0ng/LeRVXwPbOsfvn8h7lBRNI7AWdhwQV0ykRew5X/8iVDAvQzJpCa XwkHHeJk31S5WYtlCCcHNV3iz/yqRC2aBJRePZ+SvdIGciTy31KX9xlk8P/kMXsLO8RU pjRDfFb/dlkOUEeriTvfP3E32XTATF7SZF47cMdm74FgTkW9/qkrBy8WyHdvrdQOcOb7 JRwQ== X-Gm-Message-State: AJaThX4gCY0sYQVfSx96eJkhUAyPHbR7AjBDEXJzgFEwDtsH1N4Gmowg txiyL8+96/1gGa7B+LTPHEjarraDmC4= X-Google-Smtp-Source: AGs4zMbZ//C2Jk8DMIg6C2bmfJzVKDNKbWNFwTaco4JIOr079S0c4x2WnNWhx3wMinm6/rJ49OQUkA== X-Received: by 10.99.178.15 with SMTP id x15mr182703pge.243.1510800760109; Wed, 15 Nov 2017 18:52:40 -0800 (PST) Received: from [31.133.129.243] (dhcp-81f3.meeting.ietf.org. [31.133.129.243]) by smtp.gmail.com with ESMTPSA id u68sm93660pfu.154.2017.11.15.18.52.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 18:52:39 -0800 (PST) From: Leif Johansson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Thu, 16 Nov 2017 10:52:37 +0800 Message-Id: To: saag@ietf.org X-Mailer: iPhone Mail (15A432) Archived-At: Subject: [saag] Uta ietf100 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 02:52:43 -0000 The WG met yesterday. The DEEP draft is in the IESG process and is getting d= one modulo some nits. The TLSRPT and MTA-STS are now both ready to go to IES= G. Progress is being made on REQUIRETLS but not yet ready for WGLC (our fina= l document). Soon after London the WG is hoping to be able to close down.=20= From nobody Wed Nov 15 18:53:49 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9C2C129434 for ; Wed, 15 Nov 2017 18:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=augustcellars.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 Wg_kWYe2nBOH for ; Wed, 15 Nov 2017 18:53:45 -0800 (PST) Received: from mail4.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9C63129413 for ; Wed, 15 Nov 2017 18:53:44 -0800 (PST) Content-Type: multipart/alternative; boundary="----=_NextPart_000_0137_01D35EC9.293FC980" Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; d=augustcellars.com; s=winery; c=simple/simple; t=1510800822; h=from:subject:to:date:message-id; bh=x+huLyVaBBVHAEPhPBYcatyNE2tZXqMzksjwnRiyELE=; b=NdPaZs7VAGg6/lTtW4vS9WKFLeSnNNCeoGcPwyJw87tGLKiJc4bDNfCLskSQSso38Lt+OufgN4I U5Q/MjUKVxt0SxSRr94Dbillj0ZSPhmz3eN7QCn/BAtOd/f/KhlIi9RtMjvPztXlCXN9fYuIIPlv8 RtaO4QHFPJfsxp6oH+w5SHxdWxWbs7N+KplRk6eJXAer0zwBNs1xL9twnelFf5p+uhMG3chLbSKHr E1V14rSyuijQsvG3Hh2gQhwxOdgAEM6J/IjLOmq46qJ6tUllWnizBc+g60L6mtpf//OJ1dj4j2GDG Q4k2OpqhAZUX7irylogr3gNeijqLmBRJFGGA== Received: from mail2.augustcellars.com (192.168.1.201) by mail4.augustcellars.com (192.168.1.153) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 15 Nov 2017 18:53:42 -0800 Received: from Jude (31.133.136.157) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 15 Nov 2017 18:52:34 -0800 From: Jim Schaad To: 'Security Area Advisory Group' Date: Thu, 16 Nov 2017 10:53:36 +0800 Message-ID: <013601d35e86$1b1c8980$51559c80$@augustcellars.com> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdNehhSX8W4kK1APQ0CmwoVU/vstkA== X-Originating-IP: [31.133.136.157] Archived-At: Subject: [saag] LAMPS report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 02:53:48 -0000 ------=_NextPart_000_0137_01D35EC9.293FC980 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The lamps WG met on Monday of IETF 100. The current status of the WG documents was covered. The Internationalization updates for RFC5280 has been approved for publication. The other three original drafts are in the process of going from the WG to the IESG. We had a presentation on the CAA Discovery algorithm and what the current problems are. The group indicated that it would like to get a document for what the current algorithm is with the errata applied, and would then entertain a new document to deal with problems found using that algorithm. The final presentations dealt with getting SHAKE added as a hash algorithm to the various signature algorithms being used in PKIX and CMS applications today. Discussion on the current state of DSA indicated that the WG was not interested in adding SHAKE to DSA. ------=_NextPart_000_0137_01D35EC9.293FC980 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The lamps WG met on Monday of IETF 100.  The = current status of the WG documents was covered.  The = Internationalization updates for RFC5280 has been approved for = publication.  The other three original drafts are in the process of = going from the WG to the IESG.

 

We had a = presentation on the CAA Discovery algorithm and what the current = problems are.  The group indicated that it would like to get a = document for what the current algorithm is with the errata applied, and = would then entertain a new document to deal with problems found using = that algorithm.

 

The final = presentations dealt with getting SHAKE added as a hash algorithm to the = various signature algorithms being used in PKIX and CMS applications = today.  Discussion on the current state of DSA indicated that the = WG was not interested in adding SHAKE to DSA.

 

------=_NextPart_000_0137_01D35EC9.293FC980-- From nobody Wed Nov 15 18:57:49 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4F9128954 for ; Wed, 15 Nov 2017 18:57:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnt-se.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqnOlLaCG76k for ; Wed, 15 Nov 2017 18:57:46 -0800 (PST) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7594B126CC4 for ; Wed, 15 Nov 2017 18:57:46 -0800 (PST) Received: by mail-pg0-x231.google.com with SMTP id 207so16719268pgc.12 for ; Wed, 15 Nov 2017 18:57:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnt-se.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:date:subject:message-id :to; bh=jcom82V6wultKXWOez5Wo5HydW4A2IQGGM7EPSAzSB8=; b=jka7mafwfoP0EhQYRLx5hHj7SLj6IuKeMdudy36twNRTikJ249okNZp8YwGOSz4F95 QsCuBx99uEDeHnpd86J/2wLg26af3slOouMPtUMW4lbNfs7b5pe7Y/1L3Z4xJ4i+IDaQ gGLaC4sFt1vnWulLRqNTrA2+O7S17CaXQy3IwgymWRFqY3mbpdN+/2LTbAJnxrXtzMfB BcOdQWdZRQJzAzxYFAB2yvVomfox912/5bM7cnLBEo11RQCaGxByiR6cYNXK12L9+3wu vD7IC/MRS5zxJkjwya/YwSZ6PTY0OG4WAtNgKgRcWta/IpKXxPE3fEaH5ij/9+k/Vmdv wQMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:to; bh=jcom82V6wultKXWOez5Wo5HydW4A2IQGGM7EPSAzSB8=; b=UomMyBzp3qsnhLq7GH3q2BPlcY0y7IJo2u5HPUM1AdIbeVviyf4S993pcECgBAjwjz 0oEefYCRx4ZO0m6LpIS1bCOfracDXJ2Bx8m5KsFuSqcscMvVHQwxL4wjY+B9hIYNxoEy nMPDiPLjsNs9a4+0rtbsw5nQHLeqnHWpsSU5ty5PyJjJoYeaJWpOLCBTbk0YtAV/K/Mc B09ctL5QfxWK9t5mASRtpmrLEskAtV+nVWnRPBNoisiTN/884oJynH1cvLebHSE9gax9 byGkCJVCo4VMg4004Fsziysc+7Kpg/0rR/ViNomttsdgAx6Ab92979YXd2FCi75A7GO/ 4EnQ== X-Gm-Message-State: AJaThX5/ipIAA03NKkK5rep1MtK6Xaze5Or7LZ1HGAEPmFa8XU7+YXXn UnMf84kGFkCMF6dacDXfFQc5jf4dwHk= X-Google-Smtp-Source: AGs4zMaSp1xgcwIkzUK0g/yMInoC8Uej3AwEbEGRdZolOgZXxUjWRyX9f4yDGJE11YBI8aiW8p9/jA== X-Received: by 10.101.78.207 with SMTP id w15mr192127pgq.347.1510801065721; Wed, 15 Nov 2017 18:57:45 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:a010:e0f3:542b:14ee? ([2001:67c:370:128:a010:e0f3:542b:14ee]) by smtp.gmail.com with ESMTPSA id x77sm131043pfe.61.2017.11.15.18.57.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 18:57:45 -0800 (PST) From: Leif Johansson Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Date: Thu, 16 Nov 2017 10:57:43 +0800 Message-Id: <67A2874B-1366-41BB-8F0E-E900BA043944@mnt.se> To: saag@ietf.org X-Mailer: iPhone Mail (15A432) Archived-At: Subject: [saag] Tokbind ietf100 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 02:57:48 -0000 The WG met on Tuesday. The core documents are all getting ready for publicat= ion. The WG adopted a document describing token binding for TLS 1.3 and also= made progress on the proxy & tls terminators document. Leif & John= From nobody Wed Nov 15 19:27:17 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2C5212420B for ; Wed, 15 Nov 2017 19:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 2ttBSUb-htAF for ; Wed, 15 Nov 2017 19:27:06 -0800 (PST) Received: from qproxy5-pub.mail.unifiedlayer.com (qproxy5-pub.mail.unifiedlayer.com [69.89.21.30]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 834F3129456 for ; Wed, 15 Nov 2017 19:27:06 -0800 (PST) Received: from CMOut01 (unknown [10.0.90.82]) by qproxy5.mail.unifiedlayer.com (Postfix) with ESMTP id 585416AD11 for ; Wed, 15 Nov 2017 20:27:05 -0700 (MST) Received: from box514.bluehost.com ([74.220.219.114]) by CMOut01 with id aTT11w00X2UhLwi01TT4Vu; Wed, 15 Nov 2017 20:27:05 -0700 X-Authority-Analysis: v=2.2 cv=K4VSJ2eI c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=IkcTkHD0fZMA:10 a=sC3jslCIGhcA:10 a=b8_OZUx0L_AtELEfucUA:9 a=QEXdDO2ut3YA:10 Received: from dhcp-8b7b.meeting.ietf.org ([31.133.139.123]:57665) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1eFApR-001JRv-3P for saag@ietf.org; Wed, 15 Nov 2017 20:27:01 -0700 To: IETF SAAG From: =JeffH Message-ID: Date: Thu, 16 Nov 2017 11:26:56 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-BWhitelist: no X-Source-IP: 31.133.139.123 X-Exim-ID: 1eFApR-001JRv-3P X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: dhcp-8b7b.meeting.ietf.org [31.133.139.123]:57665 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 2 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== X-Local-Domain: no Archived-At: Subject: [saag] SAAG collision with DOH.. X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 03:27:08 -0000 ..is a bummer. just sayin' :( From nobody Wed Nov 15 20:06:10 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8D061289B5 for ; Wed, 15 Nov 2017 20:06:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.5 X-Spam-Level: X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=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 CWa_JiDcjxtE for ; Wed, 15 Nov 2017 20:06:06 -0800 (PST) Received: from ns1.nict.go.jp (ns1.nict.go.jp [IPv6:2001:df0:232:300::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3C712949F for ; Wed, 15 Nov 2017 20:06:05 -0800 (PST) Received: from gw1.nict.go.jp (gw1.nict.go.jp [133.243.18.250]) by ns1.nict.go.jp with ESMTP id vAG464cr077111 for ; Thu, 16 Nov 2017 13:06:04 +0900 (JST) Received: from DESKTOP2JPR8KD (ssh1.nict.go.jp [133.243.3.49]) by gw1.nict.go.jp with ESMTP id vAG463qx076841 for ; Thu, 16 Nov 2017 13:06:04 +0900 (JST) From: "Takeshi Takahashi" To: Date: Thu, 16 Nov 2017 13:06:02 +0900 Message-ID: <005101d35e90$37f0b5e0$a7d221a0$@nict.go.jp> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0052_01D35EDB.A7D85DE0" X-Mailer: Microsoft Outlook 16.0 Content-Language: ja Thread-Index: AdNej6upspGQ9iPhQQW1yyyirLRhdQ== X-Virus-Scanned: clamav-milter 0.99.2 at zenith1 X-Virus-Status: Clean Archived-At: Subject: [saag] MILE prospective report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 04:06:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0052_01D35EDB.A7D85DE0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MILE will be meeting after SAAG. We'll post a real summary then. Meanwhile, the agenda and the discussion materials are already available online. https://datatracker.ietf.org/meeting/100/session/mile Take ------=_NextPart_000_0052_01D35EDB.A7D85DE0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MILE = will be meeting after SAAG.  We’ll post a real summary = then.

Meanwhile, the agenda and the discussion = materials are already available online.

 

https://da= tatracker.ietf.org/meeting/100/session/mile

 

Take

 

 

------=_NextPart_000_0052_01D35EDB.A7D85DE0-- From nobody Wed Nov 15 20:58:17 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626E91293E3 for ; Wed, 15 Nov 2017 20:58:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=symc.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRh-4ma1kjRT for ; Wed, 15 Nov 2017 20:58:13 -0800 (PST) Received: from tussmtoutape01.symantec.com (Tussmtoutape01.symantec.com [155.64.38.231]) (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 D6218127522 for ; Wed, 15 Nov 2017 20:58:13 -0800 (PST) Received: from tussmtmtaapi02.symc.symantec.com (tus3-f5-symc-ext-prd-snat3.net.symantec.com [10.44.130.3]) by tussmtoutape01.symantec.com (Symantec Messaging Gateway) with SMTP id 8C.3E.29100.5EA1D0A5; Thu, 16 Nov 2017 04:58:13 +0000 (GMT) X-AuditID: 0a2c7e31-4271e9c0000171ac-4a-5a0d1ae590f8 Received: from TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (tus3-f5-symc-ext-prd-snat10.net.symantec.com [10.44.130.10]) by tussmtmtaapi02.symc.symantec.com (Symantec Messaging Gateway) with SMTP id D0.FE.04468.5EA1D0A5; Thu, 16 Nov 2017 04:58:13 +0000 (GMT) Received: from TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) by TUSXCHMBXWPI01.SYMC.SYMANTEC.COM (10.44.91.33) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 15 Nov 2017 20:58:12 -0800 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.44.128.3) by TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Wed, 15 Nov 2017 20:58:12 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symc.onmicrosoft.com; s=selector1-symantec-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PSisl7aVgw2vKQym0ExbTImZ1w4wucOYwL56Gm6sYsI=; b=IeMH1C/47iOdL01HSg1toukxNGsyIhBgnw2EwKK+dpE6bAquWLzYjA8XdRtUIoiVLF0M95/vqi2iG543BCQ+vLs6oJysDpBcTcqZydsdbJsUCrqdIbfrsA2NQO9PGXBE+FFRcBDjyCmhex0+86DUe4JVWYzLzeD/r2oBr9x9Ffk= Received: from MWHPR16MB1488.namprd16.prod.outlook.com (10.175.4.146) by MWHPR16MB1486.namprd16.prod.outlook.com (10.175.4.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.218.12; Thu, 16 Nov 2017 04:58:11 +0000 Received: from MWHPR16MB1488.namprd16.prod.outlook.com ([10.175.4.146]) by MWHPR16MB1488.namprd16.prod.outlook.com ([10.175.4.146]) with mapi id 15.20.0218.011; Thu, 16 Nov 2017 04:58:10 +0000 From: Brian Witten To: "saag@ietf.org" Thread-Topic: patient ietf100 Thread-Index: AQHTXpeAFwZoI1n1GECPt6tCXmVGtQ== Date: Thu, 16 Nov 2017 04:58:10 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:67c:370:1998:6cc9:7bba:1fd2:ec05] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR16MB1486; 6:klLMaDlJF3TkwBKvTmdxXTfqHc+pA0Mj1WxQric/or+8XwhSDqJk9HVeUpB7uuQJemUSOOz678hG/4r/UB2YoAtOqu89UJk0cU23o18J0G2OAjXaEYl57Zir23rZ/81JeJKN23G6ORu2NML3WQsO7npY70LThDGxk7ww/hS9yuQNQFqlESBCgUdlkrFbmnWj+EbzfWQIxxzYi2QvkxCmVlJ9dmRUu9ZBaICM5begPF5RK+nWUxP4GBt/5oimVja8SD4yAmwbtyYF1cMgmnm0T0lCfWcS0JFyji7nJi5ny2NYxgU49KRsAjrM+GyCdEiTTPQI1FH5Qr/jhVEklRWzn7BbMKvRIfJezo2HiZlclcY=; 5:2NbU5P8k4O+GQ8B3VpIFcyNmfG6nsS83wN0NrrU5EQze75hbXFiS42NuLXfdi4ydHu/XEiN7alY5ZVhIWaH7mg2QnYoYjUMNLPSYi8mzXkM3MS5xNXG46ih/ED2GbdmiDVPS4weLaWmf7SG2+Dl3i5chIj6P8YihTxQfdFxgtco=; 24:OzYUXZb2AFZXkgGLsNGqu7Ts9ig1K94jUYR1yg7tJLXtR9iO5T/thmhJqAopKk15/Gw4tuzI4XA2buBPT3ilv8+mbyjUQ5vYlcshFBq1/Is=; 7:pDa7MyNnWXcATXDr/XOMq1+JWqOjFHbXQdUQ2bTepydqRRRMmNcM5WK3efO08TlwO9v+j6p9iKgCEgF/qIMVP3DuOZcHa5woxCiyZXT4pHdOl0bTCnLOYS//LlzJ1lSIEvSnr4HUyn4ydqexKNQJRfEMg+Lsb0ILBOx5LciepP76EyKOWdlwjghhg6iIONO2ge4LB20uxurCSN+pQ8MmwTxUTGRmw2Ei5fTglIJynfC4Ld+NAJJVG4T66zs9G53m x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 309e3c40-1d3d-4314-33ca-08d52caea2c2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:MWHPR16MB1486; x-ms-traffictypediagnostic: MWHPR16MB1486: authentication-results: spf=none (sender IP is ) smtp.mailfrom=brian_witten@symantec.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3231022)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6041248)(20161123555025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR16MB1486; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR16MB1486; x-forefront-prvs: 0493852DA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(189002)(199003)(68736007)(478600001)(10290500003)(3660700001)(8936002)(3280700002)(99286004)(86362001)(102836003)(97736004)(2906002)(33656002)(6116002)(53936002)(189998001)(6506006)(105586002)(77096006)(6436002)(106356001)(2900100001)(5660300001)(74316002)(7116003)(2501003)(25786009)(7736002)(305945005)(5640700003)(8676002)(1730700003)(81156014)(81166006)(9686003)(55016002)(76176999)(54356999)(50986999)(6916009)(2950100002)(7696004)(101416001)(2351001)(316002)(14454004)(9010500006); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR16MB1486; H:MWHPR16MB1488.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: symantec.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 309e3c40-1d3d-4314-33ca-08d52caea2c2 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2017 04:58:10.8423 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3b217a9b-6c58-428b-b022-5ad741ce2016 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR16MB1486 X-OriginatorOrg: symantec.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupgleLIzCtJLcpLzFFi42Lh0mli1n0qxRtlcOKhmMWU/k4mB0aPJUt+ MgUwRnHZpKTmZJalFunbJXBlXJrTy1Twkqmi4+1OtgbGFUxdjBwcEgImEsenBncxcnEICXxi lHjT8pyti5ETLL6xcQorROIno8Suq78YIZwjjBJzXz+Dcl4wSjz608ME4rAIdDJLHF42lw0i M5VJ4tmnw+xwPe1vLzCBTGYT0JM4+vcOK4gtIqAssfzPc3YQW1hAQmLiw01MEHFZiXl7ZkPZ ehLz5zxmBLFZBFQl5kx6BNbLKxAj8XHCR7AaIQFLiXmPzoHZnAJWEpNO3QarZxQQk/h+ag1Y nFlAXOLWk/lMEN8JSCzZc54ZwhaVePn4HyuEbQlUs4cFwpaVuDS/G+xPCYFD7BL/bv+FKtKT 2DrxLSOE7StxtvcYE0TRTEaJ97daoRJaEk9vPmCGuCJG4tTaV1DbsiUuLDkMVWMt8fLcbtYJ jEazkBwIYetJ3Jg6hQ3C1pZYtvA18yywpwUlTs58wrKAkWUVo0JJaXFxbkl+aUliQaqBoV5x ZW4yiEgEpo5kveT83E2M4PRRZ7iD8dEGn0OMAhyMSjy8q/7zRAmxJpYBVR5ilOBgVhLhjVwI FOJNSaysSi3Kjy8qzUktPsQozcGiJM5bMR8oJZCeWJKanZpakFoEk2Xi4JRqYHQN3OvTt/7C zR+v/ujIdqVkqxp/tpqY9sr3Htv9oz61VyakTTg6w+bwvcj6/YmG5n9fn7xcnSHdUpSwkplL uK7t1ge/ozqXRf/zCh5mnrVilrrzgXTuN4vDo8KSebJmKDk33O2cfPTZDdMtq2f6XHx185VI nsX6STLzNQMO3lpX5v85Zvf5gwuUWIozEg21mIuKEwGp/C00GwMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLIsWRmVeSWpSXmKPExsXCpdPEpftUijfKoHEqn8WU/k4mB0aPJUt+ MgUwRnHZpKTmZJalFunbJXBlXJrTy1Twkqmi4+1OtgbGFUxdjJwcEgImEhsbp7B2MXJxCAn8 ZJTYdfUXI4RzhFFi7utnUM4LRolHf3qYQBwWgU5micPL5rJBZKYySTz7dJgdrqf97QWwyWwC ehJH/95hBbFFBJQllv95zg5iCwtISEx8uIkJIi4rMW/PbChbT2L+nMeMIDaLgKrEnEmPwHp5 BWIkPk74CFYjJGApMe/ROTCbU8BKYtKp22D1jAJiEt9PrQGLMwuIS9x6Mh/qOwGJJXvOM0PY ohIvH/9jhbAtgWr2sEDYshKX5neD/SkhcIhd4t/tv1BFehJbJ75lhLB9Jc72HmOCKJrJKPH+ VitUQkvi6c0HzBBXxEicWvsKalu2xIUlh6FqrCVentvNCtF8hVXi+TOQszmAHBmJ392WExj1 ZiE5HMLWk7gxdQobhK0tsWzha+ZZ4MAQlDg58wnLAkaWVYwKJaXFxbkluSWJiQWZBkZ6xZW5 ySAiEZg6kvWS83M3MYLTh7PkDsZDf3wOMQpwMCrx8F6I54kSYk0sA6o8xCjNwaIkzvtOgylK SCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUAyPLEZ+ZyjX62TWH7tYx+GxeUtHQvWLygl6/xbet 5aOEV07smq7288/iL2flr1dHKp2zZ7Ri71u/4Z3z7JVsp65WTrxT5ff5/ueXN5b+Cl6QcHzB Dvf/IYI75pe33fjOF9W/+OwZhlKFe7MnSc65/XP95WTjEnYVw1ky+aaTpB0vZt49z1TOpsSu xFKckWioxVxUnAgAdyfCcgADAAA= X-CFilter-Loop: TUS01 Archived-At: Subject: [saag] patient ietf100 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 04:58:15 -0000 The PATIENT side-meeting last night was well attended, though with clearly = divided discussion. Thank You Again To All Who Participated. Next step is= to assemble an Internet Draft presenting verifiable data on merits of thir= d party security, particularly third party network security. I'll do this = over next few weeks with help from volunteers.= From nobody Wed Nov 15 21:01:09 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C03127522 for ; Wed, 15 Nov 2017 21:01:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.801 X-Spam-Level: X-Spam-Status: No, score=-4.801 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=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oGuZ6lfnuxOM for ; Wed, 15 Nov 2017 21:01:05 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0056.outbound.protection.outlook.com [104.47.41.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0BC7126B72 for ; Wed, 15 Nov 2017 21:01:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lKQeMikHZistbJ4oxeE8NV/xRBicH0ulddcmRhVLlFg=; b=k1rC3BRI4LIz/D/aEQgqVPfApGQ+anExlp1cvI5Gm918RN875KtX73uTaV4wfrCqHaYtKT1UDJpANaeYqAdA1BV9u1B1piBgnsTyxIVsiZGExuFwV8id3wRI/HGPhL8iBBvvLfoMxZkKphGLwKqi5xw2FMTAS31c9KM0e6/GBbI= Received: from CY4PR06MB2456.namprd06.prod.outlook.com (10.169.186.136) by CY4PR06MB2456.namprd06.prod.outlook.com (10.169.186.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Thu, 16 Nov 2017 05:01:04 +0000 Received: from CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) by CY4PR06MB2456.namprd06.prod.outlook.com ([10.169.186.136]) with mapi id 15.20.0239.005; Thu, 16 Nov 2017 05:01:04 +0000 From: Karen O'Donoghue To: "saag@ietf.org" Thread-Topic: NTP WG Summary Thread-Index: AQHTXpfnyNbqXUDSrU2Nfcv642i3xg== Date: Thu, 16 Nov 2017 05:01:04 +0000 Message-ID: <801DBC93-E7C7-4835-AB55-273DABF2C70A@isoc.org> 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=odonoghue@isoc.org; x-originating-ip: [2001:67c:370:128:c0b2:fa22:120d:e4db] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR06MB2456; 6:ddy/0MIGXr5f7d9bIy8rbEBZOwzg17VnHgTUDweuoijYoFSF6pd6ZfwaA4tjtilz/5WTE3WUIzGp7lgTR0TixHLGq/OyxZvppVIPc18rlWcB9KGQwT7IPuQvZ8lNQwaeCYvKnw16OJRr3uJnlQNIaAi6E1+1BqiDND/VUomcHknnW8nc1xAd8l8cE7UKrsYszDO2DDk7kkeYK0BaYpOq1dMpddA2NmbwGy7nGcMnlKa4qi9ajCRFrlA7MzoSek3BXjMQm1N4E8i10fAaJDv0eYhZ556IHHE3vgm0mU8m3yKkiTklxliJTSRy9/CGS+0WotkvU8LG8m8Dm/7ddcizRWiS60oFXZ0tsJA+3t6lPrM=; 5:BqjmwJRQb3/dNPWyQnN0+OMdGGsfOBeA/rJEW8ZJDcAQKh1Lgm+04una3Xjx4ksEF5anaau0XvXwt4vFvZO3DyQOtD0GPeQiHSp9Fghidymm6Z2e7pHAnD8rPjUQ3+xXwUwOtWcviBkTuGxho+5pSyyaSPSJ8w8zAw9YzqorCfs=; 24:cvrkrx3SDkIrh8rhn0OECdPd9blD+xUkbxY+p3gOIBbNp2Jr5S6AgAa0vnQrHg0rN2wQjenfacJtYDNp4pOcTepB7FKZeOKi1DQn0vScNSk=; 7:3WyHIrWj7CNZLIoxkTb0X5abaP/aiFp80AExCMnhxRMNGTJRGYNemGvVu1LIk4BEhz+1Voj/Z7QA4D2XJDDOXcwi9VyHkYm9CoeRvTnmD33PcUMU6UGV2gyhNUNR1FoI0546NB4QHdcDUPQqaG68w9gjcOeZeaQSJDszXT87CSHpTdcvsPwv9fuBATmK5qcOhdJZzAIAd7zeLFaeuSc6dcmv0O5CceEXV4AdtoY+STK0vNfDfzOeA5W6JJoQUtiS x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 71d3131d-3e7f-44b4-28bb-08d52caf0a0b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:CY4PR06MB2456; x-ms-traffictypediagnostic: CY4PR06MB2456: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(3231022)(3002001)(10201501046)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123564025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR06MB2456; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR06MB2456; x-forefront-prvs: 0493852DA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39830400002)(346002)(376002)(199003)(189002)(2351001)(101416001)(54356999)(478600001)(50986999)(8676002)(7116003)(1730700003)(2900100001)(81156014)(81166006)(33656002)(7736002)(106356001)(102836003)(105586002)(68736007)(5660300001)(305945005)(25786009)(82746002)(6116002)(2501003)(6436002)(86362001)(6916009)(83716003)(2906002)(36756003)(6506006)(3660700001)(6512007)(3280700002)(316002)(189998001)(3480700004)(97736004)(14454004)(5640700003)(99286004)(77096006)(6486002)(8936002)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR06MB2456; H:CY4PR06MB2456.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-ID: <99AE95700480F4458590FE3AAE51ADE9@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 71d3131d-3e7f-44b4-28bb-08d52caf0a0b X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2017 05:01:04.0476 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR06MB2456 Archived-At: Subject: [saag] NTP WG Summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 05:01:07 -0000 The NTP WG met Monday, and we continue to pursue the Network Time Security = mechanism for NTP. The latest draft narrows the scope to the client/server = mode of NTP. The remaining modes are going to be specified in an experiment= al draft. Plans are underway to work on implementations in the context of I= ETF 101 Hackathon. = From nobody Wed Nov 15 21:07:07 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36536126B72 for ; Wed, 15 Nov 2017 21:07:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Rtrx4aUbxQc for ; Wed, 15 Nov 2017 21:07:03 -0800 (PST) Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 892BF126B6D for ; Wed, 15 Nov 2017 21:07:03 -0800 (PST) Received: by mail-lf0-x229.google.com with SMTP id i14so800058lfc.1 for ; Wed, 15 Nov 2017 21:07:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=9vQXZNNz7mBc30aEcn8zjJq4pdH8nNAXtDYr0RVEFvI=; b=fdE0pW9oePgSwjVIHOrAA2D75ZgaqtpOH3IFjq/w7QS32Atni9Ex05vK6LUSovNdC2 Nk81mIGHJlPonejTZrVOJWkUzFmz/dvPzZxlmEzXKAuGn1W/l6x5P11uGNCGQq+XsGm4 rKbRZZFhPfwPbcVpxFmSIVdhFM7THHGR1idNqW5i4PjMsvbM0g/6Z0EImnIbAybU5YIM SbQ5gP5com/e6WdFmDzleB4oSuCSwQ2/wWe4tx+yL/y6iXo003CCTLvlEjwTXgQoQpnk YpDSpZvlUhrfQs7h/axArMQnatOECebxmAKD3hGu6kmBB103gvZu74T+jyojehhb1hGA ViZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=9vQXZNNz7mBc30aEcn8zjJq4pdH8nNAXtDYr0RVEFvI=; b=MiVhc0Wvt01DGQSoOyLCVsyv9jHpaGWo66pintBieCowfe8ZSeia2wvyg5hc9R0O/q RLUM96nR5efktnGHhfwnKCtAaGWmtlnJ15gn4a88KD2UrQXXunHJvF7YbVpXNha+NVmk Z654hcipRjqMUH3ZNp0KSgZcHS0ODKZ/MAD6YFsI0eho8k1tE2+TLasnG9TAlChOmmV0 ZbFigM5ASdaHILmnAPl8pMyV6tTLyRKimaaQCqgHQuwYFoLEyueezOlSsu67jctADXbz 9LB38JRnh4FIDBM52F2xg+fbG4AAqRw6KJi7u8CGvnivNQLvqlew6Weq8e3Z7PgTZqSF Rjow== X-Gm-Message-State: AJaThX6EJj6Bg5B6ndPVbtg6La63HBfx+4ZysijfD7WlVg6vTJUkEuuk iTz8l3agC02g31u4qexD9ZynJF+ya3Ioa4EGXBs= X-Google-Smtp-Source: AGs4zMZ+uktTJwmQE/cWbqvrhTg8RenQdr2NlFpGXpM6+f96L41dzWbMigsURzSllKdwL39h2F49EUicEeDizajLPCk= X-Received: by 10.25.195.211 with SMTP id t202mr136372lff.53.1510808821615; Wed, 15 Nov 2017 21:07:01 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.46.70.2 with HTTP; Wed, 15 Nov 2017 21:07:01 -0800 (PST) From: Daniel Migault Date: Thu, 16 Nov 2017 00:07:01 -0500 X-Google-Sender-Auth: _BbG4gCRZpOTAmfdTEMhT98aW74 Message-ID: To: "saag@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1a19a022d130055e12970e" Archived-At: Subject: [saag] CURDLE WG Summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 05:07:06 -0000 --94eb2c1a19a022d130055e12970e Content-Type: text/plain; charset="UTF-8" The CURDLE WG did not meet this IETF meeting. The WG is progressing well. Yours, Rich and Daniel --94eb2c1a19a022d130055e12970e Content-Type: text/html; charset="UTF-8"
The CURDLE WG did not meet this IETF meeting. The WG is progressing well.

Yours,
Rich and Daniel
--94eb2c1a19a022d130055e12970e-- From nobody Wed Nov 15 21:08:27 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1D15126B6D for ; Wed, 15 Nov 2017 21:08:25 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 myR3eGHJ614N for ; Wed, 15 Nov 2017 21:08:24 -0800 (PST) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3045F127522 for ; Wed, 15 Nov 2017 21:08:24 -0800 (PST) Received: by mail-pg0-x22a.google.com with SMTP id r12so2991635pgu.10 for ; Wed, 15 Nov 2017 21:08:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=JM5FdZ7dUXaOEQF7hsMzgauj7AEGIK2/0fInv6HFCfk=; b=FEC6nEJaC3072osrCyTf8SbzmTfYupMIIkVi9PEgYRPO2a/awX+9UYpwjflcAQPVHl qfO00at4h101LmfJ8sFHpWNSqcSO2aatB/dJWSaeK+Na3ngszKEa5cCjnVqtyjBwzHKE kQ/pxVnOqpDB2o39mX0AI3N4Przx6qffcPi4w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=JM5FdZ7dUXaOEQF7hsMzgauj7AEGIK2/0fInv6HFCfk=; b=W2paTrmNmvANKIR1TiQDxtEscBYqKB5B5IVeEgvcj2WH9S3DIankutH3Lqqvj6mxoQ 1wW0I9Zk4mHC/vcATfgfg7hCxcGZp/gQgVAWqQGYelecfsVDJ+LqH1bu1edeUF3cu6oq +8dJETRVsadm4IyavpEbjA6ZBxrc9AB637e0exPFrfhIAwOWoAzJLUq3zS38Vgug1NMm LHciqIwpNG3eh8QQHSyteiurXq7nF4SViFYX4JHfxfZMtC+MNCxtqOGjKlmipse2jGj/ eVWMYthMJRxfS8M9WNAwaHEOeRt8knbs5AOSdAvZcKoA9ff1EoqKjgC51x5vNFubDMI7 OySg== X-Gm-Message-State: AJaThX4Ud0ROYf4K6kMWYBm7ZImaF0LdUM8LlA9Aj3+iltP9esPhszbq ggfTWIJW0WlMt+KZK6TLoeIZ/VTc0tQ= X-Google-Smtp-Source: AGs4zMaOJQ0Dv7mjs/+LwXqWQRCRWmHKE8Yz9A0HRwNTUsKJKpfVVTeRcCAKXsZ/bCSOGnKFJfYrpw== X-Received: by 10.99.62.10 with SMTP id l10mr487676pga.376.1510808903571; Wed, 15 Nov 2017 21:08:23 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:e992:412f:85b5:bd0a? ([2001:67c:370:128:e992:412f:85b5:bd0a]) by smtp.gmail.com with ESMTPSA id d28sm627478pfb.105.2017.11.15.21.08.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 21:08:22 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <9239DE71-38E4-44A1-A381-E41C0443E00E@sn3rd.com> Date: Thu, 16 Nov 2017 13:08:20 +0800 To: saag@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [saag] TLS@IETF100 SAAG Summary X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 05:08:26 -0000 The two remaining PRs will be merged into TLS1.3 and a -22 version will = be published. A 3rd targeted WGLC will occur in a few weeks after some = final measurement data is collected. DTLS1.3 has no outstanding issues = and will also enter WGLC shortly. The WG also agreed to adopt the = Connection ID draft (this will be confirmed on the list). The Record = Size Limit Extension draft will also enter WGLC shortly. Exporter = Authenticators is awaiting formal analysis to complete before WGLC; the = results look promising. IANA registry updates will enter WGLC this = month. There were two non-WG draft presentations. One described an extension = for protecting (D)TLS handshakes against Denial of Service; no action = wast taken to adopt the draft. The other described Application Layer = TLS; likewise no action was taken to adopt the draft. J&S= From nobody Wed Nov 15 21:16:38 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF12D1201F2; Wed, 15 Nov 2017 21:16:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.714 X-Spam-Level: X-Spam-Status: No, score=-2.714 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] 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 LR1yWqqfoULV; Wed, 15 Nov 2017 21:16:28 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 775481286B1; Wed, 15 Nov 2017 21:16:27 -0800 (PST) X-AuditID: c1b4fb25-d91ff700000020f7-71-5a0d1f299c52 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 7D.75.08439.92F1D0A5; Thu, 16 Nov 2017 06:16:25 +0100 (CET) Received: from nomadiclab.fi.eu.ericsson.se (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.352.0; Thu, 16 Nov 2017 06:16:24 +0100 Received: from nomadiclab.fi.eu.ericsson.se (localhost [127.0.0.1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id E15074EE1F; Thu, 16 Nov 2017 07:18:53 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by nomadiclab.fi.eu.ericsson.se (Postfix) with ESMTP id 297F54E689; Thu, 16 Nov 2017 07:18:51 +0200 (EET) To: Bernard Aboba , Jim Schaad CC: Security Area Advisory Group , , References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com> <4c6c9bc8-6056-c03d-a0f6-f1f32fabef39@ericsson.com> <00d401d35114$de589760$9b09c620$@augustcellars.com> <8D84F942-5D10-4DB8-8EB7-3EB8A8AEE17E@gmail.com> From: Mohit Sethi Message-ID: Date: Thu, 16 Nov 2017 13:16:21 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <8D84F942-5D10-4DB8-8EB7-3EB8A8AEE17E@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms060203040909000608070202" X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrLIsWRmVeSWpSXmKPExsUyM2K7rq6mPG+UwdUzihYb9v1ntji2fi2L xerp39kszq08zmIxpb+TyYHVY+Oc6WweO2fdZfdYsuQnUwBzFJdNSmpOZllqkb5dAldG54r3 jAU7LzJWTH28hLmBcf4ixi5GTg4JAROJGf92AdlcHEIChxkluiceZwJJCAnsYJS4dqsEIrGR UeLsm4lsEM4CRolt8w6DVQkLiElsed/N3sXIwSEiECSx96IDSJhZIFji+6FfrBD1bSwS5zft BFvHJqAn0XnuODOIzStgL/Hj9S4WEJtFQFVi5snHrCC2qECExPPm96wQNYISJ2c+AavhFLCV 2PehC2wos0A3o8T0WX/ZIX5Qk7h6bhMzxNnqEls7DjBOYBSahaR/FrKeWWAXhknsX/iHBcIW l7j1ZD4ThG0mMW/zQ2YIW1ti2cLXQDYHkK0msaxVCVUYxLaWmPHrIBuErSgxpfsh1HhTiddH PzJC2MYSy9b9ZVvAyLOKUbQ4tTgpN93IWC+1KDO5uDg/Ty8vtWQTIzCiD275rbqD8fIbx0OM AhyMSjy872V5o4RYE8uKK3MPMaoAzXm0YfUFRimWvPy8VCUR3jvSQGnelMTKqtSi/Pii0pzU 4kOM0hwsSuK8HiLcUUIC6YklqdmpqQWpRTBZJg5OqQZGG8+k8KWBUbYcW50jbqWpyy4QNymW fi0bv/B//YurD46w85roPbV+WWl0wPiU8Sleq2tJT22Drs5dvuPFoQPH7qiGLd4ucj85OScz R3mNkIVS7+szCxYGbMm37TCJKmxZdupESKWAR7LHBvu5KlerlxUJqOqUXJ01IaZ0u43s8UyN aIZDUdFKLMUZiYZazEXFiQC4+DT48AIAAA== Archived-At: Subject: [saag] EAP - TLS 1.3 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 05:16:31 -0000 --------------ms060203040909000608070202 Content-Type: multipart/alternative; boundary="------------13B46F11EA805B7B309F12A7" Content-Language: en-US This is a multi-part message in MIME format. --------------13B46F11EA805B7B309F12A7 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Bernard, Coming back to our motivation for this draft. 3GPP has decided that=20 authentication in 5G can be done with any type of credential that the=20 operator accepts and that EAP will be used for authentication. The=20 working assumption is that EAP-TLS will be used for mutual=20 authentication with certificates. 3GPP would likely want to use TLS 1.3=20 as much as possible, especially for EAP-TLS, as TLS 1.3 reduces the=20 numbers of roundtrips in EAP-TLS as well as providing encryption of the=20 handshake including the certificates. If the EAP community decides that RFC5216 adequately describes how to=20 use TLS 1.3 and does not need an update we can live with that. Our=20 conclusion is however that an update of RFC2516 is needed for several=20 reasons: * RFC5216 is very much tied to the message flows and message formats in TLS 1.0 - 1.2. The message flows and message content in TLS 1.3 is very different. While a developer could theoretically figure out how to use EAP-TLS with TLS 1.3, such an implementation would not follow RFC5216 and in the worst case, implementations would not even be compatible. * TLS 1.3 makes major changes to the Key Schedule. The PRF in TLS 1.0 is 1.2 is replaced with a HKDF. Our understanding is that an update defining the Key Hierarchy in terms of the TLS-Exporter (similar to what is done in draft-ietf-quic-tls) is needed. * RFC5216 specifies that "EAP-TLS implementations MUST support TLS v1.0= ". * RFC5216 specifies that cipher suites with 3DES, SHA-1, RC4, CBC, and MD5 are mandatory-to-implement for EAP-TLS (i.e. not based on the TLS version). If IETF does not provide new message flow diagrams for EAP-TLS with TLS=20 1.3, it is likely that 3GPP will do that, we would much rather see an=20 IETF RFC that 3GPP and other can refer to. John and Mohit On 10/30/2017 10:37 AM, Bernard Aboba wrote: > RFC 5216 only insists on support (not use) of TLS 1.0 and its=20 > mandatory ciphersuites in order to ensure interoperability with legacy = > implementations and avoid an Internet-wide =E2=80=9Cflag day=E2=80=9D r= equiring=20 > millions of hardware devices to be replaced. But if a site wants to=20 > impose a TLS version (and ciphersuite) policy, it can. > > Mandatory to support algorithms apply to a TLS version, so EAP-TLS=20 > inherits them when that version is negotiated. Similarly, EAP-TLS=20 > inherits features of each TLS version - all it does is tunnel TLS. > > Given this, I am puzzled as to why it is being proposed that RFC 5216=20 > be recycled at Proposed in a non-backward compatible manner with vast=20 > new IPR encumbrance, completely new authors, and nearly identical=20 > text, rather than being left alone or moving to the next standards leve= l. > > > > > > > > On Oct 29, 2017, at 5:20 PM, Jim Schaad > wrote: > >> There is one advantage that can be obtained by using TLS 1.3, if you=20 >> want to hide the client name then it is no longer necessary to do an=20 >> anonymous connection followed immediately by a re-negotiation with=20 >> the proper client certificate.=C2=A0 But that and perhaps mandatory=20 >> algorithms is the only think I can think of right off the bat. >> >> Jim >> >> *From:* saag [mailto:saag-bounces@ietf.org] *On Behalf Of *Bernard Abo= ba >> *Sent:* Sunday, October 29, 2017 3:59 PM >> *To:* Randy Bush > >> *Cc:* Mohit Sethi > >; Security Area Advisory Group=20 >> > >> *Subject:* Re: [saag] [Reap] PSA: New list for discussing EAP related = >> methods >> >> Randy asked: >> >> "bernard, for the clueless here, what change is needed for tls 1.3?" >> >> and >> >> [BA] None as far as I know. EAP-TLS makes use of TLS version=20 >> negotiation so it is both forward and backward compatible. So far,=20 >> implementations of RFC 5216 based on TLS 1.3 have not demonstrated=20 >> any EAP-related issues, as far as I am aware. >> >> In general, EAP-TLS can leverage TLS policies the administrator=20 >> chooses to impose. So=C2=A0 if the administrator wants to impose a ver= sion=20 >> policy (e.g. TLS versions 1.2 or later) or a ciphersuite policy (e.g. = >> no RC4),=C2=A0 there are a number of EAP servers that can be configure= d to=20 >> support this. >> >> So rather than attempting to impose an Internet-wide TLS version or=20 >> ciphersuite policy (which would impose a huge cost on everyone, given = >> that there are 2+ billion devices supporting EAP-TLS), it makes a lot = >> more sense to let the administrators decide, possibly based on=20 >> guidance from organizations they trust, such as NIST.=C2=A0 This is ho= w=20 >> things have been working for more than a decade. >> >> On Sun, Oct 29, 2017 at 2:07 PM, Randy Bush > > wrote: >> >> > Creating a separate list has real drawbacks and very little in >> the way of >> > benefits. >> >> bernard, for the clueless here, what change is needed for tls 1.3?= >> >> randy >> > > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --------------13B46F11EA805B7B309F12A7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Bernard,
Coming back to our motivation for this draft. 3GPP has decided that authentication in 5G can be done with any type of credential that the operator accepts and that EAP will be used for authentication. The working assumption is that EAP-TLS will be used for mutual authentication with certificates. 3GPP would likely want to use TLS 1.3 as much as possible, especially for EAP-TLS, as TLS 1.3 reduces the numbers of roundtrips in EAP-TLS as well as providing encryption of the handshake including the certificates.

If the EAP community decides that RFC5216 adequately describes how to use TLS 1.3 and does not need an update we can live with that. Our conclusion is however that an update of RFC2516 is needed for several reasons:
  • RFC5216 is very= much tied to the message flows and message formats in TLS 1.0 - 1.2. The message flows and message content in TLS 1.3 is very different. While a developer could theoretically figure out how to use EAP-TLS with TLS 1.3, such an implementation would not follow RFC5216 and in the worst case, implementations would not even be compatible.
  • TLS 1.3 makes major changes to the Key Schedule. The PRF in TLS 1.0 is 1.2 is replaced with a HKDF. Our understanding is that an update defining the Key Hierarchy in terms of the TLS-Exporter (similar to what is done in draft-ietf-quic-tls) is needed.
  • RFC5216 specifi= es that "EAP-TLS implementations MUST support TLS v1.0".
  • RFC5216 specifi= es that cipher suites with 3DES, SHA-1, RC4, CBC, and MD5 are mandatory-to-implement for EAP-TLS (i.e. not based on the TLS version).
=C2=A0If IETF does not provide = new message flow diagrams for EAP-TLS with TLS 1.3, it is likely that 3GPP will do that, we would much rather see an IETF RFC that 3GPP and other can refer to.

John and Mohit=

=C2=A0


On 10/30/2017 10:37 AM, Bernard Aboba wrote:
RFC 5216 only insists on support (not use) of TLS 1.0 and its mandatory ciphersuites in order to ensure interoperability with legacy implementations and avoid an Internet-wide =E2=80=9Cflag d= ay=E2=80=9D requiring millions of hardware devices to be replaced. But if a site wants to impose a TLS version (and ciphersuite) policy, it can.

Mand= atory to support algorithms apply to a TLS version, so EAP-TLS inherits them when that version is negotiated. Similarly, EAP-TLS inherits features of each TLS version - all it does is tunnel TLS.

=
Given this, I am puzzled as to why it is being proposed that RFC 5216 be recycled at Proposed in a non-backward compatible manner with vast new IPR encumbrance, completely new authors, and nearly identical text, rather than being left alone or moving to the next standards level.=C2=A0

=


=


=

=

On Oct 29, 2017, at 5:20 PM, Jim Schaad <ietf@augustcellars.com> wrote:

There is one advantage that can be obtained by using TLS 1.3, if you want to hide the client name then it is no longer necessary to do an anonymous connection followed immediately by a re-negotiation with the proper client certificate.=C2=A0 But that and perhaps mandatory algorithms is the only think I can think of right off the bat.

=C2=A0

Jim

=C2=A0

=C2=A0

From: saag [mailto:saag-bounces@ietf.o= rg] On Behalf Of Bernard Aboba
Sent: Sunday, October 29, 2017 3:59 PM
To: Randy Bush <randy@psg.com>
Cc: Mohit Sethi <mohit.m.sethi@ericsson.com= >; Security Area Advisory Group <saag@ietf.org>
Subject: Re: [saag] [Reap] PSA: New list for discussing EAP related methods

=C2=A0

Randy asked:=C2=A0

=C2=A0

"bernard, for the clueless here, what change is needed for tls 1.3?"

and=C2=A0

=C2=A0

[BA] None as far as I know. EAP-TLS makes use of TLS version negotiation so it is both forward and backward compatible. So far, implementations of RFC 5216 based on TLS 1.3 have not demonstrated any EAP-related issues, as far as I am aware.

=C2=A0

In general, EAP-TLS can leverage= TLS policies the administrator chooses to impose.=C2=A0= So=C2=A0 if the administrator wants to impose a versi= on policy (e.g. TLS versions 1.2 or later) or a ciphersuite policy (e.g. no RC4),=C2=A0 there are a number of EAP servers that can be configured to support this.

=C2=A0

So rather than attempting to impose an Internet-wide TLS version or ciphersuite policy (which would impose a huge cost on everyone, given that there are 2+ billion devices supporting EAP-TLS), it makes a lot more sense to let the administrators decide, possibly based on guidance from organizations they trust, such as NIST.=C2=A0 Th= is is how things have been working for more than a decade.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Sun, Oct 29, 2017 at 2:07 PM,= Randy Bush <randy@ps= g.com> wrote:

> Creating a separate list has real drawbacks and very little in the way of > benefits.

bernard, for the clueless here, what change is needed for tls 1.3?

randy

=C2=A0



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

--------------13B46F11EA805B7B309F12A7-- --------------ms060203040909000608070202 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DMUwggX7MIID46ADAgECAhBcf8Ki080s7KKjg2APnSBWMA0GCSqGSIb3DQEBCwUAMEcxCzAJ BgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5k aXZpZHVhbCBDQSB2MzAeFw0xNzEwMDgxMDAzMjJaFw0yMDEwMDgxMDAzMjFaMGgxETAPBgNV BAoMCEVyaWNzc29uMRYwFAYDVQQDDA1Nb2hpdCBTZXRoaSBNMSkwJwYJKoZIhvcNAQkBFhpt b2hpdC5tLnNldGhpQGVyaWNzc29uLmNvbTEQMA4GA1UEBRMHZXNldG1vaDCCASIwDQYJKoZI hvcNAQEBBQADggEPADCCAQoCggEBAN23/VIr1UI1NLeaFL45vzBE0NglNKyyUQknMqT5zRxm ocJ74fYRJmfHmaQxEYdxp6cCYFxbM2OJOiMN5LRxEQG282Dsjnff6mHXt5wNsMrHZ88poT3X yZCzFBkQF/kswJKu6OD9v1J6WWl9fV2h0QRP0ju+B/H2O3OzioHDP9Qazzr5TMTvmRmXoMfh WXyH/joBaGVyn8SCeRaI0wVGRCKDp93UzdL5o+qGqCUPJQP/2SR/4UoCUTqEtSgh4iCBNAs/ OwhHwbWdU73/EJtsaaOG2fhwMTgWR3KJOIUMyWtRBcO9cIan+82SNgAByR4x2BKIWgFvSPNo GXKn1nOi0W0CAwEAAaOCAcAwggG8MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwudHJ1 c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2My5jcmwwgYIGCCsGAQUFBwEB BHYwdDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggrBgEF BQcwAoY8aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZp ZHVhbGNhdjMuY2VyMCUGA1UdEQQeMByBGm1vaGl0Lm0uc2V0aGlAZXJpY3Nzb24uY29tMFUG A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUM0z7o31aA+qQasQqDc7/Ppn7u5MwHwYDVR0jBBgwFoAUHHsZ npecdqwgPdjc45Fq49stplMwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBCwUAA4ICAQCB 35yJmyIRJUmxQmpYX7hNdQJXxJdIAMzCe+rQsz+0F1zA8xsYn4Rn5m7SVGKbE4ONC+EUHHzQ o1OpA5txlK+IPRMqZTM2cQpAet8Qy2vRqFVd0pFDmPx0Az/SPooz7gnuIaPaCGeXOSSxtSOu rX+7fE2EiE/SuCFKmtsFmwnZH62hDDtzd3XTwmJia/5Ab+8/elAstT5a1cP52SorrkuLPgAB ny/XJzsU3LOQQ37Wm5DMyMPEK+zkBG/+2t1cOGgryvu7Hq14NfkAUZxHMei6Yf2UABNxbapB 4tyxqpZuPZDl1AwRKMGYHPsnywK4PZDdsD6R+O/YCWdfq9Q3MMCT3C6vu38phy1r6QDCVHVI IPdirDfZ2ypbeqHAwkswioykkBTln9DEyaTYMlxb41EYh/3JwUQmuQQ4ozSfcLTwoaQ+M+Z4 1J/n7AARwD7u3Lb2ls+fmvOLrC+tc0pXlvTKspIhpaNC1Cz7sbsjMSbSqBW9PtY+Vex7GB2J zI8fDHTT/8Jx+33cta2BE6mPFeUY2lu12zQiqNVUc9zEQ7WqGz4VTGFZDnzfU2gCAAYsuimf kQJD+Sr2G3wXs38yN1OhWHBuG1fglz0k5URhXMNC8HtRityIm2504ym5GpTrriJ8X1fQDYN1 WlOPvv4xJpfHAz4NMKJKQmCNtfuZ8BNNyTCCBsIwggSqoAMCAQICEFO4foPhnJkok7CbSRzs uOswDQYJKoZIhvcNAQELBQAwNzEUMBIGA1UECgwLVGVsaWFTb25lcmExHzAdBgNVBAMMFlRl bGlhU29uZXJhIFJvb3QgQ0EgdjEwHhcNMTUxMDI3MTIxNjQ2WhcNMjUxMDI3MTIxNjQ2WjBH MQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5M IEluZGl2aWR1YWwgQ0EgdjMwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDs8t8A ALhQ8qe72FS3xpP348GqO9TDRjS0s85eQ7Y0LTLZdmSz2cl+lYqs0zfSTm+7meisbhkqUXkL 7fFzoe4iIZCh/VuYUaW407CZlDCXes4n4TqTSuoklN6uOPhY7EC9ZVbXILlLhRummTdDdxhV W4Leo0awEhfLf98MvWxzwCHzMj8m6YOmNjx+f9TcJE3qaA0piuvSxlfpVdiCulPTlmsmV2RS BSAwqBshZYRcQBIDfqmdvkaoP9EzNKAh7yjthC0hpgHZyZMIs0eNo4v2PUmE0rhu+Zs0nujn whljPA2/8b8v9tGixD1zbtT7zoM2Ot1menJpFp4zJVSfdKVgtoWqg5t2H/E0XY1LwJez89W0 7nscEocyBmpC+zJAmKxKhzEWqIyP1UrZaEIFu+hO+s0Nm8sOUMa4TlG4rAUikc5U5TmUIGBR QGxulYhfAzqSYf8oLUMLky1DOa9eRu3sp0FdQDEzQlnF/h1L4AK1MOkX1vS+fLgOvBo5LRU1 fLPUZQ7FKrDXC6nl2ldvEtljHWstGBmqv25aEvAA+yrrplCh/kYvSBjvZibz9Obbwx4yqS77 /NHN1iyZyVP2s52B2BLdvo4yhzk6nRk8S/8zHaUUkBUrrvijPDaGK5FNVSaioGvkC7IKioIT KffYLtT9XuirKrHlh3VzkazG46pAVwIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAt BggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUF BzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25l cmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQB gg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFz b25lcmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVs aWFzb25lcmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUF BwMCBggrBgEFBQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFBx7GZ6XnHasID3Y3OOR auPbLaZTMB8GA1UdIwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBCwUA A4ICAQBQWGvx1Yw7tC6rV0PIjKfDyxaanIX+NZLEGOkdQLKGW2gVLtDUJQEPRs5QtaZiObNH CZ7mmSNMVek4lkt/0dqfVIFutVw/QkyFGwC99ZmNwXSX9z+OoMyoEBHGvw5RY6vRlZrj0uKv dASzYL4KMaB7m3NwurNDmmNbG52suRIZ76wBOEOddRZcZiTy50ZkBqYnnl2t3D3oBX2NZCQy sshUcqRdUbkS13HTCIChMuTV9W0tzPXUOJoJlJlU9nd91IikhGEOrPwfixWms+C8sF0r9qN1 uJGx6ELPOiFrLfNtcMNMMbAqRHwpSLxe3wcNkJGxv9T8LswLi1UrRIQ85AKjqzBnLSsjRGgb MgJ+xKtngmvEA155JmoKfUD7DRbP6Kp14/Y9XFbR/WuDj84bYNKXe4HdDc1P+UMYm16m2L6L kIIoRlx0A5mi+K7jewuGqzFKkaPNmJ0RLCi+4d4/47Zs3DC3PUNOxdOEEHf4kkdWOaSIuj3T QYhNv+LsgF0uijiBmaz2zUFDa2bcIkKakDZfAFM4HoHz8K2BZRaHKWhd3dZua/tlSiqokUFX 2DxmHmZ1n5HM9OiaAIXP/Zo2x10j/Yb1mM3i0bqGahxlHYzl/QyEG/dujp3lewuVjCI0mPDk ZGphvxyqp4Jo8qS94EnOqBvxOgftYug7OY9EKY+WkDGCAzswggM3AgEBMFswRzELMAkGA1UE BhMCU0UxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlk dWFsIENBIHYzAhBcf8Ki080s7KKjg2APnSBWMA0GCWCGSAFlAwQCAQUAoIIBsTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzExMTYwNTE2MjFaMC8GCSqG SIb3DQEJBDEiBCBZDJovbASejCQ3AoMT0bttu32tYZrM4qS/yjOnYz+ONzBqBgkrBgEEAYI3 EAQxXTBbMEcxCzAJBgNVBAYTAlNFMREwDwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJp Y3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MwIQXH/CotPNLOyio4NgD50gVjBsBgkqhkiG9w0B CQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcN AwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMGwGCyqGSIb3 DQEJEAILMV2gWzBHMQswCQYDVQQGEwJTRTERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMM HEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjMCEFx/wqLTzSzsoqODYA+dIFYwDQYJKoZI hvcNAQEBBQAEggEASn0I6VhWuI7CflZ1EUvWZlno6QTRz3MlVxdQAg/wyqqPm6n/CuMKS4Ej sGN3cI/C8suiRurST6xIz16wNs9XHlEY8R6R955bSZ0x/A+d/I7193wldYmunq1bR+hLWjZs cQsLNFCuYkH/iQycRejCOzW/fERuNiz0C5kx8CgmRxBS+HsZXy60IsswpkudZaYhyxVv+SfC 0ePuHiBj9wWXQI46zEk8IGghz/WPY+B9BZShqShWx+zt2JLluciKWbel39Q7zVpaLn/BJ9Kf R7ed3/QGg4Y+HGXL7jZwsmnSJP5w/q0ahcX1Ptyg1fevpjerjIgkYY+PPWAfQ6Q/+nfvTwAA AAAAAA== --------------ms060203040909000608070202-- From nobody Wed Nov 15 21:21:05 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E631201F2 for ; Wed, 15 Nov 2017 21:21:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 xXWnjqOwKlIV for ; Wed, 15 Nov 2017 21:21:01 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (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 D1C8B127076 for ; Wed, 15 Nov 2017 21:21:00 -0800 (PST) Received: from [192.168.91.208] ([31.133.155.188]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LlVZv-1enikH081f-00bIpC for ; Thu, 16 Nov 2017 06:20:58 +0100 To: saag From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <8c760065-1aac-15a7-92c0-f3e01465d85c@gmx.net> Date: Thu, 16 Nov 2017 06:20:55 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:ziMf473OzwJSEDbRcoKhBeBWQ14zLK/kxd4DT025FCB1svdbvmX hB4f9L3MHycGQwIZ20rqxwCQYATzwRnsBZ0QnAPQ1JqjjULkuBfU9mt3pxcoRjnMbu2HE3C VCWceDKl0PWFvG71ixIVxjPLEnQx77zjt7jZAoA/eG28p3g7/4ucrB6o7F+3VeqUmS0VOaW n71C48PBQoZCTzG9w2eSg== X-UI-Out-Filterresults: notjunk:1;V01:K0:FIaKWtVHdqE=:14R5ouFYvj9aAzVuIo1vZN fTDeD4NvQUuLTyyP+hi4WtBrpjJjaZ9zIn3iKxrF0D6Z0gQrS7PB9sfJm0TOPiwzl97W3R91t QfuQPmbnLgRLRlffZhFtGlS7kYfh3CQ6LF9yTlhSIA9AH7wYWEpeUcbGq7J00PJ2HypHoQPtu ZId1pQSN6S/c8xgGSJRzlWOBBp3XeBltKqOAkgcNsp5XRkFBnwr+f6BVNQObLFQofjDW3qPWv P8hBJW/VBfBglMVUU60ECx/HrLLf4dhpyTgdEFmrMkBBmiZZXbfU52SFYkYWE3nfrn1WOKrXt YqovwWxJnLqW9szXYVlKtUo0gtPOCqG7z3HspplRKfA6D/RP8MvRrsHvAk6DHJHVMWWcowZb1 XwuaiUZgdG025BtEt+qfBYhXcJhdCLlHhRBcbXnObq2U7bfPf1oTObrSsWiMj5H5/VJQDuUkw tgHDtUZVkGiax/Ge8OfZdXIk3Pibu13os+ILnIPFpCH9AItBSar+8ACevM1714tggcKLUt1VG hfXrsTNavQDf5szKuemzAPYLDEQq7txP/n7paKnQuOIZ/EfOjqTjCNgeUpkeYZdbRVnxhvbF5 rF2XUhhTogCzvTezWlOcq1PvHZsBPIOf755OIm2iqDt6XD/mhMTQuLhYKbLcTwTZbbY10vy+G cYoitAjvBcbuXYjKSf+slXVv3LtLhd4MccW64WhI8PBjUo3F1e5jDff71BnpFieIx2kkLuJOG y50L1CpaackMII5dscAjqiYouiYBwtISx0sRt21lucHcqc1UuI+nBceRlG/yjg6wLd+GV8wv5 iBGPnP/kZLniHeEO6BwQG0n3OdSfgeYJYyot44tZy3p1zEugsE= Archived-At: Subject: [saag] IETF#100 OAuth WG Meeting Report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 05:21:03 -0000 The OAuth working group met twice this week. The key points of the meetings were: * We have a document (see draft-ietf-oauth-security-topics-03) that offers recommendations on OAuth security topics and we are seeking input on these recommendations. * We are finalizing the OAuth Device Flow work, which is used by devices that have limited UI capabilities. Another WGLC will follow soon. * We are looking for crypto experience on the JWT BCP, see draft-ietf-oauth-jwt-bcp-00. * For the OAuth 2.0 Token Binding we are looking for implementation experience. * Several new items were proposed: - a way for a user to pair protected resources that would like to request access to each other in draft-hardt-oauth-mutual-00 - a way for the OAuth client to discovery what authorization server to use with a given resource server in draft-hardt-distributed-oauth - A solution for conveying attestation information to an authorization server in draft-wdenniss-oauth-device-posture - The use of PSK and RPK-based proof-of-possession tokens in draft-erdtman-ace-rpcc - The use of the DNS for identity management in draft-bertola-dns-openid-pidi-architecture-00 The group expressed interest to work on the first two items. Further discussion and experimentation on the other ideas is needed. From nobody Wed Nov 15 21:23:48 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68BE7127010 for ; Wed, 15 Nov 2017 21:23:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1S0l18m8RXI for ; Wed, 15 Nov 2017 21:23:46 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::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 EB1E41201F2 for ; Wed, 15 Nov 2017 21:23:45 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id r12so3017427pgu.10 for ; Wed, 15 Nov 2017 21:23:45 -0800 (PST) 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=APyoi2iUagdJw1un+53BlQhLkADCT+EnPTVnSgiSfwI=; b=pb6I+OcAd+APenGNTtARWncfyOQyH6vqfgx/KWhPb9XFf+uzA2MELm9xkGGx4lHwYV vjOGv3090nBgsXOcMjFW/vjGUsX6CZF3RC+pVtuv5+Dnc+ZTiGkw17W1V6sjrzRR2FHL cOPQI/PVwlIoTWuzi4nkQos62w2ljcpdGxkyNBmfWS2ZHIYDBHv/pNINPAAi1v2zblW+ JNmxktrQmkT8F8LuUAoHgPq2bUE9QcuqhdCx79jNjACnGjAMuUv3JUuitFmPdeENe36c ia7YeW8Y7yy5LQFJGwUU6GN9M40nGUfWPqNBq9rG044yEj/REa2d00vi3BP+lzvlW/+W 8GAg== 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=APyoi2iUagdJw1un+53BlQhLkADCT+EnPTVnSgiSfwI=; b=P4iKgReEW55SP4z38E1W5UCru7XjiH0Xh3k4Pwo1WReNqQKKLkVoI/u4rqaiZZbYB5 U+AxhDFY/43ESlpwR4ZA8qYCa+6ZXf87g0kUTLZ4nxdMy2DTTRymz6OSp79Y+2z7yShJ s1qEPsdkWxFEj7fYKlTNPAN/LyG6SGoxXtTnqWcgsBJEgRDnvb2aRFvanZtxYWRpYg/A fiF3AqAhghP2srTMazNwPY6Q+xUD7xTvS2hziq0MhdeYTDdCjZukf7DUiXbQ2go+07/4 ztO3i31nzi83HPvNjajMxZrqYHWLpNaTnr4y0Un7E36vBPFccfYnJn3ViksodY1duN4j zwlQ== X-Gm-Message-State: AJaThX7nXneh6thNwEdlQTW6h2Vi+7z62IQDXPKBTGncK/eU5uXxyBgT M5bwNkhQNN25JAluEQgb+hOVPcLX X-Google-Smtp-Source: AGs4zMY6eYU9ahOmjIpeLbeTVhxF3euHctIldDJSEZ2GLBSNTQiRy603IYSTS7pvNYsAWKua0mn5RQ== X-Received: by 10.101.64.11 with SMTP id f11mr514705pgp.217.1510809825265; Wed, 15 Nov 2017 21:23:45 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:14ed:d0a0:75f2:305e? ([2001:67c:370:128:14ed:d0a0:75f2:305e]) by smtp.gmail.com with ESMTPSA id c8sm679970pfm.47.2017.11.15.21.23.43 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Nov 2017 21:23:44 -0800 (PST) From: Yoav Nir Content-Type: multipart/signed; boundary="Apple-Mail=_DE79584C-C4CE-4522-B0E2-F8BF424E71FD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Message-Id: <49D6362A-7A3B-48A9-87BC-29B52690EF90@gmail.com> Date: Thu, 16 Nov 2017 13:24:19 +0800 To: Security Area Advisory Group X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: [saag] I2NSF@IETF100 SAAG Report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 05:23:47 -0000 --Apple-Mail=_DE79584C-C4CE-4522-B0E2-F8BF424E71FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii The I2NSF Working Group met on Tuesday. The group is making progress and = converging on the various model documents. On Wednesday a design team consisting of most of the authors met to work = on this (much needed) convergence. Yoav & Linda --Apple-Mail=_DE79584C-C4CE-4522-B0E2-F8BF424E71FD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEE9OWnAqT2UIzvSbaAuEkLFQpYzJkFAloNIQQACgkQuEkLFQpY zJlypwf9FsI2Cmm7fpEEQSORu1JDlRiPvnz06x/Wmn0BlMvPAlnWYlNCb3YSCLoz sQI/fVgUoUyApk/KmCOZoOHevFAgdHubdRLQw/1hJbXzbiFU77nio0S/nIYeSmsA x7Uwbsv4qI82AiCSAlUuLZBQwIpVl2lKBCEyCJAScpbdjwghLh2V/fGex59CJ3Yt MZa5tUREAibpX3lhZ2+4jXldnO4lvUpJMJDBzWggFvhY5uqi8D23UNMjxU1NCnBZ 5HpcpkPZDR+LqW+uN8RjG2SDR5HX36NB88t20f6kehI8qy+/T8z7zxuQZHbARJ9A GZObD/Zb+pP79mjI8P10yse90yZV6A== =1j6T -----END PGP SIGNATURE----- --Apple-Mail=_DE79584C-C4CE-4522-B0E2-F8BF424E71FD-- From nobody Wed Nov 15 21:34:30 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A99212421A for ; Wed, 15 Nov 2017 21:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 NVJkReDNKbve for ; Wed, 15 Nov 2017 21:34:26 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B838E1201F2 for ; Wed, 15 Nov 2017 21:34:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5502; q=dns/txt; s=iport; t=1510810466; x=1512020066; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=BgqIFkEyZN2B65xNiv8JB5Ql4CPkxd9zEMGHx5i74b0=; b=NFmc/pLu6JfbDgJUAWEWmOq7Xy7I5J7mPEj8zU6xn0Pp5y1bRcQz2Iu+ Ejg9HpPlFEgDyjbYgWGqEIXNNRr+8+1iAdk3JJ/xxJeTXxhd5nyokZWA7 Ly8QREcozROR7EYxlgjCShqBPLzl3LbbHd6uNWXloF/CnJY0LsAW1C34u g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CuAAAaIg1a/4gNJK0WBUMZAQEBAQEBA?= =?us-ascii?q?QEBAQEBBwEBAQEBgkRyZG4ug3iKH48gkxKFSYIRCoU7AhqEdD8YAQEBAQEBAQE?= =?us-ascii?q?Bax0LhR8GI2YCAUoCAgIwDxYCBIlTZIUZpDSCJyaKbQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAR2DNIIHgz4phC+GfzGCMgWZHokZApUEk0SWAQIRGQGBOAEfOIF0ehV?= =?us-ascii?q?JLQGCN4ReixKBEQEBAQ?= X-IronPort-AV: E=Sophos;i="5.44,402,1505779200"; d="scan'208,217";a="319400751" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Nov 2017 05:34:25 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id vAG5YPBG020508 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 16 Nov 2017 05:34:25 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 16 Nov 2017 00:34:24 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Thu, 16 Nov 2017 00:34:24 -0500 From: "Nancy Cam-Winget (ncamwing)" To: "saag@ietf.org" Thread-Topic: TEEP report Thread-Index: AQHTXpxGVhEPZoVSg0678ed9V+Ug9aMWSXwA Date: Thu, 16 Nov 2017 05:34:24 +0000 Message-ID: References: <901D30EB-2889-4DB3-AE0E-F568468FDC76@cisco.com> In-Reply-To: <901D30EB-2889-4DB3-AE0E-F568468FDC76@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1a.0.160910 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.95.250] Content-Type: multipart/alternative; boundary="_000_C54FD317C69D44BE9F505DDEA84F7A6Bciscocom_" MIME-Version: 1.0 Archived-At: Subject: [saag] TEEP report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 05:34:28 -0000 --_000_C54FD317C69D44BE9F505DDEA84F7A6Bciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpURUVQIG1ldCB5ZXN0ZXJkYXksIFdlZCBTZXNzaW9uIEkuDQoNClRoZSBDaGFpcnMgcHJlc2Vu dGVkIHRoZSBwcm9ibGVtIHN0YXRlbWVudCBhbmQgcHJvcG9zZWQgY2hhcnRlciBjcmFmdGVkIGF0 IHRoZSBsYXN0IHNpZGUgbWVldGluZyBpbiBQcmFndWUuDQpEaXNjdXNzaW9ucyBlbnN1ZWQgb24g dGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gU1VJVCBhbmQgVEVFUCBhcyB3ZWxsIGFzIHBvdGVudGlh bCBvdmVybGFwIGFzIG5vdGVkIGJ5IHR3byBHbG9iYWwgUGxhdGZvcm0gcmVwcmVzZW50YXRpdmVz Lg0KDQpBIHBvc2l0aXZlIGh1bSB3YXMgZ2l2ZW4gYnkgdGhlIGdyb3VwIGluIHRoYXQgdGhlIElF VEYgc2hvdWxkIGRvIHNvbWUgd29yayBhcm91bmQgdGhpcyBzcGFjZS4NClRoZSBjaGFpcnMgd2ls bCBjYXVjdXMgd2l0aCB0aGUgc2VjdXJpdHkgQURzIGZvciBmdWxsIHByb2Nlc3MgaW4gY2hhcnRl cmluZy4NCg0KRnVydGhlciBkaXNjdXNzaW9uIGluIHJlZmluaW5nIHRoZSBjaGFydGVyIHdpbGwg YWxzbyBjb250aW51ZSBvbiB0aGUgbGlzdC4NCg0KICAgICAgICAgICAgICAgIE5hbmN5Lg0K --_000_C54FD317C69D44BE9F505DDEA84F7A6Bciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <02E8E5FB39FC0243AF64584CA5CF5820@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseTpD YWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0K CW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6 dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBp bjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xv cj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPlRFRVAgbWV0IHllc3RlcmRheSwgV2VkIFNlc3Npb24gSS48L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoZSBDaGFpcnMgcHJlc2VudGVkIHRo ZSBwcm9ibGVtIHN0YXRlbWVudCBhbmQgcHJvcG9zZWQgY2hhcnRlciBjcmFmdGVkIGF0IHRoZSBs YXN0IHNpZGUgbWVldGluZyBpbiBQcmFndWUuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkRpc2N1c3Npb25z IGVuc3VlZCBvbiB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiBTVUlUIGFuZCBURUVQIGFzIHdlbGwg YXMgcG90ZW50aWFsIG92ZXJsYXAgYXMgbm90ZWQgYnkgdHdvIEdsb2JhbCBQbGF0Zm9ybSByZXBy ZXNlbnRhdGl2ZXMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5B IHBvc2l0aXZlIGh1bSB3YXMgZ2l2ZW4gYnkgdGhlIGdyb3VwIGluIHRoYXQgdGhlIElFVEYgc2hv dWxkIGRvIHNvbWUgd29yayBhcm91bmQgdGhpcyBzcGFjZS48L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhl IGNoYWlycyB3aWxsIGNhdWN1cyB3aXRoIHRoZSBzZWN1cml0eSBBRHMgZm9yIGZ1bGwgcHJvY2Vz cyBpbiBjaGFydGVyaW5nLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+RnVydGhlciBkaXNjdXNzaW9uIGluIHJlZmluaW5nIHRoZSBjaGFydGVyIHdpbGwgYWxzbyBj b250aW51ZSBvbiB0aGUgbGlzdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBOYW5jeS48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_C54FD317C69D44BE9F505DDEA84F7A6Bciscocom_-- From nobody Wed Nov 15 21:37:17 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8895B127058 for ; Wed, 15 Nov 2017 21:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 zCvL1s4Ot5pw for ; Wed, 15 Nov 2017 21:37:14 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3E03F12741D for ; Wed, 15 Nov 2017 21:37:01 -0800 (PST) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 2809BA15786CE for ; Thu, 16 Nov 2017 05:36:58 +0000 (GMT) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 16 Nov 2017 05:36:59 +0000 Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.92]) by SJCEML701-CHM.china.huawei.com ([169.254.3.246]) with mapi id 14.03.0361.001; Wed, 15 Nov 2017 21:36:57 -0800 From: Linda Dunbar To: "saag@ietf.org" Thread-Topic: I2NSF WG Report Thread-Index: AdNenOdsT19H370hRam11etlN74zlA== Date: Thu, 16 Nov 2017 05:36:56 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F66AFCF9C8@sjceml521-mbs.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.33.30] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [saag] I2NSF WG Report X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 05:37:15 -0000 DQpLYXRobGVlbiwgDQoNCkkyTlNGIG1ldCBvbiBUdWVzZGF5IGFmdGVybm9vbi4gV2UgaGFkIDIg c2VwYXJhdGUgc2lkZSBtZWV0aW5ncyB0byBnbyB0aHJvdWdoIGRpc2NyZXBhbmNpZXMgYW1vbmcg aW5mb3JtYXRpb24gbW9kZWwgYW5kIGRhdGEgbW9kZWwgZHJhZnRzLiANClRoZSBXRyBkZWNpZGVk IHRvIGZpcnN0IGNvbXBsZXRlIHRoZSBJMk5TRiBjYXBhYmlsaXR5IGluZm9ybWF0aW9uIG1vZGVs LCBzZWNvbmQgdG8gaGF2ZSBOU0YgZmFjaW5nIERhdGEgTW9kZWwgYWxpZ25lZCB3aXRoIHRoZSBD YXBhYmlsaXR5IGluZm9ybWF0aW9uIG1vZGVsLCBhbmQgdGhpcmQgdG8gd29yayBvbiB0aGUgQ2xp ZW50IGZhY2luZyBkYXRhIG1vZGVsLiANCg0KTGluZGEgJiBZb2F2DQoNCi0tLS0tT3JpZ2luYWwg TWVzc2FnZS0tLS0tDQpGcm9tOiBLYXRobGVlbiBNb3JpYXJ0eSBbbWFpbHRvOmthdGhsZWVuLm1v cmlhcnR5LmlldGZAZ21haWwuY29tXQ0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDE2LCAyMDE3 IDExOjAzIEFNDQpUbzogc2VjLWNoYWlyc0B0b29scy5pZXRmLm9yZw0KU3ViamVjdDogUmU6IFdH IHJlcG9ydHMNCg0KSWYgeW91IHVwZGF0ZWQgdGhlIFdHIHN0YXR1cyBpbiB0aGUgZGF0YXRyYWNr ZXIsIGNhbiB5b3Ugc2VuZCBFS1IgYW5kIEkgYSBub3RlPyAgV2UgZG9uJ3QgZ2V0IG5vdGlmaWVk IGFuZCBJIGtub3cgU3RlcGhlbiBhbmQgSSBzdWdnZXN0ZWQgdGhpcyBpcyBhIGJldHRlciB1cGRh dGUgbWV0aG9kIGFzIGl0J3MgZWFzaWVyIHRvIGZpbmQgdGhlIHN0YXR1cyByZXBvcnRzLg0KDQpJ cyBhbnlvbmUgaW50ZXJlc3RlZCB0byB3b3JrIGF0IGEgY29kZSBzcHJpbnQgdG8gaGF2ZSB0aGUg dXBkYXRlZCBzdGF0dXMgZ2V0IHNlbnQgdG8gU0FBRyBmb3Igb3VyIFdHcyBhbmQgcmVsYXRlZCBv bmVzPyAgVGhpcyB3b3VsZCBoYXZlIHRvIHdvcmsgZm9yIG90aGVyIGFyZWFzIGFzIHdlbGwgYW5k IHRoZSBhYmlsaXR5IHRvIHNlbmQgcmVwb3J0cyB0byBtdWx0aXBsZSBhcmVhcyBpZiB0aGUgV0cg aXMgY3Jvc3MgYXJlYS4gIFllcywgdGhhdCByZWxpZXMgb24gYW5vdGhlciBmaWVsZCBiZWluZyBh ZGRlZCB0aGF0IHNob3dzIGFkZGl0aW9uYWwgYXJlYXMgKGNvdWxkIGJlIG1vcmUgdGhhbiBvbmUp IHRoYXQgYSBXRyBmaXRzIGludG8uDQoNClRoYW5rcywNCkthdGhsZWVuDQoNCk9uIFdlZCwgTm92 IDE1LCAyMDE3IGF0IDk6MjMgUE0sIEthdGhsZWVuIE1vcmlhcnR5IDxrYXRobGVlbi5tb3JpYXJ0 eS5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQo+IEhlbGxvLA0KPg0KPiBQbGVhc2Ugc2VuZCBpbiB5 b3VyIFdHIHJlcG9ydHMgdG8gdGhlIFNBQUcgbGlzdC4gIFdlIGFyZSByZWFsbHkgdGlnaHQgDQo+ IG9uIHRpbWUgZm9yIHRoZSBTZWNEaXNwYXRjaCBleHBlcmltZW50IGFuZCBldmVyeSBtaW51dGUg d2UgY2FuIHNhdmUgDQo+IHdpbGwgYmUgaGVscGZ1bC4NCj4NCj4gLS0NCj4NCj4gQmVzdCByZWdh cmRzLA0KPiBLYXRobGVlbg0KDQoNCg0KLS0gDQoNCkJlc3QgcmVnYXJkcywNCkthdGhsZWVuDQo= From nobody Wed Nov 15 22:12:55 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A761294D8; Wed, 15 Nov 2017 22:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.493 X-Spam-Level: X-Spam-Status: No, score=-0.493 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, SUBJ_ALL_CAPS=1.506] autolearn=no 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 HmVIdAPy1uI9; Wed, 15 Nov 2017 22:12:51 -0800 (PST) Received: from mail-ua0-x22c.google.com (mail-ua0-x22c.google.com [IPv6:2607:f8b0:400c:c08::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 510BF129521; Wed, 15 Nov 2017 22:12:51 -0800 (PST) Received: by mail-ua0-x22c.google.com with SMTP id f14so7877688uaa.5; Wed, 15 Nov 2017 22:12:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ShP3e3tUxe2Mt0Jg+VAaS8zAl4mfnisRhQqnBeYACMQ=; b=bC5Oj94BsIr/O8FKFDTWDis/8GWO4imDKzUvBnbEnbvSugHpxqe0Bhom7EpU5Ck8ne Em5npfOBvDOUTU6EbNYlgWnhkv5SqIl24g9EQQgaJ96b/HjDj379ffsuqwVac5fPWnoJ vwoTtAaOPK8YN5SVxhj1qi/wcpEYPcL93IBhK2oeDs+vPBDUDDEyQ9Edxn7SAY0XVdno on87CiGP6W8LyWZIjV5Ba2CGwcShg/wIJYxowChBqSs8JnZAcWl8YffxoOGDtKLpen+0 JN7RwwuSozmLCUKejLdpXwozirhreFcXwmj2d4OgEhu5vWqM8hVhwLQs+f+g7XCmnP60 JeGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ShP3e3tUxe2Mt0Jg+VAaS8zAl4mfnisRhQqnBeYACMQ=; b=PQrrgU6YOqQn+ZwMxpn7OJ/IkiAtHsrWFzjbC8Q2cSnuq0MvVgZJJklIXclBtDugcB kNr2mAqVNV7jlxHsDHI5nrHLQaAY2rwFMEDcD+fqqisDcuqsoDF7js7REMmbGpeU9hlv +AraxWhnsQZmM9eNG+DEg6L9eWQ03kSdzLFoGpDw1UVgJWoTdBLCH05VsiRbqC8O/sUe e0p3bnA1CjPA2BJldThWi74pATNQvlknCb6RoqQmzfi+jT22olxtselC0c/7Ad0vxiDu 18s+VPloWTUURkh4z9SoGsraSSmSc1Hp6INHlpV0PG476FLsdbwJnScogkf3Wf+VSv3K x9+g== X-Gm-Message-State: AJaThX52qXTYEi+ln/AfqMCr7rk++1E0ncrgepsC/leTKVGL0vmsbcbm o/o0X+5JSE8IuUD3DPDKeZG3AjRG69/gK9YmMzo= X-Google-Smtp-Source: AGs4zMbpS3Lszz06wLVp8a4NdSFeLak/EkMixO4Bs4Zd1CO9s2vaFDsiRMBTh6SKuWA5YCJU+eApQz/Ztc/wVXrQy4w= X-Received: by 10.176.20.225 with SMTP id f30mr447813uae.66.1510812770197; Wed, 15 Nov 2017 22:12:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.38.130 with HTTP; Wed, 15 Nov 2017 22:12:29 -0800 (PST) In-Reply-To: References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com> <4c6c9bc8-6056-c03d-a0f6-f1f32fabef39@ericsson.com> <00d401d35114$de589760$9b09c620$@augustcellars.com> <8D84F942-5D10-4DB8-8EB7-3EB8A8AEE17E@gmail.com> From: Bernard Aboba Date: Wed, 15 Nov 2017 22:12:29 -0800 Message-ID: To: Mohit Sethi Cc: Jim Schaad , Security Area Advisory Group , emu@ietf.org, reap@ietf.org Content-Type: multipart/alternative; boundary="001a1145ab007d661f055e138206" Archived-At: Subject: Re: [saag] EAP - TLS 1.3 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 06:12:54 -0000 --001a1145ab007d661f055e138206 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable - RFC5216 is very much tied to the message flows and message formats in TLS 1.0 - 1.2. [BA] EAP-TLS encapsulates TLS within EAP so the basic protocol flow is not version dependent. The (non-normative) examples were designed to illustrate the EAP-TLS protocol flow, so though they are based on TLS 1.0/1.1 (1.2 came later) that doesn't affect the protocol. - The message flows and message content in TLS 1.3 is very different. While a developer could theoretically figure out how to use EAP-TLS with TLS 1.3, such an implementation would not follow RFC5216 and in the wors= t case, implementations would not even be compatible. [BA] While the TLS protocol changes with version 1.3, the basic flow of the EAP conversation (and EAP-TLS) does not change - it's just a tunneling protocol that takes TLS blobs and encapsulates them in EAP. As a result, there are already experimental implementations of EAP-TLS based on version 1.3 that required minimal code changes in EAP-TLS. Do you have an implementation of EAP-TLS that supported earlier versions? - TLS 1.3 makes major changes to the Key Schedule. The PRF in TLS 1.0 is 1.2 is replaced with a HKDF. Our understanding is that an update definin= g the Key Hierarchy in terms of the TLS-Exporter (similar to what is done = in draft-ietf-quic-tls) is needed. TLS 1.3 Section 7.3 defines how the keys are calculated - and so the TLS-Exporter changes should be straightforward. - RFC5216 specifies that "EAP-TLS implementations MUST support TLS v1.0"= . [BA] Support for TLS v1.0 is required for backward compatibility. EAP-TLS has been deployed on over 2+ billion systems and is supported by a hardware ecosystem. Many of those existing implementations would be broken if the requirement to support TLS v1.0 were to be removed. So while any organization can decide they only want to allow a given version of TLS, the requirement to support 1.0 must remain. - RFC5216 specifies that cipher suites with 3DES, SHA-1, RC4, CBC, and MD5 are mandatory-to-implement for EAP-TLS (i.e. not based on the TLS version). Those ciphersuite choices were based on the need for backward compatibility. An organization mandating more advanced versions of TLS will automatically inherit the mandatory ciphersuites of those versions. So this doesn't preclude interoperability of EAP-TLS 1.1, 1.2, 1.3 or any future version of TLS. On Wed, Nov 15, 2017 at 9:16 PM, Mohit Sethi wrote: > Hi Bernard, > > Coming back to our motivation for this draft. 3GPP has decided that > authentication in 5G can be done with any type of credential that the > operator accepts and that EAP will be used for authentication. The workin= g > assumption is that EAP-TLS will be used for mutual authentication with > certificates. 3GPP would likely want to use TLS 1.3 as much as possible, > especially for EAP-TLS, as TLS 1.3 reduces the numbers of roundtrips in > EAP-TLS as well as providing encryption of the handshake including the > certificates. > > If the EAP community decides that RFC5216 adequately describes how to use > TLS 1.3 and does not need an update we can live with that. Our conclusion > is however that an update of RFC2516 is needed for several reasons: > > - RFC5216 is very much tied to the message flows and message formats > in TLS 1.0 - 1.2. The message flows and message content in TLS 1.3 is = very > different. While a developer could theoretically figure out how to use > EAP-TLS with TLS 1.3, such an implementation would not follow RFC5216 = and > in the worst case, implementations would not even be compatible. > - TLS 1.3 makes major changes to the Key Schedule. The PRF in TLS 1.0 > is 1.2 is replaced with a HKDF. Our understanding is that an update > defining the Key Hierarchy in terms of the TLS-Exporter (similar to wh= at is > done in draft-ietf-quic-tls) is needed. > - RFC5216 specifies that "EAP-TLS implementations MUST support TLS > v1.0". > - RFC5216 specifies that cipher suites with 3DES, SHA-1, RC4, CBC, and > MD5 are mandatory-to-implement for EAP-TLS (i.e. not based on the TLS > version). > > If IETF does not provide new message flow diagrams for EAP-TLS with TLS > 1.3, it is likely that 3GPP will do that, we would much rather see an IET= F > RFC that 3GPP and other can refer to. > > John and Mohit > > > > On 10/30/2017 10:37 AM, Bernard Aboba wrote: > > RFC 5216 only insists on support (not use) of TLS 1.0 and its mandatory > ciphersuites in order to ensure interoperability with legacy > implementations and avoid an Internet-wide =E2=80=9Cflag day=E2=80=9D req= uiring millions of > hardware devices to be replaced. But if a site wants to impose a TLS > version (and ciphersuite) policy, it can. > > Mandatory to support algorithms apply to a TLS version, so EAP-TLS > inherits them when that version is negotiated. Similarly, EAP-TLS inherit= s > features of each TLS version - all it does is tunnel TLS. > > Given this, I am puzzled as to why it is being proposed that RFC 5216 be > recycled at Proposed in a non-backward compatible manner with vast new IP= R > encumbrance, completely new authors, and nearly identical text, rather th= an > being left alone or moving to the next standards level. > > > > > > > > On Oct 29, 2017, at 5:20 PM, Jim Schaad wrote: > > There is one advantage that can be obtained by using TLS 1.3, if you want > to hide the client name then it is no longer necessary to do an anonymous > connection followed immediately by a re-negotiation with the proper clien= t > certificate. But that and perhaps mandatory algorithms is the only think= I > can think of right off the bat. > > > > Jim > > > > > > *From:* saag [mailto:saag-bounces@ietf.org ] *On > Behalf Of *Bernard Aboba > *Sent:* Sunday, October 29, 2017 3:59 PM > *To:* Randy Bush > *Cc:* Mohit Sethi ; Security Area Advisory > Group > *Subject:* Re: [saag] [Reap] PSA: New list for discussing EAP related > methods > > > > Randy asked: > > > > "bernard, for the clueless here, what change is needed for tls 1.3?" > > and > > > > [BA] None as far as I know. EAP-TLS makes use of TLS version negotiation > so it is both forward and backward compatible. So far, implementations of > RFC 5216 based on TLS 1.3 have not demonstrated any EAP-related issues, a= s > far as I am aware. > > > > In general, EAP-TLS can leverage TLS policies the administrator chooses t= o > impose. So if the administrator wants to impose a version policy (e.g. > TLS versions 1.2 or later) or a ciphersuite policy (e.g. no RC4), there > are a number of EAP servers that can be configured to support this. > > > > So rather than attempting to impose an Internet-wide TLS version or > ciphersuite policy (which would impose a huge cost on everyone, given tha= t > there are 2+ billion devices supporting EAP-TLS), it makes a lot more sen= se > to let the administrators decide, possibly based on guidance from > organizations they trust, such as NIST. This is how things have been > working for more than a decade. > > > > > > > > > > > > > > > > > > > > On Sun, Oct 29, 2017 at 2:07 PM, Randy Bush wrote: > > > Creating a separate list has real drawbacks and very little in the way = of > > benefits. > > bernard, for the clueless here, what change is needed for tls 1.3? > > randy > > > > > > _______________________________________________ > saag mailing listsaag@ietf.orghttps://www.ietf.org/mailman/listinfo/saag > > > --001a1145ab007d661f055e138206 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
  • RFC5216 is very much tied= to the message flows and message formats in TLS 1.0 - 1.2.
    • [BA] EAP-TLS encapsulates TLS wit= hin EAP so the basic protocol flow is not version dependent.=C2=A0 The (non= -normative) examples were designed to illustrate the EAP-TLS protocol flow,= so though they are based on TLS 1.0/1.1 (1.2 came later) that doesn't = affect the protocol.=C2=A0
    • =C2= =A0The message flows and message content in TLS 1.3 is very different. Whil= e a developer could theoretically figure out how to use EAP-TLS with TLS 1.= 3, such an implementation would not follow RFC5216 and in the worst case, i= mplementations would not even be compatible.
    [BA] While the TLS protocol changes with version= 1.3, the basic flow of the EAP conversation (and EAP-TLS) does not change = - it's just a tunneling protocol that takes TLS blobs and encapsulates = them in EAP.=C2=A0 As a result, there are already experimental implementati= ons of EAP-TLS based on version 1.3 that required minimal code changes in E= AP-TLS. Do you have an implementation of EAP-TLS that supported earlier ver= sions?
    • TLS 1.3 makes major cha= nges to the Key Schedule. The PRF in TLS 1.0 is 1.2 is replaced with a HKDF= . Our understanding is that an update defining the Key Hierarchy in terms o= f the TLS-Exporter (similar to what is done in draft-ietf-quic-tls) is need= ed.
    TLS 1.3 Section 7.3 defines how the = keys are calculated - and so the TLS-Exporter changes should be straightfor= ward.
  • RFC5216 specifies that &= quot;EAP-TLS implementations MUST sup= port TLS v1.0".
[BA] Support for TL= S v1.0 is required for backward compatibility.=C2=A0 EAP-TLS has been deplo= yed on over 2+ billion systems and is supported by a hardware ecosystem. Ma= ny of those existing implementations would be broken if the requirement to = support TLS v1.0 were to be removed.=C2=A0 So while any organization can de= cide they only want to allow a given version of TLS, the requirement to sup= port 1.0 must remain.=C2=A0
  • RF= C5216 specifies that cipher suites with 3DES, SHA-1, RC4, CBC, and MD5 are = mandatory-to-implement for EAP-TLS (i.e. not based on the TLS version).=C2=A0
Those ciphersuite = choices were based on the need for backward compatibility.=C2=A0 An organiz= ation mandating more advanced versions of TLS will automatically inherit th= e mandatory ciphersuites of those versions.=C2=A0 So this doesn't precl= ude interoperability of EAP-TLS 1.1, 1.2, 1.3 or any future version of TLS.= =C2=A0

On Wed, Nov 15, 2017 at 9:16 PM, Mohit Sethi <= mohit.m.set= hi@ericsson.com> wrote:
=20 =20 =20
Hi Bernard,

Coming back to our motivation for this draft. 3GPP has decided that authentication in 5G can be done with any type of credential that the operator accepts and that EAP will be used for authentication. The working assumption is that EAP-TLS will be used for mutual authentication with certificates. 3GPP would likely want to use TLS 1.3 as much as possible, especially for EAP-TLS, as TLS 1.3 reduces the numbers of roundtrips in EAP-TLS as well as providing encryption of the handshake including the certificates.

If the EAP community decides that RFC5216 adequately describes how to use TLS 1.3 and does not need an update we can live with that. Our conclusion is however that an update of RFC2516 is needed for several reasons:
  • RFC5216 is very much tied to the message flows and message formats in TLS 1.0 - 1.2. The message flows and message content in TLS 1.3 is very different. While a developer could theoretically figure out how to use EAP-TLS with TLS 1.3, such an implementation would not follow RFC5216 and in the worst case, implementations would not even be compatible.
  • TLS 1.3 makes major changes to the Key Schedule. The PRF in TLS 1.0 is 1.2 is replaced with a HKDF. Our understanding is that an update defining the Key Hierarchy in terms of the TLS-Exporter (similar to what is done in draft-ietf-quic-tls) is needed.
  • RFC5216 specifies that "EAP-TLS implementations MUST support TLS v1.0".
  • RFC5216 specifies that cipher suites with 3DES, SHA-1, RC4, CBC, and MD5 are mandatory-to-implement for EAP-TLS (i.e. not based on the TLS version).
=C2=A0If IETF does not provide new message flow diagrams for EAP-TLS with TLS 1.3, it is likely that 3GPP will do that, we would much rather see an IETF RFC that 3GPP and other can refer to.

John and Mohit

=

= =C2=A0


On 10/30/2017 10:3= 7 AM, Bernard Aboba wrote:
=20
RFC 5216 only insists on support (not use) of TLS 1.0 and its mandatory ciphersuites in order to ensure interoperability with legacy implementations and avoid an Internet-wide =E2=80=9Cflag day= =E2=80=9D requiring millions of hardware devices to be replaced. But if a site wants to impose a TLS version (and ciphersuite) policy, it can.

Mandatory to support algorithms apply to a TLS version, so EAP-TLS inherits them when that version is negotiated. Similarly, EAP-TLS inherits features of each TLS version - all it does is tunnel TLS.

Given this, I am puzzled as to why it is being proposed that RFC 5216 be recycled at Proposed in a non-backward compatible manner with vast new IPR encumbrance, completely new authors, and nearly identical text, rather than being left alone or moving to the next standards level.=C2=A0







On Oct 29, 2017, at 5:20 PM, Jim Schaad <ietf@augustcellars.com> wrote:

=20 =20 =20

There is one advantage that can be obtained by using TLS 1.3, if you want to hide the client name then it is no longer necessary to do an anonymous connection followed immediately by a re-negotiation with the proper client certificate.=C2=A0 But that and perhaps mandatory algorithms is the only think I can think of right off the bat.

=C2=A0

Jim

=C2=A0

=C2=A0

From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Sunday, October 29, 2017 3:59 PM
To: Randy Bush <randy@psg.com>
Cc: Mohit Sethi <mohit.m.sethi@ericsson.com>; Security Area Advisory Group <saag@ietf.org>
Subject: Re: [saag] [Reap] PSA: New list for discussing EAP related methods

=C2=A0

Randy asked:=C2=A0

=C2=A0

"bernard, for the clueless here, what change is needed for tls 1.3?"

and=C2=A0

=C2=A0

[BA] None as far as I know. EAP-TLS makes use of TLS version negotiation so it is both forward and backward compatible. So far, implementations of RFC 5216 based on TLS 1.3 have not demonstrated any EAP-related issues, as far as I am aware.

=C2=A0

In general, EAP-TLS can leverage TLS policies the administrator chooses to impose.=C2=A0 So=C2=A0 if the administrator wants to impose a version policy (e.g. TLS versions 1.2 or later) or a ciphersuite policy (e.g. no RC4),=C2=A0 there are a number of EAP servers that can be configured to support this.

=C2=A0

So rather than attempting to impose an Internet-wide TLS version or ciphersuite policy (which would impose a huge cost on everyone, given that there are 2+ billion devices supporting EAP-TLS), it makes a lot more sense to let the administrators decide, possibly based on guidance from organizations they trust, such as NIST.=C2=A0 This is how things have been working for more than a decade.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

On Sun, Oct 29, 2017 at 2:07 PM, Randy Bush <randy@psg.com> wrote:

> Creating a separate list has real drawbacks and very little in the way of
> benefits.

bernard, for the clueless here, what change is needed for tls 1.3?

randy<= /span>

=C2=A0



_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/ma=
ilman/listinfo/saag


--001a1145ab007d661f055e138206-- From nobody Thu Nov 16 01:09:01 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12823127369 for ; Thu, 16 Nov 2017 01:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] 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 uei5EoYA38Qv for ; Thu, 16 Nov 2017 01:08:58 -0800 (PST) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id E7723127275 for ; Thu, 16 Nov 2017 01:08:57 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id C75CC3740FDE; Thu, 16 Nov 2017 09:08:57 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id MT1vOoad4ULz; Thu, 16 Nov 2017 04:08:56 -0500 (EST) Received: from dhcp-8b1d.meeting.ietf.org (dhcp-8b1d.meeting.ietf.org [31.133.139.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id ED84F3740C38; Thu, 16 Nov 2017 04:08:55 -0500 (EST) To: "saag@ietf.org" , "Polk, Tim (Fed)" From: "Dr. Pala" Organization: OpenCA Labs Message-ID: Date: Thu, 16 Nov 2017 17:08:53 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070804040805030107090607" Archived-At: Subject: [saag] OCSP over DNS X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 09:09:01 -0000 This is a cryptographically signed message in MIME format. --------------ms070804040805030107090607 Content-Type: multipart/alternative; boundary="------------D7D7A9FE639FA0664EC87956" Content-Language: en-US This is a multi-part message in MIME format. --------------D7D7A9FE639FA0664EC87956 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi all, although the I-D was not adopted by IETF, I have one question and I=20 would like to provide some comments related to proposal that might have=20 not been conveyed or stressed enough. The question is: in order to effectively move forward with our work, how = can we request the allocation for the DNS RR type for OCSP response data = ? Is there a possibility to get it allocated even if the submission will = be an individual one ? First of all, although mechanisms like OCSP stapling exist and are used=20 in (some) environments like Web/Browsers [*] , there are many=20 environment where that is not happening (not implemented). Even when=20 stapling is supported, the parties (client and server) still need to=20 retrieve the OCSP responses somehow and HTTP/s might not be a viable=20 option - maybe I failed in conveying this point, but I think it is a=20 very important one. Last but not least, reducing the amount of data sent = for establishing secure sessions might not be relevant for large devices = (e.g., laptop/etc.) or generic applications (e.g. browsers), but it=20 definitely matter in the IoT space. On the costs associated with the distribution of revocation information, = I think that the comments on that were not really based on data. Large=20 PKIs exist outside the ICA that issue BILLIONS of certificates and the=20 proposed solution might not only be encouraged but required to provide=20 revocation support in those environment. This said, I am still a bit confused about the reasons for not adopting=20 this work since it would improve access to revocation information, lower = operational costs for CAs (and thus lowering the costs of certificates=20 management), and, in general, provide more options for a more secure=20 networking environment. Last but not least, I would like to thank all the people that actually=20 provided support and valuable comments (from ISC to individual=20 contributors). Also, in case any of the people on the list are still=20 interested in pursuing the idea and improve the draft (that is what we=20 were hoping for - improving an INITIAL idea), please contact me directly = as the work will still continue outside the IETF. Thanks again for the opportunity to present at DISPATCH. Cheers, Max [*] =3D Fun fact, here's reference of a thread in the mozilla sec lists=20 where this proposal was positively considered even back in 2011 -=20 https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/pfFLv= TFZxE8 --=20 Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------D7D7A9FE639FA0664EC87956 Content-Type: multipart/related; boundary="------------8422A4D27234D6D3C892A9E1" --------------8422A4D27234D6D3C892A9E1 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi all,

although the I-D was not adopted by IETF, I have one question and I would like to provide some comments related to proposal that might have not been conveyed or stressed enough.

The question is: in order to effectively move forward with our work, how can we request the allocation for the DNS RR type for OCSP response data ? Is there a possibility to get it allocated even if the submission will be an individual one ?

First of all, although mechanisms like OCSP stapling exist and are used in (some) environments like Web/Browsers [*] , there are many environment where that is not happening (not implemented). Even when stapling is supported, the parties (client and server) still need to retrieve the OCSP responses somehow and HTTP/s might not be a viable option - maybe I failed in conveying this point, but I think it is a very important one. Last but not least, reducing the amount of data sent for establishing secure sessions might not be relevant for large devices (e.g., laptop/etc.) or generic applications (e.g. browsers), but it definitely matter in the IoT space.

On the costs associated with the distribution of revocation information, I think that the comments on that were not really based on data. Large PKIs exist outside the ICA that issue BILLIONS of certificates and the proposed solution might not only be encouraged but required to provide revocation support in those environment.

This said, I am still a bit confused about the reasons for not adopting this work since it would improve access to revocation information, lower operational costs for CAs (and thus lowering the costs of certificates management), and, in general, provide more options for a more secure networking environment.

Last but not least, I would like to thank all the people that actually provided support and valuable comments (from ISC to individual contributors). Also, in case any of the people on the list are still interested in pursuing the idea and improve the draft (that is what we were hoping for - improving an INITIAL idea), please contact me directly as the work will still continue outside the IETF.

Thanks again for the opportunity to present at DISPATCH.

Cheers,
Max

[*] =3D Fun fact, here's reference of a thread in the mozilla sec lists where this proposal was positively considered even back in 2011 - https://groups.google.= com/forum/#!topic/mozilla.dev.security.policy/pfFLvTFZxE8

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA
--------------8422A4D27234D6D3C892A9E1 Content-Type: image/png; name="nkgniblnbknhlflj.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="nkgniblnbknhlflj.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------8422A4D27234D6D3C892A9E1-- --------------D7D7A9FE639FA0664EC87956-- --------------ms070804040805030107090607 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfUwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU+MIIEJqADAgECAhEA/bu0LJsAKXVhEpPllE0lYzANBgkq hkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBMB4XDTE2MTEzMDAwMDAwMFoXDTE3MTEzMDIzNTk1OVowJDEiMCAGCSqGSIb3DQEJ ARYTZGlyZWN0b3JAb3BlbmNhLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AKnGg/GUuTjn0dKCEpRhVd+uiYbCjLQht+dbkvyRLm4aqlL7yHCe+21HQLIcU68ZCHT2ImpF CFFrxQMQh4KijAwkbLc8+xZZSwXeZt58qnPn5c4vcpYU5LFq1q9oDT8MXH33DhVUT/7/IDSi wRWM6FcgM6VrIjBmmvl9dW3gQaEd1bOAhO2X489fChRQYTaB6AEhqb8RSvWW7ZYzfNw8sPxV afMCzWBPpO5RmLqOciZBhAinAM9dXmP5ckg/HjJQYSjvTc7HDcg75mpr5wH8Tk/ChyIYk4CT zqONQV8HKCzZPTVmd2ZuMrliJwMFs3uEg0aBSzHjJTyAmZ89q5Mz3XsCAwEAAaOCAfEwggHt MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTGgh9JWBvcrak1 PhAWBLGrECNAjzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHgYDVR0RBBcwFYETZGlyZWN0b3JAb3Bl bmNhLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEAdIqtPcvA+g6VTYUpEo0I9Vtnrf9PiZ3OpkRL O7U78EaeUfvOotThqj74XyrIl6eYlg+EdGIIUVB1CI05wPMRlZN3/R/Tj28vWkwckLRIbpL4 A5ZQyKgA9vK15/EEBVFIpCtAI6xJX0zx6TySlIgjcca05L0JgO7nzLGD2MY/dVWEE+QBuNI+ NBci+c+9q6YDPoXOpo0Wwbe0Bq95jNNWmZwhGzc+N5rhOGZmQT4P7TnpzvMik8ugbkqWyyHa DQbLKYzM1RKS/mwcvFqjJCQgORnaCilSbfClwdWGI7vwcTR8eAzduvwG61u46Cgb57K5sMck RicpWRvEYxCCVTwnozGCBEQwggRAAgEBMIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCWCGSAFlAwQC AQUAoIICYzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEx MTYwOTA4NTNaMC8GCSqGSIb3DQEJBDEiBCCQOsk9RZx5lJrdfTjOetiu/UClJaZwbyy/Behi WszzvjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHCBgkrBgEEAYI3EAQxgbQwgbEwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAP27tCybACl1YRKT5ZRNJWMwgcQGCyqGSIb3DQEJ EAILMYG0oIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCSqGSIb3DQEBAQUABIIBAIA+gG4sQmHYFDun uZtfMNsz2qhHhb1J8/IHRtsW5GM574bwdKcLasGG372rdOLoJuoeAfbZxvH9EYv9omJHqFHb hKWuip7y/wjXapDHffSfAIo100iMHOi4YTgKQShV4gdfDplSXWBJzzV5eFkicRC4kOV/Kdge BaVSNjEzwbiwiezJBEHjF4sx7pscBFvMHNMoCxilv7WZvJ9VLiiV4V2fsA5BeHavcSDSbGTx rEbAZWlp8s0LiIIIvYlwFv9P1kt60NFb6ooG/2hzyOR9d+ZYUG0AMseQYtJ0PuhO6xE2k0GH 7zA7zRC2Cu10R1cO9XDaQx11J1pI+wDvP1PAr0wAAAAAAAA= --------------ms070804040805030107090607-- From nobody Thu Nov 16 01:48:11 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14F57127201 for ; Thu, 16 Nov 2017 01:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.898 X-Spam-Level: X-Spam-Status: No, score=-6.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5] 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 U4jy0RcnIB_s for ; Thu, 16 Nov 2017 01:48:06 -0800 (PST) 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 96BB1129432 for ; Thu, 16 Nov 2017 01:48:06 -0800 (PST) Received: from [IPv6:2001:67c:370:128:2d89:cd37:f9c7:36c0] ([IPv6:2001:67c:370:128:2d89:cd37:f9c7:36c0]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id vAG9m0UV052048 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 16 Nov 2017 09:48:05 GMT (envelope-from joelja@bogus.com) Content-Type: multipart/alternative; boundary=Apple-Mail-AB54828C-6AA1-42D7-AF1F-6B63DDB78216 Mime-Version: 1.0 (1.0) From: Joel Jaeggli X-Mailer: iPhone Mail (15B93) In-Reply-To: Date: Thu, 16 Nov 2017 17:47:56 +0800 Cc: "saag@ietf.org" , "Polk, Tim (Fed)" Content-Transfer-Encoding: 7bit Message-Id: <40B78B55-1BF3-4266-BC0A-9BAA9A2C40EB@bogus.com> References: To: "Dr. Pala" Archived-At: Subject: Re: [saag] OCSP over DNS X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 09:48:09 -0000 --Apple-Mail-AB54828C-6AA1-42D7-AF1F-6B63DDB78216 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sent from my iPhone > On Nov 16, 2017, at 17:08, Dr. Pala wrote: >=20 > Hi all, >=20 > although the I-D was not adopted by IETF, I have one question and I would l= ike to provide some comments related to proposal that might have not been co= nveyed or stressed enough. >=20 > The question is: in order to effectively move forward with our work, how c= an we request the allocation for the DNS RR type for OCSP response data ? Is= there a possibility to get it allocated even if the submission will be an i= ndividual one ? >=20 DNS RR types may be allocated by expert review. See RFC 6895 section 3.1.1.=20= Fill out the template and send it off to the IANA experts. > First of all, although mechanisms like OCSP stapling exist and are used in= (some) environments like Web/Browsers [*] , there are many environment wher= e that is not happening (not implemented). Even when stapling is supported, t= he parties (client and server) still need to retrieve the OCSP responses som= ehow and HTTP/s might not be a viable option - maybe I failed in conveying t= his point, but I think it is a very important one. Last but not least, reduc= ing the amount of data sent for establishing secure sessions might not be re= levant for large devices (e.g., laptop/etc.) or generic applications (e.g. b= rowsers), but it definitely matter in the IoT space. > On the costs associated with the distribution of revocation information, I= think that the comments on that were not really based on data. Large PKIs e= xist outside the ICA that issue BILLIONS of certificates and the proposed so= lution might not only be encouraged but required to provide revocation suppo= rt in those environment. > This said, I am still a bit confused about the reasons for not adopting th= is work since it would improve access to revocation information, lower opera= tional costs for CAs (and thus lowering the costs of certificates management= ), and, in general, provide more options for a more secure networking enviro= nment. > Last but not least, I would like to thank all the people that actually pro= vided support and valuable comments (from ISC to individual contributors). A= lso, in case any of the people on the list are still interested in pursuing t= he idea and improve the draft (that is what we were hoping for - improving a= n INITIAL idea), please contact me directly as the work will still continue o= utside the IETF. >=20 > Thanks again for the opportunity to present at DISPATCH. > Cheers, > Max >=20 > [*] =3D Fun fact, here's reference of a thread in the mozilla sec lists wh= ere this proposal was positively considered even back in 2011 - https://grou= ps.google.com/forum/#!topic/mozilla.dev.security.policy/pfFLvTFZxE8 > --=20 > Best Regards, > Massimiliano Pala, Ph.D. > OpenCA Labs Director > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag --Apple-Mail-AB54828C-6AA1-42D7-AF1F-6B63DDB78216 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

Sent from my iPhone

On Nov 16, 2017, at 17:08, Dr. Pala <director@openca.org> wrote:

Hi all,

although the I-D was not adopted by IETF, I have one question and I would like to provide some comments related to proposal that might have not been conveyed or stressed enough.

The question is: in order to effectively move forward with our work, how can we request the allocation for the DNS RR type for OCSP response data ? Is there a possibility to get it allocated even if the submission will be an individual one ?


DNS RR types may be allocated by expert review. See RFC 6895 section 3.1.1. 

Fill out the template and send it off to the IANA experts.

First of all, although mechanisms like OCSP stapling exist and are used in (some) environments like Web/Browsers [*] , there are many environment where that is not happening (not implemented). Even when stapling is supported, the parties (client and server) still need to retrieve the OCSP responses somehow and HTTP/s might not be a viable option - maybe I failed in conveying this point, but I think it is a very important one. Last but not least, reducing the amount of data sent for establishing secure sessions might not be relevant for large devices (e.g., laptop/etc.) or generic applications (e.g. browsers), but it definitely matter in the IoT space.

On the costs associated with the distribution of revocation information, I think that the comments on that were not really based on data. Large PKIs exist outside the ICA that issue BILLIONS of certificates and the proposed solution might not only be encouraged but required to provide revocation support in those environment.

This said, I am still a bit confused about the reasons for not adopting this work since it would improve access to revocation information, lower operational costs for CAs (and thus lowering the costs of certificates management), and, in general, provide more options for a more secure networking environment.

Last but not least, I would like to thank all the people that actually provided support and valuable comments (from ISC to individual contributors). Also, in case any of the people on the list are still interested in pursuing the idea and improve the draft (that is what we were hoping for - improving an INITIAL idea), please contact me directly as the work will still continue outside the IETF.

Thanks again for the opportunity to present at DISPATCH.

Cheers,
Max

[*] = Fun fact, here's reference of a thread in the mozilla sec lists where this proposal was positively considered even back in 2011 - https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/pfFLvTFZxE8

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
<nkgniblnbknhlflj.png>
_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag
--Apple-Mail-AB54828C-6AA1-42D7-AF1F-6B63DDB78216-- From nobody Thu Nov 16 02:12:38 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B331200CF for ; Thu, 16 Nov 2017 02:12:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ya4c1u1JxLjl for ; Thu, 16 Nov 2017 02:12:31 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25AC4126C2F for ; Thu, 16 Nov 2017 02:12:31 -0800 (PST) Received: from [10.32.60.89] (dhcp-8904.meeting.ietf.org [31.133.137.4]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id vAGAAwPc097466 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 16 Nov 2017 03:11:01 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host dhcp-8904.meeting.ietf.org [31.133.137.4] claimed to be [10.32.60.89] From: "Paul Hoffman" To: "Brian Witten" Cc: "saag@ietf.org" Date: Thu, 16 Nov 2017 18:12:15 +0800 Message-ID: <6DF7F2EB-80AE-4AB9-A98F-076F12B4B8BD@vpnc.org> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.7r5425) Archived-At: Subject: Re: [saag] patient ietf100 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 10:12:37 -0000 On 16 Nov 2017, at 12:58, Brian Witten wrote: > The PATIENT side-meeting last night was well attended, though with > clearly divided discussion. Thank You Again To All Who Participated. > Next step is to assemble an Internet Draft presenting verifiable data > on merits of third party security, particularly third party network > security. I'll do this over next few weeks with help from volunteers. I would love to hear more about what was said at the meeting. Are there fuller notes somewhere? --Paul Hoffman From nobody Thu Nov 16 03:33:30 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4871293EE for ; Thu, 16 Nov 2017 03:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.89 X-Spam-Level: X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] 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 NR5DIl66RfHv for ; Thu, 16 Nov 2017 03:33:27 -0800 (PST) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 23F8E126DFB for ; Thu, 16 Nov 2017 03:33:26 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id CD7BA3740FDE; Thu, 16 Nov 2017 11:33:26 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id cu-nYO05_ZBb; Thu, 16 Nov 2017 06:33:21 -0500 (EST) Received: from [31.133.151.254] (dhcp-97fe.meeting.ietf.org [31.133.151.254]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 53C2B3740F7F; Thu, 16 Nov 2017 06:33:20 -0500 (EST) Content-Type: multipart/alternative; boundary=Apple-Mail-3BF4083C-8982-4E4D-92A3-EFA362C5E0FE Content-Transfer-Encoding: 7bit From: "Dr. Pala" Mime-Version: 1.0 (1.0) Date: Thu, 16 Nov 2017 18:02:00 +0800 Message-Id: References: <40B78B55-1BF3-4266-BC0A-9BAA9A2C40EB@bogus.com> Cc: "saag@ietf.org" , "Polk, Tim (Fed)" In-Reply-To: <40B78B55-1BF3-4266-BC0A-9BAA9A2C40EB@bogus.com> To: Joel Jaeggli X-Mailer: iPhone Mail (15A432) Archived-At: Subject: Re: [saag] OCSP over DNS X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 11:33:29 -0000 --Apple-Mail-3BF4083C-8982-4E4D-92A3-EFA362C5E0FE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Joel, Thanks! Cheers, Max > On Nov 16, 2017, at 5:47 PM, Joel Jaeggli wrote: >=20 >=20 >=20 > Sent from my iPhone >=20 >> On Nov 16, 2017, at 17:08, Dr. Pala wrote: >>=20 >> Hi all, >>=20 >> although the I-D was not adopted by IETF, I have one question and I would= like to provide some comments related to proposal that might have not been c= onveyed or stressed enough. >>=20 >> The question is: in order to effectively move forward with our work, how c= an we request the allocation for the DNS RR type for OCSP response data ? Is= there a possibility to get it allocated even if the submission will be an i= ndividual one ? >>=20 >=20 > DNS RR types may be allocated by expert review. See RFC 6895 section 3.1.1= .=20 >=20 > Fill out the template and send it off to the IANA experts. >> First of all, although mechanisms like OCSP stapling exist and are used i= n (some) environments like Web/Browsers [*] , there are many environment whe= re that is not happening (not implemented). Even when stapling is supported,= the parties (client and server) still need to retrieve the OCSP responses s= omehow and HTTP/s might not be a viable option - maybe I failed in conveying= this point, but I think it is a very important one. Last but not least, red= ucing the amount of data sent for establishing secure sessions might not be r= elevant for large devices (e.g., laptop/etc.) or generic applications (e.g. b= rowsers), but it definitely matter in the IoT space. >> On the costs associated with the distribution of revocation information, I= think that the comments on that were not really based on data. Large PKIs e= xist outside the ICA that issue BILLIONS of certificates and the proposed so= lution might not only be encouraged but required to provide revocation suppo= rt in those environment. >> This said, I am still a bit confused about the reasons for not adopting t= his work since it would improve access to revocation information, lower oper= ational costs for CAs (and thus lowering the costs of certificates managemen= t), and, in general, provide more options for a more secure networking envir= onment. >> Last but not least, I would like to thank all the people that actually pr= ovided support and valuable comments (from ISC to individual contributors). A= lso, in case any of the people on the list are still interested in pursuing t= he idea and improve the draft (that is what we were hoping for - improving a= n INITIAL idea), please contact me directly as the work will still continue o= utside the IETF. >>=20 >> Thanks again for the opportunity to present at DISPATCH. >> Cheers, >> Max >>=20 >> [*] =3D Fun fact, here's reference of a thread in the mozilla sec lists w= here this proposal was positively considered even back in 2011 - https://gro= ups.google.com/forum/#!topic/mozilla.dev.security.policy/pfFLvTFZxE8 >> --=20 >> Best Regards, >> Massimiliano Pala, Ph.D. >> OpenCA Labs Director >> >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag --Apple-Mail-3BF4083C-8982-4E4D-92A3-EFA362C5E0FE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi Joel,

Thanks!

Cheers,
Max


On Nov 16, 2017, at 5:47 PM, Joel Jaeggli <joelja@bogus.com> wrote:



Sent from my iPhone

On Nov 16, 2017, at 17:08, Dr. Pala <director@openca.org> wrote:

Hi all,

although the I-D was not adopted by IETF, I have one question and I would like to provide some comments related to proposal that might have not been conveyed or stressed enough.

The question is: in order to effectively move forward with our work, how can we request the allocation for the DNS RR type for OCSP response data ? Is there a possibility to get it allocated even if the submission will be an individual one ?


DNS RR types may be allocated by expert review. See RFC 6895 section 3.1.1. 

Fill out the template and send it off to the IANA experts.

First of all, although mechanisms like OCSP stapling exist and are used in (some) environments like Web/Browsers [*] , there are many environment where that is not happening (not implemented). Even when stapling is supported, the parties (client and server) still need to retrieve the OCSP responses somehow and HTTP/s might not be a viable option - maybe I failed in conveying this point, but I think it is a very important one. Last but not least, reducing the amount of data sent for establishing secure sessions might not be relevant for large devices (e.g., laptop/etc.) or generic applications (e.g. browsers), but it definitely matter in the IoT space.

On the costs associated with the distribution of revocation information, I think that the comments on that were not really based on data. Large PKIs exist outside the ICA that issue BILLIONS of certificates and the proposed solution might not only be encouraged but required to provide revocation support in those environment.

This said, I am still a bit confused about the reasons for not adopting this work since it would improve access to revocation information, lower operational costs for CAs (and thus lowering the costs of certificates management), and, in general, provide more options for a more secure networking environment.

Last but not least, I would like to thank all the people that actually provided support and valuable comments (from ISC to individual contributors). Also, in case any of the people on the list are still interested in pursuing the idea and improve the draft (that is what we were hoping for - improving an INITIAL idea), please contact me directly as the work will still continue outside the IETF.

Thanks again for the opportunity to present at DISPATCH.

Cheers,
Max

[*] = Fun fact, here's reference of a thread in the mozilla sec lists where this proposal was positively considered even back in 2011 - https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/pfFLvTFZxE8

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
<nkgniblnbknhlflj.png>
_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag
--Apple-Mail-3BF4083C-8982-4E4D-92A3-EFA362C5E0FE-- From nobody Thu Nov 16 04:03:08 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48607129435; Thu, 16 Nov 2017 04:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nj9nC2H7ivrL; Thu, 16 Nov 2017 04:02:35 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id B5CF0128B44; Thu, 16 Nov 2017 04:02:34 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id DF9BD2D199; Thu, 16 Nov 2017 14:02:32 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6mmxdeeXxkbN; Thu, 16 Nov 2017 14:02:31 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 6292B2CD0D; Thu, 16 Nov 2017 14:02:30 +0200 (EET) (envelope-from jari.arkko@piuha.net) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: Date: Thu, 16 Nov 2017 20:02:28 +0800 Cc: reap@ietf.org, Security Area Advisory Group , emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <58815EFC-3CF9-4F62-A7E3-6E76FBAA295A@piuha.net> References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com> <4c6c9bc8-6056-c03d-a0f6-f1f32fabef39@ericsson.com> <00d401d35114$de589760$9b09c620$@augustcellars.com> <8D84F942-5D10-4DB8-8EB7-3EB8A8AEE17E@gmail.com> To: Bernard Aboba , Mohit Sethi X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [saag] [Emu] EAP - TLS 1.3 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 12:02:38 -0000 I don=E2=80=99t want to push the decision in either direction without = looking into the details. But I wanted to point out that there=E2=80=99s usually a third = alternative between =E2=80=9Cno need for new documents=E2=80=9D and = =E2=80=9Cneed a new RFC to describe the new version=E2=80=9D. Explaining = that the old protocol can be used and what the implications are may by = itself be a useful document. In the specific example, is not immediately = obvious to me for instance if the security consideration would somehow = change, or if 0-RTT can or can not be used, etc. Jari From nobody Thu Nov 16 05:02:25 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14BEC129454; Thu, 16 Nov 2017 05:02:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ZKxMl7xdfFqR; Thu, 16 Nov 2017 05:02:10 -0800 (PST) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) by ietfa.amsl.com (Postfix) with ESMTP id AE6001273B1; Thu, 16 Nov 2017 05:02:06 -0800 (PST) Received: from [192.168.2.25] (198-84-205-59.cpe.teksavvy.com [198.84.205.59]) by mail.networkradius.com (Postfix) with ESMTPSA id 81775673; Thu, 16 Nov 2017 13:02:04 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alan DeKok In-Reply-To: Date: Thu, 16 Nov 2017 08:02:03 -0500 Cc: Bernard Aboba , Jim Schaad , reap@ietf.org, Security Area Advisory Group , emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <514629D2-0726-4AA3-8982-4735B9EBEB16@deployingradius.com> References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com> <4c6c9bc8-6056-c03d-a0f6-f1f32fabef39@ericsson.com> <00d401d35114$de589760$9b09c620$@augustcellars.com> <8D84F942-5D10-4DB8-8EB7-3EB8A8AEE17E@gmail.com> To: Mohit Sethi X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [saag] [Reap] EAP - TLS 1.3 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 13:02:13 -0000 On Nov 16, 2017, at 12:16 AM, Mohit Sethi = wrote: >=20 > Coming back to our motivation for this draft. 3GPP has decided that = authentication in 5G can be done with any type of credential that the = operator accepts and that EAP will be used for authentication. The = working assumption is that EAP-TLS will be used for mutual = authentication with certificates. 3GPP would likely want to use TLS 1.3 = as much as possible, especially for EAP-TLS, as TLS 1.3 reduces the = numbers of roundtrips in EAP-TLS as well as providing encryption of the = handshake including the certificates. That's good. But as Bernard points out, there's no need to change = EAP-TLS. You can just use TLS 1.3. I think one of the concerns here is the procedural aspect. Your = proposal was to forbid everyone *else* from using TLS 1.0 because your = requirements were for TLS 1.3. That's not the way to gain support. In addition, your other arguments are hand-waving, and don't provide = concrete details to back up your position. Having concrete details = would help. > If the EAP community decides that RFC5216 adequately describes how to = use TLS 1.3 and does not need an update we can live with that. Our = conclusion is however that an update of RFC2516 is needed for several = reasons: > =E2=80=A2 RFC5216 is very much tied to the message flows and = message formats in TLS 1.0 - 1.2. The message flows and message content = in TLS 1.3 is very different. While a developer could theoretically = figure out how to use EAP-TLS with TLS 1.3, such an implementation would = not follow RFC5216 How so? 5216 says (essentially) "encapsulate TLS within EAP". How, = exactly, does this change with TLS 1.3? > and in the worst case, implementations would not even be compatible. > =E2=80=A2 TLS 1.3 makes major changes to the Key Schedule. The = PRF in TLS 1.0 is 1.2 is replaced with a HKDF. Our understanding is that = an update defining the Key Hierarchy in terms of the TLS-Exporter = (similar to what is done in draft-ietf-quic-tls) is needed. Implementations of EAP-TLS do need to change when the key derivation = changes. Such as for TLS 1.2. However, those changes are largely = limited to the TLS library, not the EAP-TLS code. > =E2=80=A2 RFC5216 specifies that "EAP-TLS implementations MUST = support TLS v1.0". You're free to deprecate TLS 1.0 in documents which update RFC5216... = if you have IETF consensus. Further, you're free to mandate use of TLS 1.3 in 5G specifications. = They're your specifications, and you're free to ignore IETF requirements = if you so choose. > =E2=80=A2 RFC5216 specifies that cipher suites with 3DES, SHA-1, = RC4, CBC, and MD5 are mandatory-to-implement for EAP-TLS (i.e. not based = on the TLS version).=20 The same comment as above applies here. > If IETF does not provide new message flow diagrams for EAP-TLS with = TLS 1.3, it is likely that 3GPP will do that, we would much rather see = an IETF RFC that 3GPP and other can refer to. What, exactly is different with the message flows in EAP-TLS when TLS = 1.3 is used? Please be specific. Alan DeKok. From nobody Thu Nov 16 05:56:50 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736C51293F3; Thu, 16 Nov 2017 05:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQPVxqFkSu6N; Thu, 16 Nov 2017 05:56:46 -0800 (PST) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEC69126C2F; Thu, 16 Nov 2017 05:56:45 -0800 (PST) Received: by mail-vk0-x22b.google.com with SMTP id b7so16556921vkh.12; Thu, 16 Nov 2017 05:56:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TABAMLXA0H2f2C+KvuNuE5eVolyDDQ7CPP/BB4YEd5A=; b=tHxD5iK1vIsKBq1UbVGm20nAGffTWgfuVJwZatt7SC1MtGTUlLmlsf7/ezpwLHfrKL 8mGdFKyyD0oivIREkIu4I6rhpWYDk2fqbrrDTnxKjIi8Ypb8zQZI/KhDBNm5mQu4whlt l8F6ptw6Hx1Frz+9pBTC7gIqVCZjf449nBC+G1bDeew69BfhGxAMpZ/y5C8b/Plfme7O rjJ4WhrzB7lwi0AHxQvyY0lps3ckNyJYccjdr7BigN09/eisPCbRSQ1nBN54HeWI/4Hk 4BWDwdYf6N+GW2NqfUqvvaHJkyjy0sxdp8LvlPiohUQBmwmRx8PMfRqO12ir8Nrv31ln Nmlg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TABAMLXA0H2f2C+KvuNuE5eVolyDDQ7CPP/BB4YEd5A=; b=GrvpKoB2OsoU3SQWIluFmx+9f4IMrMcNvGE0BWVY5u4LSKcc11WsXs2sX/5hdsyyVC IN/GXTI0VbFEtYxVFTdAzJjBNbVqZd9Ga/Q009Kn/qZgHUF+/8Qwxy9OsILxc70mBf6D 6kMe0akEylJY3SUhewJvxSueSjCVeEmgTqM6M9r00NBUiYtGOuIAqx4xoSmU3qZQUbVE qKS2+ioUN2IxC1IGFxOpEngvWwll6Su1hYZUl22rULAfOjfyxI4PH4ktoHuux4RBZJzx OFgeEQ1sTLQA1SygA5KWIYPTBKWPl7zAckggRxZG/m42DZExB903gfl7Xe4Fa4QOTY+8 TLJQ== X-Gm-Message-State: AJaThX6K9FqHRtdWT7yi6Db0GgcrSW6QrlP/gxl46fkoNEc0nqOlY4C0 0hNkLm03B5bbew8C4QIAl/hZgQhxP14leKy20pg= X-Google-Smtp-Source: AGs4zMafyGUjUMVtGq2OBBrWFpwNj7q9a37xGDy5EhQsq1JbR13rfb4yx8/SjZh+z1xNoPk/fTT1sVTjemv3iugSM6I= X-Received: by 10.31.13.14 with SMTP id 14mr1182174vkn.24.1510840604353; Thu, 16 Nov 2017 05:56:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.38.130 with HTTP; Thu, 16 Nov 2017 05:56:23 -0800 (PST) In-Reply-To: <514629D2-0726-4AA3-8982-4735B9EBEB16@deployingradius.com> References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com> <4c6c9bc8-6056-c03d-a0f6-f1f32fabef39@ericsson.com> <00d401d35114$de589760$9b09c620$@augustcellars.com> <8D84F942-5D10-4DB8-8EB7-3EB8A8AEE17E@gmail.com> <514629D2-0726-4AA3-8982-4735B9EBEB16@deployingradius.com> From: Bernard Aboba Date: Thu, 16 Nov 2017 05:56:23 -0800 Message-ID: To: Alan DeKok Cc: Mohit Sethi , Jim Schaad , reap@ietf.org, Security Area Advisory Group , emu@ietf.org Content-Type: multipart/alternative; boundary="001a1143835a8905dc055e19fdb2" Archived-At: Subject: Re: [saag] [Reap] EAP - TLS 1.3 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 13:56:48 -0000 --001a1143835a8905dc055e19fdb2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Alan said: "That's good. But as Bernard points out, there's no need to change EAP-TLS. You can just use TLS 1.3." [BA] Existing implementations enable organizations to impose TLS version and ciphersuite requirements on *their* devices. For example, I have worked with organizations that require FIPS 140-3 support, who impose those cryptographic requirements through policy. Of course, such a constraint may bring with it the need to upgrade EAP-TLS clients and AAA servers - but that cost is imposed *only* on the organization imposing the policy. "I think one of the concerns here is the procedural aspect. Your proposal was to forbid everyone *else* from using TLS 1.0 because your requirements were for TLS 1.3. That's not the way to gain support." [BA] The proposal would force the replacement of 2+ billion EAP implementations along with millions of smartcards and other hardware that is incompatible with TLS 1.3. It would also make every EAP-TLS implementation subject to patent declarations on later TLS versions. A search through the IPR declaration database discloses a horrifying number of declarations that would apply as a result. A proposal imposing such extraordinary costs requires extraordinary justification. So far, I am not aware of a declaration from any standards organization or authority that versions of TLS prior to 1.3 need to be phased out. "In addition, your other arguments are hand-waving, and don't provide concrete details to back up your position. Having concrete details would help." [BA] So far, I read the argument as "Someone implementing EAP-TLS from scratch with TLS 1.3 might not get it right." But given the *huge* number of deployed devices out there, we need something much more concrete - like test data demonstrating a real interoperability problem. On Thu, Nov 16, 2017 at 5:02 AM, Alan DeKok wrote: > On Nov 16, 2017, at 12:16 AM, Mohit Sethi > wrote: > > > > Coming back to our motivation for this draft. 3GPP has decided that > authentication in 5G can be done with any type of credential that the > operator accepts and that EAP will be used for authentication. The workin= g > assumption is that EAP-TLS will be used for mutual authentication with > certificates. 3GPP would likely want to use TLS 1.3 as much as possible, > especially for EAP-TLS, as TLS 1.3 reduces the numbers of roundtrips in > EAP-TLS as well as providing encryption of the handshake including the > certificates. > > That's good. But as Bernard points out, there's no need to change > EAP-TLS. You can just use TLS 1.3. > > I think one of the concerns here is the procedural aspect. Your > proposal was to forbid everyone *else* from using TLS 1.0 because your > requirements were for TLS 1.3. That's not the way to gain support. > > In addition, your other arguments are hand-waving, and don't provide > concrete details to back up your position. Having concrete details would > help. > > > If the EAP community decides that RFC5216 adequately describes how to > use TLS 1.3 and does not need an update we can live with that. Our > conclusion is however that an update of RFC2516 is needed for several > reasons: > > =E2=80=A2 RFC5216 is very much tied to the message flows and mess= age > formats in TLS 1.0 - 1.2. The message flows and message content in TLS 1.= 3 > is very different. While a developer could theoretically figure out how t= o > use EAP-TLS with TLS 1.3, such an implementation would not follow RFC5216 > > How so? 5216 says (essentially) "encapsulate TLS within EAP". How, > exactly, does this change with TLS 1.3? > > > and in the worst case, implementations would not even be compatible. > > =E2=80=A2 TLS 1.3 makes major changes to the Key Schedule. The PR= F in TLS > 1.0 is 1.2 is replaced with a HKDF. Our understanding is that an update > defining the Key Hierarchy in terms of the TLS-Exporter (similar to what = is > done in draft-ietf-quic-tls) is needed. > > Implementations of EAP-TLS do need to change when the key derivation > changes. Such as for TLS 1.2. However, those changes are largely limite= d > to the TLS library, not the EAP-TLS code. > > > =E2=80=A2 RFC5216 specifies that "EAP-TLS implementations MUST su= pport TLS > v1.0". > > You're free to deprecate TLS 1.0 in documents which update RFC5216... i= f > you have IETF consensus. > > Further, you're free to mandate use of TLS 1.3 in 5G specifications. > They're your specifications, and you're free to ignore IETF requirements = if > you so choose. > > > =E2=80=A2 RFC5216 specifies that cipher suites with 3DES, SHA-1, = RC4, CBC, > and MD5 are mandatory-to-implement for EAP-TLS (i.e. not based on the TLS > version). > > The same comment as above applies here. > > > If IETF does not provide new message flow diagrams for EAP-TLS with TL= S > 1.3, it is likely that 3GPP will do that, we would much rather see an IET= F > RFC that 3GPP and other can refer to. > > What, exactly is different with the message flows in EAP-TLS when TLS > 1.3 is used? > > Please be specific. > > Alan DeKok. > > --001a1143835a8905dc055e19fdb2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Alan said:

"That's good.=C2=A0 But as Bernard points out, there's no= need to change EAP-TLS.=C2=A0 You can just use TLS 1.3."
=

[BA] Existing implementations enable organizations to imp= ose TLS version and ciphersuite requirements on *their* devices.=C2=A0 For = example, I have worked with organizations that require FIPS 140-3 support, = who impose those cryptographic requirements through policy. Of course, such= a constraint may bring with it the need to upgrade EAP-TLS clients and AAA= servers - but that cost is imposed *only* on the organization imposing the= policy.=C2=A0

=C2=A0"I think one of the conc= erns here is the procedural aspect.=C2=A0 Your proposal was to forbid every= one *else* from using TLS 1.0 because your requirements were for TLS 1.3.= =C2=A0 That's not the way to gain support."

<= div>[BA] The proposal would force the replacement of 2+ billion EAP impleme= ntations along with millions of smartcards and other hardware that is incom= patible with TLS 1.3.=C2=A0 It would also make every EAP-TLS implementation= subject to patent declarations on later TLS versions.=C2=A0 A search throu= gh the IPR declaration database discloses a horrifying number of declaratio= ns that would apply as a result.

A proposal imposi= ng such extraordinary costs requires extraordinary justification.=C2=A0 So = far, I am not aware of a declaration from any standards organization or aut= hority that versions of TLS prior to 1.3 need to be phased out.=C2=A0
=

"In addition, you= r other arguments are hand-waving, and don't provide concrete details t= o back up your position.=C2=A0 Having concrete details would help.&q= uot;

[BA] So far, I read the argument as "= ;Someone implementing EAP-TLS from scratch with TLS 1.3 might not get it ri= ght."=C2=A0 But given the *huge* number of deployed devices out there,= we need something much more concrete - like test data demonstrating a real= interoperability problem.

On Thu, Nov 16, 2017 at 5:02 AM, Alan DeKok <aland@deployingradius.com> wrote:
On Nov 16, 2017, at 12:16 AM, Mohit Sethi <mohit.m.sethi@ericsson.com>= ; wrote:
>
> Coming back to our motivation for this draft. 3GPP has decided that au= thentication in 5G can be done with any type of credential that the operato= r accepts and that EAP will be used for authentication. The working assumpt= ion is that EAP-TLS will be used for mutual authentication with certificate= s. 3GPP would likely want to use TLS 1.3 as much as possible, especially fo= r EAP-TLS, as TLS 1.3 reduces the numbers of roundtrips in EAP-TLS as well = as providing encryption of the handshake including the certificates.

=C2=A0 That's good.=C2=A0 But as Bernard points out, there's= no need to change EAP-TLS.=C2=A0 You can just use TLS 1.3.

=C2=A0 I think one of the concerns here is the procedural aspect.=C2=A0 You= r proposal was to forbid everyone *else* from using TLS 1.0 because your re= quirements were for TLS 1.3.=C2=A0 That's not the way to gain support.<= br>
=C2=A0 In addition, your other arguments are hand-waving, and don't pro= vide concrete details to back up your position.=C2=A0 Having concrete detai= ls would help.

> If the EAP community decides that RFC5216 adequately describes how to = use TLS 1.3 and does not need an update we can live with that. Our conclusi= on is however that an update of RFC2516 is needed for several reasons:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 RFC5216 is very much tied to the m= essage flows and message formats in TLS 1.0 - 1.2. The message flows and me= ssage content in TLS 1.3 is very different. While a developer could theoret= ically figure out how to use EAP-TLS with TLS 1.3, such an implementation w= ould not follow RFC5216

=C2=A0 How so?=C2=A0 5216 says (essentially) "encapsulate TLS w= ithin EAP".=C2=A0 How, exactly, does this change with TLS 1.3?

> and in the worst case, implementations would not even be compatible. >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 TLS 1.3 makes major changes to the= Key Schedule. The PRF in TLS 1.0 is 1.2 is replaced with a HKDF. Our under= standing is that an update defining the Key Hierarchy in terms of the TLS-E= xporter (similar to what is done in draft-ietf-quic-tls) is needed.

=C2=A0 Implementations of EAP-TLS do need to change when the key der= ivation changes.=C2=A0 Such as for TLS 1.2.=C2=A0 However, those changes ar= e largely limited to the TLS library, not the EAP-TLS code.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 RFC5216 specifies that "EAP-T= LS implementations MUST support TLS v1.0".

=C2=A0 You're free to deprecate TLS 1.0 in documents which update RFC52= 16... if you have IETF consensus.

=C2=A0 Further, you're free to mandate use of TLS 1.3 in 5G specificati= ons.=C2=A0 They're your specifications, and you're free to ignore I= ETF requirements if you so choose.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 RFC5216 specifies that cipher suit= es with 3DES, SHA-1, RC4, CBC, and MD5 are mandatory-to-implement for EAP-T= LS (i.e. not based on the TLS version).

=C2=A0 The same comment as above applies here.

>=C2=A0 If IETF does not provide new message flow diagrams for EAP-TLS w= ith TLS 1.3, it is likely that 3GPP will do that, we would much rather see = an IETF RFC that 3GPP and other can refer to.

=C2=A0 What, exactly is different with the message flows in EAP-TLS = when TLS 1.3 is used?

=C2=A0 Please be specific.

=C2=A0 Alan DeKok.


--001a1143835a8905dc055e19fdb2-- From nobody Thu Nov 16 06:15:34 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D590F12954B; Thu, 16 Nov 2017 06:15:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qsJp_NAnSlnx; Thu, 16 Nov 2017 06:15:15 -0800 (PST) Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 413E01293FD; Thu, 16 Nov 2017 06:15:15 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id k82so8465268vkd.5; Thu, 16 Nov 2017 06:15:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=h+gUjhU4N+7Z6jkhAAB97DijI2qcRD1D0kNoWJqJ+dk=; b=d+tWYc4XNWdQL4yn8ALhm4aLHw4rVULAeSMfty7dLNCSUF8PaSuaVfEk0quImhbDVT aenal7UzrIQCYdQB7Wpkjxj806dDZq/m+8mZP+sZTSPyhBRZv/liLgNZeBJYqUBz5SrT cdFnceMhFn5gEQ5XyWGRoOjCq+lvAGSWwjYociHQ3zXLAaX+UjFj0L63079XHKhR6e1B AY5kWvpL86xjzlNePRAnmx3NV/JfJjLLPWQ/dIoLVEwEjVR+e0K11hapWuIFYWsKw2Iv ZUnCiCsZnbTGBAmOAOawt4gAAwedLw9pyoh/KQp6AG0kJz/FDIOMpmh1n5hHhdbm58HX F8OQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=h+gUjhU4N+7Z6jkhAAB97DijI2qcRD1D0kNoWJqJ+dk=; b=Keet7q4tLrJtKFmcfc39SuEJoPS60fxHwYTGIZNh+yhyAGtl9iw8oFTCRF2r+cgZnC 6d5YIL0rqAEjeHh2Bzm1LAw3fNzthsjZNTY2SYHLjO9r7Mfe8JgzREy52t2xPhb9CXb4 blPYDyiQfWhv31H+CBX/AtJXilkYi3ewUWSvD84ODXY2KjOB0KZFkwMDczk821n/gVUM khw6KUlaq71IkzmRtkRHosTnz8l0YWFevJrDXzXvyJwk8zKSGZHmRy7S+TSxHPUrRSS7 334r0SR5oeZbZS/SdQUXnrAomzZvaksmWEPIFol9w/WPlE3fcolx4y9uT4BG1Bh1CVde n20g== X-Gm-Message-State: AJaThX5yb+VSb7t50xMGAZZaITGxgKYxqlQ1NcSk7kfXZ5vhASDVqpW8 5qO/xa6EmkON+UvVpaeGmGQeEAUSDck6rQ06rxE= X-Google-Smtp-Source: AGs4zMYoAjhq9OFYkVIn+Yd/6Qu3gOuQHZSufxvG1v64trAya2o3Lh1IfkWIVu1Gu+t76OnE8KvMAQrspptYAndSd8s= X-Received: by 10.31.13.14 with SMTP id 14mr1257644vkn.24.1510841713957; Thu, 16 Nov 2017 06:15:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.38.130 with HTTP; Thu, 16 Nov 2017 06:14:53 -0800 (PST) In-Reply-To: <514629D2-0726-4AA3-8982-4735B9EBEB16@deployingradius.com> References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com> <4c6c9bc8-6056-c03d-a0f6-f1f32fabef39@ericsson.com> <00d401d35114$de589760$9b09c620$@augustcellars.com> <8D84F942-5D10-4DB8-8EB7-3EB8A8AEE17E@gmail.com> <514629D2-0726-4AA3-8982-4735B9EBEB16@deployingradius.com> From: Bernard Aboba Date: Thu, 16 Nov 2017 06:14:53 -0800 Message-ID: To: Alan DeKok Cc: Mohit Sethi , Jim Schaad , reap@ietf.org, Security Area Advisory Group , emu@ietf.org Content-Type: multipart/alternative; boundary="001a1143835aac1fa5055e1a3fd2" Archived-At: Subject: Re: [saag] [Reap] EAP - TLS 1.3 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 14:15:18 -0000 --001a1143835aac1fa5055e1a3fd2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Alan said: " Further, you're free to mandate use of TLS 1.3 in 5G specifications. They're your specifications, and you're free to ignore IETF requirements if you so choose." [BA] There are many organizations who have imposed cryptographic or version policies on their EAP-TLS implementations. For example, governments requiring FIPS 140-3 compliance configure their AAA servers to impose that requirement. No change to the specification is required for members of 3GPP to configure such restrictions in their AAA servers. Of course, imposing such a restriction is only practical if you're willing to deny access to devices that don't implement TLS 1.3. That typically is only workable in the case of a new service that can only be accessed with new devices conforming to a new specification. If that is the situation we're talking about, 3GPP can add TLS cryptographic or version restrictions to their specifications. That wouldn't violate RFC 5216, and it would avoid imposing huge costs on everyone else. On Thu, Nov 16, 2017 at 5:02 AM, Alan DeKok wrote: > On Nov 16, 2017, at 12:16 AM, Mohit Sethi > wrote: > > > > Coming back to our motivation for this draft. 3GPP has decided that > authentication in 5G can be done with any type of credential that the > operator accepts and that EAP will be used for authentication. The workin= g > assumption is that EAP-TLS will be used for mutual authentication with > certificates. 3GPP would likely want to use TLS 1.3 as much as possible, > especially for EAP-TLS, as TLS 1.3 reduces the numbers of roundtrips in > EAP-TLS as well as providing encryption of the handshake including the > certificates. > > That's good. But as Bernard points out, there's no need to change > EAP-TLS. You can just use TLS 1.3. > > I think one of the concerns here is the procedural aspect. Your > proposal was to forbid everyone *else* from using TLS 1.0 because your > requirements were for TLS 1.3. That's not the way to gain support. > > In addition, your other arguments are hand-waving, and don't provide > concrete details to back up your position. Having concrete details would > help. > > > If the EAP community decides that RFC5216 adequately describes how to > use TLS 1.3 and does not need an update we can live with that. Our > conclusion is however that an update of RFC2516 is needed for several > reasons: > > =E2=80=A2 RFC5216 is very much tied to the message flows and mess= age > formats in TLS 1.0 - 1.2. The message flows and message content in TLS 1.= 3 > is very different. While a developer could theoretically figure out how t= o > use EAP-TLS with TLS 1.3, such an implementation would not follow RFC5216 > > How so? 5216 says (essentially) "encapsulate TLS within EAP". How, > exactly, does this change with TLS 1.3? > > > and in the worst case, implementations would not even be compatible. > > =E2=80=A2 TLS 1.3 makes major changes to the Key Schedule. The PR= F in TLS > 1.0 is 1.2 is replaced with a HKDF. Our understanding is that an update > defining the Key Hierarchy in terms of the TLS-Exporter (similar to what = is > done in draft-ietf-quic-tls) is needed. > > Implementations of EAP-TLS do need to change when the key derivation > changes. Such as for TLS 1.2. However, those changes are largely limite= d > to the TLS library, not the EAP-TLS code. > > > =E2=80=A2 RFC5216 specifies that "EAP-TLS implementations MUST su= pport TLS > v1.0". > > You're free to deprecate TLS 1.0 in documents which update RFC5216... i= f > you have IETF consensus. > > Further, you're free to mandate use of TLS 1.3 in 5G specifications. > They're your specifications, and you're free to ignore IETF requirements = if > you so choose. > > > =E2=80=A2 RFC5216 specifies that cipher suites with 3DES, SHA-1, = RC4, CBC, > and MD5 are mandatory-to-implement for EAP-TLS (i.e. not based on the TLS > version). > > The same comment as above applies here. > > > If IETF does not provide new message flow diagrams for EAP-TLS with TL= S > 1.3, it is likely that 3GPP will do that, we would much rather see an IET= F > RFC that 3GPP and other can refer to. > > What, exactly is different with the message flows in EAP-TLS when TLS > 1.3 is used? > > Please be specific. > > Alan DeKok. > > --001a1143835aac1fa5055e1a3fd2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Alan said:=C2=A0

"=C2=A0Further, you're free to mandate use of TLS 1.3 i= n 5G specifications.=C2=A0 They're your specifications, and you're = free to ignore IETF requirements if you so choose."
<= br>
[BA] There are many organizations who have imposed cryptograp= hic or version policies on their EAP-TLS implementations.=C2=A0 For example= , governments requiring FIPS 140-3 compliance configure their AAA servers t= o impose that requirement.=C2=A0 No change to the specification is required= for members of 3GPP to configure such restrictions in their AAA servers.= =C2=A0

Of course, imposing such a restriction is o= nly practical if you're willing to deny access to devices that don'= t implement TLS 1.3. That typically is only workable in the case of a new s= ervice that can only be accessed with new devices conforming to a new speci= fication.=C2=A0

If that is the situation we're= talking about, 3GPP can add TLS cryptographic or version restrictions to t= heir specifications.=C2=A0 That wouldn't violate RFC 5216, and it would= avoid imposing huge costs on everyone else.=C2=A0

On Thu, Nov 16, 2017 at 5:02 A= M, Alan DeKok <aland@deployingradius.com> wrote:
=
On Nov 16, 2017, at 12:16 A= M, Mohit Sethi <mohit.m.se= thi@ericsson.com> wrote:
>
> Coming back to our motivation for this draft. 3GPP has decided that au= thentication in 5G can be done with any type of credential that the operato= r accepts and that EAP will be used for authentication. The working assumpt= ion is that EAP-TLS will be used for mutual authentication with certificate= s. 3GPP would likely want to use TLS 1.3 as much as possible, especially fo= r EAP-TLS, as TLS 1.3 reduces the numbers of roundtrips in EAP-TLS as well = as providing encryption of the handshake including the certificates.

=C2=A0 That's good.=C2=A0 But as Bernard points out, there's= no need to change EAP-TLS.=C2=A0 You can just use TLS 1.3.

=C2=A0 I think one of the concerns here is the procedural aspect.=C2=A0 You= r proposal was to forbid everyone *else* from using TLS 1.0 because your re= quirements were for TLS 1.3.=C2=A0 That's not the way to gain support.<= br>
=C2=A0 In addition, your other arguments are hand-waving, and don't pro= vide concrete details to back up your position.=C2=A0 Having concrete detai= ls would help.

> If the EAP community decides that RFC5216 adequately describes how to = use TLS 1.3 and does not need an update we can live with that. Our conclusi= on is however that an update of RFC2516 is needed for several reasons:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 RFC5216 is very much tied to the m= essage flows and message formats in TLS 1.0 - 1.2. The message flows and me= ssage content in TLS 1.3 is very different. While a developer could theoret= ically figure out how to use EAP-TLS with TLS 1.3, such an implementation w= ould not follow RFC5216

=C2=A0 How so?=C2=A0 5216 says (essentially) "encapsulate TLS w= ithin EAP".=C2=A0 How, exactly, does this change with TLS 1.3?

> and in the worst case, implementations would not even be compatible. >=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 TLS 1.3 makes major changes to the= Key Schedule. The PRF in TLS 1.0 is 1.2 is replaced with a HKDF. Our under= standing is that an update defining the Key Hierarchy in terms of the TLS-E= xporter (similar to what is done in draft-ietf-quic-tls) is needed.

=C2=A0 Implementations of EAP-TLS do need to change when the key der= ivation changes.=C2=A0 Such as for TLS 1.2.=C2=A0 However, those changes ar= e largely limited to the TLS library, not the EAP-TLS code.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 RFC5216 specifies that "EAP-T= LS implementations MUST support TLS v1.0".

=C2=A0 You're free to deprecate TLS 1.0 in documents which update RFC52= 16... if you have IETF consensus.

=C2=A0 Further, you're free to mandate use of TLS 1.3 in 5G specificati= ons.=C2=A0 They're your specifications, and you're free to ignore I= ETF requirements if you so choose.

>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 RFC5216 specifies that cipher suit= es with 3DES, SHA-1, RC4, CBC, and MD5 are mandatory-to-implement for EAP-T= LS (i.e. not based on the TLS version).

=C2=A0 The same comment as above applies here.

>=C2=A0 If IETF does not provide new message flow diagrams for EAP-TLS w= ith TLS 1.3, it is likely that 3GPP will do that, we would much rather see = an IETF RFC that 3GPP and other can refer to.

=C2=A0 What, exactly is different with the message flows in EAP-TLS = when TLS 1.3 is used?

=C2=A0 Please be specific.

=C2=A0 Alan DeKok.


--001a1143835aac1fa5055e1a3fd2-- From nobody Thu Nov 16 09:35:26 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9D4126BF6 for ; Thu, 16 Nov 2017 09:35:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ieU6_LVQHBb for ; Thu, 16 Nov 2017 09:35:21 -0800 (PST) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65B0B124C27 for ; Thu, 16 Nov 2017 09:35:21 -0800 (PST) Received: by mail-ot0-x236.google.com with SMTP id g104so11112785otg.7 for ; Thu, 16 Nov 2017 09:35:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7yqc/EDn6H1iBcVgImquTh2QWSnHxWnIgChc9kyu8/8=; b=VF4fn0hQ9DJ+bUkTVu4dtihvLnABDcePcmvQpV9Bn7Xn85X9T6I8FsSCv4O8cBjbqS y65InxJ961ly+XQoj8DsnhA0/XJENjLt+9TGZRuQcQhnYS1GSP6Ep7NJJgx7pKQdW4gp xjekMSmXRDi75mrnL3WKnadkkiHxcAV2P1o3Yq/0wYe7ry3o2mPP6/iNA+jo1md3dbV8 0RsGi2MrDA8j6coVIsjPpGeWG4bcRPxhoprn5rKYppppHinU+moROoKpropou2IV+bRh jR3E6uVaj8TRXHT84cDlYakOk5a+yyohZlkC9Lm8h/Om15VGng8cY10douaqsdd2NusA Mznw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7yqc/EDn6H1iBcVgImquTh2QWSnHxWnIgChc9kyu8/8=; b=oqy7n/f+ItZ+Rq+BkO5LhE9/YhBnMAZ739HIOL99x+7trrWYq83zWsWp8Q09UEPO+w R8tdX1NfGfSXYa0VyJsXSPxqBwf7mDAse6iLj1NxLXRerNVc2wTJ+SAo7BNjwNzvmHRT I8xWTCcC7IjMEwG2K0pcUdiCzuetv/yKUwZ5fGg8iFPTdQGQb5sojOwA9ZPWR/DuMy9K 8WiI1inzX2LEOcsnZ2fMAcdGOuu138FjmynoyDouJHKxaew+kyulzlPHSAyf/NyAKjQE oqlZfb+mWrdelF0g5zpMhRVX5ukfL/sAbBBeZ/vdFn7dCK3OF8L0eBmbjlEPJ3bHx+cr 7Bpw== X-Gm-Message-State: AJaThX7YxgaqMHU9sbqXzkr7SHsRSetY9y0o6QXpoGpHfbO8KKB64KoW YrRNmzlHjmFjXfWTMROlL9ezVTijTVm7/DHCl5I= X-Google-Smtp-Source: AGs4zMa8voLFtqJRzR/YhhPT497TMpxXYfDlgipAIcIAB1BNLGDnIPmQc7INZSpVQ1sT9rMauqnwaVOeBRweO+fdXbE= X-Received: by 10.157.25.2 with SMTP id j2mr1866986ota.16.1510853720644; Thu, 16 Nov 2017 09:35:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Thu, 16 Nov 2017 09:35:19 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Fri, 17 Nov 2017 01:35:19 +0800 Message-ID: To: "Dr. Pala" Cc: "saag@ietf.org" , "Polk, Tim (Fed)" Content-Type: multipart/related; boundary="f4030435b334544783055e1d0b4f" Archived-At: Subject: Re: [saag] OCSP over DNS X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 17:35:24 -0000 --f4030435b334544783055e1d0b4f Content-Type: multipart/alternative; boundary="f4030435b334544781055e1d0b4e" --f4030435b334544781055e1d0b4e Content-Type: text/plain; charset="UTF-8" This is the current advice: https://www.iab.org/documents/correspondence-reports-documents/2017-2/iab-statement-on-ocsp-stapling/ And here is some info on its relative prevalence: https://mzl.la/2AQ7gpM To address your points: * The primary part of a CA workload is signing, not storage and retrieval of OCSP. * Stapling provides superior access, security and (critically) privacy. DNS would not be any significant improvement over CRL or OCSP privacy. * That thread you cite is very old and not any basis for a decision in 2017. You didn't address the comment I made about the cache - stapling has the virtue that it results in a cache of the OCSP in exactly one place: the entity that holds the certificate. DNS caching would result in copies in DNS caches throughout the network. I don't understand the claim that DNS provides better access for certificate-holders. The number of places that HTTP fails and DNS succeeds is not significant enough to be relevant. On Thu, Nov 16, 2017 at 5:08 PM, Dr. Pala wrote: > Hi all, > > although the I-D was not adopted by IETF, I have one question and I would > like to provide some comments related to proposal that might have not been > conveyed or stressed enough. > > The question is: in order to effectively move forward with our work, how > can we request the allocation for the DNS RR type for OCSP response data ? > Is there a possibility to get it allocated even if the submission will be > an individual one ? > > First of all, although mechanisms like OCSP stapling exist and are used in > (some) environments like Web/Browsers [*] , there are many environment > where that is not happening (not implemented). Even when stapling is > supported, the parties (client and server) still need to retrieve the OCSP > responses somehow and HTTP/s might not be a viable option - maybe I failed > in conveying this point, but I think it is a very important one. Last but > not least, reducing the amount of data sent for establishing secure > sessions might not be relevant for large devices (e.g., laptop/etc.) or > generic applications (e.g. browsers), but it definitely matter in the IoT > space. > > On the costs associated with the distribution of revocation information, I > think that the comments on that were not really based on data. Large PKIs > exist outside the ICA that issue BILLIONS of certificates and the proposed > solution might not only be encouraged but required to provide revocation > support in those environment. > > This said, I am still a bit confused about the reasons for not adopting > this work since it would improve access to revocation information, lower > operational costs for CAs (and thus lowering the costs of certificates > management), and, in general, provide more options for a more secure > networking environment. > > Last but not least, I would like to thank all the people that actually > provided support and valuable comments (from ISC to individual > contributors). Also, in case any of the people on the list are still > interested in pursuing the idea and improve the draft (that is what we were > hoping for - improving an INITIAL idea), please contact me directly as the > work will still continue outside the IETF. > > Thanks again for the opportunity to present at DISPATCH. > > Cheers, > Max > > [*] = Fun fact, here's reference of a thread in the mozilla sec lists > where this proposal was positively considered even back in 2011 - > https://groups.google.com/forum/#!topic/mozilla.dev. > security.policy/pfFLvTFZxE8 > -- > Best Regards, > Massimiliano Pala, Ph.D. > OpenCA Labs Director > [image: OpenCA Logo] > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > > --f4030435b334544781055e1d0b4e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is the current advice:

=
And here is some info on its relative prevalence:

To address your points:
* The primary part of a CA workload= is signing, not storage and retrieval of OCSP.
* Stapling provid= es superior access, security and (critically) privacy.=C2=A0 DNS would not = be any significant improvement over CRL or OCSP privacy.
* Th= at thread you cite is very old and not any basis for a decision in 2017.

You didn't address the comment I made about the = cache - stapling has the virtue that it results in a cache of the OCSP in e= xactly one place: the entity that holds the certificate.=C2=A0 DNS caching = would result in copies in DNS caches throughout the network.

=
I don't understand the claim that DNS provides better access= for certificate-holders.=C2=A0 The number of places that HTTP fails and DN= S succeeds is not significant enough to be relevant.

On Thu, Nov 16, 2017 at 5:0= 8 PM, Dr. Pala <director@openca.org> wrote:
=20 =20 =20

Hi all,

although the I-D was not adopted by IETF, I have one question and I would like to provide some comments related to proposal that might have not been conveyed or stressed enough.

The question is: in order to effectively move forward with our work, how can we request the allocation for the DNS RR type for OCSP response data ? Is there a possibility to get it allocated even if the submission will be an individual one ?

First of all, although mechanisms like OCSP stapling exist and are used in (some) environments like Web/Browsers [*] , there are many environment where that is not happening (not implemented). Even when stapling is supported, the parties (client and server) still need to retrieve the OCSP responses somehow and HTTP/s might not be a viable option - maybe I failed in conveying this point, but I think it is a very important one. Last but not least, reducing the amount of data sent for establishing secure sessions might not be relevant for large devices (e.g., laptop/etc.) or generic applications (e.g. browsers), but it definitely matter in the IoT space.

On the costs associated with the distribution of revocation information, I think that the comments on that were not really based on data. Large PKIs exist outside the ICA that issue BILLIONS of certificates and the proposed solution might not only be encouraged but required to provide revocation support in those environment.

This said, I am still a bit confused about the reasons for not adopting this work since it would improve access to revocation information, lower operational costs for CAs (and thus lowering the costs of certificates management), and, in general, provide more options for a more secure networking environment.

Last but not least, I would like to thank all the people that actually provided support and valuable comments (from ISC to individual contributors). Also, in case any of the people on the list are still interested in pursuing the idea and improve the draft (that is what we were hoping for - improving an INITIAL idea), please contact me directly as the work will still continue outside the IETF.

Thanks again for the opportunity to present at DISPATCH.

Cheers,
Max

[*] =3D Fun fact, here's reference of a thread in the mozilla se= c lists where this proposal was positively considered even back in 2011 - https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/pfFLvTFZxE8

--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA

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


--f4030435b334544781055e1d0b4e-- --f4030435b334544783055e1d0b4f Content-Type: image/png; name="nkgniblnbknhlflj.png" Content-Disposition: inline; filename="nkgniblnbknhlflj.png" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: e7d0715865738d7f_0.0.0.1.1 iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoXBwES CQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAqMjpXKgs/ MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1SGdDR0lDSFJf RDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27PgCaSANtUT57VBer SQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXaeVR+lVRZrYld1ZiB7YEuS YQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDVWQJ1blapYjbXWgDRXACMaU6W bgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3WqaS6BcGeobwndXwzkXwLgYgDaYwyM eCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuvcEPrZQDQaSyockrFbSvmZwnabQLvZwDp aQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqK gnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXleSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQ iwCximixim/EkAORkZGVkYrOh0rPiVL5giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvK lGqpnJLdlF2boKy+m324nImkoZ+eo6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/S rI7dq4bqqXTOrpWttL+6s6uwtbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfR wbXFyMvbxbPNyMP8zgTczMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp 7/Hy9PHw9fj6/v3YktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPX GT6E+l9BZ0EFsTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+U SgFL4r9gEaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqE SrMplYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75UjLZf p6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/85sH2KeX vj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf70RPUPjxLouB EgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxcAwyWTbacW0sTDGoJ en4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+NpuKpq32qLVaexOCCJB91 aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq1LzUMQ4uxxycjl0LWO1bBsY6 yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XOcajZb6GDu7PTFEdPkVu0k4vQyd3J c/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV 2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRbjuxtfqRypNACK28+j3FsqcilAD0ADuIWCt0y Ra7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7 QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxar lr0grlQn92DQt1vBUk+nUFeHGZmegUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJ o+2PGLb2d9WE5bw1L4DcnOco9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bF zhw3eZylM2dgwkbWW3IyJp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwd ElJmarxedr/u3P6CNn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivo BjrfUgNB69zfb6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toV EevCi9/ffmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzS Y3FuBkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/dY1p7 qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1RgrYlfrRe SqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxHdRJFGJkhfKxg mM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3luaLNe1F++bjXGyWyz ZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCmGIzpqKlm27KTSWUcAX1g oBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJCBVkrrBJ1BewMmlVpgRUQF7wp ItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQYIOhklDKzo2C1IV2sijzdhjorqwef NdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41qKFl02YaswYNkULTeLC9CFFK4bDHDMmZb hnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYvJpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkc Hz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkhmt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlC XaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7Wfg ZOv4uLLl0w8wUah71QLBpJeXq/eMVVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6 vjt1z/ghMehVKiUpyt1VYBXCN6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oE DQ6jB9Wc3Z6bm6zLTtLlgLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgX s2kV4WUC0YR/KOLvPby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP 7LnTfsd42at3+B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw90 1G+ttVlTJa34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K +f59qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a8XoA AAAASUVORK5CYII= --f4030435b334544783055e1d0b4f-- From nobody Thu Nov 16 10:15:45 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D04901270FC for ; Thu, 16 Nov 2017 10:15:43 -0800 (PST) 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 JfXZEYZUCf7j for ; Thu, 16 Nov 2017 10:15:41 -0800 (PST) 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 8CA971205F1 for ; Thu, 16 Nov 2017 10:15:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 14AF7BE5B; Thu, 16 Nov 2017 18:15:39 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie 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 WYGW46-HGHKL; Thu, 16 Nov 2017 18:15:37 +0000 (GMT) Received: from [31.133.146.132] (dhcp-9284.meeting.ietf.org [31.133.146.132]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 729EABE39; Thu, 16 Nov 2017 18:15:36 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1510856137; bh=H1AoHJ3dqECbCKFs5tjYDa5UrzxmsCC40erX5g9yqYE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=ulitJmB/+q37lqQVpmF7YOZhSPIULjuYfpKgTe1ItDhfmCiLXE2QinuA5PGDtDJ4m do2hyJKImeJVGBLHDR2fuyu9eeCKfd7FXfOtTIW4ymmQ41V3mXKi3ndC7zLnvMTTKm mEZFB1j12acTvN8PNjNIKjTMf56tnTeiFJkbPlG4= To: Paul Hoffman , Brian Witten Cc: "saag@ietf.org" References: <6DF7F2EB-80AE-4AB9-A98F-076F12B4B8BD@vpnc.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <92dccb1f-5194-5632-a35f-ad31f2ca8b85@cs.tcd.ie> Date: Thu, 16 Nov 2017 18:15:33 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <6DF7F2EB-80AE-4AB9-A98F-076F12B4B8BD@vpnc.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="M0LQ7dqrlADPrRBdGX3NgFRG98EQVkPkC" Archived-At: Subject: Re: [saag] patient ietf100 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 18:15:44 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --M0LQ7dqrlADPrRBdGX3NgFRG98EQVkPkC Content-Type: multipart/mixed; boundary="QGw4WKJ6mQEdJkUbK792wb0mGEiuA5TUH"; protected-headers="v1" From: Stephen Farrell To: Paul Hoffman , Brian Witten Cc: "saag@ietf.org" Message-ID: <92dccb1f-5194-5632-a35f-ad31f2ca8b85@cs.tcd.ie> Subject: Re: [saag] patient ietf100 References: <6DF7F2EB-80AE-4AB9-A98F-076F12B4B8BD@vpnc.org> In-Reply-To: <6DF7F2EB-80AE-4AB9-A98F-076F12B4B8BD@vpnc.org> --QGw4WKJ6mQEdJkUbK792wb0mGEiuA5TUH Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 16/11/17 10:12, Paul Hoffman wrote: > On 16 Nov 2017, at 12:58, Brian Witten wrote: >=20 >> The PATIENT side-meeting last night was well attended, though with >> clearly divided discussion.=C2=A0 Thank You Again To All Who Participa= ted.=C2=A0 >> Next step is to assemble an Internet Draft presenting verifiable data >> on merits of third party security, particularly third party network >> security.=C2=A0 I'll do this over next few weeks with help from volunt= eers. >=20 > I would love to hear more about what was said at the meeting. Are there= > fuller notes somewhere? I'm not sure if there are notes. I think one of the proponents was taking some so I guess they'll speak up on that when they get a chance. My take: it went as expected. The proponents wanted a standard way to mitm https between enterprise browsers and the Internet so as to do malware scanning. That was discussed with the usual points raised and at the end (10pm) about 25% of the room wanted to pursue something like that and 75% didn't want the IETF to go there. I did miss the start of the session and do have a position on this so it is at least theoretically possible that the above might not be perfectly objective;-) S. >=20 > --Paul Hoffman >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag >=20 --QGw4WKJ6mQEdJkUbK792wb0mGEiuA5TUH-- --M0LQ7dqrlADPrRBdGX3NgFRG98EQVkPkC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJaDdXFAAoJEC88hzaAX42iHOMH/1xMW2dn77gK3+TW1zBUpSXU GECr6u3dCIF+L0i1r88AxnyMtfGkT5VKo9mnib+OQ86QtOBrdRk4+YNuyHaZNLqu 0witkyqtqkue0Q+/xpeiob9F85ZZ46TaDIQiYj8fUsI+ngJ/JvwEwHemDFb85wOi /PD3yi3wXjrrWoGO/xVelGy8RqpteFVuOYo2g9VhDfVNTK6vZUdfnFCIvfsQgfxi IXS6NQmOHkmQws20ZRJfHfgQUd/e/crvjo8I9famOeXqVewtpySFORJFvlO5YMbq p/XDbn9JHj45LjTBBoeSu6bnvhPC659oGTizA2VEUQnhT3Hv5atKVd7m2CGA784= =XQ/q -----END PGP SIGNATURE----- --M0LQ7dqrlADPrRBdGX3NgFRG98EQVkPkC-- From nobody Thu Nov 16 14:27:44 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E6B1273E2 for ; Thu, 16 Nov 2017 14:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.39 X-Spam-Level: X-Spam-Status: No, score=-1.39 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_HK_NAME_DR=0.01] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S5PsYgtRKdTu for ; Thu, 16 Nov 2017 14:27:37 -0800 (PST) Received: from mail.katezarealty.com (mail.katezarealty.com [104.168.158.213]) by ietfa.amsl.com (Postfix) with ESMTP id 473D7126BF3 for ; Thu, 16 Nov 2017 14:27:37 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.katezarealty.com (Postfix) with ESMTP id 193D83741015; Thu, 16 Nov 2017 22:27:37 +0000 (UTC) X-Virus-Scanned: amavisd-new at katezarealty.com Received: from mail.katezarealty.com ([127.0.0.1]) by localhost (mail.katezarealty.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Mw5UX1bxveef; Thu, 16 Nov 2017 17:27:32 -0500 (EST) Received: from dhcp-98fb.meeting.ietf.org (dhcp-98fb.meeting.ietf.org [31.133.152.251]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.katezarealty.com (Postfix) with ESMTPSA id 9BAAF3740FDE; Thu, 16 Nov 2017 17:27:30 -0500 (EST) To: Martin Thomson Cc: "saag@ietf.org" , "Polk, Tim (Fed)" , Kathleen Moriarty References: From: "Dr. Pala" Organization: OpenCA Labs Message-ID: Date: Fri, 17 Nov 2017 06:27:28 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090204020005010601080504" Archived-At: Subject: Re: [saag] OCSP over DNS X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Nov 2017 22:27:41 -0000 This is a cryptographically signed message in MIME format. --------------ms090204020005010601080504 Content-Type: multipart/alternative; boundary="------------5825C96D828B80D5DB566041" Content-Language: en-US This is a multi-part message in MIME format. --------------5825C96D828B80D5DB566041 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi Martin, thanks for the reply. In general, I am a bit puzzled by the fact that=20 you focus your attention on OCSP stapling. The proposal does not address = or try to improve that in any way. The fair and right comparison from an = engineering standpoint of view would be to compare it with OCSP over=20 HTTP. It seems to me that this is a pretty important point that probably = you might have ... missed ? Don't you agree? Have you read Section 3 of=20 the draft ? After all, even when using OCSP stapling, the OCSP response need to be=20 retrieved by the communication party - that is what we should talk=20 about, I think. This said, let me try to address your points where relevant.. I always=20 enjoy an healthy discussion :D My responses inline. On 11/17/17 1:35 AM, Martin Thomson wrote: > This is the current advice: > https://www.iab.org/documents/correspondence-reports-documents/2017-2/i= ab-statement-on-ocsp-stapling/ This report provides a good description about OCSP stapling, and I do=20 not disagree that in the environment where this report is actually=20 relevant (Browser), that is a great solution. As pointed out at the end=20 of the report, however, it seems that its adoption is far from being=20 widespread - the report says that only 20% of the website actually do=20 adopt stapling (Feb 2017). Interesting post, but I do not think is relevant for the proposal=20 evaluation. In the view of the two solution not to be in competition but = complementary, can you explain why this is relevant for the proposal=20 evaluation ? > And here is some info on its relative prevalence: > https://mzl.la/2AQ7gpM Thanks for the link.. probably is the lack of sleep but it seems a bit=20 difficult to interpret the data. In particular it seems that the first=20 graph is related to the current session, while the second is the total=20 submission of OCSP stapling reported by Firefox ? If that is the case,=20 it would be interesting to know what is the percentage with respect of=20 all the website visited. If that is correct, than the numbers seem quite = low (I think I am interpreting this graph wrong because the numbers=20 seems way too low...) - 15/20M is not a large number calculated daily.=20 But as I said, I must have the interpretation wrong - could you please=20 provide some details about how to interpret the data ? The third graph's = numbers seem more in the ballpark of what I would expect, but without a=20 percentage of how many websites actually use stapling, it is difficult=20 to interpret the data. As I said during the meeting, I am NOT discounting the value of OCSP=20 stapling - I never did. It is a good approach that has been around for=20 quite a while and has its merits. If in the browsers' / web environment=20 that works fine, great. But I do not think this solution works for=20 everybody. And, as explained in the first paragraph, I think that the=20 comparison should be done with OCSP over HTTP instead. Providing a standard that describes how to use DNS in environments that=20 have different constraints and characteristics than the environment you=20 are probably used to, seems, to me, a good idea for providing=20 interoperability for those environment that might require a different=20 solution. Also this link, although interesting, does not qualify as a relevant=20 point for the evaluation of the proposal. In the view of the two=20 solution not to be in competition but complementary, can you explain why = this is relevant for the proposal evaluation ? > > To address your points: > * The primary part of a CA workload is signing, not storage and=20 > retrieval of OCSP. I do strongly disagree with this statement. The primary "part" or better = role of a CA is to provide a trust path for applications to be able to=20 authenticate and protect data and communication. The load for signing=20 certificates is, actually, negligible. On commodity servers you can=20 easily have the capacity to address practically any load (I grant you=20 that today's HSM really fall behind when it comes to 2017 standards...=20 ). For example, in my previous job, our (internally developed)=20 certification system could easily crank out 500M certificates a day on a = single server (full process: certificate requests -> server ->=20 certificate signing -> certificate returned to the client) [this is real = data]. For the storage and retrieval of OCSP I am not sure why you say that=20 that is not part of the primary CA's responsibility. We can argue about=20 how the revocation system might be improved (I proposed several times to = open a WG to address, at least, the revocation issue in PKIX but,=20 unfortunately, that was at times ignored and at times rejected with the=20 "we don't want to do PKIX anymore" pointless rant) - but that is not the = scope of the proposal here. Since today's trust model is based on the=20 availability (and checking) of revocation information, a CA should=20 provide revocation information and make it available as much as possible.= This said, I do not think this is a relevant argument/point for the=20 evaluation of the proposal. If you disagree, can you please provide a=20 more extensive argument for the above statement and why it is relevant=20 in this case ? > * Stapling provides superior access, security and (critically)=20 > privacy.=C2=A0 DNS would not be any significant improvement over CRL or= =20 > OCSP privacy. Again, I am not saying using DNS is an improvement over OCSP stapling -=20 since they are not in competition and address slightly different=20 problems (after all, OCSP stapling still required OCSP over HTTP, right=20 ?). Actually there are many good arguments about the fact that the=20 distributed nature of the DNS would actually help in case of experienced = downtime of OCSP responders or DDoS attacks. The party who staples the=20 response, still need to access the OCSP responder at some point - DNS=20 could be a viable fallback mechanism to provide business continuity. If possible, I would like you to qualify more your statements on these=20 three points. Here's my attempt at providing some considerations about=20 your generic statement above: * In which way stapling provide superior access ? What about who has to retrieve the response, that is not OCSP stapling but OCSP over HTTP. This is the transport protocol we should compare to, not OCSP stapling which is orthogonal to the proposal. Do you disagree? If so, can you tell me why? * In which way OCSP stapling is superior for security ? Since OCSP stapling depends on the ability to retrieve the response in the first place, I would say that the comparison should be with OCSP over HTTP from this point of view. If you read the draft, the security considerations cover this topic. Once the response is in the hands of the client or server, then the in-band deliver to the other party is secure, but OCSP over DNS does not prevent using OCSP stapling where supported. * When it comes to OCSP and privacy, the two solutions are not that dissimilar since the client never contacts the CA's DNS server directly, IMHO. I do not think that the proposal weakens today's situation (in the vision of 20% deployment). OCSP stapling is, in my opinion, far worse from this point of view when it comes to client certificates (clients have to directly retrieve their own OCSP response in order to be able to staple it, don't they ?), IMHO. > * That thread you cite is very old and not any basis for a decision in = > 2017. That is correct, it is an old thread and was provided as an example - as = I said during the presentation, the idea is not new. However, I think=20 that age has never qualified as a valid technical consideration :D So I=20 do not understand your point here. "old" is not "bits on the wire".=20 Sorry, I do not want to be polemic here, but I would like to focus the=20 discussion on the technical merits. If the thread contains reasonable=20 and sound technical considerations, why those can not contribute to a=20 decision in 2017 ? Can you please qualify more your statement ? > You didn't address the comment I made about the cache - stapling has=20 > the virtue that it results in a cache of the OCSP in exactly one=20 > place: the entity that holds the certificate. DNS caching would result = > in copies in DNS caches throughout the network. And this is wrong because.... ? Wouldn't be the same argument for other=20 protocols like DANE as well ? I think that leveraging distributed cache=20 to bring the data actually closer to where it is needed is actually a=20 very good thing, not a bad one. Have you considered the advantages of cross-application caching ?=20 Stapling does not provide that. But again, you would have to compare the = caching capabilities of HTTP to the ones of DNS (same argument, let's=20 compare apples with apples, not apples with apple juice) > I don't understand the claim that DNS provides better access for=20 > certificate-holders.=C2=A0 The number of places that HTTP fails and DNS= =20 > succeeds is not significant enough to be relevant. Martin, the world is more complex than you picture here. You say it is=20 not relevant, but I do disagree with this statement. What works for=20 browsers might not work in other (maybe more constrained) environments=20 like class1 devices, corporate environments, restricted networks, etc. In general, I would say, that the proposal has good technical merits and = I think I did address all of your points - the time for the presentation = was not enough and even the time to actually reply was insufficient, I=20 hope I clarified all your doubts with this very detailed reply. I am actually quite surprised about this resistance to even given the=20 idea a shot but that is what happened. I wonder how many people did=20 actually read the proposal, and how many of them have experience running = large CAs or network with large number of mutually authenticated=20 objects/devices/agents. From the type of discussions, questions, and=20 remarks it seems that the set is pretty small. Although, as I said, I am an old-time believer... I do not think it is=20 worth proposing more work here unless the technical evaluation is=20 properly done (I am a very reasonable person and very open to=20 discussions, but that is not what happened, IMO). In particular, I think = that the SEC dispatch really does not provide presenters enough time to=20 give ideas a fair shot (especially anything that touches, in any way,=20 established TLS practices) because the limited amount of time and=20 because the audience might not have the technical expertise in=20 particular areas to provide sound technical judgments. Even someone as expert as you that does such amazing work in TLS have=20 completely missed the main point (OCSP Stapling instead of OCSP over=20 HTTP) in a very short draft. Maybe it is my fault, have I forgotten to=20 spell it out explicitly ? Honestly, I did not think there was much need=20 for more than what is in Section 3 of the document - did you miss that=20 section or you just disagreed with the considerations there ? I already sent this feedback to the SEC dispatch chairs and I hope it=20 might help to improve future sessions for the people who will be willing = to be shot at. This experience, sincerely, made me regret taking this=20 work to the IETF - a feeling shared among many newcomers, as we all know.= Thanks again for your reply, looking forward to your (or other people)=20 reply, Cheers, Max > > On Thu, Nov 16, 2017 at 5:08 PM, Dr. Pala > wrote: > > Hi all, > > although the I-D was not adopted by IETF, I have one question and > I would like to provide some comments related to proposal that > might have not been conveyed or stressed enough. > > The question is: in order to effectively move forward with our > work, how can we request the allocation for the DNS RR type for > OCSP response data ? Is there a possibility to get it allocated > even if the submission will be an individual one ? > > First of all, although mechanisms like OCSP stapling exist and are > used in (some) environments like Web/Browsers [*] , there are many > environment where that is not happening (not implemented). Even > when stapling is supported, the parties (client and server) still > need to retrieve the OCSP responses somehow and HTTP/s might not > be a viable option - maybe I failed in conveying this point, but I > think it is a very important one. Last but not least, reducing the > amount of data sent for establishing secure sessions might not be > relevant for large devices (e.g., laptop/etc.) or generic > applications (e.g. browsers), but it definitely matter in the IoT > space. > > On the costs associated with the distribution of revocation > information, I think that the comments on that were not really > based on data. Large PKIs exist outside the ICA that issue > BILLIONS of certificates and the proposed solution might not only > be encouraged but required to provide revocation support in those > environment. > > This said, I am still a bit confused about the reasons for not > adopting this work since it would improve access to revocation > information, lower operational costs for CAs (and thus lowering > the costs of certificates management), and, in general, provide > more options for a more secure networking environment. > > Last but not least, I would like to thank all the people that > actually provided support and valuable comments (from ISC to > individual contributors). Also, in case any of the people on the > list are still interested in pursuing the idea and improve the > draft (that is what we were hoping for - improving an INITIAL > idea), please contact me directly as the work will still continue > outside the IETF. > > Thanks again for the opportunity to present at DISPATCH. > > Cheers, > Max > > [*] =3D Fun fact, here's reference of a thread in the mozilla sec > lists where this proposal was positively considered even back in > 2011 - > https://groups.google.com/forum/#!topic/mozilla.dev.security.policy= /pfFLvTFZxE8 > > > --=20 Best Regards, Massimiliano Pala, Ph.D. OpenCA Labs Director OpenCA Logo --------------5825C96D828B80D5DB566041 Content-Type: multipart/related; boundary="------------0AC1D55F4906953221D54E92" --------------0AC1D55F4906953221D54E92 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Hi Martin,

thanks for the reply. In general, I am a bit puzzled by the fact that you focus your attention on OCSP stapling. The proposal does not address or try to improve that in any way. The fair and right comparison from an engineering standpoint of view would be to compare it with OCSP over HTTP. It seems to me that this is a pretty important point that probably you might have ... missed ? Don't you agree? Have you read Section 3 of the draft ?

After all, even when using OCSP stapling, the OCSP response need to be retrieved by the communication party - that is what we should talk about, I think.

This said, let me try to address your points where relevant.. I always enjoy an healthy discussion :D My responses inline.

On 11/17/17 1:35 AM, Martin Thomson wrote:
This report provides a good description about OCSP stapling, and I do not disagree that in the environment where this report is actually relevant (Browser), that is a great solution. As pointed out at the end of the report, however, it seems that its adoption is far from being widespread - the report says that only 20% of the website actually do adopt stapling (Feb 2017).

Interesting post, but I do not think is relevant for the proposal evaluation. In the view of the two solution not to be in competition but complementary, can you explain why this is relevant for the proposal evaluation ?
And here is some info on its relative prevalence:
Thanks for the link.. probably is the lack of sleep but it seems a bit difficult to interpret the data. In particular it seems that the first graph is related to the current session, while the second is the total submission of OCSP stapling reported by Firefox ? If that is the case, it would be interesting to know what is the percentage with respect of all the website visited. If that is correct, than the numbers seem quite low (I think I am interpreting this graph wrong because the numbers seems way too low...) - 15/20M is not a large number calculated daily. But as I said, I must have the interpretation wrong - could you please provide some details about how to interpret the data ? The third graph's numbers seem more in the ballpark of what I would expect, but without a percentage of how many websites actually use stapling, it is difficult to interpret the data.

As I said during the meeting, I am NOT discounting the value of OCSP stapling - I never did. It is a good approach that has been around for quite a while and has its merits. If in the browsers' / web environment that works fine, great. But I do not think this solution works for everybody. And, as explained in the first paragraph, I think that the comparison should be done with OCSP over HTTP instead.

Providing a standard that describes how to use DNS in environments that have different constraints and characteristics than the environment you are probably used to, seems, to me, a good idea for providing interoperability for those environment that might require a different solution.

Also this link, although interesting, does not qualify as a relevant point for the evaluation of the proposal. In the view of the two solution not to be in competition but complementary, can you explain why this is relevant for the proposal evaluation ?

To address your points:
* The primary part of a CA workload is signing, not storage and retrieval of OCSP.
I do strongly disagree with this statement. The primary "part" or better role of a CA is to provide a trust path for applications to be able to authenticate and protect data and communication. The load for signing certificates is, actually, negligible. On commodity servers you can easily have the capacity to address practically any load (I grant you that today's HSM really fall behind when it comes to 2017 standards... ). For example, in my previous job, our (internally developed) certification system could easily crank out 500M certificates a day on a single server (full process: certificate requests -> server -> certificate signing -> certificate returned to the client) [this is real data].

For the storage and retrieval of OCSP I am not sure why you say that that is not part of the primary CA's responsibility. We can argue about how the revocation system might be improved (I proposed several times to open a WG to address, at least, the revocation issue in PKIX but, unfortunately, that was at times ignored and at times rejected with the "we don't want to do PKIX anymore" pointless rant) - but that is not the scope of the proposal here. Since today's trust model is based on the availability (and checking) of revocation information, a CA should provide revocation information and make it available as much as possible.

This said, I do not think this is a relevant argument/point for the evaluation of the proposal. If you disagree, can you please provide a more extensive argument for the above statement and why it is relevant in this case ?
* Stapling provides superior access, security and (critically) privacy.=C2=A0 DNS would not be any significant improvement over CRL or OCSP privacy.
Again, I am not saying using DNS is an improvement over OCSP stapling - since they are not in competition and address slightly different problems (after all, OCSP stapling still required OCSP over HTTP, right ?). Actually there are many good arguments about the fact that the distributed nature of the DNS would actually help in case of experienced downtime of OCSP responders or DDoS attacks. The party who staples the response, still need to access the OCSP responder at some point - DNS could be a viable fallback mechanism to provide business continuity.

If possible, I would like you to qualify more your statements on these three points. Here's my attempt at providing some considerations about your generic statement above:
  • In which way stapling provide superior access ? What about who has to retrieve the response, that is not OCSP stapling but OCSP over HTTP. This is the transport protocol we should compare to, not OCSP stapling which is orthogonal to the proposal. Do you disagree? If so, can you tell me why?

  • In which way OCSP stapling is superior for security ? Since OCSP stapling depends on the ability to retrieve the response in the first place, I would say that the comparison should be with OCSP over HTTP from this point of view. If you read the draft, the security considerations cover this topic. Once the response is in the hands of the client or server, then the in-band deliver to the other party is secure, but OCSP over DNS does not prevent using OCSP stapling where supported.

  • When it comes to OCSP and privacy, the two solutions are not that dissimilar since the client never contacts the CA's DNS server directly, IMHO. I do not think that the proposal weakens today's situation (in the vision of 20% deployment). OCSP stapling is, in my opinion, far worse from this point of view when it comes to client certificates (clients have to directly retrieve their own OCSP response in order to be able to staple it, don't they ?), IMHO.


* That thread you cite is very old and not any basis for a decision in 2017.
That is correct, it is an old thread and was provided as an example - as I said during the presentation, the idea is not new. However, I think that age has never qualified as a valid technical consideration :D So I do not understand your point here. "old" is not "bits on the wire". Sorry, I do not want to be polemic here, but I would like to focus the discussion on the technical merits. If the thread contains reasonable and sound technical considerations, why those can not contribute to a decision in 2017 ? Can you please qualify more your statement ?

You didn't address the comment I made about the cache - stapling has the virtue that it results in a cache of the OCSP in exactly one place: the entity that holds the certificate.=C2= =A0 DNS caching would result in copies in DNS caches throughout the network.
And this is wrong because.... ? Wouldn't be the same argument for other protocols like DANE as well ? I think that leveraging distributed cache to bring the data actually closer to where it is needed is actually a very good thing, not a bad one.

Have you considered the advantages of cross-application caching ? Stapling does not provide that. But again, you would have to compare the caching capabilities of HTTP to the ones of DNS (same argument, let's compare apples with apples, not apples with apple juice)
I don't understand the claim that DNS provides better access for certificate-holders.=C2=A0 The number of places that= HTTP fails and DNS succeeds is not significant enough to be relevant.
Martin, the world is more complex than you picture here. You say it is not relevant, but I do disagree with this statement. What works for browsers might not work in other (maybe more constrained) environments like class1 devices, corporate environments, restricted networks, etc.

In general, I would say, that the proposal has good technical merits and I think I did address all of your points - the time for the presentation was not enough and even the time to actually reply was insufficient, I hope I clarified all your doubts with this very detailed reply.

I am actually quite surprised about this resistance to even given the idea a shot but that is what happened. I wonder how many people did actually read the proposal, and how many of them have experience running large CAs or network with large number of mutually authenticated objects/devices/agents. From the type of discussions, questions, and remarks it seems that the set is pretty small.

Although, as I said, I am an old-time believer... I do not think it is worth proposing more work here unless the technical evaluation is properly done (I am a very reasonable person and very open to discussions, but that is not what happened, IMO). In particular, I think that the SEC dispatch really does not provide presenters enough time to give ideas a fair shot (especially anything that touches, in any way, established TLS practices) because the limited amount of time and because the audience might not have the technical expertise in particular areas to provide sound technical judgments.
Even someone as expert as you that does such amazing work in TLS have completely missed the main point (OCSP Stapling instead of OCSP over HTTP) in a very short draft. Maybe it is my fault, have I forgotten to spell it out explicitly ? Honestly, I did not think there was much need for more than what is in Section 3 of the document - did you miss that section or you just disagreed with the considerations there ?

I already sent this feedback to the SEC dispatch chairs and I hope it might help to improve future sessions for the people who will be willing to be shot at. This experience, sincerely, made me regret taking this work to the IETF - a feeling shared among many newcomers, as we all know.

Thanks again for your reply, looking forward to your (or other people) reply,

Cheers,
Max


On Thu, Nov 16, 2017 at 5:08 PM, Dr. Pala <director@openca.= org> wrote:

Hi all,

although the I-D was not adopted by IETF, I have one question and I would like to provide some comments related to proposal that might have not been conveyed or stressed enough.

The question is: in order to effectively move forward with our work, how can we request the allocation for the DNS RR type for OCSP response data ? Is there a possibility to get it allocated even if the submission will be an individual one ?

First of all, although mechanisms like OCSP stapling exist and are used in (some) environments like Web/Browsers [*] , there are many environment where that is not happening (not implemented). Even when stapling is supported, the parties (client and server) still need to retrieve the OCSP responses somehow and HTTP/s might not be a viable option - maybe I failed in conveying this point, but I think it is a very important one. Last but not least, reducing the amount of data sent for establishing secure sessions might not be relevant for large devices (e.g., laptop/etc.) or generic applications (e.g. browsers), but it definitely matter in the IoT space.

On the costs associated with the distribution of revocation information, I think that the comments on that were not really based on data. Large PKIs exist outside the ICA that issue BILLIONS of certificates and the proposed solution might not only be encouraged but required to provide revocation support in those environment.

This said, I am still a bit confused about the reasons for not adopting this work since it would improve access to revocation information, lower operational costs for CAs (and thus lowering the costs of certificates management), and, in general, provide more options for a more secure networking environment.

Last but not least, I would like to thank all the people that actually provided support and valuable comments (from ISC to individual contributors). Also, in case any of the people on the list are still interested in pursuing the idea and improve the draft (that is what we were hoping for - improving an INITIAL idea), please contact me directly as the work will still continue outside the IETF.

Thanks again for the opportunity to present at DISPATCH.

Cheers,
Max

[*] =3D Fun fact, here's reference of a thread in the mozilla sec lists where this proposal was positively considered even back in 2011 - https://grou= ps.google.com/forum/#!topic/mozilla.dev.security.policy/pfFLvTF= ZxE8



--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
3D"OpenCA
--------------0AC1D55F4906953221D54E92 Content-Type: image/png; name="ckkeppfndilfhdnm.png" Content-Transfer-Encoding: base64 Content-ID: Content-Disposition: inline; filename="ckkeppfndilfhdnm.png" iVBORw0KGgoAAAANSUhEUgAAAGQAAAA2CAMAAAAGesyaAAADAFBMVEUsJiEAAQAKAwMABwoX BwESCQAqDgEkEQItFQESGykaGh0WGyE1FwE9GwJHHwElJiY4JBQmKDE1KCAfLUQ8KygoMEAq MjpXKgs/MilMMR0pOFEyOUo4OTo1OkRqMgpjOBlpNxUwQV1DPz48QExdOyM4QVV+OQRRQzo1 SGdDR0lDSFJfRDFASVyaPwF+RRpNT1I9UXlwSi8+UnNDUm6hQgCPRhBdUEZTUlBKVGlPVF27 PgCaSANtUT57VBerSQOMUgxHW4KMUiepTwmJVDh6WT6KVjGCWDpRYH21TwFiYF57YgJXYXae VR+lVRZrYld1ZiB7YEuSYQBgZW+8VAlkZWjBVQCfXiqqXwG1WhPLVgedYDazXiDZVgCWZEDV WQJ1blapYjbXWgDRXACMaU6WbgCiZjnIXw9mcIixZC6pZjJ/cUeLbFdycmZ4cGnnWwNwc3Wq aS6BcGeobwndXwzkXwLgYgDaYwyMeCq/bQHJaBi9ajDMagWVegvRZxzVaAvXaQDLainqZAuv cEPrZQDQaSyockrFbSvmZwnabQLvZwDpaQB0fpPkaxGld1d+f3/3aACfeV6RfG2JfnLebSF7 gYy2fQmugQCigxW8d0K3eEr1bQXaciTicRqKgnzNewHuchbUdzKYiDzrdwKah1erjAvOfEXl eSq5g1qYjGikiHO2kADigwC2hmSZjIGGj6aHkJzQiwCximixim/EkAORkZGVkYrOh0rPiVL5 giTvhDKkk4LMjF23mR+zmTrhikrviDzsi0TAlHDCnwvKlGqpnJLdlF2boKy+m324nImkoZ+e o6XKpgrloATwl1WypZPOn3zfqQjYrgLBrVDdo3nGq5mysa/SrI7dq4bqqXTOrpWttL+6s6uw tbe/t4rhvALetpjQuqnuwwe9v8LAv7vauqD3xA68w9XBw83rvJfRwbXFyMvbxbPNyMP8zgTc zMDr0mb91xLM1ODQ1NfS1c7p0sD70bPd19PX4qj83cje4+Xr4tv54NLp7/Hy9PHw9fj6/v3Y ktvJAAAAAXRSTlMAQObYZgAAAAFiS0dEAIgFHUgAAAjrSURBVFjDtVcNWFPXGT6E+l9BZ0EF sTKEIQaUAIrTZdYqxqG0I3UjIuiDM0ipoyO5l0rFh2PE472EoIJKL9hQV2OxqM+USgFL4r9g EaIoQxgqKBZBR+nGGhXYdwNro0Kfkcp3ntzce/7e8/2e70PoJVDl3bMlZyurUSsaKnqESrMp lYrByozCjUOEUZORodMRVsViTjJc8GbLUGCUUstLv1SyLCGch8DGRiDPe/kY5/2HCQQTxZEE y4fb2gDI8KjjLxsjfyyc3lZgM3KixwgeY4TEzk7+kjHODbeb6u0xAhiw8XgFMOxolpP6J75U jLZfp6dzHIcBYCQbIBB4sCxDOLK6eMAVT39it57+e09ysCnDUtnrJ0vS5ZMW0PBFWDbd40G/ 85sH2KeXvj94u/flX8/2J6kYQkhkHbzWbkdH0N0UDN8sURS8uMd9dMzPL7BxIIjOayuWLBIf 70RPUPjxLouBEgVhMaYuWXQlMjwsN+eFTR4cDZ4werRDYOoAIFkrptm/Ni0gthOt9Q4yWQxc AwyWTbacW0sTDGoJen4P002/2S7LjgV6BpY1N6OO5g5eeiZTY/P9b1FzRwfKWuk9p/72ct+N puKpq32qLVaexOCCJB91aezt5y6zt7fXILSdJZjlVr1w0mCR66x6FL3QOXiUQ2a0k/sFlDlq 1LzUMQ4uxxycjl0LWO1bBsY6yXR3wSTJGxqLhdsJHDsS9cwF47XlvcQGQiXhRbih/HkQv4XO cajZb6GDu7PTFEdPkVu0k4vQyd3Jc/SUwNnB+RJ/XsI9ptZDIxMly3dbLNwGnGBJF+Id3cZM 9ui8Gjq5P/TDiRCegbOFgSKRo5e7yNHV2dnPdVb0bHfHQCevNIV/rxqrX48oFQdYcpKMtYRb juxtfqRypNACK28+j3FsqcilAD0ADuIWCt0yRa7zRNEOY2YELhW5CV2dXVKixH8BC+s8GDN9 wWKxf94zpsRiJuWmBYjgndsKFmu5Bc+D3HQXCcu7QTFTMl3HF0SLxruLvGa4zUqdMGFWqqfX 3GSxN0y6NT154i+v75zvH2thXiWgY2YVElhwYl9NYxarlr0grlQn92DQt1vBUk+nUFeHGZme gUIvl1RXr1AnV/fx6zd4v3HptM/YaXbrzmYFePu2WpowYRlJo+2PGLb2d9WE5bw1L4DcnOco 9HIcH3o02HOecMqMJhQqdLPXpArHl2uEo+Na8qZPXxw0+bVx46bFzhw3eZylM2dgwkbWW3Iy Jp9lMDe9H2/raiqPCy5/fHSCu+M7mkffoQuzQhvRhWVlj1FcWTfq6dwdElJmarxedr/u3P6C Nn7Fk95ol8wRjIMsOLGJSwLm/OMGjlFHJ7hqelDuxdMlpbU16JvqlJTamivoBjrfUgNB69zf b6Fr1TWPKmtOw9xCdLayEFWvBlaSfmEBsk6LSdTMNnQaldTe7Qfj20yveddR2toVEevCi9/f fmntR7ErtvompmyICM9qyYpZsG3FhqwNYRH5KUtyW7eGRRxfH1OHDv0ZXH6ihbSyVYzSY3Fu BkVR9LaS2wPxUxyTFpu2eGverr+dezvi0ttpOy/tTKlL2ZkWs6p4VV1Kyq60nevS8iLyi1tW hfNWzMfhYT+ArAQ+5odRBENjlRW5F/vH6O7u7urpXtvR/bQbmX/dPd3w7Ok+2Ij4ry5o0N/d Y1p7qA21FodhFRc1ctjIsXZ2Y18VcwCixNgcWlgVbUiue3b3J33te7497vv/oT1Bj5/7br1R grYlfrReSqmwPDyK0GqOUHKWj/RwP0J0ZlmsK3o2HP+7Qt9HBr3BYH5aNL3FG/+ul8sjKcxH dRJFGJkhfKxgmM2rUoaSg5h4GAwXJsF00dRGq+/21k2EF7o50oNswrNfsYUQKRBIZWIFh3lu aLNe1F++bjXGyWyzZiGoYFYLx5Ys4v0R3GWRdBHNErBiSiqVRhHMyeaYrMQ4SENWCvEcfhCm GIzpqKlm27KTSWUcAX1goBw5oATctDb33aLTYV5SWoaXP5+gyqlFdnZ23nB+plcnREv0RWJC BVkrrBJ1BewMmlVpgRUQF7wpItMJTcsJ34GBRVaFdQZaqoqxFmSb3qDQgu1A2GI4YAnODkQY IOhklDKzo2C1IV2sijzdhjorqwefNdL6ihxzegU7SynexHgBMXy+xWFG8qvdf91D8WpRi41q KFl02YaswYNkULTeLC9CFFK4bDHDMmZbhnuXSOdAsnN1LxgfVu7ZvG8LpSJUlO/gnaWQFwYv JpZeKdUaSC8ApuhIShYQYp5yWQ0oPgVXPtkcHz/fx5rqqzosHSSlBYHIxKSolJcUsIIpnzkh mt4b7Z/tOzBRQWaA6uNCNdet0nxLkL8CgzeQKIlCXaHjXR9MlqQn9Y1fNd5RE0zF/ryKwVR/ JMnsI3S8Umcw6NRYxRuUKqk3lfnKeGcTySAx5hy+7WfgZOv4uLLl0w8wUah71QLBpJeXq/eM VVivV8jz6lB2ofWF6i1dEYRZfMJ4piE+ZweNeb7A2VVyKEx6vjt1z/ghMehVKiUpyt1VYBXC N6j0Q4Mazp7TvvndhIaGhqqvP1bwFk0YRYR5RoLR+PkWmlIpV/oEDQ6jB9Wc3Z6bm6zLTtLl gLC4LVWXz5Q1ffbV5oZ24wmsV/NeKTlirmg+u/q7w7/38PDdeKF8UBgXs2kV4WUC0YR/KOLv Pby3L5O30yvG9vY/6vX8JSbb2je96coXX5QPznqfokKKEPWBAwd20ApaTWsP7LnTfsd42at3 +B+H7+zRUfwZZMutN6baHCX5+Ou9Zy4f3nuiKr7KaHxoNDbsSwhp6htvfyg3Zw901G+ttVlT Ja34/E+fvrXmvY3713xy6tSZfadOJby7X1P/vwn/MeaYr0mF7IMEq690Gu95KwQq5L5K+f59 qGUtaZMSciHMKjdVbY6zFqRC/pv3LgxY5tcW0pjIpGGJ7+89kxBnbXZSmjuz7CeyihyG8fbd XXYdrWlqQg+sZWTdzPqBB68VEdnkzDY0lHSjSD9/GRpaMt3OWqLpQENOTf/PpP8CK9ZVVe2a 8XoAAAAASUVORK5CYII= --------------0AC1D55F4906953221D54E92-- --------------5825C96D828B80D5DB566041-- --------------ms090204020005010601080504 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CfUwggSvMIIDl6ADAgECAhEA4CPLFRKDU4mtYW56VGdrITANBgkqhkiG9w0BAQsFADBvMQsw CQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxJjAkBgNVBAsTHUFkZFRydXN0IEV4 dGVybmFsIFRUUCBOZXR3b3JrMSIwIAYDVQQDExlBZGRUcnVzdCBFeHRlcm5hbCBDQSBSb290 MB4XDTE0MTIyMjAwMDAwMFoXDTIwMDUzMDEwNDgzOFowgZsxCzAJBgNVBAYTAkdCMRswGQYD VQQIExJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNP TU9ETyBDQSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVu dGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBAImxDdp6UxlOcFIdvFamBia3uEngludRq/HwWhNJFaO0jBtgvHpRQqd5jKQi3xdh TpHVdiMKFNNKAn+2HQmAbqUEPdm6uxb+oYepLkNSQxZ8rzJQyKZPWukI2M+TJZx7iOgwZOak +FaA/SokFDMXmaxE5WmLo0YGS8Iz1OlAnwawsayTQLm1CJM6nCpToxDbPSBhPFUDjtlOdiUC ISn6o3xxdk/u4V+B6ftUgNvDezVSt4TeIj0sMC0xf1m9UjewM2ktQ+v61qXxl3dnUYzZ7ifr vKUHOHaMpKk4/9+M9QOsSb7K93OZOg8yq5yVOhM9DkY6V3RhUL7GQD/L5OKfoiECAwEAAaOC ARcwggETMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0GA1UdDgQWBBSSYWuC 4aKgqk/sZ/HCo/e0gADB7DAOBgNVHQ8BAf8EBAMCAYYwEgYDVR0TAQH/BAgwBgEB/wIBADAd BgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEQYDVR0gBAowCDAGBgRVHSAAMEQGA1Ud HwQ9MDswOaA3oDWGM2h0dHA6Ly9jcmwudXNlcnRydXN0LmNvbS9BZGRUcnVzdEV4dGVybmFs Q0FSb290LmNybDA1BggrBgEFBQcBAQQpMCcwJQYIKwYBBQUHMAGGGWh0dHA6Ly9vY3NwLnVz ZXJ0cnVzdC5jb20wDQYJKoZIhvcNAQELBQADggEBABsqbqxVwTqriMXY7c1V86prYSvACRAj mQ/FZmpvsfW0tXdeDwJhAN99Bf4Ss6SAgAD8+x1banICCkG8BbrBWNUmwurVTYT7/oKYz1gb 4yJjnFL4uwU2q31Ypd6rO2Pl2tVz7+zg+3vio//wQiOcyraNTT7kSxgDsqgt1Ni7QkuQaYUQ 26Y3NOh74AEQpZzKOsefT4g0bopl0BqKu6ncyso20fT8wmQpNa/WsadxEdIDQ7GPPprsnjJT 9HaSyoY0B7ksyuYcStiZDcGG4pCS+1pCaiMhEOllx/XVu37qjIUgAmLq0ToHLFnFmTPyOInl tukWeh95FPZKEBom+nyK+5swggU+MIIEJqADAgECAhEA/bu0LJsAKXVhEpPllE0lYzANBgkq hkiG9w0BAQsFADCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3Rl cjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVt YWlsIENBMB4XDTE2MTEzMDAwMDAwMFoXDTE3MTEzMDIzNTk1OVowJDEiMCAGCSqGSIb3DQEJ ARYTZGlyZWN0b3JAb3BlbmNhLm9yZzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB AKnGg/GUuTjn0dKCEpRhVd+uiYbCjLQht+dbkvyRLm4aqlL7yHCe+21HQLIcU68ZCHT2ImpF CFFrxQMQh4KijAwkbLc8+xZZSwXeZt58qnPn5c4vcpYU5LFq1q9oDT8MXH33DhVUT/7/IDSi wRWM6FcgM6VrIjBmmvl9dW3gQaEd1bOAhO2X489fChRQYTaB6AEhqb8RSvWW7ZYzfNw8sPxV afMCzWBPpO5RmLqOciZBhAinAM9dXmP5ckg/HjJQYSjvTc7HDcg75mpr5wH8Tk/ChyIYk4CT zqONQV8HKCzZPTVmd2ZuMrliJwMFs3uEg0aBSzHjJTyAmZ89q5Mz3XsCAwEAAaOCAfEwggHt MB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTGgh9JWBvcrak1 PhAWBLGrECNAjzAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggr BgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQv Q1BTMF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NI QTI1NkNsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUF BwEBBIGDMIGAMFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9T SEEyNTZDbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUF BzABhhhodHRwOi8vb2NzcC5jb21vZG9jYS5jb20wHgYDVR0RBBcwFYETZGlyZWN0b3JAb3Bl bmNhLm9yZzANBgkqhkiG9w0BAQsFAAOCAQEAdIqtPcvA+g6VTYUpEo0I9Vtnrf9PiZ3OpkRL O7U78EaeUfvOotThqj74XyrIl6eYlg+EdGIIUVB1CI05wPMRlZN3/R/Tj28vWkwckLRIbpL4 A5ZQyKgA9vK15/EEBVFIpCtAI6xJX0zx6TySlIgjcca05L0JgO7nzLGD2MY/dVWEE+QBuNI+ NBci+c+9q6YDPoXOpo0Wwbe0Bq95jNNWmZwhGzc+N5rhOGZmQT4P7TnpzvMik8ugbkqWyyHa DQbLKYzM1RKS/mwcvFqjJCQgORnaCilSbfClwdWGI7vwcTR8eAzduvwG61u46Cgb57K5sMck RicpWRvEYxCCVTwnozGCBEQwggRAAgEBMIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMS R3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8g Q0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCWCGSAFlAwQC AQUAoIICYzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzEx MTYyMjI3MjhaMC8GCSqGSIb3DQEJBDEiBCAL2Mv8kT5uZTR8sUPo8wm7IwK9hG5hxKUXsMPB dwH7EzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHCBgkrBgEEAYI3EAQxgbQwgbEwgZsxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJH cmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBD QSBMaW1pdGVkMUEwPwYDVQQDEzhDT01PRE8gU0hBLTI1NiBDbGllbnQgQXV0aGVudGljYXRp b24gYW5kIFNlY3VyZSBFbWFpbCBDQQIRAP27tCybACl1YRKT5ZRNJWMwgcQGCyqGSIb3DQEJ EAILMYG0oIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVy MRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1h aWwgQ0ECEQD9u7QsmwApdWESk+WUTSVjMA0GCSqGSIb3DQEBAQUABIIBAIjultkseoGj9mWX H9cwK1P106uXFaWUGPBJvb293jckRtfRASb/gtle4LWmKKxnjWTYLVJ5gKdWSeOA1SvwElBI dtAuAXnWpydx/tcpgoqUGnlCilXwplsftcuY8x6ZwV4mvORXG0rLJjiJRpwRYL9unhYvf4xa P54K2JkpkGnHFINVH2CbWZSExs0QgDuE9BZ58U9nrC+JPpl/sADW4P9wzFpsxnzyqi5C/eYH nF3WNqWvUv+aO8g3pG9Io+UPeu5UT/8gzPjD6gHvZ0fiOKoLgD3rdAo/PR1MG1clKZz8d00n QVKk+/hZRpboSuY9/AQtyppfzKuu7gJCko5fbOoAAAAAAAA= --------------ms090204020005010601080504-- From nobody Thu Nov 16 18:10:53 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64489127B52; Thu, 16 Nov 2017 18:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0G3lxmkFHUm1; Thu, 16 Nov 2017 18:10:35 -0800 (PST) Received: from smtp-out-1.mxes.net (smtp-out-1.mxes.net [67.222.241.250]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7EDF127868; Thu, 16 Nov 2017 18:10:31 -0800 (PST) Received: from dhcp-894b.meeting.ietf.org (dhcp-894b.meeting.ietf.org [31.133.137.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3D84027552; Thu, 16 Nov 2017 21:10:29 -0500 (EST) From: Sean Leonard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Message-Id: <0F8DD20D-7ED5-4AEC-9D7E-8F64086DC2AB@seantek.com> Date: Fri, 17 Nov 2017 10:10:23 +0800 Cc: draft-foudil-securitytxt@ietf.org To: Security Area Advisory Group X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: [saag] Wherefore draft-foudil-securitytxt-00? in favor X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 02:10:36 -0000 According to the SAAG Agenda, we were supposed to discuss = draft-foudil-securitytxt-00 if time allowed. Time went over at SAAG IETF 100, so we did not get to talk about this = draft. Nevertheless, I read the draft and would like to speak in favor of the = IETF adopting the work. The draft has a number of areas of improvement, = which I would like to address at an appropriate time, but as a general = matter the IETF is an appropriate venue for this work. Thanks, Sean PS The subject content of security.txt is also appropriate for WHOIS = inclusion. I have no idea how palatable it is to do that, but again, I = think that IETF is the right venue to figure all that out.= From nobody Thu Nov 16 18:31:41 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2F412778E for ; Thu, 16 Nov 2017 18:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=symc.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id caTveMDZ0jBg for ; Thu, 16 Nov 2017 18:31:20 -0800 (PST) Received: from tussmtoutape01.symantec.com (Tussmtoutape01.symantec.com [155.64.38.231]) (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 A6AFE1274D2 for ; Thu, 16 Nov 2017 18:31:20 -0800 (PST) Received: from tussmtmtaapi01.symc.symantec.com (tus3-f5-symc-ext-prd-snat10.net.symantec.com [10.44.130.10]) by tussmtoutape01.symantec.com (Symantec Messaging Gateway) with SMTP id 3C.60.29100.8F94E0A5; Fri, 17 Nov 2017 02:31:20 +0000 (GMT) X-AuditID: 0a2c7e31-4271e9c0000171ac-ec-5a0e49f8b521 Received: from TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (tus3-f5-symc-ext-prd-snat8.net.symantec.com [10.44.130.8]) by tussmtmtaapi01.symc.symantec.com (Symantec Messaging Gateway) with SMTP id 06.91.04246.8F94E0A5; Fri, 17 Nov 2017 02:31:20 +0000 (GMT) Received: from TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) by TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Thu, 16 Nov 2017 18:31:19 -0800 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.44.128.6) by TUSXCHMBXWPI02.SYMC.SYMANTEC.COM (10.44.91.34) with Microsoft SMTP Server (TLS) id 15.0.1236.3 via Frontend Transport; Thu, 16 Nov 2017 18:31:18 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=symc.onmicrosoft.com; s=selector1-symantec-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XTI4qPDlxZlKZji6/QprSqthIPlNS2OWf5AkZ7Zemy8=; b=1DsYipCBaD9T/oY871qWTuQ61AQMN272hKby/NbT8o2M3Mp2tITonfxS47NGja9Pa/yh3vVRB4wJ4hYGTctle6A+Y53ijrCdqIZQ3PKjmpGbEHTA2NyArLcSieDby/oxqFcFJ/JijzQT70qdDr+8nNvqpU+/IPLEunRZQu6r+Jo= Received: from MWHPR16MB1488.namprd16.prod.outlook.com (10.175.4.146) by MWHPR16MB1485.namprd16.prod.outlook.com (10.175.4.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Fri, 17 Nov 2017 02:31:17 +0000 Received: from MWHPR16MB1488.namprd16.prod.outlook.com ([10.175.4.146]) by MWHPR16MB1488.namprd16.prod.outlook.com ([10.175.4.146]) with mapi id 15.20.0218.015; Fri, 17 Nov 2017 02:31:17 +0000 From: Brian Witten To: Stephen Farrell CC: Paul Hoffman , "saag@ietf.org" Thread-Topic: [EXT] Re: [saag] patient ietf100 Thread-Index: AQHTXpeAFwZoI1n1GECPt6tCXmVGtaMWyZGAgACHCICAAIqCQg== Date: Fri, 17 Nov 2017 02:31:17 +0000 Message-ID: <2AE14034-0634-4A6F-BDF6-77E5AD3AF78F@symantec.com> References: <6DF7F2EB-80AE-4AB9-A98F-076F12B4B8BD@vpnc.org>, <92dccb1f-5194-5632-a35f-ad31f2ca8b85@cs.tcd.ie> In-Reply-To: <92dccb1f-5194-5632-a35f-ad31f2ca8b85@cs.tcd.ie> 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=brian_witten@symantec.com; x-originating-ip: [155.64.38.117] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR16MB1485; 6:7NyPgWxuUg6q7AUHgBXXrqJd3s5y+3eu4h2HTOtsvR/2d1scEQ77RMEqqb7YBYy4U7j/vHq5k+omuKpAOwBpDT+NI+xnKSC0xUNhZFGAWJq4lHL6io4iepzmGq7woLqgLmSsy1PWeDcHWcJWF6+IWJieLz+sQ2AvS2aGDoWjFCV7dW9kkIQZGFuKBaQKaKtTHA4tvX0JpCU3OMxW4xIwCPy4j2VOJ0B0M2D7tQpBAFxFxiyZF5NgOU5g8qyR11FSrJi1vIOUg5z5CFsdJRdEGSrmNwgreUJ1I7hXQr9E+Dl0AKDUrpqObvqqmoj+gv4P0cwClF0omkw9SlSRggsN5hd/IM9BBXHS9UhG2YYM/hY=; 5:wsnCirc2Dw7saenab0i5k8Ruxh5uyUI0hWrBTf4/5WHlqNl4bkKUq8vCLViCBAiaqlVNqwYColhS1a+Hv1hQlNHl8uX1xU3w0Y3u7JUNAoxjMFUYM+Yo7HEaxmOzhDPkm5N0b6qIKcf1FobMshxPENm39N5yA8bnBmDA3ddKP0k=; 24:X7nCafUNbhgFBeLRwlrppizkweLcypyMkuuxrYgTeSlcCkyf60o5Ymf3eRWvrDjlh1QGdSnJ03NuL/msAUxnjnSvVSTfYroBih8sakBmVjU=; 7:rJQ12t7kM6cUiGUu4auQd/VKw9I3tPzsgrqRaw429+5eP5nr/u90LBTEEOEf5tzkI/hJ4jk980w45Hzk8MzdgbT2pVPRptX/NogOMziTlYEnQqhtKuphpALZG1IZg7YRuV+40iAAK5RKCthzP+oa9K/HKSIdyTmg5xDIoBrPzquWZw4R6eSyeLLfP7uaxVP3GzZ92RHH3NcAYFm2VYadQJsSaIHoEOVcmpNNteTVbhfAnCCXjFtKLHEZMntioV22 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 82d3a87e-c776-4a0d-7e8c-08d52d6347cf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:MWHPR16MB1485; x-ms-traffictypediagnostic: MWHPR16MB1485: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(3231022)(6041248)(20161123558100)(20161123564025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR16MB1485; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR16MB1485; x-forefront-prvs: 049486C505 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(189002)(24454002)(199003)(50986999)(3280700002)(77096006)(316002)(6486002)(6436002)(6506006)(6512007)(97736004)(229853002)(53936002)(54906003)(4326008)(2900100001)(3846002)(102836003)(6306002)(6116002)(6246003)(36756003)(6916009)(2950100002)(66066001)(101416001)(81166006)(81156014)(54356999)(8936002)(8676002)(76176999)(105586002)(189998001)(33656002)(5660300001)(305945005)(106356001)(7736002)(93886005)(53546010)(10290500003)(3660700001)(83716003)(25786009)(966005)(575784001)(14454004)(82746002)(86362001)(2906002)(478600001)(99286004)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR16MB1485; H:MWHPR16MB1488.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: symantec.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 82d3a87e-c776-4a0d-7e8c-08d52d6347cf X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2017 02:31:17.0398 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 3b217a9b-6c58-428b-b022-5ad741ce2016 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR16MB1485 X-OriginatorOrg: symantec.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGKsWRmVeSWpSXmKPExsXCpdPEpfvDky/KYNEFbotb67+wWkzp72Sy mL73GrsDs8fa7qtsHkuW/GTy+Dz7KnMAcxSXTUpqTmZZapG+XQJXxrXLu9kKNgtUfHyyh6mB 8RVvFyMnh4SAicTBbWtZuhi5OIQEvjBKrFm6khUm8aRjL1TiO6PEpE0LGUESQgJHGCXWPnCF sF8wSkztrAApYhHoZJaYeeoKM0RiKpPE42+1cA0dTfUgNpuAnsTRv3fANogI6Evs3XyOHcRm FvCUWHNwJQuILSygK7Fgwn0miBo9ie2ffrFB2E4Su7bNA6rhAFqmKrHmgR5ImFfAXmLCgxNQ t71nlGj75g5icwrYSsz8ew8sziggJvH91BomiFXiEreezGeCeFJAYsme88wQtqjEy8f/WCHq YyROrX0FFVeUWHh4MRuELStxaX43I8i/EgKH2CX+/tnKDpHQk9g68S0jyG0SAr4Szf1aEDUz GSUezJ3BCFGjJXFgaisLRE22xMlP7BMYjWchOQnC1pFYsPsTG4StLbFs4WvmWWBvCkqcnPmE ZQEjyypGhZLS4uLckvzSksSCVANDveLK3GQQkQhMK8l6yfm5mxjBqaXOcAfjow0+hxgFOBiV eHjbrPiihFgTy4AqDzFKcDArifA2TOSNEuJNSaysSi3Kjy8qzUktPsQozcGiJM5bMZ8nSkgg PbEkNTs1tSC1CCbLxMEp1cCoGPr0Yfrn2RcMZ9wxExWNrXv7z+5LyFPJNzNT1KK2t5tKXwu8 vmKz7AStda3OYt/U82d2tTznqun8rOz/40ycnc9U+Yrbv+KT1svnhNqGr7aXWaDk2MPi5if7 Zr51TanNmmSOMHvn2eKrE4IuHJL41bFDlknN523lqkvH0u6u/XN8AtcajhYlluKMREMt5qLi RAAktGTmKQMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTYRTA+e69u7sbLb7Ww4MR1aAQH9NBkJVaFJZmUiD+M4RcesnlZmub YoVlPvIVuUKxKeWGklgbgmaT1KFT8YFUmK6QqKmLzLDISnNptOuV6J/Dj3N+h3MOHIaU/qYC GXWWkdVnqTQyWkyJQwuYsF/xG5URN25RkZMtPwSRVZVlRGRNt1t4hIyzV0zQcY2Ny0Tc97oJ 8gypFEelsxp1DqsPj0kVZ7hfddK6Npz7zdtF5KM5STkSMYD3gbe0mypHYkaKlxDcbbUiriDF /QjsnlieZxFUl+VyEoXLSDCPjJN8oZqAmcW8fw2lBdc5prEcBlbfCjjegsOhu+25kGMSx4Ot t5nieDMOA4vpPcE7cnAs+Giej8Kzpw/8DuMftgdsHjmXluDDYPIMre/2FcHNxRMci3A0mFff reUR3gZLIzaCHxUAk956gj8SQ2PXC5LnrfBp5o+A91NgxD63nt8N1r4GmucdMFZfgbh7AbuE sLrSLuQLcmi/M4+43QAnQmFlMO+YEXju30O8Eww91cUU72TC8MJ6awLMDlhp3h8XwOjUHGlC 4bX/7cpzKFg6F2ieQ+Ch9TNZu3b/Jhg2eykLoh6hXcZsg0Fr1BpVKp06QiE3XNamcUHl/5U0 edpFbSta+5Zj0IGcK6dcCDNItkGC+yVKqUCV4zddaDtDyQIkX4IIpRSfVxnZTJbVsfqz+mwN a3AhghEF5qMq2evbeSUHFM5zrQk7Pw6RqUmx5jqB5cKYw5GT+NPcdupSyJtkUdO0Y3A+IcUB NS+j5Aol1VmV/CRputTmayiM7mlh9oY+Pnkt/aD29OD8qL23We30XY05rmdKXMUplK65T9MR ICoirzgziQ9F7kNTiSZPPXYXN/n2LweRMsqQoVIEk3qD6i9p4EStDgMAAA== X-CFilter-Loop: TUS01 Archived-At: Subject: Re: [saag] [EXT] Re: patient ietf100 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 02:31:25 -0000 Um, clarification: count was 50/50. > On Nov 17, 2017, at 2:16 AM, Stephen Farrell = wrote: >=20 >=20 >=20 >> On 16/11/17 10:12, Paul Hoffman wrote: >>> On 16 Nov 2017, at 12:58, Brian Witten wrote: >>>=20 >>> The PATIENT side-meeting last night was well attended, though with >>> clearly divided discussion. Thank You Again To All Who Participated.=20 >>> Next step is to assemble an Internet Draft presenting verifiable data >>> on merits of third party security, particularly third party network >>> security. I'll do this over next few weeks with help from volunteers. >>=20 >> I would love to hear more about what was said at the meeting. Are there >> fuller notes somewhere? >=20 > I'm not sure if there are notes. I think one of the proponents was > taking some so I guess they'll speak up on that when they get a chance. >=20 > My take: it went as expected. The proponents wanted a standard way to > mitm https between enterprise browsers and the Internet so as to do > malware scanning. That was discussed with the usual points raised and > at the end (10pm) about 25% of the room wanted to pursue something like > that and 75% didn't want the IETF to go there. >=20 > I did miss the start of the session and do have a position on this > so it is at least theoretically possible that the above might not be > perfectly objective;-) >=20 > S. >=20 >=20 >>=20 >> --Paul Hoffman >>=20 >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://clicktime.symantec.com/a/1/FedBNm0xXKqMDaQ-rMCL0usINpFJEeiCwvND6= guTIsc=3D?d=3Dqp7H-RJleuSvHyvhbUk3TBIWIvgfU14xyptYYmkqvyk6gchm-KaN5KeD8E4_r= ZKIFHoX6aahh0Xk7UpdyS5H7eycUmGWWElisug2gQ2KcT0hYqhhzWYYvIJ2T6_JjUhNN8oy42CD= Z_bi07B-_LNiMOzhq3VodQIM6IptE7_eOWOoSEDRJwLmZ1P-rnNzAE8Vx98Evt7RP0q-L9sMPhd= pcKZ-udC0ObKPJnmeGHulDvyluAlU8_DV1ipplGnlURbYNqrUKmZVJwnDDrmru8TVCDpB7nKpVF= HH2Yd3M5ALZ19b1Gr-imMsDHsPdDheU-w7Id4XnGjzW83Zdm8M90_cn_2Cr6y3dFF-To13eWj-Q= Atoqsx6mX5b&u=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsaag >>=20 From nobody Thu Nov 16 18:48:03 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 149731279E5 for ; Thu, 16 Nov 2017 18:48:01 -0800 (PST) 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 (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 ViFhChlGBw2T for ; Thu, 16 Nov 2017 18:47:54 -0800 (PST) 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 224A9127B60 for ; Thu, 16 Nov 2017 18:47:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5F434BDCC; Fri, 17 Nov 2017 02:47:48 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie 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 Q6wP5GyyLzc8; Fri, 17 Nov 2017 02:47:46 +0000 (GMT) Received: from [31.133.132.197] (dhcp-84c5.meeting.ietf.org [31.133.132.197]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 69EAEBE5F; Fri, 17 Nov 2017 02:47:45 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1510886866; bh=pX9oc4R7PCYKOegzxLGNznqN8pyzDmyzRTjoM3J2+E0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=xN5Ou2bxSqzJXYKboNJeRRDIhwlW2fy49myQAhU156NoEGKxsifhQLKgqX4ybfDFT sa9q5jOYLEIVRb9TbVSfpbe61iy4MX5HYuPGvqO7Z/xQfI9l6W5pNQk3nXcDcgYxLa Vjis00vp8dHXG+D5LSHv1aEe/RnQHCsCDo67zPnI= To: Brian Witten Cc: Paul Hoffman , "saag@ietf.org" References: <6DF7F2EB-80AE-4AB9-A98F-076F12B4B8BD@vpnc.org> <92dccb1f-5194-5632-a35f-ad31f2ca8b85@cs.tcd.ie> <2AE14034-0634-4A6F-BDF6-77E5AD3AF78F@symantec.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <39a6dfef-d159-b54a-159c-c98ee3b2d3e7@cs.tcd.ie> Date: Fri, 17 Nov 2017 02:47:39 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <2AE14034-0634-4A6F-BDF6-77E5AD3AF78F@symantec.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="JviNV85rWwvtIUWR5LIHh0dLdF8nc0T15" Archived-At: Subject: Re: [saag] [EXT] Re: patient ietf100 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 02:48:01 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --JviNV85rWwvtIUWR5LIHh0dLdF8nc0T15 Content-Type: multipart/mixed; boundary="J1Q0Ku4veDCT42TfkN0kpcP9rA9b0DH4X"; protected-headers="v1" From: Stephen Farrell To: Brian Witten Cc: Paul Hoffman , "saag@ietf.org" Message-ID: <39a6dfef-d159-b54a-159c-c98ee3b2d3e7@cs.tcd.ie> Subject: Re: [EXT] Re: [saag] patient ietf100 References: <6DF7F2EB-80AE-4AB9-A98F-076F12B4B8BD@vpnc.org> <92dccb1f-5194-5632-a35f-ad31f2ca8b85@cs.tcd.ie> <2AE14034-0634-4A6F-BDF6-77E5AD3AF78F@symantec.com> In-Reply-To: <2AE14034-0634-4A6F-BDF6-77E5AD3AF78F@symantec.com> --J1Q0Ku4veDCT42TfkN0kpcP9rA9b0DH4X Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 17/11/17 02:31, Brian Witten wrote: > Um, clarification: count was 50/50. We disagree. That can happen depending where one is in the room. S >=20 >> On Nov 17, 2017, at 2:16 AM, Stephen Farrell wrote: >> >> >> >>> On 16/11/17 10:12, Paul Hoffman wrote: >>>> On 16 Nov 2017, at 12:58, Brian Witten wrote: >>>> >>>> The PATIENT side-meeting last night was well attended, though with >>>> clearly divided discussion. Thank You Again To All Who Participated= =2E=20 >>>> Next step is to assemble an Internet Draft presenting verifiable dat= a >>>> on merits of third party security, particularly third party network >>>> security. I'll do this over next few weeks with help from volunteer= s. >>> >>> I would love to hear more about what was said at the meeting. Are the= re >>> fuller notes somewhere? >> >> I'm not sure if there are notes. I think one of the proponents was >> taking some so I guess they'll speak up on that when they get a chance= =2E >> >> My take: it went as expected. The proponents wanted a standard way to >> mitm https between enterprise browsers and the Internet so as to do >> malware scanning. That was discussed with the usual points raised and >> at the end (10pm) about 25% of the room wanted to pursue something lik= e >> that and 75% didn't want the IETF to go there. >> >> I did miss the start of the session and do have a position on this >> so it is at least theoretically possible that the above might not be >> perfectly objective;-) >> >> S. >> >> >>> >>> --Paul Hoffman >>> >>> _______________________________________________ >>> saag mailing list >>> saag@ietf.org >>> https://clicktime.symantec.com/a/1/FedBNm0xXKqMDaQ-rMCL0usINpFJEeiCwv= ND6guTIsc=3D?d=3Dqp7H-RJleuSvHyvhbUk3TBIWIvgfU14xyptYYmkqvyk6gchm-KaN5KeD= 8E4_rZKIFHoX6aahh0Xk7UpdyS5H7eycUmGWWElisug2gQ2KcT0hYqhhzWYYvIJ2T6_JjUhNN= 8oy42CDZ_bi07B-_LNiMOzhq3VodQIM6IptE7_eOWOoSEDRJwLmZ1P-rnNzAE8Vx98Evt7RP0= q-L9sMPhdpcKZ-udC0ObKPJnmeGHulDvyluAlU8_DV1ipplGnlURbYNqrUKmZVJwnDDrmru8T= VCDpB7nKpVFHH2Yd3M5ALZ19b1Gr-imMsDHsPdDheU-w7Id4XnGjzW83Zdm8M90_cn_2Cr6y3= dFF-To13eWj-QAtoqsx6mX5b&u=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2Flisti= nfo%2Fsaag >>> >=20 --J1Q0Ku4veDCT42TfkN0kpcP9rA9b0DH4X-- --JviNV85rWwvtIUWR5LIHh0dLdF8nc0T15 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEbBAEBCAAGBQJaDk3LAAoJEC88hzaAX42iUjEH+L6+0YiSBbhWElecyIG4JRpz hpw9N02X7deGYbJNywsjP4xV9IZVlQzjEPVpAMQc9AcgtIgfy6CRR4Y5qvCSXxxx iDylTVw1ayKbqdvZt9CIPsEQp1u7Qii3iw5m4+Hyf+rTXYX5Ked9s594a+Pycazo Qaz2ZrV9+DGr+lckIPgbOTIMk8QUAlXfps4dGK9XuALRcDqiiWlFc/ChSATEQlwc NkvQzc0IvN/HheVgqRMLfYLjUNwKnBQ7hNXcUmlBfaC5pSqy2IFI+YXVzLq/u91P 1Wu6oZnlFyvCV7eoNo7etCDtu7Zc3fqB+ZKFoQqQp2wk9MHJBu8EDFKUk/w/FA== =btlJ -----END PGP SIGNATURE----- --JviNV85rWwvtIUWR5LIHh0dLdF8nc0T15-- From nobody Thu Nov 16 18:51:21 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17900126D3F for ; Thu, 16 Nov 2017 18:51:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SaJjyTqvLf5g for ; Thu, 16 Nov 2017 18:51:16 -0800 (PST) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA1E21267BB for ; Thu, 16 Nov 2017 18:51:16 -0800 (PST) Received: by mail-pg0-x231.google.com with SMTP id 4so876572pge.1 for ; Thu, 16 Nov 2017 18:51:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to; bh=lY8iON6edxwVwxPInzv0oYe5kKs0+vHmHW1njOZG/Zg=; b=MpNAfedZaqK/MoXxgZ9ilc7ezYlBKkoxZIKOMeJuSWHOcgAQf7sQ/7ipPSt5ogk4KT cm33YZLtHfuV83EOu3qWBZYsTOJ/3btQYJDZIOdEdKJX2P3dNhV3ZTqpWH/ifRkOr502 TzY0zWLXnUNz56UMLgQAuGx6eszQZkp4gVpecX4fwXSuMKehTn9GLHvioxIwtBuj3L4i HYi2K9jKeSHwprVY//FA53CJ2rLT2XrKZBluVC9CWGavKeU7oX9bWHP3/Maqsn6PVIzu cZx5BB/VrWWe0LJ5GOcYAdB974k2kQZdL+m5quCgw7o5UJy+5ithXRlnpkYL9avUJKh7 7AAg== 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; bh=lY8iON6edxwVwxPInzv0oYe5kKs0+vHmHW1njOZG/Zg=; b=rd3X/WqgmkEQ94cyFIs0YGOtT5ZexihpqEIDJUd90oR23ha4Z6ZOGxVDW2sfzLnw6a 1g0b/hIxRly7FQWECTV6xJHDPdiGR5cbsJlicU9MUQQMXbHOz95h1YvtbtSIdByK1Nuq 0WgvRO9Kz8SkhqkyNkejBchsjgt/qaZZpG8Eq1dkNAhPvglxZjvosFVZzMmEGSzDlmLA fpK8p4e3Vganwlvly8Wu2K61mwPfAE6navzD7idOUUH+ZOVfaMGgKh00PcpZiYuSuYnE HS+SBld+AfcwXux6iOo/Q4DFRN7doHf4hryEKdfF87e+Ik6IMCK6qaExu+pqFTd80R7u m2Jw== X-Gm-Message-State: AJaThX6xAx/h89XucR5XGAhYjTlpB5BYSJLjeHnYRP3h34+LpbCrgri0 kEPfiK3C02MO0mAjaROt8mFYQ0mo X-Google-Smtp-Source: AGs4zMYTksrC3KbQqr2jTUSQAA/EDWLSKPjx9Cl+Gvv1FrILp3wJaraWS55WMVodZv/Vk+eY/BXrxw== X-Received: by 10.101.80.3 with SMTP id f3mr3736270pgo.109.1510887075590; Thu, 16 Nov 2017 18:51:15 -0800 (PST) Received: from dhcp-815f.meeting.ietf.org ([2001:67c:370:128:dc1e:e107:8cee:b8ef]) by smtp.gmail.com with ESMTPSA id d2sm4404403pgu.86.2017.11.16.18.51.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 18:51:14 -0800 (PST) To: Brian Witten Cc: "saag@ietf.org" References: <6DF7F2EB-80AE-4AB9-A98F-076F12B4B8BD@vpnc.org> <92dccb1f-5194-5632-a35f-ad31f2ca8b85@cs.tcd.ie> <2AE14034-0634-4A6F-BDF6-77E5AD3AF78F@symantec.com> From: Melinda Shore Message-ID: <1316107b-9607-1db4-57de-7504fb6290a3@gmail.com> Date: Fri, 17 Nov 2017 10:51:12 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <2AE14034-0634-4A6F-BDF6-77E5AD3AF78F@symantec.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="5e2Pim31shFN8uXDXoDkd2H7fn7JEPkJ4" Archived-At: Subject: Re: [saag] [EXT] Re: patient ietf100 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 02:51:19 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5e2Pim31shFN8uXDXoDkd2H7fn7JEPkJ4 Content-Type: multipart/mixed; boundary="miEjksGqMNW7LkfpI1Hbme48HNMe7deNh"; protected-headers="v1" From: Melinda Shore To: Brian Witten Cc: "saag@ietf.org" Message-ID: <1316107b-9607-1db4-57de-7504fb6290a3@gmail.com> Subject: Re: [saag] [EXT] Re: patient ietf100 References: <6DF7F2EB-80AE-4AB9-A98F-076F12B4B8BD@vpnc.org> <92dccb1f-5194-5632-a35f-ad31f2ca8b85@cs.tcd.ie> <2AE14034-0634-4A6F-BDF6-77E5AD3AF78F@symantec.com> In-Reply-To: <2AE14034-0634-4A6F-BDF6-77E5AD3AF78F@symantec.com> --miEjksGqMNW7LkfpI1Hbme48HNMe7deNh Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/17/17 10:31 AM, Brian Witten wrote: > Um, clarification: count was 50/50. Not to be tiresome about process, but we don't vote. Melinda --miEjksGqMNW7LkfpI1Hbme48HNMe7deNh-- --5e2Pim31shFN8uXDXoDkd2H7fn7JEPkJ4 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEOwSIcj4Q6xsnay8FuIZGkzoegS4FAloOTqAACgkQuIZGkzoe gS5q+hAAtX0z4c4sTp5O+o6XIE1LgDyYu83S0m1qoPSaMFU6ZLmXZMCM/W/AEa3g Ud6nlGBvqrKkImFMmeNdL2ZOfu2S2xigbG32dyeSeSPLgGjl3f7uXClpRPCoWk6f YfQYvwF8WZLTiYFpp13mgmBN1klu1yW0H6ys12PX7Rs3vKd9p4P3XT130cGwUtMU M3v3Z1NsUNsYOi//2YnnfzEQ84j+Hz/0DpQCRp4Pu8qJHsnCxDxy/Zxu60QrjugP NYrXf/RUuZZHhi7GDCxJc58DspS4uE07ITUNqowaCBDpx3TI/yCgLs6gtC657VrH CtcFb8i/mr4YaC6p3dxB8mhME7YPBjRxba+vCUOmHdNbqLLSRWALeTDNAvWv0uVH UmRO8vUDnizRBtsjGJ1nrdTH8M5GIjkf0tUI6dyB+igOlIFrF0HgPQHW5HzbS0vj wm9/YtW7X9uqPMduRWHf/WrQQ3v2BeybZ/SB+HfY7I44m5qV6yEpnmT9WCqEMws9 PL0l6uZgV8Pqkra3PTcut7PuI4wBcWuWYlM4HaZ8gLgVB2yXQFpJAggpzwqHa46y fYx+mNVsBCKNcna2Cdfs0zuvYU+VcRcMdLCzZQ8i5Y9hAHX1M/XKNsr/Cqzsm+fw lVVMZqVW1z3XIODHTmKV1S9eu3NcVn2zc9fZjWCZSEQr0osxX/8= =xrfY -----END PGP SIGNATURE----- --5e2Pim31shFN8uXDXoDkd2H7fn7JEPkJ4-- From nobody Thu Nov 16 18:57:11 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50D6E126CB6 for ; Thu, 16 Nov 2017 18:57:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 357zwKdmioJL for ; Thu, 16 Nov 2017 18:57:05 -0800 (PST) Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::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 182E01267BB for ; Thu, 16 Nov 2017 18:57:05 -0800 (PST) Received: by mail-pf0-x232.google.com with SMTP id x7so879690pfa.1 for ; Thu, 16 Nov 2017 18:57:05 -0800 (PST) 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=fnMLtDwICwBEqhALnnT+3LNtSXrgaOtPK8UN+F4ohDc=; b=qOho/ElBT7lNLFRCfikExoCtSaoC87qtCqPcAhfXltlIOYmVdWqIwzZwXiRuJ80EBs 840IdD+gldgCyVhnkWRk89mjGT5V8hOnGDMTmW6Hh2ndGcdGoiZjh1jFg1hGEKQndOF5 M69C90ZPQhFOV1Q/vJGmeZ/4X5wjQATNVBcFFzSrIRq6/kT9y37HVt4TyjUY3//3sJGK 6jmoHnyD2BSLwOTygCPSM+YjK9YcsmLlO3ArGSOXKFkC57iTW4TF/f7CfFa7qJSAU2oh UVpjAKZF/n06qvjfO6bqgZPgFs18xRAdQXWgN46SpGY+OspipUr4qX4aN7NrGGZV6IIu qceg== 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=fnMLtDwICwBEqhALnnT+3LNtSXrgaOtPK8UN+F4ohDc=; b=kvHBATjSa6fgsGHpMZ7PNYw98CxffRcirPY+ttVIYaDayCP6WAMe6TRnZHojBGk/st QqC1IhOVekaGkZYB/+Dc8Z2dqY9QQlzn0AGfBHPK5/WbUN7KG2vKynq/EL8wf8GZJllI WipjXdGvEwwx7x3GjTFRDiXgt+MGCJffKoV42sGe5Xg2XO+oALQeA/x1AxEquMtksKrE CaRszgc+c7ljajEqoiynGUcvw6XjT2s2yObpwKwrnEeBSLZJXH0Ptcj2f9Ldjxiactf/ tmawqOO6H3cscyg1yCAttCx3Z5Jb5i1+8MOwPJnkDgG4hzZZZ53O+NMHwxI6lqMj1xLI qZCw== X-Gm-Message-State: AJaThX6Vg8CRmEgYjbL/yO0/NP5JQduUs6jf//iAyjBXLzo0K+DY08Jj Tbgc4JmxMzygLTNA1KLHrMNqflxz X-Google-Smtp-Source: AGs4zMaCHg+DKWakOX7d/oIJHWAsYDY5AbXjr03UgWzE9csf5gGof4EiVh+VbCVWTC3gr58pq1umyg== X-Received: by 10.98.92.129 with SMTP id q123mr463869pfb.147.1510887424272; Thu, 16 Nov 2017 18:57:04 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:b8ad:42cd:76d0:6ea2? ([2001:67c:370:128:b8ad:42cd:76d0:6ea2]) by smtp.gmail.com with ESMTPSA id f191sm4126236pgc.32.2017.11.16.18.57.03 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 18:57:03 -0800 (PST) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_5017785B-2EE1-4997-9C6D-C19C7FAC0531" Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Message-Id: <420FE946-1EC3-49AC-A0DC-666347E708C0@gmail.com> Date: Fri, 17 Nov 2017 10:57:23 +0800 To: Security Area Advisory Group X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: [saag] Report on Side Meeting about Short Term Automatically Renewed (STAR) Certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 02:57:08 -0000 --Apple-Mail=_5017785B-2EE1-4997-9C6D-C19C7FAC0531 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello all Last night (Thursday) we had a side meeting about the goals of = draft-nir-saag-star. 21 people attended the meeting and it lasted a = little over one hour. I got a lot of useful comments, some of which I will list here in no = particular order: The unique thing about STAR certificates is not that they are short = term, but that the Relying Parties do not check revocation of the End = Entity certificates. The document should be refactored to make this the = subject, with short-termness presented as mitigation for the lack of = revocation checking (Stefan Santesson). =E2=80=9CShort=E2=80=9D and =E2=80=9Clong=E2=80=9D are relative and any = cut-off point would be arbitrary. The lifetime of a STAR certificate = should be defined by the requirements for revocation, not by some = arbitrary limit defined in an RFC. The draft should add privacy and latency concerns (both are compromised = by revocation checking, so a plus to STAR) to the considerations. (DKG) It should be noted (in the draft) that when the PKI is a hierarchy the = RP still needs to check revocation for the sub-CAs. This negates much of = the simplicity advantage. We should consider what use cases are appropriate for STAR. In the web = (as measured by Google and others) clock skews are rampant, and 5-7 day = skew have to be assumed. Additionally, the CAs on the web typically use = one or more layers of sub-CAs. Closed environments such as datacenters, = corporate networks and managed systems have better control of clocks and = can often forego hierarchy. Examples of =E2=80=9Cmanaged systems=E2=80=9D that were mentioned: A bunch of NSFs controlled by a single Security Controller (as we=E2=80=99= re doing in I2NSF, but vendors have been doing with proprietary = protocols for years) A bunch of IPsec endpoints (either tunneling gateways or hosts) managed = by an NSF (we=E2=80=99re doing that in I2NSF as well) Vehicle-to-vehicle networks where certificates are issued for a month, = 20 times a month (Bob Moskowitz) Storage Area Networks where data clients connect to data servers and = require at least authentication and often encryption, which they get = using TLS or IKE/IPsec. STAR certificates seem to be equivalent in terms of security how long it = takes to revoke a certificate to PKI certificates with OCSP Must-Staple. = The draft should call out that the lifetime of a certificate should be = similar to the =E2=80=9Clifetime=E2=80=9D (time from thisUpdate to = nextUpdate) of the OCSP responses. There was some discussion about whether STAR certificates should be = specially marked, perhaps by an certificate extension, as such. The = reasoning is that at some point having none or CRL DP or OCSP URI may be = treated as invalid, so STAR status may need to be called out explicitly. = Current CABF guidance is that lack of revocation is fine for = certificates whose validity period is shorter than X (TBD what X is) so = at least for now and for the web such an extension is not needed. If = ever such a certificate extension is needed, it can be done in a short = standards-track document. The intention is for this document to be = informational Another thing that was discussed is where this work should go. It = obviously requires a lot of feedback, so it doesn=E2=80=99t seem to be a = good fit for either AD-sponsored or an independent submission. Neither = of these streams tend to get a good review. The authors should discuss = with the security ADs and SecDispatch which existing or new WG is the = right home for this work. Thank you to everyone who took the time to attend. Yoav --Apple-Mail=_5017785B-2EE1-4997-9C6D-C19C7FAC0531 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello= all

Last night = (Thursday) we had a side meeting about the goals of draft-nir-saag-star. =  21 people attended the meeting and it lasted a little over one = hour.

I got a = lot of useful comments, some of which I will list here in no particular = order:

  • The unique thing about STAR = certificates is not that they are short term, but that the Relying = Parties do not check revocation of the End Entity certificates. The = document should be refactored to make this the subject, with = short-termness presented as mitigation for the lack of revocation = checking (Stefan Santesson).
  • =E2=80=9CShort=E2=80=9D = and =E2=80=9Clong=E2=80=9D are relative and any cut-off point would be = arbitrary. The lifetime of a STAR certificate should be defined by the = requirements for revocation, not by some arbitrary limit defined in an = RFC.
  • The draft should add privacy and latency = concerns (both are compromised by revocation checking, so a plus to = STAR) to the considerations. (DKG)
  • It should be noted = (in the draft) that when the PKI is a hierarchy the RP still needs to = check revocation for the sub-CAs. This negates much of the simplicity = advantage.
  • We should consider what use cases are = appropriate for STAR. In the web (as measured by Google and others) = clock skews are rampant, and 5-7 day skew have to be assumed. = Additionally, the CAs on the web typically use one or more layers of = sub-CAs.  Closed environments such as datacenters, corporate = networks and managed systems have better control of clocks and can often = forego hierarchy.
    • Examples of = =E2=80=9Cmanaged systems=E2=80=9D that were mentioned:
      • A bunch of NSFs controlled by a single = Security Controller (as we=E2=80=99re doing in I2NSF, but vendors have = been doing with proprietary protocols for years)
      • A = bunch of IPsec endpoints (either tunneling gateways or hosts) managed by = an NSF (we=E2=80=99re doing that in I2NSF as well)
      • Vehicle-to-vehicle networks where certificates are issued for = a month, 20 times a month (Bob Moskowitz)
      • Storage = Area Networks where data clients connect to data servers and require at = least authentication and often encryption, which they get using TLS or = IKE/IPsec.
  • STAR certificates seem to be = equivalent in terms of security how long it = takes to revoke a certificate to PKI certificates with OCSP Must-Staple. = The draft should call out that the lifetime of a certificate should be = similar to the =E2=80=9Clifetime=E2=80=9D (time from thisUpdate to = nextUpdate) of the OCSP responses.
  • There was some = discussion about whether STAR certificates should be specially marked, = perhaps by an certificate extension, as such. The reasoning is that at = some point having none or CRL DP or OCSP URI may be treated as invalid, = so STAR status may need to be called out explicitly.  Current CABF = guidance is that lack of revocation is fine for certificates whose = validity period is shorter than X (TBD what X is) so at least for now = and for the web such an extension is not needed. If ever such a = certificate extension is needed, it can be done in a short = standards-track document. The intention is for this document to be = informational

Another thing that was discussed is where this work should = go.  It obviously requires a lot of feedback, so it doesn=E2=80=99t = seem to be a good fit for either AD-sponsored or an independent = submission. Neither of these streams tend to get a good review. The = authors should discuss with the security ADs and SecDispatch which = existing or new WG is the right home for this work.

Thank you to everyone = who took the time to attend.

Yoav

= --Apple-Mail=_5017785B-2EE1-4997-9C6D-C19C7FAC0531-- From nobody Thu Nov 16 19:11:27 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A91D126B71 for ; Thu, 16 Nov 2017 19:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iJvLMhsZGWpM for ; Thu, 16 Nov 2017 19:11:23 -0800 (PST) Received: from mail-pf0-x234.google.com (mail-pf0-x234.google.com [IPv6:2607:f8b0:400e:c00::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66A331241F3 for ; Thu, 16 Nov 2017 19:11:23 -0800 (PST) Received: by mail-pf0-x234.google.com with SMTP id l24so891511pfj.6 for ; Thu, 16 Nov 2017 19:11:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=tJ1TCoVMiM2vTbyPBEDXC1EE8R4GMNZsV3gzEumpbvQ=; b=T9WAkWz2bac6FFHij4949Bq6mhf/QFb9JEw6y3zr8lKzA5XgB2Ar96BwqJbdIOCajR eWKPlNsMfYyheQtoFVo047UDDfgKeZQLYUjAfrvTnMSiNm9UghjsBX83MGBjsgPp/Bod IzTBUSY57Xbx+9y8k/WDqFTCLxc4B4CBDJd0KHm8Tx283vYSQWPfOVL59Ad6M5fAEPgO WwGT2CYBwlSeNx9drTiHmrmv5HovqC3aeUREgzQTWGRiktIeRPjDt9o6+NeW6liIi0Qy MCai3zcLImQ18H/Dd2vExTP2TjcwOWmwoO0crt2OiC3ikbW8cj/x3T6JN3j4Z05/J5TR i/XQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=tJ1TCoVMiM2vTbyPBEDXC1EE8R4GMNZsV3gzEumpbvQ=; b=Bu6SSrvcIcgz2FQB/JKmku+jfEv8gyWLMSqkzpc6SJSSHbI5IzydWqALoFUWgtoGAT o4uKKyFbFU3X3qTlMjuBRBImQE9IFspdHzMuZ5cd1KtTKrK2WQYg1hk2Y0z2U8zdzjqW af7hAaGK5/QveCGxU/IXDCYl8+I/V7KDlBeulRNk59Fs8SctT5Dr/2drzgKdvn+FVpN3 Kj96S6D4sK8nhllaqpp6RG5G71fqm0h/x4ozNsOclVcErbTrtJoEKJwgAIia7KB/8WTc nDnU2YB9cuOe8PkqeDxhHCKuh73RO+pgMipTv4bBpHJH5j7W7WLZWaLxkzFYrOBnyR5F 6nzw== X-Gm-Message-State: AJaThX6mSRP2A+cQXoyk+FXx/W15h1Gb/iBUtWw9e8eZlgFYpw7/+8ed GLUhF/inNP/VfIuOBpzkXe0sfA== X-Google-Smtp-Source: AGs4zMaTkdVyDBcRe9JldXZBcqPCYJoTzA+ASB268aVGz1fJ8WYre579IakkdjibrAM347qdhHmb7g== X-Received: by 10.98.73.196 with SMTP id r65mr492139pfi.169.1510888282834; Thu, 16 Nov 2017 19:11:22 -0800 (PST) Received: from ?IPv6:2001:67c:370:1998:64db:3d1e:6d2f:8b68? ([2001:67c:370:1998:64db:3d1e:6d2f:8b68]) by smtp.gmail.com with ESMTPSA id x6sm4316612pgq.57.2017.11.16.19.11.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 19:11:22 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F32AC4A6-C631-4960-AB17-81D9022D2099" Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Date: Fri, 17 Nov 2017 11:11:19 +0800 In-Reply-To: <1316107b-9607-1db4-57de-7504fb6290a3@gmail.com> Cc: Brian Witten , "saag@ietf.org" To: Melinda Shore References: <6DF7F2EB-80AE-4AB9-A98F-076F12B4B8BD@vpnc.org> <92dccb1f-5194-5632-a35f-ad31f2ca8b85@cs.tcd.ie> <2AE14034-0634-4A6F-BDF6-77E5AD3AF78F@symantec.com> <1316107b-9607-1db4-57de-7504fb6290a3@gmail.com> X-Mailer: Apple Mail (2.3445.4.7) Archived-At: Subject: Re: [saag] [EXT] Re: patient ietf100 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 03:11:25 -0000 --Apple-Mail=_F32AC4A6-C631-4960-AB17-81D9022D2099 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Nov 17, 2017, at 10:51 AM, Melinda Shore = wrote: >> Um, clarification: count was 50/50. > Not to be tiresome about process, but we don't vote. Indeed, one of the strengths of the IETF process is that we are not = required to treat all positions as being equivalently valid, regardless = of technical merit. If 100 people think this is a good idea, and one = points out a good technical reason why it is not, I would hope that the = one person would be believed, and the 100 would not get their way. --Apple-Mail=_F32AC4A6-C631-4960-AB17-81D9022D2099 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = Nov 17, 2017, at 10:51 AM, Melinda Shore <melinda.shore@gmail.com> wrote:
Um, clarification: count was = 50/50.
Not to be tiresome about process, but we = don't vote.

Indeed, one of the strengths of the IETF process is that we = are not required to treat all positions as being equivalently valid, = regardless of technical merit.   If 100 people think this is a good = idea, and one points out a good technical reason why it is not, I would = hope that the one person would be believed, and the 100 would not get = their way.

= --Apple-Mail=_F32AC4A6-C631-4960-AB17-81D9022D2099-- From nobody Thu Nov 16 21:31:16 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB13E120227 for ; Thu, 16 Nov 2017 21:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gY1F2GRdpDJp for ; Thu, 16 Nov 2017 21:31:13 -0800 (PST) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDD8A126B72 for ; Thu, 16 Nov 2017 21:31:12 -0800 (PST) Received: by mail-pg0-x236.google.com with SMTP id 207so1138123pgc.12 for ; Thu, 16 Nov 2017 21:31:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=D2NPWJwZaUogSMyTDXC0gnxpaQPyX6ioUFEee88H6QQ=; b=fO5cTBlJsaXXG8yw/99NXFM1U75IyJZtFnEqlKemcOQ+5L27F1vwnNzLyyhakUlc4e tFLEoGLkpWc1wmlP2D0+0MIbVambpsWuczpj7+40eRWO7jYE7RATwRdeRL0h1ZzFQvRm P6WfsKNI0OroQxwkJxH+DuAme1m16Kpsy/XWZ2w4U7ufi2NPOkVhK/jj80hXJyljIAvg G3jfaTlTtkDybxHf7fyTBO3Gxfon3NwkBwtVTMWVDw/TQToaZ9YDRX4v/bRKNBuC0ldm jPc3teDt0MqZOtU3Y28aY2CX8TFG68c+hJQemf2fbrBghoYKDNLDBNoVjDs3QZw7pcef Xf6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to :content-transfer-encoding; bh=D2NPWJwZaUogSMyTDXC0gnxpaQPyX6ioUFEee88H6QQ=; b=FVC5snuDF9US57yXQUSRjmhmaOx/bAf1BEqwcAS9FEmUWjmJ/eLA/penz0ATScyJRs OG6RFd6FX/5JlkyGQ8JLfDC96P99+IPxVLeV7rb0nXNq5CPKaFPZm799Xz817ABli8EX JXkGBjkW0a5xyrpSrnOF2EpjZhLCuYQJFpLQ1NZRCc43MCJRAgSRDTX1A4RytBtPjXqI Hed049lqfKt6PiJs5rwTbp6FWc4dsDf23jhBdlivf7OvdTHUEX1VJE4Lwq8SQ6G9dWA5 rtaErKXRHbpt9slZMTEdUUuyWmXZPxtvNZVBX3GSrZ9gWo4dChuNODVS4sGcyHG5SUh3 Rpjg== X-Gm-Message-State: AJaThX6bkq/XxIciRGkq7Yxbous5h9VsTMn03OcI0iELsRFmswSSbO4V 9W+xgRzF56jD4VKLpSnkwdFaYuNktc/ZLvHEKeSVTA== X-Google-Smtp-Source: AGs4zMYs/EE1x3NCgCXFS6RrJUfWWYoHAq6oKmVKzRjHApPnuRzYBEVgdtkVZN8FKpGTf/YaHfSYJD/Obx7iKOIgODw= X-Received: by 10.84.172.195 with SMTP id n61mr3999794plb.78.1510896672336; Thu, 16 Nov 2017 21:31:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.155.9 with HTTP; Thu, 16 Nov 2017 21:30:31 -0800 (PST) From: Kathleen Moriarty Date: Fri, 17 Nov 2017 00:30:31 -0500 Message-ID: To: "saag@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [saag] Thoughts on SecDispatch Experiment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 05:31:15 -0000 Hi, In the interest of improving SecDispatch in the event we go forward with this as a WG, I'm sharing my thoughts and ideas of how to improve it. Your thoughts are welcome. SecDispatch Experiment Thoughts Additional pre-screening of drafts would be needed for this to be successfu= l. For SAAG sessions and AD sponsored drafts, what we have done in the past few years is to wait for requests to come in, we didn=E2=80=99t solici= t them. Then we=E2=80=99d review the associated draft(s). IF we thought it wa= s ready and worthwhile, we=E2=80=99d ask for discussion on the list. IF there was interest and time, we=E2=80=99d put it on the agenda. The pre-screening would involve asking if/where this had been presented before and the outcome. We might check list traffic on the draft and might check with the chairs of associated WGs to get their thoughts. Stephen and I would discuss AD sponsor draft requests, which might be separate from SAAG slot requests. There were times one of us would just accept one that we thought was sensible and thought that additional process around it wasn=E2=80=99t needed. For some others, we mig= ht discuss the request and see who could take it on, splitting up the work evenly. Then my process for AD sponsored drafts (different from Stephen=E2=80=99s) = was to either ask the authors to find a shepherd or to assign one if they were not able to find someone reasonable on their own. I used this as an opportunity to train possible WG chairs and in some cases folks who might be interested to be a SecAD in the future. The shepherd would perform a draft review, look at discussions on the draft, ask all the questions on the shepherd report, and provide their thoughts. I=E2=80=99d t= hen perform my review and if appropriate kick off last call. The shepherd would ensure all the comments received were addressed in the draft, I=E2=80=99d recheck that and the normal checks for a draft and put it on a telechat. SecDispatch seemed useful to have a hum on restarting a WG, so we could avoid a BoF. For some that a separate WG is needed, a BoF may or may not be necessary. We have started WGs in the past with list discussion only, so that=E2=80=99s possible still too. If we went ahead with SecDispatch, I=E2=80=99d expect the chairs to call a decision with each proposal and have this go to the list for objections. If the result was a recommendation for AD sponsorship, I would expect that the discussion as to who would sponsor would happen after the meeting between ADs who could consider a balance in workload when dividing them up. Nancy also had some ideas to streamline and improve the session if this experiment goes forward, so it=E2=80=99ll be good to get that document= ed. I=E2=80=99ll need to think a bit more on if I think this should go forward, but would like each of your thoughts. --=20 Best regards, Kathleen From nobody Fri Nov 17 15:49:03 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F250F126E64 for ; Fri, 17 Nov 2017 15:49:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.909 X-Spam-Level: X-Spam-Status: No, score=-2.909 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_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHR6h_Us6Pj4 for ; Fri, 17 Nov 2017 15:48:59 -0800 (PST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40117.outbound.protection.outlook.com [40.107.4.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 967E51250B8 for ; Fri, 17 Nov 2017 15:48:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5HS/NDIDn3g4paA8lHJ0V/aKBFfsmt3vHfJntbdpbD8=; b=YUFMeB49b8RDv6Fr1CL4TfqHEF8ry80XgUB7RmbPLWbX/JrHVq1kamiLW8vBOYC+3NRee++9y9f2cAZI9eGRe79JOLqmceUp0FvHUHGXpe6FAMXd8Us/eU6lxmfWzh1f82A8Hy6ki+uwVveZndANM9CsJ/bKqo+yRuT+EZ9aj7g= Received: from VI1PR07MB1102.eurprd07.prod.outlook.com (10.163.168.26) by VI1PR07MB1101.eurprd07.prod.outlook.com (10.163.168.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.2; Fri, 17 Nov 2017 23:48:55 +0000 Received: from VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::6021:c53d:b66d:4a61]) by VI1PR07MB1102.eurprd07.prod.outlook.com ([fe80::6021:c53d:b66d:4a61%13]) with mapi id 15.20.0260.001; Fri, 17 Nov 2017 23:48:54 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: Yoav Nir , Security Area Advisory Group CC: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Thread-Topic: [saag] Report on Side Meeting about Short Term Automatically Renewed (STAR) Certificates Thread-Index: AQHTX0/STXbKIN3VVkiQH2crDigHxqMZxMOA Date: Fri, 17 Nov 2017 23:48:54 +0000 Message-ID: <420411BF-C183-4DED-99C0-8F91490159C9@nokia.com> References: <420FE946-1EC3-49AC-A0DC-666347E708C0@gmail.com> In-Reply-To: <420FE946-1EC3-49AC-A0DC-666347E708C0@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [88.111.111.222] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1101; 6:VuTX8DcI8JWUorNqxPBCVw+xnx4T5ecJBmYf9OeLf4vWmCiFX9fUjnIsWctJZXnO+f+w6zT2gFmWH0/Gk+N+kzyIp9YDWjlktpX/QyPXuN1YNwRbPuAV7VNLxPS7M1cZzGk++/3UrOS06jpx3853cpQz3HsMVGts745YcY71b+gkiUEcgQmziMofunESoGk54AP2CV23SUS+He+Z8pwyNafkBiAoSZ/din6DOx0Xp3W6dgcKg/E4PrTLqjq2UST4K8vp8GgRGYLSglwR0F5sm+96q83Nra2SxjAF+kfXRmCAET3Huznc1Kf8INGYwT5ZENq9/xE82GP2BBooN+TVTi8+5k0f7acDN2IJ/+m15Vg=; 5:j4/qdpqfaSyzGStkoVPgJlM5Z7jMaf6PAjQoc9bo5b0/ODcHm32Pr76acnoQ5IjrCKT8mdrksvdy0zSpgI1Z58bOlEdj9nHo6PIBIqMuWRkIuWyY67y6b0qXHBHIVj384HqqcYyjlGtwrrKQqyAW8w3SwBKoJ8AsAc+mVs1ohE0=; 24:PjyOer1SmJTVq5kUbcSUAj7VGJr2AN1vP6gfgKX4mOw+7ZRhXqh8cZoIvffhqIOHDyJTZU3MNai3We4p0cKmf9NBQWM5TLgtbyx5fiXyHmw=; 7:jdVAUzNTXgIsdpMVCOcLJQiq6led9hn2KXsjcALdQN1jUQhY0qQVBOFMkZ+C6mqqJkkVlh3/NVDsWk57RqH5zznMjdychYR6hWt0lLojaBFvYcvoAYaXKOt7E8xJc3pmrl//7q3q6A4gctwpZCZD5MzzbNe0DpPZDtpWEvPwOLjqlLygTj7bNU7kZ75bYrkzZ2FAM96qklt/892O692x9PBqQQnXn6NnVFWHdnOKLKmcwDeR3kbi3WlyvtZ8i627 x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(346002)(39860400002)(376002)(53754006)(199003)(24454002)(189002)(4326008)(6436002)(6486002)(2900100001)(6506006)(7736002)(3280700002)(3660700001)(316002)(107886003)(39060400002)(66066001)(83716003)(58126008)(229853002)(2906002)(6246003)(110136005)(36756003)(97736004)(236005)(50986999)(53546010)(6116002)(106356001)(102836003)(83506002)(101416001)(9326002)(966005)(99286004)(14454004)(189998001)(8676002)(76176999)(68736007)(81156014)(606006)(54356999)(53936002)(81166006)(54896002)(6306002)(25786009)(6512007)(5250100002)(86362001)(478600001)(82746002)(8936002)(105586002)(2950100002)(5660300001)(34040400001)(3846002)(33656002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1101; H:VI1PR07MB1102.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: c4c8f69d-dcfd-4257-d805-08d52e15c34f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603258); SRVR:VI1PR07MB1101; x-ms-traffictypediagnostic: VI1PR07MB1101: authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(211936372134217)(179696456005106)(227612066756510)(21748063052155)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(3231022)(920507027)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(20161123555025)(20161123564025)(20161123560025)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB1101; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB1101; x-forefront-prvs: 049486C505 received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_420411BFC1834DED99C08F91490159C9nokiacom_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: c4c8f69d-dcfd-4257-d805-08d52e15c34f X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2017 23:48:54.7367 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1101 Archived-At: Subject: Re: [saag] Report on Side Meeting about Short Term Automatically Renewed (STAR) Certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Nov 2017 23:49:02 -0000 --_000_420411BFC1834DED99C08F91490159C9nokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgWW9hdiwNCg0KVGhhbmtzIGZvciBvcmdhbmlzaW5nIHRoZSBtZWV0aW5nIGFuZCBmb3IgdGhp cyByZXBvcnQuDQoNClR3byBxdWljayBub3Rlcy9jb21tZW50czoNCg0KMS4gICAgICAgRm9yIGRh dGEgYmFja2luZyB0aGUgNS03IGRheXMgbWluaW11bSBzaG9ydC10ZXJtbmVzcyBpbiB0aGUgd2ls ZCwgc2VlIGh0dHBzOi8vc3RhdGljLmdvb2dsZXVzZXJjb250ZW50LmNvbS9tZWRpYS9yZXNlYXJj aC5nb29nbGUuY29tL2VuLy9wdWJzL2FyY2hpdmUvNDYzNTkucGRmPGh0dHBzOi8vc3RhdGljLmdv b2dsZXVzZXJjb250ZW50LmNvbS9tZWRpYS9yZXNlYXJjaC5nb29nbGUuY29tL2VuL3B1YnMvYXJj aGl2ZS80NjM1OS5wZGY+IC0gc3BlY2lmaWNhbGx5LCB0aGUgQ0RGIGluIEZpZ3VyZSA0Ow0KDQoy LiAgICAgICBXUlQgd2hlcmUgdG8gaG9zdCB0aGlzIHdvcms6IG1heWJlIGEgdmVyeSBuYXJyb3ds eSBzY29wZWQgV0cgY291bGQgYmUgdGhlIGNvcnJlY3QgZm9ybWF0IGZvciBkZWxpdmVyaW5nDQoN CmEuICAgICAgIHRoZSBJbmZvcm1hdGlvbmFsIGRvY3VtZW50IGFib3V0IHRoZSBvcGVyYXRpb25h bCBhbmQgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgcmVnYXJkaW5nIHRoZSB1c2Ugb2YgU1RBUiBh bmQNCg0KYi4gICAgICAgYSB0aW55IFBTIGZvciB0aGUgY2VydGlmaWNhdGUgZXh0ZW5zaW9uDQoN CkNoZWVycywgdA0KDQoNCk9uIDE3LzExLzIwMTcsIDAyOjU3LCAic2FhZyBvbiBiZWhhbGYgb2Yg WW9hdiBOaXIiIDxzYWFnLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNhYWctYm91bmNlc0BpZXRm Lm9yZz4gb24gYmVoYWxmIG9mIHluaXIuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnluaXIuaWV0ZkBn bWFpbC5jb20+PiB3cm90ZToNCg0KSGVsbG8gYWxsDQoNCkxhc3QgbmlnaHQgKFRodXJzZGF5KSB3 ZSBoYWQgYSBzaWRlIG1lZXRpbmcgYWJvdXQgdGhlIGdvYWxzIG9mIGRyYWZ0LW5pci1zYWFnLXN0 YXIuICAyMSBwZW9wbGUgYXR0ZW5kZWQgdGhlIG1lZXRpbmcgYW5kIGl0IGxhc3RlZCBhIGxpdHRs ZSBvdmVyIG9uZSBob3VyLg0KDQpJIGdvdCBhIGxvdCBvZiB1c2VmdWwgY29tbWVudHMsIHNvbWUg b2Ygd2hpY2ggSSB3aWxsIGxpc3QgaGVyZSBpbiBubyBwYXJ0aWN1bGFyIG9yZGVyOg0KDQrCtyAg ICAgICAgIFRoZSB1bmlxdWUgdGhpbmcgYWJvdXQgU1RBUiBjZXJ0aWZpY2F0ZXMgaXMgbm90IHRo YXQgdGhleSBhcmUgc2hvcnQgdGVybSwgYnV0IHRoYXQgdGhlIFJlbHlpbmcgUGFydGllcyBkbyBu b3QgY2hlY2sgcmV2b2NhdGlvbiBvZiB0aGUgRW5kIEVudGl0eSBjZXJ0aWZpY2F0ZXMuIFRoZSBk b2N1bWVudCBzaG91bGQgYmUgcmVmYWN0b3JlZCB0byBtYWtlIHRoaXMgdGhlIHN1YmplY3QsIHdp dGggc2hvcnQtdGVybW5lc3MgcHJlc2VudGVkIGFzIG1pdGlnYXRpb24gZm9yIHRoZSBsYWNrIG9m IHJldm9jYXRpb24gY2hlY2tpbmcgKFN0ZWZhbiBTYW50ZXNzb24pLg0KwrcgICAgICAgICDigJxT aG9ydOKAnSBhbmQg4oCcbG9uZ+KAnSBhcmUgcmVsYXRpdmUgYW5kIGFueSBjdXQtb2ZmIHBvaW50 IHdvdWxkIGJlIGFyYml0cmFyeS4gVGhlIGxpZmV0aW1lIG9mIGEgU1RBUiBjZXJ0aWZpY2F0ZSBz aG91bGQgYmUgZGVmaW5lZCBieSB0aGUgcmVxdWlyZW1lbnRzIGZvciByZXZvY2F0aW9uLCBub3Qg Ynkgc29tZSBhcmJpdHJhcnkgbGltaXQgZGVmaW5lZCBpbiBhbiBSRkMuDQrCtyAgICAgICAgIFRo ZSBkcmFmdCBzaG91bGQgYWRkIHByaXZhY3kgYW5kIGxhdGVuY3kgY29uY2VybnMgKGJvdGggYXJl IGNvbXByb21pc2VkIGJ5IHJldm9jYXRpb24gY2hlY2tpbmcsIHNvIGEgcGx1cyB0byBTVEFSKSB0 byB0aGUgY29uc2lkZXJhdGlvbnMuIChES0cpDQrCtyAgICAgICAgIEl0IHNob3VsZCBiZSBub3Rl ZCAoaW4gdGhlIGRyYWZ0KSB0aGF0IHdoZW4gdGhlIFBLSSBpcyBhIGhpZXJhcmNoeSB0aGUgUlAg c3RpbGwgbmVlZHMgdG8gY2hlY2sgcmV2b2NhdGlvbiBmb3IgdGhlIHN1Yi1DQXMuIFRoaXMgbmVn YXRlcyBtdWNoIG9mIHRoZSBzaW1wbGljaXR5IGFkdmFudGFnZS4NCsK3ICAgICAgICAgV2Ugc2hv dWxkIGNvbnNpZGVyIHdoYXQgdXNlIGNhc2VzIGFyZSBhcHByb3ByaWF0ZSBmb3IgU1RBUi4gSW4g dGhlIHdlYiAoYXMgbWVhc3VyZWQgYnkgR29vZ2xlIGFuZCBvdGhlcnMpIGNsb2NrIHNrZXdzIGFy ZSByYW1wYW50LCBhbmQgNS03IGRheSBza2V3IGhhdmUgdG8gYmUgYXNzdW1lZC4gQWRkaXRpb25h bGx5LCB0aGUgQ0FzIG9uIHRoZSB3ZWIgdHlwaWNhbGx5IHVzZSBvbmUgb3IgbW9yZSBsYXllcnMg b2Ygc3ViLUNBcy4gIENsb3NlZCBlbnZpcm9ubWVudHMgc3VjaCBhcyBkYXRhY2VudGVycywgY29y cG9yYXRlIG5ldHdvcmtzIGFuZCBtYW5hZ2VkIHN5c3RlbXMgaGF2ZSBiZXR0ZXIgY29udHJvbCBv ZiBjbG9ja3MgYW5kIGNhbiBvZnRlbiBmb3JlZ28gaGllcmFyY2h5Lg0KbyAgICBFeGFtcGxlcyBv ZiDigJxtYW5hZ2VkIHN5c3RlbXPigJ0gdGhhdCB3ZXJlIG1lbnRpb25lZDoNCsKnICBBIGJ1bmNo IG9mIE5TRnMgY29udHJvbGxlZCBieSBhIHNpbmdsZSBTZWN1cml0eSBDb250cm9sbGVyIChhcyB3 ZeKAmXJlIGRvaW5nIGluIEkyTlNGLCBidXQgdmVuZG9ycyBoYXZlIGJlZW4gZG9pbmcgd2l0aCBw cm9wcmlldGFyeSBwcm90b2NvbHMgZm9yIHllYXJzKQ0KwqcgIEEgYnVuY2ggb2YgSVBzZWMgZW5k cG9pbnRzIChlaXRoZXIgdHVubmVsaW5nIGdhdGV3YXlzIG9yIGhvc3RzKSBtYW5hZ2VkIGJ5IGFu IE5TRiAod2XigJlyZSBkb2luZyB0aGF0IGluIEkyTlNGIGFzIHdlbGwpDQrCpyAgVmVoaWNsZS10 by12ZWhpY2xlIG5ldHdvcmtzIHdoZXJlIGNlcnRpZmljYXRlcyBhcmUgaXNzdWVkIGZvciBhIG1v bnRoLCAyMCB0aW1lcyBhIG1vbnRoIChCb2IgTW9za293aXR6KQ0KwqcgIFN0b3JhZ2UgQXJlYSBO ZXR3b3JrcyB3aGVyZSBkYXRhIGNsaWVudHMgY29ubmVjdCB0byBkYXRhIHNlcnZlcnMgYW5kIHJl cXVpcmUgYXQgbGVhc3QgYXV0aGVudGljYXRpb24gYW5kIG9mdGVuIGVuY3J5cHRpb24sIHdoaWNo IHRoZXkgZ2V0IHVzaW5nIFRMUyBvciBJS0UvSVBzZWMuDQrCtyAgICAgICAgIFNUQVIgY2VydGlm aWNhdGVzIHNlZW0gdG8gYmUgZXF1aXZhbGVudCBpbiB0ZXJtcyBvZiBzZWN1cml0eSBob3cgbG9u ZyBpdCB0YWtlcyB0byByZXZva2UgYSBjZXJ0aWZpY2F0ZSB0byBQS0kgY2VydGlmaWNhdGVzIHdp dGggT0NTUCBNdXN0LVN0YXBsZS4gVGhlIGRyYWZ0IHNob3VsZCBjYWxsIG91dCB0aGF0IHRoZSBs aWZldGltZSBvZiBhIGNlcnRpZmljYXRlIHNob3VsZCBiZSBzaW1pbGFyIHRvIHRoZSDigJxsaWZl dGltZeKAnSAodGltZSBmcm9tIHRoaXNVcGRhdGUgdG8gbmV4dFVwZGF0ZSkgb2YgdGhlIE9DU1Ag cmVzcG9uc2VzLg0KwrcgICAgICAgICBUaGVyZSB3YXMgc29tZSBkaXNjdXNzaW9uIGFib3V0IHdo ZXRoZXIgU1RBUiBjZXJ0aWZpY2F0ZXMgc2hvdWxkIGJlIHNwZWNpYWxseSBtYXJrZWQsIHBlcmhh cHMgYnkgYW4gY2VydGlmaWNhdGUgZXh0ZW5zaW9uLCBhcyBzdWNoLiBUaGUgcmVhc29uaW5nIGlz IHRoYXQgYXQgc29tZSBwb2ludCBoYXZpbmcgbm9uZSBvciBDUkwgRFAgb3IgT0NTUCBVUkkgbWF5 IGJlIHRyZWF0ZWQgYXMgaW52YWxpZCwgc28gU1RBUiBzdGF0dXMgbWF5IG5lZWQgdG8gYmUgY2Fs bGVkIG91dCBleHBsaWNpdGx5LiAgQ3VycmVudCBDQUJGIGd1aWRhbmNlIGlzIHRoYXQgbGFjayBv ZiByZXZvY2F0aW9uIGlzIGZpbmUgZm9yIGNlcnRpZmljYXRlcyB3aG9zZSB2YWxpZGl0eSBwZXJp b2QgaXMgc2hvcnRlciB0aGFuIFggKFRCRCB3aGF0IFggaXMpIHNvIGF0IGxlYXN0IGZvciBub3cg YW5kIGZvciB0aGUgd2ViIHN1Y2ggYW4gZXh0ZW5zaW9uIGlzIG5vdCBuZWVkZWQuIElmIGV2ZXIg c3VjaCBhIGNlcnRpZmljYXRlIGV4dGVuc2lvbiBpcyBuZWVkZWQsIGl0IGNhbiBiZSBkb25lIGlu IGEgc2hvcnQgc3RhbmRhcmRzLXRyYWNrIGRvY3VtZW50LiBUaGUgaW50ZW50aW9uIGlzIGZvciB0 aGlzIGRvY3VtZW50IHRvIGJlIGluZm9ybWF0aW9uYWwNCg0KQW5vdGhlciB0aGluZyB0aGF0IHdh cyBkaXNjdXNzZWQgaXMgd2hlcmUgdGhpcyB3b3JrIHNob3VsZCBnby4gIEl0IG9idmlvdXNseSBy ZXF1aXJlcyBhIGxvdCBvZiBmZWVkYmFjaywgc28gaXQgZG9lc27igJl0IHNlZW0gdG8gYmUgYSBn b29kIGZpdCBmb3IgZWl0aGVyIEFELXNwb25zb3JlZCBvciBhbiBpbmRlcGVuZGVudCBzdWJtaXNz aW9uLiBOZWl0aGVyIG9mIHRoZXNlIHN0cmVhbXMgdGVuZCB0byBnZXQgYSBnb29kIHJldmlldy4g VGhlIGF1dGhvcnMgc2hvdWxkIGRpc2N1c3Mgd2l0aCB0aGUgc2VjdXJpdHkgQURzIGFuZCBTZWNE aXNwYXRjaCB3aGljaCBleGlzdGluZyBvciBuZXcgV0cgaXMgdGhlIHJpZ2h0IGhvbWUgZm9yIHRo aXMgd29yay4NCg0KVGhhbmsgeW91IHRvIGV2ZXJ5b25lIHdobyB0b29rIHRoZSB0aW1lIHRvIGF0 dGVuZC4NCg0KWW9hdg0KDQo= --_000_420411BFC1834DED99C08F91490159C9nokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6 bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBs ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwgbGku TXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXByaW9y aXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDowY207DQoJbWFyZ2luLWJv dHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCnNw YW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo1OTUuMHB0IDg0Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIu MHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8q IExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjM3MDQyNjExNTsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTIwNjc4NjEwODY7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w OjcyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxp c3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjE4MC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIx Ni4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjMyNC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTMyNjM5 ODg0MDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTcx NzgxNzgxNCAxMzQ4MDc1NjcgMTM0ODA3NTc3IDEzNDgwNzU3OSAxMzQ4MDc1NjcgMTM0ODA3NTc3 IDEzNDgwNzU3OSAxMzQ4MDc1NjcgMTM0ODA3NTc3IDEzNDgwNzU3OTt9DQpAbGlzdCBsMTpsZXZl bDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 O30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwx OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRl eHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhh LWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05 LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBj bTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVO LUdCIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9u MSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBZb2F2LDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rcyBmb3Igb3JnYW5pc2luZyB0aGUgbWVldGluZyBh bmQgZm9yIHRoaXMgcmVwb3J0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlR3byBxdWljayBub3Rl cy9jb21tZW50czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFn cmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIi PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPjEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bh bj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Gb3IgZGF0YSBi YWNraW5nIHRoZSA1LTcgZGF5cyBtaW5pbXVtIHNob3J0LXRlcm1uZXNzIGluIHRoZSB3aWxkLCBz ZWUNCjxhIGhyZWY9Imh0dHBzOi8vc3RhdGljLmdvb2dsZXVzZXJjb250ZW50LmNvbS9tZWRpYS9y ZXNlYXJjaC5nb29nbGUuY29tL2VuL3B1YnMvYXJjaGl2ZS80NjM1OS5wZGYiPg0KaHR0cHM6Ly9z dGF0aWMuZ29vZ2xldXNlcmNvbnRlbnQuY29tL21lZGlhL3Jlc2VhcmNoLmdvb2dsZS5jb20vZW4v L3B1YnMvYXJjaGl2ZS80NjM1OS5wZGY8L2E+IC0gc3BlY2lmaWNhbGx5LCB0aGUgQ0RGIGluIEZp Z3VyZSA0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBo IiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+PCFb aWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+Mi48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9t YW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwv c3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPldSVCB3aGVyZSB0byBo b3N0IHRoaXMgd29yazogbWF5YmUgYSB2ZXJ5IG5hcnJvd2x5IHNjb3BlZCBXRyBjb3VsZCBiZSB0 aGUgY29ycmVjdCBmb3JtYXQgZm9yIGRlbGl2ZXJpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0 LWluZGVudDotMTguMHB0O21zby1saXN0OmwxIGxldmVsMiBsZm8yIj4NCjwhW2lmICFzdXBwb3J0 TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi PmEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFu PjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxp YnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj50aGUgSW5mb3JtYXRpb25hbCBkb2N1bWVu dCBhYm91dCB0aGUgb3BlcmF0aW9uYWwgYW5kIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIHJlZ2Fy ZGluZyB0aGUgdXNlIG9mIFNUQVIgYW5kPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6 LTE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDIgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5iLjxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRp Zl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+YSB0aW55IFBTIGZvciB0aGUgY2VydGlmaWNhdGUgZXh0 ZW5zaW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJy aTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Q2hlZXJzLCB0PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaTttc28tZmFyZWFzdC1sYW5ndWFnZTpF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiAxNy8xMS8yMDE3LCAw Mjo1NywgJnF1b3Q7c2FhZyBvbiBiZWhhbGYgb2YgWW9hdiBOaXImcXVvdDsgJmx0OzxhIGhyZWY9 Im1haWx0bzpzYWFnLWJvdW5jZXNAaWV0Zi5vcmciPnNhYWctYm91bmNlc0BpZXRmLm9yZzwvYT4g b24gYmVoYWxmIG9mDQo8YSBocmVmPSJtYWlsdG86eW5pci5pZXRmQGdtYWlsLmNvbSI+eW5pci5p ZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+SGVsbG8gYWxsIDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+TGFzdCBuaWdodCAoVGh1cnNkYXkpIHdlIGhhZCBhIHNpZGUg bWVldGluZyBhYm91dCB0aGUgZ29hbHMgb2YgZHJhZnQtbmlyLXNhYWctc3Rhci4gJm5ic3A7MjEg cGVvcGxlIGF0dGVuZGVkIHRoZSBtZWV0aW5nIGFuZCBpdCBsYXN0ZWQgYSBsaXR0bGUgb3ZlciBv bmUgaG91ci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+SSBnb3QgYSBsb3Qgb2YgdXNlZnVsIGNvbW1lbnRzLCBzb21lIG9mIHdoaWNoIEkgd2lsbCBs aXN0IGhlcmUgaW4gbm8gcGFydGljdWxhciBvcmRlcjo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVs MSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8 c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPlRoZSB1bmlxdWUgdGhpbmcgYWJvdXQgU1RBUiBjZXJ0aWZpY2F0 ZXMgaXMgbm90IHRoYXQgdGhleSBhcmUgc2hvcnQgdGVybSwgYnV0IHRoYXQgdGhlIFJlbHlpbmcg UGFydGllcyBkbyBub3QgY2hlY2sgcmV2b2NhdGlvbiBvZiB0aGUgRW5kIEVudGl0eSBjZXJ0aWZp Y2F0ZXMuIFRoZSBkb2N1bWVudCBzaG91bGQgYmUgcmVmYWN0b3JlZCB0byBtYWtlIHRoaXMgdGhl IHN1YmplY3QsIHdpdGggc2hvcnQtdGVybW5lc3MNCiBwcmVzZW50ZWQgYXMgbWl0aWdhdGlvbiBm b3IgdGhlIGxhY2sgb2YgcmV2b2NhdGlvbiBjaGVja2luZyAoU3RlZmFuIFNhbnRlc3NvbikuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6NzIuMHB0O3Rl eHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBv cnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9s Ij48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0 ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+4oCc U2hvcnTigJ0gYW5kIOKAnGxvbmfigJ0gYXJlIHJlbGF0aXZlIGFuZCBhbnkgY3V0LW9mZiBwb2lu dCB3b3VsZCBiZSBhcmJpdHJhcnkuIFRoZSBsaWZldGltZSBvZiBhIFNUQVIgY2VydGlmaWNhdGUg c2hvdWxkIGJlIGRlZmluZWQgYnkgdGhlIHJlcXVpcmVtZW50cyBmb3IgcmV2b2NhdGlvbiwgbm90 IGJ5IHNvbWUgYXJiaXRyYXJ5IGxpbWl0IGRlZmluZWQgaW4gYW4gUkZDLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDot MTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlRoZSBkcmFmdCBzaG91 bGQgYWRkIHByaXZhY3kgYW5kIGxhdGVuY3kgY29uY2VybnMgKGJvdGggYXJlIGNvbXByb21pc2Vk IGJ5IHJldm9jYXRpb24gY2hlY2tpbmcsIHNvIGEgcGx1cyB0byBTVEFSKSB0byB0aGUgY29uc2lk ZXJhdGlvbnMuIChES0cpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFy Z2luLWxlZnQ6NzIuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxm bzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwv c3Bhbj48IVtlbmRpZl0+SXQgc2hvdWxkIGJlIG5vdGVkIChpbiB0aGUgZHJhZnQpIHRoYXQgd2hl biB0aGUgUEtJIGlzIGEgaGllcmFyY2h5IHRoZSBSUCBzdGlsbCBuZWVkcyB0byBjaGVjayByZXZv Y2F0aW9uIGZvciB0aGUgc3ViLUNBcy4gVGhpcyBuZWdhdGVzIG11Y2ggb2YgdGhlIHNpbXBsaWNp dHkgYWR2YW50YWdlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdp bi1sZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8x Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPldlIHNob3VsZCBjb25zaWRlciB3aGF0IHVzZSBjYXNlcyBhcmUgYXBwcm9w cmlhdGUgZm9yIFNUQVIuIEluIHRoZSB3ZWIgKGFzIG1lYXN1cmVkIGJ5IEdvb2dsZSBhbmQgb3Ro ZXJzKSBjbG9jayBza2V3cyBhcmUgcmFtcGFudCwgYW5kIDUtNyBkYXkgc2tldyBoYXZlIHRvIGJl IGFzc3VtZWQuIEFkZGl0aW9uYWxseSwgdGhlIENBcyBvbiB0aGUgd2ViIHR5cGljYWxseSB1c2Ug b25lIG9yIG1vcmUNCiBsYXllcnMgb2Ygc3ViLUNBcy4gJm5ic3A7Q2xvc2VkIGVudmlyb25tZW50 cyBzdWNoIGFzIGRhdGFjZW50ZXJzLCBjb3Jwb3JhdGUgbmV0d29ya3MgYW5kIG1hbmFnZWQgc3lz dGVtcyBoYXZlIGJldHRlciBjb250cm9sIG9mIGNsb2NrcyBhbmQgY2FuIG9mdGVuIGZvcmVnbyBo aWVyYXJjaHkuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDoxMDguMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwyIGxmbzEi Pg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPm88c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkV4 YW1wbGVzIG9mIOKAnG1hbmFnZWQgc3lzdGVtc+KAnSB0aGF0IHdlcmUgbWVudGlvbmVkOg0KPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MTQ0LjBwdDt0 ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMyBsZm8xIj4NCjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Oldpbmdk aW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wqc8c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPkEgYnVuY2ggb2YgTlNGcyBjb250cm9sbGVkIGJ5IGEgc2luZ2xlIFNl Y3VyaXR5IENvbnRyb2xsZXIgKGFzIHdl4oCZcmUgZG9pbmcgaW4gSTJOU0YsIGJ1dCB2ZW5kb3Jz IGhhdmUgYmVlbiBkb2luZyB3aXRoIHByb3ByaWV0YXJ5IHByb3RvY29scyBmb3IgeWVhcnMpPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MTQ0LjBwdDt0 ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMyBsZm8xIj4NCjwhW2lmICFzdXBw b3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Oldpbmdk aW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wqc8c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPkEgYnVuY2ggb2YgSVBzZWMgZW5kcG9pbnRzIChlaXRoZXIgdHVubmVs aW5nIGdhdGV3YXlzIG9yIGhvc3RzKSBtYW5hZ2VkIGJ5IGFuIE5TRiAod2XigJlyZSBkb2luZyB0 aGF0IGluIEkyTlNGIGFzIHdlbGwpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87bWFyZ2luLWxlZnQ6MTQ0LjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxl dmVsMyBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9y ZSI+wqc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsi PiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPlZlaGljbGUtdG8tdmVoaWNs ZSBuZXR3b3JrcyB3aGVyZSBjZXJ0aWZpY2F0ZXMgYXJlIGlzc3VlZCBmb3IgYSBtb250aCwgMjAg dGltZXMgYSBtb250aCAoQm9iIE1vc2tvd2l0eik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxNDQuMHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxp c3Q6bDAgbGV2ZWwzIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj7CpzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+U3RvcmFnZSBB cmVhIE5ldHdvcmtzIHdoZXJlIGRhdGEgY2xpZW50cyBjb25uZWN0IHRvIGRhdGEgc2VydmVycyBh bmQgcmVxdWlyZSBhdCBsZWFzdCBhdXRoZW50aWNhdGlvbiBhbmQgb2Z0ZW4gZW5jcnlwdGlvbiwg d2hpY2ggdGhleSBnZXQgdXNpbmcgVExTIG9yIElLRS9JUHNlYy48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDo3Mi4wcHQ7dGV4dC1pbmRlbnQ6LTE4LjBw dDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJt c28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3 IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5TVEFSIGNlcnRpZmljYXRlcyBz ZWVtIHRvIGJlIGVxdWl2YWxlbnQgaW4gdGVybXMgb2YNCjxzPnNlY3VyaXR5PC9zPiBob3cgbG9u ZyBpdCB0YWtlcyB0byByZXZva2UgYSBjZXJ0aWZpY2F0ZSB0byBQS0kgY2VydGlmaWNhdGVzIHdp dGggT0NTUCBNdXN0LVN0YXBsZS4gVGhlIGRyYWZ0IHNob3VsZCBjYWxsIG91dCB0aGF0IHRoZSBs aWZldGltZSBvZiBhIGNlcnRpZmljYXRlIHNob3VsZCBiZSBzaW1pbGFyIHRvIHRoZSDigJxsaWZl dGltZeKAnSAodGltZSBmcm9tIHRoaXNVcGRhdGUgdG8gbmV4dFVwZGF0ZSkgb2YgdGhlIE9DU1Ag cmVzcG9uc2VzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0OjcyLjBwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4N CjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+ PCFbZW5kaWZdPlRoZXJlIHdhcyBzb21lIGRpc2N1c3Npb24gYWJvdXQgd2hldGhlciBTVEFSIGNl cnRpZmljYXRlcyBzaG91bGQgYmUgc3BlY2lhbGx5IG1hcmtlZCwgcGVyaGFwcyBieSBhbiBjZXJ0 aWZpY2F0ZSBleHRlbnNpb24sIGFzIHN1Y2guIFRoZSByZWFzb25pbmcgaXMgdGhhdCBhdCBzb21l IHBvaW50IGhhdmluZyBub25lIG9yIENSTCBEUCBvciBPQ1NQIFVSSSBtYXkgYmUgdHJlYXRlZCBh cyBpbnZhbGlkLA0KIHNvIFNUQVIgc3RhdHVzIG1heSBuZWVkIHRvIGJlIGNhbGxlZCBvdXQgZXhw bGljaXRseS4gJm5ic3A7Q3VycmVudCBDQUJGIGd1aWRhbmNlIGlzIHRoYXQgbGFjayBvZiByZXZv Y2F0aW9uIGlzIGZpbmUgZm9yIGNlcnRpZmljYXRlcyB3aG9zZSB2YWxpZGl0eSBwZXJpb2QgaXMg c2hvcnRlciB0aGFuIFggKFRCRCB3aGF0IFggaXMpIHNvIGF0IGxlYXN0IGZvciBub3cgYW5kIGZv ciB0aGUgd2ViIHN1Y2ggYW4gZXh0ZW5zaW9uIGlzIG5vdCBuZWVkZWQuIElmDQogZXZlciBzdWNo IGEgY2VydGlmaWNhdGUgZXh0ZW5zaW9uIGlzIG5lZWRlZCwgaXQgY2FuIGJlIGRvbmUgaW4gYSBz aG9ydCBzdGFuZGFyZHMtdHJhY2sgZG9jdW1lbnQuIFRoZSBpbnRlbnRpb24gaXMgZm9yIHRoaXMg ZG9jdW1lbnQgdG8gYmUgaW5mb3JtYXRpb25hbDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5Bbm90aGVyIHRoaW5nIHRoYXQgd2FzIGRpc2N1c3NlZCBp cyB3aGVyZSB0aGlzIHdvcmsgc2hvdWxkIGdvLiAmbmJzcDtJdCBvYnZpb3VzbHkgcmVxdWlyZXMg YSBsb3Qgb2YgZmVlZGJhY2ssIHNvIGl0IGRvZXNu4oCZdCBzZWVtIHRvIGJlIGEgZ29vZCBmaXQg Zm9yIGVpdGhlciBBRC1zcG9uc29yZWQgb3IgYW4gaW5kZXBlbmRlbnQgc3VibWlzc2lvbi4gTmVp dGhlciBvZiB0aGVzZQ0KIHN0cmVhbXMgdGVuZCB0byBnZXQgYSBnb29kIHJldmlldy4gVGhlIGF1 dGhvcnMgc2hvdWxkIGRpc2N1c3Mgd2l0aCB0aGUgc2VjdXJpdHkgQURzIGFuZCBTZWNEaXNwYXRj aCB3aGljaCBleGlzdGluZyBvciBuZXcgV0cgaXMgdGhlIHJpZ2h0IGhvbWUgZm9yIHRoaXMgd29y ay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+VGhh bmsgeW91IHRvIGV2ZXJ5b25lIHdobyB0b29rIHRoZSB0aW1lIHRvIGF0dGVuZC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+WW9hdjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_420411BFC1834DED99C08F91490159C9nokiacom_-- From nobody Fri Nov 17 16:48:39 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9955A1286D6 for ; Fri, 17 Nov 2017 16:48:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.69 X-Spam-Level: X-Spam-Status: No, score=-4.69 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 s4Aw_WMsRBeM for ; Fri, 17 Nov 2017 16:48:34 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0133.outbound.protection.outlook.com [104.47.0.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82F4C120725 for ; Fri, 17 Nov 2017 16:48:32 -0800 (PST) Received: from AM5PR0602MB3251.eurprd06.prod.outlook.com (10.167.170.156) by AM5PR0602MB3250.eurprd06.prod.outlook.com (10.167.170.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Sat, 18 Nov 2017 00:48:30 +0000 Received: from AM5PR0602MB3251.eurprd06.prod.outlook.com ([fe80::118e:cd3f:70c3:f495]) by AM5PR0602MB3251.eurprd06.prod.outlook.com ([fe80::118e:cd3f:70c3:f495%13]) with mapi id 15.20.0239.007; Sat, 18 Nov 2017 00:48:30 +0000 From: "Diego R. Lopez" To: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" , Yoav Nir , Security Area Advisory Group Thread-Topic: [saag] Report on Side Meeting about Short Term Automatically Renewed (STAR) Certificates Thread-Index: AQHTX0/jHQaTa82XqkerClxTqZZcW6MZPqAAgAAQpoA= Date: Sat, 18 Nov 2017 00:48:30 +0000 Message-ID: References: <420FE946-1EC3-49AC-A0DC-666347E708C0@gmail.com> <420411BF-C183-4DED-99C0-8F91490159C9@nokia.com> In-Reply-To: <420411BF-C183-4DED-99C0-8F91490159C9@nokia.com> Accept-Language: en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-originating-ip: [42.61.209.253] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0602MB3250; 6:g4N5ccIAH+SFPMCRA+HMYUbCWPlD+rGLSFZ0wsTXJX8bmC5R2htqMIO4XpZ1CPKKZZBFzJr0d+yWtB3wWpIbFnLT5fLbin2tZOv1MdkuJx06lh3OS0uO+5VDTMHk401WSKcw2RK7rwxpR9w0+ZgOr1Zkwwcmjt2LTKy1fPHle0nt+OoT2L7cFhgmyHjFMiPIBgqe0LS7ga9bFq1ptwBTETlgJ7a6P1mC4KURY/sJuTpXGkrPr/Q8YD2xQ0bOojR5/B5Z1ocb2tC3q1BR8yBvA8d5GW9+ip6IFmYshVooIZPFGf7x4K4m+bXqdWY0YqgeDwFQpRGk11EMdBCspSpfjAYYlHitd0YJqAvPU7uU9Ko=; 5:0Dwsp/mBcM1u23a4CTt2Ni5kRdCnjcbPquPp99sqVPnV8Wvhwrkd7zx24D9vsS4RbamZnN/1yka5h4NNR+28eY81CsG5jdE2meKXjW5bV8qBfUL/Aw07Cn5IhauqQDolz9iz7/naQ6AbIHy1FUsBVcHtGThGJUopVUFKd9Z61ns=; 24:FmjeQGL9uf28mHiV5VI9GPpymFUrSmd6SGY5xOw9jM+nPVU6IY4dR+88wNEnd/dwx2iycUOvPUxK2ZkBWoUI5aRdK1GsCAvVxDr57euDO8c=; 7:Sw2AcbnlDxx/iSJdJcDoCimZiPJeRSzfPWOmxndolmTpE8t8S64jIYpVLHTMAQHkfeiTWwt5vZZlm9kZjD+BD/ggE86aHgIifzlvYSdwHI4lpOK7/IhT1qfRRUqVK/u8mVkRvW9yzSHuL7JvH2sLd+4obAogYb00ex/ylm/AEFTBQFpBZM96aITZueUR6X1oO0K4BRBpEkPXFlW+AYy12JMkbCDJWw44Q+typj/mRT/OLYdLBCwoIaO9P0JoG7nM x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: fb2e79d8-4623-4c92-405f-08d52e1e1656 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603258); SRVR:AM5PR0602MB3250; x-ms-traffictypediagnostic: AM5PR0602MB3250: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(40392960112811)(192374486261705)(82608151540597)(211936372134217)(179696456005106)(227612066756510)(21748063052155)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(3231022)(920507027)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0602MB3250; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0602MB3250; x-forefront-prvs: 04953B1F22 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(346002)(25724002)(53754006)(199003)(189002)(24454002)(40134004)(252514010)(106356001)(36756003)(101416001)(229853002)(2900100001)(66066001)(33656002)(54896002)(6306002)(6512007)(83716003)(236005)(6246003)(6486002)(53936002)(58126008)(2906002)(5250100002)(50986999)(3846002)(54356999)(102836003)(76176999)(99286004)(606006)(6506006)(6116002)(478600001)(83506002)(5660300001)(8656006)(53546010)(7736002)(8936002)(110136005)(6436002)(966005)(14454004)(2950100002)(39060400002)(86362001)(34040400001)(81156014)(81166006)(105586002)(82746002)(25786009)(786003)(68736007)(316002)(8676002)(3660700001)(97736004)(3280700002)(189998001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0602MB3250; H:AM5PR0602MB3251.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BA8C9981D5564C298233EE430611F1E4telefonicacom_" MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-Network-Message-Id: fb2e79d8-4623-4c92-405f-08d52e1e1656 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2017 00:48:30.0503 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0602MB3250 Archived-At: Subject: Re: [saag] Report on Side Meeting about Short Term Automatically Renewed (STAR) Certificates X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Nov 2017 00:48:38 -0000 --_000_BA8C9981D5564C298233EE430611F1E4telefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkxvb2tpbmcgYXQgdGhlIGRpdmVyc2l0eSBvZiB1c2UgY2FzZXMsIGFuZCB0aGUgYWRk aXRpb25hbCBpbXBsaWNhdGlvbnMgdGhhdCB3aGVyZSBkaXNjdXNzZWQgZHVyaW5nIHRoZSBtZWV0 aW5nLCBJIHN1cHBvcnQgdGhlIGlkZWEgb2YgYSB2ZXJ5IGZvY3VzZWQgV0cgZm9yIHRoaXMgdGFz ay4NCg0KQmUgZ29vZGUsDQotLQ0KIkVzdGEgdmV6IG5vIGZhbGxhcmVtb3MsIERvY3RvciBJbmZp ZXJubyINCg0KRHIgRGllZ28gUi4gTG9wZXoNClRlbGVmb25pY2EgSStEDQpodHRwOi8vcGVvcGxl LnRpZC5lcy9kaWVnby5sb3Blei8NCg0KZS1tYWlsOiBkaWVnby5yLmxvcGV6QHRlbGVmb25pY2Eu Y29tPG1haWx0bzpkaWVnby5yLmxvcGV6QHRlbGVmb25pY2EuY29tPg0KVGVsOiAgICAgICAgKzM0 IDkxMyAxMjkgMDQxDQpNb2JpbGU6ICszNCA2ODIgMDUxIDA5MQ0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCg0KDQoNCk9uIDE4LzExLzE3IDc6NTAsICJzYWFnIGVuIG5vbWJy ZSBkZSBGb3NzYXRpLCBUaG9tYXMgKE5va2lhIC0gR0IvQ2FtYnJpZGdlLCBVSykiIDxzYWFnLWJv dW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnNhYWctYm91bmNlc0BpZXRmLm9yZz4gZW4gbm9tYnJlIGRl IHRob21hcy5mb3NzYXRpQG5va2lhLmNvbTxtYWlsdG86dGhvbWFzLmZvc3NhdGlAbm9raWEuY29t Pj4gd3JvdGU6DQoNCkhpIFlvYXYsDQoNClRoYW5rcyBmb3Igb3JnYW5pc2luZyB0aGUgbWVldGlu ZyBhbmQgZm9yIHRoaXMgcmVwb3J0Lg0KDQpUd28gcXVpY2sgbm90ZXMvY29tbWVudHM6DQoNCjEu ICAgICAgRm9yIGRhdGEgYmFja2luZyB0aGUgNS03IGRheXMgbWluaW11bSBzaG9ydC10ZXJtbmVz cyBpbiB0aGUgd2lsZCwgc2VlIGh0dHBzOi8vc3RhdGljLmdvb2dsZXVzZXJjb250ZW50LmNvbS9t ZWRpYS9yZXNlYXJjaC5nb29nbGUuY29tL2VuLy9wdWJzL2FyY2hpdmUvNDYzNTkucGRmPGh0dHBz Oi8vc3RhdGljLmdvb2dsZXVzZXJjb250ZW50LmNvbS9tZWRpYS9yZXNlYXJjaC5nb29nbGUuY29t L2VuL3B1YnMvYXJjaGl2ZS80NjM1OS5wZGY+IC0gc3BlY2lmaWNhbGx5LCB0aGUgQ0RGIGluIEZp Z3VyZSA0Ow0KDQoyLiAgICAgIFdSVCB3aGVyZSB0byBob3N0IHRoaXMgd29yazogbWF5YmUgYSB2 ZXJ5IG5hcnJvd2x5IHNjb3BlZCBXRyBjb3VsZCBiZSB0aGUgY29ycmVjdCBmb3JtYXQgZm9yIGRl bGl2ZXJpbmcNCg0KYS4gICAgICAgdGhlIEluZm9ybWF0aW9uYWwgZG9jdW1lbnQgYWJvdXQgdGhl IG9wZXJhdGlvbmFsIGFuZCBzZWN1cml0eSBjb25zaWRlcmF0aW9ucyByZWdhcmRpbmcgdGhlIHVz ZSBvZiBTVEFSIGFuZA0KDQpiLiAgICAgIGEgdGlueSBQUyBmb3IgdGhlIGNlcnRpZmljYXRlIGV4 dGVuc2lvbg0KDQpDaGVlcnMsIHQNCg0KDQpPbiAxNy8xMS8yMDE3LCAwMjo1NywgInNhYWcgb24g YmVoYWxmIG9mIFlvYXYgTmlyIiA8c2FhZy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpzYWFnLWJv dW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiB5bmlyLmlldGZAZ21haWwuY29tPG1haWx0bzp5 bmlyLmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQoNCkhlbGxvIGFsbA0KDQpMYXN0IG5pZ2h0IChU aHVyc2RheSkgd2UgaGFkIGEgc2lkZSBtZWV0aW5nIGFib3V0IHRoZSBnb2FscyBvZiBkcmFmdC1u aXItc2FhZy1zdGFyLiAgMjEgcGVvcGxlIGF0dGVuZGVkIHRoZSBtZWV0aW5nIGFuZCBpdCBsYXN0 ZWQgYSBsaXR0bGUgb3ZlciBvbmUgaG91ci4NCg0KSSBnb3QgYSBsb3Qgb2YgdXNlZnVsIGNvbW1l bnRzLCBzb21lIG9mIHdoaWNoIEkgd2lsbCBsaXN0IGhlcmUgaW4gbm8gcGFydGljdWxhciBvcmRl cjoNCg0KwrcgICAgICAgICBUaGUgdW5pcXVlIHRoaW5nIGFib3V0IFNUQVIgY2VydGlmaWNhdGVz IGlzIG5vdCB0aGF0IHRoZXkgYXJlIHNob3J0IHRlcm0sIGJ1dCB0aGF0IHRoZSBSZWx5aW5nIFBh cnRpZXMgZG8gbm90IGNoZWNrIHJldm9jYXRpb24gb2YgdGhlIEVuZCBFbnRpdHkgY2VydGlmaWNh dGVzLiBUaGUgZG9jdW1lbnQgc2hvdWxkIGJlIHJlZmFjdG9yZWQgdG8gbWFrZSB0aGlzIHRoZSBz dWJqZWN0LCB3aXRoIHNob3J0LXRlcm1uZXNzIHByZXNlbnRlZCBhcyBtaXRpZ2F0aW9uIGZvciB0 aGUgbGFjayBvZiByZXZvY2F0aW9uIGNoZWNraW5nIChTdGVmYW4gU2FudGVzc29uKS4NCsK3ICAg ICAgICAg4oCcU2hvcnTigJ0gYW5kIOKAnGxvbmfigJ0gYXJlIHJlbGF0aXZlIGFuZCBhbnkgY3V0 LW9mZiBwb2ludCB3b3VsZCBiZSBhcmJpdHJhcnkuIFRoZSBsaWZldGltZSBvZiBhIFNUQVIgY2Vy dGlmaWNhdGUgc2hvdWxkIGJlIGRlZmluZWQgYnkgdGhlIHJlcXVpcmVtZW50cyBmb3IgcmV2b2Nh dGlvbiwgbm90IGJ5IHNvbWUgYXJiaXRyYXJ5IGxpbWl0IGRlZmluZWQgaW4gYW4gUkZDLg0Kwrcg ICAgICAgICBUaGUgZHJhZnQgc2hvdWxkIGFkZCBwcml2YWN5IGFuZCBsYXRlbmN5IGNvbmNlcm5z IChib3RoIGFyZSBjb21wcm9taXNlZCBieSByZXZvY2F0aW9uIGNoZWNraW5nLCBzbyBhIHBsdXMg dG8gU1RBUikgdG8gdGhlIGNvbnNpZGVyYXRpb25zLiAoREtHKQ0KwrcgICAgICAgICBJdCBzaG91 bGQgYmUgbm90ZWQgKGluIHRoZSBkcmFmdCkgdGhhdCB3aGVuIHRoZSBQS0kgaXMgYSBoaWVyYXJj aHkgdGhlIFJQIHN0aWxsIG5lZWRzIHRvIGNoZWNrIHJldm9jYXRpb24gZm9yIHRoZSBzdWItQ0Fz LiBUaGlzIG5lZ2F0ZXMgbXVjaCBvZiB0aGUgc2ltcGxpY2l0eSBhZHZhbnRhZ2UuDQrCtyAgICAg ICAgIFdlIHNob3VsZCBjb25zaWRlciB3aGF0IHVzZSBjYXNlcyBhcmUgYXBwcm9wcmlhdGUgZm9y IFNUQVIuIEluIHRoZSB3ZWIgKGFzIG1lYXN1cmVkIGJ5IEdvb2dsZSBhbmQgb3RoZXJzKSBjbG9j ayBza2V3cyBhcmUgcmFtcGFudCwgYW5kIDUtNyBkYXkgc2tldyBoYXZlIHRvIGJlIGFzc3VtZWQu IEFkZGl0aW9uYWxseSwgdGhlIENBcyBvbiB0aGUgd2ViIHR5cGljYWxseSB1c2Ugb25lIG9yIG1v cmUgbGF5ZXJzIG9mIHN1Yi1DQXMuICBDbG9zZWQgZW52aXJvbm1lbnRzIHN1Y2ggYXMgZGF0YWNl bnRlcnMsIGNvcnBvcmF0ZSBuZXR3b3JrcyBhbmQgbWFuYWdlZCBzeXN0ZW1zIGhhdmUgYmV0dGVy IGNvbnRyb2wgb2YgY2xvY2tzIGFuZCBjYW4gb2Z0ZW4gZm9yZWdvIGhpZXJhcmNoeS4NCm8gICAg RXhhbXBsZXMgb2Yg4oCcbWFuYWdlZCBzeXN0ZW1z4oCdIHRoYXQgd2VyZSBtZW50aW9uZWQ6DQrC pyAgQSBidW5jaCBvZiBOU0ZzIGNvbnRyb2xsZWQgYnkgYSBzaW5nbGUgU2VjdXJpdHkgQ29udHJv bGxlciAoYXMgd2XigJlyZSBkb2luZyBpbiBJMk5TRiwgYnV0IHZlbmRvcnMgaGF2ZSBiZWVuIGRv aW5nIHdpdGggcHJvcHJpZXRhcnkgcHJvdG9jb2xzIGZvciB5ZWFycykNCsKnICBBIGJ1bmNoIG9m IElQc2VjIGVuZHBvaW50cyAoZWl0aGVyIHR1bm5lbGluZyBnYXRld2F5cyBvciBob3N0cykgbWFu YWdlZCBieSBhbiBOU0YgKHdl4oCZcmUgZG9pbmcgdGhhdCBpbiBJMk5TRiBhcyB3ZWxsKQ0Kwqcg IFZlaGljbGUtdG8tdmVoaWNsZSBuZXR3b3JrcyB3aGVyZSBjZXJ0aWZpY2F0ZXMgYXJlIGlzc3Vl ZCBmb3IgYSBtb250aCwgMjAgdGltZXMgYSBtb250aCAoQm9iIE1vc2tvd2l0eikNCsKnICBTdG9y YWdlIEFyZWEgTmV0d29ya3Mgd2hlcmUgZGF0YSBjbGllbnRzIGNvbm5lY3QgdG8gZGF0YSBzZXJ2 ZXJzIGFuZCByZXF1aXJlIGF0IGxlYXN0IGF1dGhlbnRpY2F0aW9uIGFuZCBvZnRlbiBlbmNyeXB0 aW9uLCB3aGljaCB0aGV5IGdldCB1c2luZyBUTFMgb3IgSUtFL0lQc2VjLg0KwrcgICAgICAgICBT VEFSIGNlcnRpZmljYXRlcyBzZWVtIHRvIGJlIGVxdWl2YWxlbnQgaW4gdGVybXMgb2Ygc2VjdXJp dHkgaG93IGxvbmcgaXQgdGFrZXMgdG8gcmV2b2tlIGEgY2VydGlmaWNhdGUgdG8gUEtJIGNlcnRp ZmljYXRlcyB3aXRoIE9DU1AgTXVzdC1TdGFwbGUuIFRoZSBkcmFmdCBzaG91bGQgY2FsbCBvdXQg dGhhdCB0aGUgbGlmZXRpbWUgb2YgYSBjZXJ0aWZpY2F0ZSBzaG91bGQgYmUgc2ltaWxhciB0byB0 aGUg4oCcbGlmZXRpbWXigJ0gKHRpbWUgZnJvbSB0aGlzVXBkYXRlIHRvIG5leHRVcGRhdGUpIG9m IHRoZSBPQ1NQIHJlc3BvbnNlcy4NCsK3ICAgICAgICAgVGhlcmUgd2FzIHNvbWUgZGlzY3Vzc2lv biBhYm91dCB3aGV0aGVyIFNUQVIgY2VydGlmaWNhdGVzIHNob3VsZCBiZSBzcGVjaWFsbHkgbWFy a2VkLCBwZXJoYXBzIGJ5IGFuIGNlcnRpZmljYXRlIGV4dGVuc2lvbiwgYXMgc3VjaC4gVGhlIHJl YXNvbmluZyBpcyB0aGF0IGF0IHNvbWUgcG9pbnQgaGF2aW5nIG5vbmUgb3IgQ1JMIERQIG9yIE9D U1AgVVJJIG1heSBiZSB0cmVhdGVkIGFzIGludmFsaWQsIHNvIFNUQVIgc3RhdHVzIG1heSBuZWVk IHRvIGJlIGNhbGxlZCBvdXQgZXhwbGljaXRseS4gIEN1cnJlbnQgQ0FCRiBndWlkYW5jZSBpcyB0 aGF0IGxhY2sgb2YgcmV2b2NhdGlvbiBpcyBmaW5lIGZvciBjZXJ0aWZpY2F0ZXMgd2hvc2UgdmFs aWRpdHkgcGVyaW9kIGlzIHNob3J0ZXIgdGhhbiBYIChUQkQgd2hhdCBYIGlzKSBzbyBhdCBsZWFz dCBmb3Igbm93IGFuZCBmb3IgdGhlIHdlYiBzdWNoIGFuIGV4dGVuc2lvbiBpcyBub3QgbmVlZGVk LiBJZiBldmVyIHN1Y2ggYSBjZXJ0aWZpY2F0ZSBleHRlbnNpb24gaXMgbmVlZGVkLCBpdCBjYW4g YmUgZG9uZSBpbiBhIHNob3J0IHN0YW5kYXJkcy10cmFjayBkb2N1bWVudC4gVGhlIGludGVudGlv biBpcyBmb3IgdGhpcyBkb2N1bWVudCB0byBiZSBpbmZvcm1hdGlvbmFsDQoNCkFub3RoZXIgdGhp bmcgdGhhdCB3YXMgZGlzY3Vzc2VkIGlzIHdoZXJlIHRoaXMgd29yayBzaG91bGQgZ28uICBJdCBv YnZpb3VzbHkgcmVxdWlyZXMgYSBsb3Qgb2YgZmVlZGJhY2ssIHNvIGl0IGRvZXNu4oCZdCBzZWVt IHRvIGJlIGEgZ29vZCBmaXQgZm9yIGVpdGhlciBBRC1zcG9uc29yZWQgb3IgYW4gaW5kZXBlbmRl bnQgc3VibWlzc2lvbi4gTmVpdGhlciBvZiB0aGVzZSBzdHJlYW1zIHRlbmQgdG8gZ2V0IGEgZ29v ZCByZXZpZXcuIFRoZSBhdXRob3JzIHNob3VsZCBkaXNjdXNzIHdpdGggdGhlIHNlY3VyaXR5IEFE cyBhbmQgU2VjRGlzcGF0Y2ggd2hpY2ggZXhpc3Rpbmcgb3IgbmV3IFdHIGlzIHRoZSByaWdodCBo b21lIGZvciB0aGlzIHdvcmsuDQoNClRoYW5rIHlvdSB0byBldmVyeW9uZSB3aG8gdG9vayB0aGUg dGltZSB0byBhdHRlbmQuDQoNCllvYXYNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KDQpFc3RlIG1lbnNhamUgeSBzdXMgYWRqdW50b3Mgc2UgZGlyaWdlbiBleGNsdXNpdmFt ZW50ZSBhIHN1IGRlc3RpbmF0YXJpbywgcHVlZGUgY29udGVuZXIgaW5mb3JtYWNpw7NuIHByaXZp bGVnaWFkYSBvIGNvbmZpZGVuY2lhbCB5IGVzIHBhcmEgdXNvIGV4Y2x1c2l2byBkZSBsYSBwZXJz b25hIG8gZW50aWRhZCBkZSBkZXN0aW5vLiBTaSBubyBlcyB1c3RlZC4gZWwgZGVzdGluYXRhcmlv IGluZGljYWRvLCBxdWVkYSBub3RpZmljYWRvIGRlIHF1ZSBsYSBsZWN0dXJhLCB1dGlsaXphY2nD s24sIGRpdnVsZ2FjacOzbiB5L28gY29waWEgc2luIGF1dG9yaXphY2nDs24gcHVlZGUgZXN0YXIg cHJvaGliaWRhIGVuIHZpcnR1ZCBkZSBsYSBsZWdpc2xhY2nDs24gdmlnZW50ZS4gU2kgaGEgcmVj aWJpZG8gZXN0ZSBtZW5zYWplIHBvciBlcnJvciwgbGUgcm9nYW1vcyBxdWUgbm9zIGxvIGNvbXVu aXF1ZSBpbm1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtaXNtYSB2w61hIHkgcHJvY2VkYSBhIHN1IGRl c3RydWNjacOzbi4NCg0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIHRyYW5zbWlz c2lvbiBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24gaW50ZW5kZWQg b25seSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgbmFtZWQgYWJvdmUu IElmIHRoZSByZWFkZXIgb2YgdGhpcyBtZXNzYWdlIGlzIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmllZCB0aGF0IGFueSBkaXNzZW1pbmF0aW9uLCBkaXN0 cmlidXRpb24gb3IgY29weWluZyBvZiB0aGlzIGNvbW11bmljYXRpb24gaXMgc3RyaWN0bHkgcHJv aGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3Is IGRvIG5vdCByZWFkIGl0LiBQbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhlIHNlbmRlciB0 aGF0IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciBhbmQgdGhl biBkZWxldGUgaXQuDQoNCkVzdGEgbWVuc2FnZW0gZSBzZXVzIGFuZXhvcyBzZSBkaXJpZ2VtIGV4 Y2x1c2l2YW1lbnRlIGFvIHNldSBkZXN0aW5hdMOhcmlvLCBwb2RlIGNvbnRlciBpbmZvcm1hw6fD o28gcHJpdmlsZWdpYWRhIG91IGNvbmZpZGVuY2lhbCBlIMOpIHBhcmEgdXNvIGV4Y2x1c2l2byBk YSBwZXNzb2Egb3UgZW50aWRhZGUgZGUgZGVzdGluby4gU2UgbsOjbyDDqSB2b3NzYSBzZW5ob3Jp YSBvIGRlc3RpbmF0w6FyaW8gaW5kaWNhZG8sIGZpY2Egbm90aWZpY2FkbyBkZSBxdWUgYSBsZWl0 dXJhLCB1dGlsaXphw6fDo28sIGRpdnVsZ2HDp8OjbyBlL291IGPDs3BpYSBzZW0gYXV0b3JpemHD p8OjbyBwb2RlIGVzdGFyIHByb2liaWRhIGVtIHZpcnR1ZGUgZGEgbGVnaXNsYcOnw6NvIHZpZ2Vu dGUuIFNlIHJlY2ViZXUgZXN0YSBtZW5zYWdlbSBwb3IgZXJybywgcm9nYW1vcy1saGUgcXVlIG5v cyBvIGNvbXVuaXF1ZSBpbWVkaWF0YW1lbnRlIHBvciBlc3RhIG1lc21hIHZpYSBlIHByb2NlZGEg YSBzdWEgZGVzdHJ1acOnw6NvDQo= --_000_BA8C9981D5564C298233EE430611F1E4telefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVMOtdHVsbyIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9IktleXdvcmRzIiBjb250 ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAx NSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAq Lw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCXBhbm9zZS0xOjIg NyAzIDkgMiAyIDUgMiA0IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpXaW5nZGluZ3M7 DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0 IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9y bWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2Vy aWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwg c3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29s b3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdy YXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCglt YXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h biIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9 DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglmb250LXZhcmlhbnQ6bm9ybWFsICFp bXBvcnRhbnQ7DQoJY29sb3I6d2luZG93dGV4dDsNCgl0ZXh0LXRyYW5zZm9ybTpub25lOw0KCXRl eHQtZGVjb3JhdGlvbjpub25lIG5vbmU7DQoJdmVydGljYWwtYWxpZ246YmFzZWxpbmU7fQ0Kc3Bh bi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6 IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NTk1LjBwdCA4NDIuMHB0Ow0KCW1hcmdpbjo3 Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlz dC1pZDozNzA0MjYxMTU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0yMDY3ODYxMDg2O30NCkBs aXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1z by1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJU aW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDox MDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxNDQuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyODgu MHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTgu MHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwx DQoJe21zby1saXN0LWlkOjEzMjYzOTg4NDA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOi03MTc4MTc4MTQgMTM0ODA3NTY3IDEzNDgwNzU3NyAxMzQ4MDc1 NzkgMTM0ODA3NTY3IDEzNDgwNzU3NyAxMzQ4MDc1NzkgMTM0ODA3NTY3IDEzNDgwNzU3NyAxMzQ4 MDc1Nzk7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBs aXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxp c3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw3 DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9 DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpy aWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0K dWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJn Y29sb3I9IndoaXRlIiBsYW5nPSJFUy1UUkFEIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4N CjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+TG9va2luZyBhdCB0aGUgZGl2ZXJzaXR5IG9mIHVzZSBjYXNlcywgYW5kIHRoZSBh ZGRpdGlvbmFsIGltcGxpY2F0aW9ucyB0aGF0IHdoZXJlIGRpc2N1c3NlZCBkdXJpbmcgdGhlIG1l ZXRpbmcsIEkgc3VwcG9ydCB0aGUgaWRlYSBvZg0KIGEgdmVyeSBmb2N1c2VkIFdHIGZvciB0aGlz IHRhc2suIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkJlIGdvb2RlLDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4tLTwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZxdW90O0VzdGEgdmV6IG5vIGZhbGxhcmVtb3Ms IERvY3RvciBJbmZpZXJubyZxdW90Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkRyIERpZWdvIFIuIExv cGV6PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRVMi IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGVsZWZvbmljYSBJJiM0MztE PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PGEgaHJlZj0iaHR0cDovL3Blb3Bs ZS50aWQuZXMvZGllZ28ubG9wZXovIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+aHR0 cDovL3Blb3BsZS50aWQuZXMvZGllZ28ubG9wZXovPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJl YXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPmUtbWFp bDombmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1s YW5ndWFnZTpFTi1VUyI+PGEgaHJlZj0ibWFpbHRvOmRpZWdvLnIubG9wZXpAdGVsZWZvbmljYS5j b20iPjxzcGFuIGxhbmc9IkVTLVRSQUQiIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij5kaWVnby5y LmxvcGV6QHRlbGVmb25pY2EuY29tPC9zcGFuPjwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj5UZWw6Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyYjNDM7MzQgOTEzIDEyOSAwNDE8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1HQiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj5Nb2JpbGU6ICYjNDM7MzQgNjgyIDA1MSAwOTE8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi Pi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNS40cHQiPk9uIDE4LzExLzE3IDc6NTAsICZxdW90O3NhYWcgZW4gbm9tYnJlIGRl IEZvc3NhdGksIFRob21hcyAoTm9raWEgLSBHQi9DYW1icmlkZ2UsIFVLKSZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOnNhYWctYm91bmNlc0BpZXRmLm9yZyI+c2FhZy1ib3VuY2VzQGlldGYub3Jn PC9hPiBlbiBub21icmUgZGUNCjxhIGhyZWY9Im1haWx0bzp0aG9tYXMuZm9zc2F0aUBub2tpYS5j b20iPnRob21hcy5mb3NzYXRpQG5va2lhLmNvbTwvYT4mZ3Q7IHdyb3RlOjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6 RU4tVVMiPkhpIFlvYXYsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPlRoYW5rcyBmb3Igb3JnYW5pc2luZyB0aGUgbWVldGlu ZyBhbmQgZm9yIHRoaXMgcmVwb3J0Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Ud28gcXVpY2sgbm90ZXMvY29tbWVudHM6 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDo3MS40cHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBsZXZl bDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj4xLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlm XT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkZvciBkYXRhIGJh Y2tpbmcgdGhlIDUtNyBkYXlzIG1pbmltdW0gc2hvcnQtdGVybW5lc3MgaW4gdGhlIHdpbGQsIHNl ZQ0KPGEgaHJlZj0iaHR0cHM6Ly9zdGF0aWMuZ29vZ2xldXNlcmNvbnRlbnQuY29tL21lZGlhL3Jl c2VhcmNoLmdvb2dsZS5jb20vZW4vcHVicy9hcmNoaXZlLzQ2MzU5LnBkZiI+DQpodHRwczovL3N0 YXRpYy5nb29nbGV1c2VyY29udGVudC5jb20vbWVkaWEvcmVzZWFyY2guZ29vZ2xlLmNvbS9lbi8v cHVicy9hcmNoaXZlLzQ2MzU5LnBkZjwvYT4gLSBzcGVjaWZpY2FsbHksIHRoZSBDREYgaW4gRmln dXJlIDQ7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgi IHN0eWxlPSJtYXJnaW4tbGVmdDo3MS40cHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDps MSBsZXZlbDEgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj4yLjxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwh W2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPldSVCB3 aGVyZSB0byBob3N0IHRoaXMgd29yazogbWF5YmUgYSB2ZXJ5IG5hcnJvd2x5IHNjb3BlZCBXRyBj b3VsZCBiZSB0aGUgY29ycmVjdCBmb3JtYXQgZm9yIGRlbGl2ZXJpbmc8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEw Ny40cHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDIgbGZvMiI+DQo8IVtp ZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5hLjxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPnRoZSBJbmZvcm1hdGlvbmFsIGRv Y3VtZW50IGFib3V0IHRoZSBvcGVyYXRpb25hbCBhbmQgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMg cmVnYXJkaW5nIHRoZSB1c2Ugb2YgU1RBUiBhbmQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjEwNy40cHQ7dGV4dC1p bmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMSBsZXZlbDIgbGZvMiI+DQo8IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj5iLjxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPmEgdGlueSBQUyBmb3IgdGhlIGNlcnRpZmljYXRlIGV4dGVuc2lv bjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNS40cHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTIj5DaGVlcnMsIHQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 NzEuNHB0Ij5PbiAxNy8xMS8yMDE3LCAwMjo1NywgJnF1b3Q7c2FhZyBvbiBiZWhhbGYgb2YgWW9h diBOaXImcXVvdDsgJmx0OzxhIGhyZWY9Im1haWx0bzpzYWFnLWJvdW5jZXNAaWV0Zi5vcmciPnNh YWctYm91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxmIG9mDQo8YSBocmVmPSJtYWlsdG86eW5p ci5pZXRmQGdtYWlsLmNvbSI+eW5pci5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6NzEuNHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcxLjRwdCI+SGVsbG8gYWxs IDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDo3MS40cHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcxLjRwdCI+TGFzdCBuaWdodCAo VGh1cnNkYXkpIHdlIGhhZCBhIHNpZGUgbWVldGluZyBhYm91dCB0aGUgZ29hbHMgb2YgZHJhZnQt bmlyLXNhYWctc3Rhci4gJm5ic3A7MjEgcGVvcGxlIGF0dGVuZGVkIHRoZSBtZWV0aW5nIGFuZCBp dCBsYXN0ZWQgYSBsaXR0bGUgb3ZlciBvbmUgaG91ci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3MS40cHQiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjcxLjRwdCI+SSBnb3QgYSBsb3Qgb2YgdXNlZnVsIGNvbW1lbnRz LCBzb21lIG9mIHdoaWNoIEkgd2lsbCBsaXN0IGhlcmUgaW4gbm8gcGFydGljdWxhciBvcmRlcjo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDo3MS40cHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEwNy40cHQ7dGV4dC1pbmRlbnQ6 LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvNCI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0 eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGlt ZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5UaGUgdW5pcXVlIHRo aW5nIGFib3V0IFNUQVIgY2VydGlmaWNhdGVzIGlzIG5vdCB0aGF0IHRoZXkgYXJlIHNob3J0IHRl cm0sIGJ1dCB0aGF0IHRoZSBSZWx5aW5nIFBhcnRpZXMgZG8gbm90IGNoZWNrIHJldm9jYXRpb24g b2YgdGhlIEVuZCBFbnRpdHkgY2VydGlmaWNhdGVzLiBUaGUgZG9jdW1lbnQgc2hvdWxkIGJlIHJl ZmFjdG9yZWQgdG8gbWFrZSB0aGlzIHRoZSBzdWJqZWN0LCB3aXRoIHNob3J0LXRlcm1uZXNzDQog cHJlc2VudGVkIGFzIG1pdGlnYXRpb24gZm9yIHRoZSBsYWNrIG9mIHJldm9jYXRpb24gY2hlY2tp bmcgKFN0ZWZhbiBTYW50ZXNzb24pLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvO21hcmdpbi1sZWZ0OjEwNy40cHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBs ZXZlbDEgbGZvNCI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi PsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48 L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT7igJxTaG9ydOKAnSBhbmQg4oCcbG9uZ+KAnSBhcmUgcmVs YXRpdmUgYW5kIGFueSBjdXQtb2ZmIHBvaW50IHdvdWxkIGJlIGFyYml0cmFyeS4gVGhlIGxpZmV0 aW1lIG9mIGEgU1RBUiBjZXJ0aWZpY2F0ZSBzaG91bGQgYmUgZGVmaW5lZCBieSB0aGUgcmVxdWly ZW1lbnRzIGZvciByZXZvY2F0aW9uLCBub3QgYnkgc29tZSBhcmJpdHJhcnkgbGltaXQgZGVmaW5l ZCBpbiBhbiBSRkMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2lu LWxlZnQ6MTA3LjRwdDt0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm80 Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3Nw YW4+PCFbZW5kaWZdPlRoZSBkcmFmdCBzaG91bGQgYWRkIHByaXZhY3kgYW5kIGxhdGVuY3kgY29u Y2VybnMgKGJvdGggYXJlIGNvbXByb21pc2VkIGJ5IHJldm9jYXRpb24gY2hlY2tpbmcsIHNvIGEg cGx1cyB0byBTVEFSKSB0byB0aGUgY29uc2lkZXJhdGlvbnMuIChES0cpPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MTA3LjRwdDt0ZXh0LWluZGVudDot MTguMHB0O21zby1saXN0OmwwIGxldmVsMSBsZm80Ij4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbCI+PHNwYW4gc3R5 bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1l cyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkl0IHNob3VsZCBiZSBu b3RlZCAoaW4gdGhlIGRyYWZ0KSB0aGF0IHdoZW4gdGhlIFBLSSBpcyBhIGhpZXJhcmNoeSB0aGUg UlAgc3RpbGwgbmVlZHMgdG8gY2hlY2sgcmV2b2NhdGlvbiBmb3IgdGhlIHN1Yi1DQXMuIFRoaXMg bmVnYXRlcyBtdWNoIG9mIHRoZSBzaW1wbGljaXR5IGFkdmFudGFnZS48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxMDcuNHB0O3RleHQtaW5kZW50Oi0x OC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzQiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3ltYm9sIj48c3BhbiBzdHls ZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVz IE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+V2Ugc2hvdWxkIGNvbnNp ZGVyIHdoYXQgdXNlIGNhc2VzIGFyZSBhcHByb3ByaWF0ZSBmb3IgU1RBUi4gSW4gdGhlIHdlYiAo YXMgbWVhc3VyZWQgYnkgR29vZ2xlIGFuZCBvdGhlcnMpIGNsb2NrIHNrZXdzIGFyZSByYW1wYW50 LCBhbmQgNS03IGRheSBza2V3IGhhdmUgdG8gYmUgYXNzdW1lZC4gQWRkaXRpb25hbGx5LCB0aGUg Q0FzIG9uIHRoZSB3ZWIgdHlwaWNhbGx5IHVzZSBvbmUgb3IgbW9yZQ0KIGxheWVycyBvZiBzdWIt Q0FzLiAmbmJzcDtDbG9zZWQgZW52aXJvbm1lbnRzIHN1Y2ggYXMgZGF0YWNlbnRlcnMsIGNvcnBv cmF0ZSBuZXR3b3JrcyBhbmQgbWFuYWdlZCBzeXN0ZW1zIGhhdmUgYmV0dGVyIGNvbnRyb2wgb2Yg Y2xvY2tzIGFuZCBjYW4gb2Z0ZW4gZm9yZWdvIGhpZXJhcmNoeS4NCjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjE0My40cHQ7dGV4dC1pbmRlbnQ6LTE4 LjBwdDttc28tbGlzdDpsMCBsZXZlbDIgbGZvNCI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyxzZXJpZiI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+bzxzcGFuIHN0eWxlPSJm b250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+RXhhbXBsZXMgb2Yg4oCcbWFuYWdlZCBz eXN0ZW1z4oCdIHRoYXQgd2VyZSBtZW50aW9uZWQ6DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxNzkuNHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDAgbGV2ZWwzIGxmbzQiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj7CpzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+QSBidW5j aCBvZiBOU0ZzIGNvbnRyb2xsZWQgYnkgYSBzaW5nbGUgU2VjdXJpdHkgQ29udHJvbGxlciAoYXMg d2XigJlyZSBkb2luZyBpbiBJMk5TRiwgYnV0IHZlbmRvcnMgaGF2ZSBiZWVuIGRvaW5nIHdpdGgg cHJvcHJpZXRhcnkgcHJvdG9jb2xzIGZvciB5ZWFycyk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxNzkuNHB0O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNv LWxpc3Q6bDAgbGV2ZWwzIGxmbzQiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj7CpzxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+QSBidW5j aCBvZiBJUHNlYyBlbmRwb2ludHMgKGVpdGhlciB0dW5uZWxpbmcgZ2F0ZXdheXMgb3IgaG9zdHMp IG1hbmFnZWQgYnkgYW4gTlNGICh3ZeKAmXJlIGRvaW5nIHRoYXQgaW4gSTJOU0YgYXMgd2VsbCk8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDoxNzkuNHB0 O3RleHQtaW5kZW50Oi0xOC4wcHQ7bXNvLWxpc3Q6bDAgbGV2ZWwzIGxmbzQiPg0KPCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6V2lu Z2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CpzxzcGFuIHN0eWxlPSJmb250 OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFu Pjwvc3Bhbj48IVtlbmRpZl0+VmVoaWNsZS10by12ZWhpY2xlIG5ldHdvcmtzIHdoZXJlIGNlcnRp ZmljYXRlcyBhcmUgaXNzdWVkIGZvciBhIG1vbnRoLCAyMCB0aW1lcyBhIG1vbnRoIChCb2IgTW9z a293aXR6KTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0 OjE3OS40cHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDMgbGZvNCI+DQo8 IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTpXaW5nZGluZ3MiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsKnPHNwYW4gc3R5 bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwvc3Bh bj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5TdG9yYWdlIEFyZWEgTmV0d29ya3Mgd2hlcmUgZGF0 YSBjbGllbnRzIGNvbm5lY3QgdG8gZGF0YSBzZXJ2ZXJzIGFuZCByZXF1aXJlIGF0IGxlYXN0IGF1 dGhlbnRpY2F0aW9uIGFuZCBvZnRlbiBlbmNyeXB0aW9uLCB3aGljaCB0aGV5IGdldCB1c2luZyBU TFMgb3IgSUtFL0lQc2VjLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21h cmdpbi1sZWZ0OjEwNy40cHQ7dGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEg bGZvNCI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+ PC9zcGFuPjwhW2VuZGlmXT5TVEFSIGNlcnRpZmljYXRlcyBzZWVtIHRvIGJlIGVxdWl2YWxlbnQg aW4gdGVybXMgb2YNCjxzPnNlY3VyaXR5PC9zPiBob3cgbG9uZyBpdCB0YWtlcyB0byByZXZva2Ug YSBjZXJ0aWZpY2F0ZSB0byBQS0kgY2VydGlmaWNhdGVzIHdpdGggT0NTUCBNdXN0LVN0YXBsZS4g VGhlIGRyYWZ0IHNob3VsZCBjYWxsIG91dCB0aGF0IHRoZSBsaWZldGltZSBvZiBhIGNlcnRpZmlj YXRlIHNob3VsZCBiZSBzaW1pbGFyIHRvIHRoZSDigJxsaWZldGltZeKAnSAodGltZSBmcm9tIHRo aXNVcGRhdGUgdG8gbmV4dFVwZGF0ZSkgb2YgdGhlIE9DU1AgcmVzcG9uc2VzLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjEwNy40cHQ7dGV4dC1pbmRl bnQ6LTE4LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvNCI+DQo8IVtpZiAhc3VwcG9ydExpc3Rz XT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpTeW1ib2wiPjxzcGFu IHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsK3PHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7 VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5UaGVyZSB3YXMg c29tZSBkaXNjdXNzaW9uIGFib3V0IHdoZXRoZXIgU1RBUiBjZXJ0aWZpY2F0ZXMgc2hvdWxkIGJl IHNwZWNpYWxseSBtYXJrZWQsIHBlcmhhcHMgYnkgYW4gY2VydGlmaWNhdGUgZXh0ZW5zaW9uLCBh cyBzdWNoLiBUaGUgcmVhc29uaW5nIGlzIHRoYXQgYXQgc29tZSBwb2ludCBoYXZpbmcgbm9uZSBv ciBDUkwgRFAgb3IgT0NTUCBVUkkgbWF5IGJlIHRyZWF0ZWQgYXMgaW52YWxpZCwNCiBzbyBTVEFS IHN0YXR1cyBtYXkgbmVlZCB0byBiZSBjYWxsZWQgb3V0IGV4cGxpY2l0bHkuICZuYnNwO0N1cnJl bnQgQ0FCRiBndWlkYW5jZSBpcyB0aGF0IGxhY2sgb2YgcmV2b2NhdGlvbiBpcyBmaW5lIGZvciBj ZXJ0aWZpY2F0ZXMgd2hvc2UgdmFsaWRpdHkgcGVyaW9kIGlzIHNob3J0ZXIgdGhhbiBYIChUQkQg d2hhdCBYIGlzKSBzbyBhdCBsZWFzdCBmb3Igbm93IGFuZCBmb3IgdGhlIHdlYiBzdWNoIGFuIGV4 dGVuc2lvbiBpcyBub3QgbmVlZGVkLiBJZg0KIGV2ZXIgc3VjaCBhIGNlcnRpZmljYXRlIGV4dGVu c2lvbiBpcyBuZWVkZWQsIGl0IGNhbiBiZSBkb25lIGluIGEgc2hvcnQgc3RhbmRhcmRzLXRyYWNr IGRvY3VtZW50LiBUaGUgaW50ZW50aW9uIGlzIGZvciB0aGlzIGRvY3VtZW50IHRvIGJlIGluZm9y bWF0aW9uYWw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6NzEuNHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjcxLjRw dCI+QW5vdGhlciB0aGluZyB0aGF0IHdhcyBkaXNjdXNzZWQgaXMgd2hlcmUgdGhpcyB3b3JrIHNo b3VsZCBnby4gJm5ic3A7SXQgb2J2aW91c2x5IHJlcXVpcmVzIGEgbG90IG9mIGZlZWRiYWNrLCBz byBpdCBkb2VzbuKAmXQgc2VlbSB0byBiZSBhIGdvb2QgZml0IGZvciBlaXRoZXIgQUQtc3BvbnNv cmVkIG9yIGFuIGluZGVwZW5kZW50IHN1Ym1pc3Npb24uIE5laXRoZXIgb2YgdGhlc2UNCiBzdHJl YW1zIHRlbmQgdG8gZ2V0IGEgZ29vZCByZXZpZXcuIFRoZSBhdXRob3JzIHNob3VsZCBkaXNjdXNz IHdpdGggdGhlIHNlY3VyaXR5IEFEcyBhbmQgU2VjRGlzcGF0Y2ggd2hpY2ggZXhpc3Rpbmcgb3Ig bmV3IFdHIGlzIHRoZSByaWdodCBob21lIGZvciB0aGlzIHdvcmsuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzEu NHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3MS40cHQiPlRoYW5rIHlvdSB0byBldmVyeW9uZSB3 aG8gdG9vayB0aGUgdGltZSB0byBhdHRlbmQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6NzEuNHB0Ij4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDo3MS40cHQiPllvYXY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDo3MS40cHQiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxicj4NCjxocj4NCjxmb250IGZhY2U9IkFy aWFsIiBjb2xvcj0iR3JheSIgc2l6ZT0iMSI+PGJyPg0KRXN0ZSBtZW5zYWplIHkgc3VzIGFkanVu dG9zIHNlIGRpcmlnZW4gZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8sIHB1ZWRlIGNv bnRlbmVyIGluZm9ybWFjacOzbiBwcml2aWxlZ2lhZGEgbyBjb25maWRlbmNpYWwgeSBlcyBwYXJh IHVzbyBleGNsdXNpdm8gZGUgbGEgcGVyc29uYSBvIGVudGlkYWQgZGUgZGVzdGluby4gU2kgbm8g ZXMgdXN0ZWQuIGVsIGRlc3RpbmF0YXJpbyBpbmRpY2FkbywgcXVlZGEgbm90aWZpY2FkbyBkZSBx dWUgbGENCiBsZWN0dXJhLCB1dGlsaXphY2nDs24sIGRpdnVsZ2FjacOzbiB5L28gY29waWEgc2lu IGF1dG9yaXphY2nDs24gcHVlZGUgZXN0YXIgcHJvaGliaWRhIGVuIHZpcnR1ZCBkZSBsYSBsZWdp c2xhY2nDs24gdmlnZW50ZS4gU2kgaGEgcmVjaWJpZG8gZXN0ZSBtZW5zYWplIHBvciBlcnJvciwg bGUgcm9nYW1vcyBxdWUgbm9zIGxvIGNvbXVuaXF1ZSBpbm1lZGlhdGFtZW50ZSBwb3IgZXN0YSBt aXNtYSB2w61hIHkgcHJvY2VkYSBhIHN1IGRlc3RydWNjacOzbi48YnI+DQo8YnI+DQpUaGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgdHJhbnNtaXNzaW9uIGlzIHByaXZpbGVnZWQgYW5k IGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBvbmx5IGZvciB0aGUgdXNlIG9mIHRo ZSBpbmRpdmlkdWFsIG9yIGVudGl0eSBuYW1lZCBhYm92ZS4gSWYgdGhlIHJlYWRlciBvZiB0aGlz IG1lc3NhZ2UgaXMgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5v dGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sDQogZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcg b2YgdGhpcyBjb21tdW5pY2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBkbyBub3QgcmVhZCBpdC4gUGxl YXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgdGhhdCB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGNvbW11bmljYXRpb24gaW4gZXJyb3IgYW5kIHRoZW4gZGVsZXRlIGl0Ljxicj4NCjxi cj4NCkVzdGEgbWVuc2FnZW0gZSBzZXVzIGFuZXhvcyBzZSBkaXJpZ2VtIGV4Y2x1c2l2YW1lbnRl IGFvIHNldSBkZXN0aW5hdMOhcmlvLCBwb2RlIGNvbnRlciBpbmZvcm1hw6fDo28gcHJpdmlsZWdp YWRhIG91IGNvbmZpZGVuY2lhbCBlIMOpIHBhcmEgdXNvIGV4Y2x1c2l2byBkYSBwZXNzb2Egb3Ug ZW50aWRhZGUgZGUgZGVzdGluby4gU2UgbsOjbyDDqSB2b3NzYSBzZW5ob3JpYSBvIGRlc3RpbmF0 w6FyaW8gaW5kaWNhZG8sIGZpY2Egbm90aWZpY2FkbyBkZSBxdWUgYQ0KIGxlaXR1cmEsIHV0aWxp emHDp8OjbywgZGl2dWxnYcOnw6NvIGUvb3UgY8OzcGlhIHNlbSBhdXRvcml6YcOnw6NvIHBvZGUg ZXN0YXIgcHJvaWJpZGEgZW0gdmlydHVkZSBkYSBsZWdpc2xhw6fDo28gdmlnZW50ZS4gU2UgcmVj ZWJldSBlc3RhIG1lbnNhZ2VtIHBvciBlcnJvLCByb2dhbW9zLWxoZSBxdWUgbm9zIG8gY29tdW5p cXVlIGltZWRpYXRhbWVudGUgcG9yIGVzdGEgbWVzbWEgdmlhIGUgcHJvY2VkYSBhIHN1YSBkZXN0 cnVpw6fDo288YnI+DQo8L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BA8C9981D5564C298233EE430611F1E4telefonicacom_-- From nobody Sun Nov 19 15:20:57 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 647E71200C1; Sun, 19 Nov 2017 15:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lRdfAJj2oGNW; Sun, 19 Nov 2017 15:20:37 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CA3312009C; Sun, 19 Nov 2017 15:20:37 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id o145so4583719vkd.0; Sun, 19 Nov 2017 15:20:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uy6Aqva3JGxqjO/+FMOghJIh+UYx2DP6JK/A733C4XE=; b=KUmziprSGpqdmzACtInWbkgdLxxzlNjkMlzh7M/ssb81NBTsB2IPUdQ8qzrS+Q3BpD WW3j4v+xGsZ/GewiugDs1NSj9Zw/eSZ0FQfpSLP37MKuv+8w/TmYMYmOtS+lPQ/4QYUn qWaSwQMnZY0vS945W/dpM5jMZdHPrp64afvj8wJa9cD3sKt8OpHmBL7akupjyHPUfy5q SeVatxXHlwHhSkcYSHYZL5zpbg6/D5IjQLK6EBjLowj3fQZdwKIxL7JYC75/+IhXY5If WzTAsfEv5zUNLrKqeA7RIqmhdjbVdFxjvMLPnUVZ+LkDwfayfvPzFIWvzDgYe0BhZHgL 5ppw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uy6Aqva3JGxqjO/+FMOghJIh+UYx2DP6JK/A733C4XE=; b=C0t764zlQLP1rfZqxWQmg3HGgccKEZK6zGiykfkJ8oKseJG46jEihtFoT/t3IczXaV PMkbapEge38PC/c4t93XkcPjuZmOuCYeYQaGjtPb524/soviTP2JRhI2G2WqxAwNArCi fiiCFv1B9s8QQ/jl6+2BHyK8F4SS0OQu2i6VnmpPJNbDzk8FRYpEy22TKdWJj+sVzz+m UekIbnHCJjPfCbO6dLnqoeyTZWeYlfumg+H8F2fM4kWzJz6Zk7hIGzh4fJeSxbMdYLNR 432VzqeJS5q3xB5RUUH9ljtIIUcZoqEeLEMuFewv5eUIniTFwz/7SxRJmJOTg4aUd8Hz 2FwQ== X-Gm-Message-State: AJaThX5o04XpzW9O6YIwIOYgVyUyxiXJcPC/DH3ej1LrriZVfbyvkFEB dGXNFvVw0xBhAw6T/4SBLzeU1FgnBuBZyFZVj0Q= X-Google-Smtp-Source: AGs4zMYDN8CLqHBhN2b+jK77nZrQaVYp4Zr16ay6QCdtcJNEqq/V2aw5fFxGpKdtqddg47ntC7RH1B+qFdnuP26No8s= X-Received: by 10.31.178.205 with SMTP id b196mr5017052vkf.85.1511133635860; Sun, 19 Nov 2017 15:20:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.159.54.230 with HTTP; Sun, 19 Nov 2017 15:20:15 -0800 (PST) In-Reply-To: <58815EFC-3CF9-4F62-A7E3-6E76FBAA295A@piuha.net> References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com> <4c6c9bc8-6056-c03d-a0f6-f1f32fabef39@ericsson.com> <00d401d35114$de589760$9b09c620$@augustcellars.com> <8D84F942-5D10-4DB8-8EB7-3EB8A8AEE17E@gmail.com> <58815EFC-3CF9-4F62-A7E3-6E76FBAA295A@piuha.net> From: Bernard Aboba Date: Sun, 19 Nov 2017 15:20:15 -0800 Message-ID: To: Jari Arkko Cc: Mohit Sethi , reap@ietf.org, Security Area Advisory Group , emu@ietf.org Content-Type: multipart/alternative; boundary="001a11440b3492df7d055e5e37b5" Archived-At: Subject: Re: [saag] [Emu] EAP - TLS 1.3 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 19 Nov 2017 23:20:39 -0000 --001a11440b3492df7d055e5e37b5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable The big question is "Why not create a new EAP method"? The overall intent seems to be to create an pre-shared key EAP method optimized for 5G, based on EAP-TLS v1.3. Since the protocol described will not interoperate with any of the existing 2+ billion EAP-TLS devices, why reuse the EAP-TLS code point or EAP-TLS name? What has been described is an entirely distinct authentication method, not a "clarification" to an existing specification. In fact, from how it has been described, it would appear that the new protocol is only for use with new devices supporting 5G and new 5G servers supporting the new method. In which case, if the new method is not for general use on the Internet, why can't 3GPP just define the method themselves and allocate their own private EAP type code? On Thu, Nov 16, 2017 at 4:02 AM, Jari Arkko wrote: > I don=E2=80=99t want to push the decision in either direction without loo= king into > the details. > > But I wanted to point out that there=E2=80=99s usually a third alternativ= e between > =E2=80=9Cno need for new documents=E2=80=9D and =E2=80=9Cneed a new RFC t= o describe the new > version=E2=80=9D. Explaining that the old protocol can be used and what t= he > implications are may by itself be a useful document. In the specific > example, is not immediately obvious to me for instance if the security > consideration would somehow change, or if 0-RTT can or can not be used, e= tc. > > Jari > > --001a11440b3492df7d055e5e37b5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The big question is "Why not create a new EAP method&= quot;?=C2=A0

The overall intent seems to be to create an= pre-shared key EAP method optimized for 5G, based on EAP-TLS v1.3.=C2=A0= =C2=A0

Since the protocol described will not inter= operate with any of the existing 2+ billion EAP-TLS devices, why reuse the = EAP-TLS code point or EAP-TLS name?=C2=A0 =C2=A0What has been described is = an entirely distinct authentication method, not a "clarification"= to an existing specification.

In fact, from how i= t has been described, it would appear that the new protocol is only for use= with new devices supporting 5G and new 5G servers supporting the new metho= d.=C2=A0 In which case, if the new method is not for general use on the Int= ernet, why can't 3GPP just define the method themselves and allocate th= eir own private EAP type code?=C2=A0
=
On Thu, Nov 16, 2017 at 4:02 AM, Jari Arkko = <jari.arkko@piuha.net> wrote:
I don=E2=80=99t want to push the decision in either direction withou= t looking into the details.

But I wanted to point out that there=E2=80=99s usually a third alternative = between =E2=80=9Cno need for new documents=E2=80=9D and =E2=80=9Cneed a new= RFC to describe the new version=E2=80=9D. Explaining that the old protocol= can be used and what the implications are may by itself be a useful docume= nt. In the specific example, is not immediately obvious to me for instance = if the security consideration would somehow change, or if 0-RTT can or can = not be used, etc.

Jari


--001a11440b3492df7d055e5e37b5-- From nobody Sun Nov 19 20:57:18 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8DF127011 for ; Sun, 19 Nov 2017 20:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=w4PZyMwH; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=kkSLi1Eg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsD31u4f0_Dk for ; Sun, 19 Nov 2017 20:57:15 -0800 (PST) Received: from esa4.dell-outbound.iphmx.com (esa4.dell-outbound.iphmx.com [68.232.149.214]) (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 144CB127010 for ; Sun, 19 Nov 2017 20:57:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1511153835; x=1542689835; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=PnJmAANEYGuCO4hYym1aBeX8BjRo9Y8Ed1A2oP4uu+4=; b=w4PZyMwH1IkM89vwlGUdD7gnm0HQiMoFvLNiyG6sBKLEXGok0e4e7fOk a0msdl+2SZ/Ub4sgHCwLFwM2x8FDxug3Tw8hHq1+eU86aYChFY3aw2sdl T5OLZbmfhsBN3GSCCd+qWK9GWRjCURiI8M3sXILwyRNchoka6KnrNncjh A=; IronPort-PHdr: =?us-ascii?q?9a23=3A3bBepBBjPZ+lbZ5tn5zpUyQJP3N1i/DPJgcQr6Af?= =?us-ascii?q?oPdwSPX7psbcNUDSrc9gkEXOFd2CrakV26yO6+jJYi8p2d65qncMcZhBBVcuqP?= =?us-ascii?q?49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL1LdrWev4jEMBx7xKRR6?= =?us-ascii?q?JvjvGo7Vks+7y/2+94fdbghMhzexe69+IAmrpgjNq8cahpdvJLwswRXTuHtIfO?= =?us-ascii?q?pWxWJsJV2Nmhv3+9m98p1+/SlOovwt78FPX7n0cKQ+VrxYES8pM3sp683xtBnM?= =?us-ascii?q?VhWA630BWWgLiBVIAgzF7BbnXpfttybxq+Rw1DWGMcDwULs5Xymp4aV2Rx/ykC?= =?us-ascii?q?oJNyA3/nzLisJ+j6xbrhCupx1jzIDbb46YL+Z+cbjZcN8GWWZNQsRcWipcCY28?= =?us-ascii?q?dYsPCO8BMP5Wo4Tgo1sBtwexBQq0COjyxDFHnGH23awn3OgvDArL2wIuEMgQsH?= =?us-ascii?q?TVsdr5LrofUeSvw6bUzjXOdO5Z1in56IjMaBwuvfaMXbdpfMfX1EIhGQTFjlCK?= =?us-ascii?q?pozkOTOYzuUNvHaH7+puT+6vjHQnqw53rzOyxckskpHEi4MWx1ze6yl0zpg5Kc?= =?us-ascii?q?elREN7btOoCp9duiKCO4drXs8uWXxktDo6x7EcupO3ZjUGxZonyhLHZfyIbYuF?= =?us-ascii?q?7g7mWeuUIjp1i3ZoeLy6ihuy7Eev0PPwW8yp3FpXtSVIl9bBu34O2hHT7MWMV+?= =?us-ascii?q?Fz8V272TmV0gDe8uREIUcpmqXFM5Mh2bswloYLsUTEAy/2hF36jK+IeUUg/eil?= =?us-ascii?q?8/roYq78qZKTLYN7lx/xMqAqmsCmBuQ4LxQOUHOc+eSh0r3s4FP1TK9Ljv0ukq?= =?us-ascii?q?nZtZ/bKd4Hqa6+Bg9Zyocj6xChADe6yNkVnHoKIEhbdB+JkYTlIUzCLfD3APul?= =?us-ascii?q?h1mhky9nx/XcMb3gBpXNIGLDkLDkfbtl5UBT0hQzzdFC6J5OF7wBJOj8VVPytN?= =?us-ascii?q?HDExA2LQi0w+L9BNph0YMeXHqDArWFP6PKrV+I+uUvLvGXZIAPojn9JOMo5//w?= =?us-ascii?q?gn8ll18RZ66p3YEYaCPwIvMzAEyFYX7hj9FJNGAQvwMkUP2i3F6LTT5Xanu0Ga?= =?us-ascii?q?c7/DAyEp63S4bOWo6Fj7mI3SP9FZpTMCQOQEuFGHjAdoiYVbELci3Yapt6mzUL?= =?us-ascii?q?fbmsV4Fn0guh4lzU0b1ie6D+/iQTttar+NFr5uGZ3UUe/CJ1A4K312iGTEl4k2?= =?us-ascii?q?cMATQx2fYs8gRG1l6f3P0g0LRjHttJ6qYRXw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GuAAB+XxJah2Ka6ERbGgEBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYJsgSYQbicHg3iZR4F9fpV0gT5DChgLhRgCGoRNQxQBAQEBAQEBAQE?= =?us-ascii?q?BAhABAQEKCwkIKC+COCIQSCEFBgEBAQEBASYBAQEBAQEBAQEBAQEBAQEBAQEXA?= =?us-ascii?q?j0BEgEBGAEBAQEDAQEMFREMHwYJDAsEAgEIEQQBAQMCBh0DAgICJQsUAQgIAgQ?= =?us-ascii?q?BEgiKHQEPqTCCJ4MQh2QBAQEBAQEBAQEBAQEBAQEBAQEBAQEVAwWBD4IlggeBV?= =?us-ascii?q?oFognU2hF8INhWCfjGCMqI9BgKLWotGhgyLKpYFAgQCBAUCGoE6NoIXel6CZIJ?= =?us-ascii?q?sgXIBd4pCgRQBAQE?= X-IPAS-Result: =?us-ascii?q?A2GuAAB+XxJah2Ka6ERbGgEBAQEBAgEBAQEIAQEBAYJsgSY?= =?us-ascii?q?QbicHg3iZR4F9fpV0gT5DChgLhRgCGoRNQxQBAQEBAQEBAQEBAhABAQEKCwkIK?= =?us-ascii?q?C+COCIQSCEFBgEBAQEBASYBAQEBAQEBAQEBAQEBAQEBAQEXAj0BEgEBGAEBAQE?= =?us-ascii?q?DAQEMFREMHwYJDAsEAgEIEQQBAQMCBh0DAgICJQsUAQgIAgQBEgiKHQEPqTCCJ?= =?us-ascii?q?4MQh2QBAQEBAQEBAQEBAQEBAQEBAQEBAQEVAwWBD4IlggeBVoFognU2hF8INhW?= =?us-ascii?q?CfjGCMqI9BgKLWotGhgyLKpYFAgQCBAUCGoE6NoIXel6CZIJsgXIBd4pCgRQBA?= =?us-ascii?q?QE?= Received: from esa4.dell-outbound2.iphmx.com ([68.232.154.98]) by esa4.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Nov 2017 22:57:11 -0600 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa4.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Nov 2017 10:57:10 +0600 Received: from maildlpprd56.lss.emc.com (maildlpprd56.lss.emc.com [10.106.48.160]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id vAK4v8kM032604 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 19 Nov 2017 23:57:09 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com vAK4v8kM032604 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1511153829; bh=u+jKvIGCJqZx24kBWb4Rug9DMRY=; h=From:To:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=kkSLi1EgZEZGqoeH/i1HDkObxnfxO0L6u+LjkBUBzJ4Ndame0CFlRXyKFKPxr2gBB xMy2TZEuOpDtX2R4KIgvPCZb5mKqXaCZ4wnfRsvgghRqyUTnzzjGqT7l05KgFIcceX wmLkMrR6N6ixgFRG20vJvV3QV2VE6ToEpCTeTYYE= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com vAK4v8kM032604 Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd56.lss.emc.com (RSA Interceptor); Sun, 19 Nov 2017 23:57:00 -0500 Received: from MXHUB310.corp.emc.com (MXHUB310.corp.emc.com [10.146.3.36]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id vAK4uv1P002243 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Sun, 19 Nov 2017 23:56:57 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB310.corp.emc.com ([10.146.3.36]) with mapi id 14.03.0352.000; Sun, 19 Nov 2017 23:56:57 -0500 To: Kathleen Moriarty , "saag@ietf.org" Thread-Topic: [saag] Thoughts on SecDispatch Experiment Thread-Index: AQHTX2VOf7xOnkZGUkuMpYycazYIoKMctVeA Date: Mon, 20 Nov 2017 04:56:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.105.8.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com X-RSA-Classifications: public Archived-At: Subject: Re: [saag] Thoughts on SecDispatch Experiment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 04:57:17 -0000 SSBzZW50IHNvbWUgcHJpdmF0ZSBjb21tZW50cyB0byBLYXRobGVlbiB3aG8gc3VnZ2VzdGVkIHRo YXQgSSBmb3J3YXJkIHRoZW0gaGVyZSBmb3Igd2lkZXIgZGlzY3Vzc2lvbiAuLi4NCg0KQW4gYXJl YS13aWRlIGZvcnVtIGxpa2UgU2VjRGlzcGF0Y2ggY291bGQgYmUgdmVyeSB1c2VmdWwgZm9yIHNt YWxsZXIgbmV3IGlkZWFzIHRoYXQgZG9uJ3QgbWVyaXQgU0FBRyBhZ2VuZGEgdGltZSwgcGFydGlj dWxhcmx5IGFzIHRoZSBTZWN1cml0eSBBcmVhIGRvZXMgbm90IGhhdmUgYW4gYXJlYS13aWRlIFdH IGFuYWxvZ291cyB0byBUU1ZXRyBvciBPUFNBV0cgdGhhdCBjYW4gYmUgdXNlZCB0byBkZWFsIHdp dGggc21hbGxlciBwcm9wb3NhbHMuICBQbGVhc2Ugbm90ZSB0aGF0IHdoaWxlIEkgZHJhdyB1cG9u IG15IGV4cGVyaWVuY2UgYXMgb25lIG9mIHRoZSBjaGFpcnMgb2YgVFNWV0csIEknbSB3cml0aW5n IHRoaXMgbm90ZSBhcyBhbiBpbmRpdmlkdWFsLiAgU2VjRGlzcGF0Y2ggY291bGQgYWxzbyBoZWxw IGF2b2lkIGEgdHJhcCB0aGF0IG1heSBhd2FpdCBzb21lIG5ld2NvbWVyczogd2hlbiBpdCdzIG5v dCBvYnZpb3VzIHdoZXJlIGEgbmV3IGlkZWEgZml0cywgdGhlIHByb3Bvc2VyIG1heSB0YWxrIHRv IG11bHRpcGxlIFdHL1JHIGNoYWlycyBhbmQvb3Igb3RoZXIgZm9sa3MgYWJvdXQgd2hlcmUgdG8g cHJlc2VudCAuLi4gdGhhdCdzIGEgZmV3IG1pbm9yIGNvbW11bmljYXRpb24gbWlzc3RlcHMgYXdh eSBmcm9tIGxvb2tpbmcgbGlrZSBmb3J1bS1zaG9wcGluZyAuLi4gd2hpY2ggaXMgc29tZXRoaW5n IHRoYXQgd2UgdGFrZSBhIHJhdGhlciBkaW0gdmlldyBvZi4NCg0KU29tZSBsaWdodCBkcmFmdCBw cmUtc2NyZWVuaW5nIGlzIG9idmlvdXNseSBpbiBvcmRlciB0byBhdm9pZCByaWRpY3Vsb3VzIHN0 dWZmIHN1Y2ggYXMgUk9UMTMgY2lwaGVycyBhbmQgdGhlIGxpa2UuICBGV0lXLCB0aGF0J3Mgc3Rh bmRpbmcgcHJhY3RpY2UgZm9yIFRTVldHIC0gZS5nLiwgcHJvcG9zYWxzIHRoYXQgY2xlYXJseSBi cmVhayBjb25nZXN0aW9uIGNvbnRyb2wgYXJlIG5vdCBsaWtlbHkgdG8gZ2V0IGFnZW5kYSB0aW1l LiAgQmV5b25kIHRoYXQsIEknZCBzdWdnZXN0IGFwcGx5aW5nIEpvbiBQb3N0ZWwncyBhZG1vbml0 aW9uIG9uIGJlaW5nIGxpYmVyYWwgaW4gd2hhdCBvbmUgYWNjZXB0cyB0byBjb25zaWRlcmF0aW9u IG9mIG5ldyBpZGVhcy4gIE5vbmUgb2YgdGhlIFNlY0Rpc3BhdGNoIGRyYWZ0cyBzdHJ1Y2sgbWUg YXMgcmlkaWN1bG91cywgaW5kZXBlbmRlbnQgb2Ygd2hldGhlciBJJ2Qgc3VwcG9ydCBJRVRGIHdv cmsgb24gdGhlbS4NCg0KVGhlIFNlY0Rpc3BhdGNoIHByb2Nlc3MgZmVsdCBsaWtlIGl0IGNvdWxk IHVzZSBzb21lIG1vcmUgY2xhcml0eSwgcGFydGljdWxhcmx5IGluIGRlbGluZWF0aW5nIHBvc3Np YmxlIG91dGNvbWVzIGluIGFkdmFuY2UuICAgSXQgYXBwZWFyZWQgdGhhdCBwcm9jZXNzIHdhcyBi ZWluZyBpbnZlbnRlZCBvbiB0aGUgZmx5IGFzIHRoZSBzZXNzaW9uIHdlbnQgYWxvbmcsIGUuZy4s IHJlZmVycmFsIHRvIENGUkcgYW5kIGNsYXJpZmljYXRpb24gb2YgQUQgc3BvbnNvcnNoaXAgcmVj b21tZW5kYXRpb25zLiAgRldJVywgSSBhZ3JlZSB3aXRoIHRoZSBrZXkgY29uY2x1c2lvbiBvbiBB RCBzcG9uc29yc2hpcCAtIHRoYXQgY2FuIG9ubHkgYmUgcmVjb21tZW5kZWQgYnkgdGhpcyBzb3J0 IG9mIGZvcnVtLCBhcyBhbiBBRCBpcyAoSU1ITykgcGVyc29uYWxseSByZXNwb25zaWJsZSBmb3Ig ZHJhZnRzIHRoYXQgcy9oZSBzcG9uc29ycy4gIEhlbmNlIGlmIGEgZm9ydW0gbGlrZSBTZWNEaXNw YXRjaCByZWNvbW1lbmRzIEFEIHNwb25zb3JzaGlwLCBlYWNoIEFEIG5vbmV0aGVsZXNzIGhhcyB0 byByZXNlcnZlIGEgcG9zc2libGUgZGVjaXNpb24gdG8gbm90IHNwb25zb3Igc29tZXRoaW5nIHRo YXQgdXBvbiB0aG91Z2h0ZnVsIHJldmlldywgcy9oZSBiZWxpZXZlcyBpcyBpbmFwcHJvcHJpYXRl LCBmbGF3ZWQsIGV0Yy4NCg0KVGhhbmtzLCAtLURhdmlkDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogc2FhZyBbbWFpbHRvOnNhYWctYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIEthdGhsZWVuIE1vcmlhcnR5DQo+IFNlbnQ6IEZyaWRheSwgTm92ZW1iZXIgMTcs IDIwMTcgMTI6MzEgQU0NCj4gVG86IHNhYWdAaWV0Zi5vcmcNCj4gU3ViamVjdDogW3NhYWddIFRo b3VnaHRzIG9uIFNlY0Rpc3BhdGNoIEV4cGVyaW1lbnQNCj4gDQo+IEhpLA0KPiANCj4gSW4gdGhl IGludGVyZXN0IG9mIGltcHJvdmluZyBTZWNEaXNwYXRjaCBpbiB0aGUgZXZlbnQgd2UgZ28gZm9y d2FyZA0KPiB3aXRoIHRoaXMgYXMgYSBXRywgSSdtIHNoYXJpbmcgbXkgdGhvdWdodHMgYW5kIGlk ZWFzIG9mIGhvdyB0byBpbXByb3ZlDQo+IGl0LiAgWW91ciB0aG91Z2h0cyBhcmUgd2VsY29tZS4N Cj4gDQo+IFNlY0Rpc3BhdGNoIEV4cGVyaW1lbnQgVGhvdWdodHMNCj4gDQo+IEFkZGl0aW9uYWwg cHJlLXNjcmVlbmluZyBvZiBkcmFmdHMgd291bGQgYmUgbmVlZGVkIGZvciB0aGlzIHRvIGJlIHN1 Y2Nlc3NmdWwuDQo+IA0KPiBGb3IgU0FBRyBzZXNzaW9ucyBhbmQgQUQgc3BvbnNvcmVkIGRyYWZ0 cywgd2hhdCB3ZSBoYXZlIGRvbmUgaW4gdGhlDQo+IHBhc3QgZmV3IHllYXJzIGlzIHRvIHdhaXQg Zm9yIHJlcXVlc3RzIHRvIGNvbWUgaW4sIHdlIGRpZG7igJl0IHNvbGljaXQNCj4gdGhlbS4gVGhl biB3ZeKAmWQgcmV2aWV3IHRoZSBhc3NvY2lhdGVkIGRyYWZ0KHMpLiBJRiB3ZSB0aG91Z2h0IGl0 IHdhcw0KPiByZWFkeSBhbmQgd29ydGh3aGlsZSwgd2XigJlkIGFzayBmb3IgZGlzY3Vzc2lvbiBv biB0aGUgbGlzdC4gSUYgdGhlcmUNCj4gd2FzIGludGVyZXN0IGFuZCB0aW1lLCB3ZeKAmWQgcHV0 IGl0IG9uIHRoZSBhZ2VuZGEuDQo+IA0KPiBUaGUgcHJlLXNjcmVlbmluZyB3b3VsZCBpbnZvbHZl IGFza2luZyBpZi93aGVyZSB0aGlzIGhhZCBiZWVuDQo+IHByZXNlbnRlZCBiZWZvcmUgYW5kIHRo ZSBvdXRjb21lLiBXZSBtaWdodCBjaGVjayBsaXN0IHRyYWZmaWMgb24gdGhlDQo+IGRyYWZ0IGFu ZCBtaWdodCBjaGVjayB3aXRoIHRoZSBjaGFpcnMgb2YgYXNzb2NpYXRlZCBXR3MgdG8gZ2V0IHRo ZWlyDQo+IHRob3VnaHRzLg0KPiANCj4gU3RlcGhlbiBhbmQgSSB3b3VsZCBkaXNjdXNzIEFEIHNw b25zb3IgZHJhZnQgcmVxdWVzdHMsIHdoaWNoIG1pZ2h0IGJlDQo+IHNlcGFyYXRlIGZyb20gU0FB RyBzbG90IHJlcXVlc3RzLiBUaGVyZSB3ZXJlIHRpbWVzIG9uZSBvZiB1cyB3b3VsZA0KPiBqdXN0 IGFjY2VwdCBvbmUgdGhhdCB3ZSB0aG91Z2h0IHdhcyBzZW5zaWJsZSBhbmQgdGhvdWdodCB0aGF0 DQo+IGFkZGl0aW9uYWwgcHJvY2VzcyBhcm91bmQgaXQgd2FzbuKAmXQgbmVlZGVkLiBGb3Igc29t ZSBvdGhlcnMsIHdlIG1pZ2h0DQo+IGRpc2N1c3MgdGhlIHJlcXVlc3QgYW5kIHNlZSB3aG8gY291 bGQgdGFrZSBpdCBvbiwgc3BsaXR0aW5nIHVwIHRoZQ0KPiB3b3JrIGV2ZW5seS4NCj4gDQo+IFRo ZW4gbXkgcHJvY2VzcyBmb3IgQUQgc3BvbnNvcmVkIGRyYWZ0cyAoZGlmZmVyZW50IGZyb20gU3Rl cGhlbuKAmXMpIHdhcw0KPiB0byBlaXRoZXIgYXNrIHRoZSBhdXRob3JzIHRvIGZpbmQgYSBzaGVw aGVyZCBvciB0byBhc3NpZ24gb25lIGlmIHRoZXkNCj4gd2VyZSBub3QgYWJsZSB0byBmaW5kIHNv bWVvbmUgcmVhc29uYWJsZSBvbiB0aGVpciBvd24uIEkgdXNlZCB0aGlzIGFzDQo+IGFuIG9wcG9y dHVuaXR5IHRvIHRyYWluIHBvc3NpYmxlIFdHIGNoYWlycyBhbmQgaW4gc29tZSBjYXNlcyBmb2xr cyB3aG8NCj4gbWlnaHQgYmUgaW50ZXJlc3RlZCB0byBiZSBhIFNlY0FEIGluIHRoZSBmdXR1cmUu IFRoZSBzaGVwaGVyZCB3b3VsZA0KPiBwZXJmb3JtIGEgZHJhZnQgcmV2aWV3LCBsb29rIGF0IGRp c2N1c3Npb25zIG9uIHRoZSBkcmFmdCwgYXNrIGFsbCB0aGUNCj4gcXVlc3Rpb25zIG9uIHRoZSBz aGVwaGVyZCByZXBvcnQsIGFuZCBwcm92aWRlIHRoZWlyIHRob3VnaHRzLiBJ4oCZZCB0aGVuDQo+ IHBlcmZvcm0gbXkgcmV2aWV3IGFuZCBpZiBhcHByb3ByaWF0ZSBraWNrIG9mZiBsYXN0IGNhbGwu IFRoZSBzaGVwaGVyZA0KPiB3b3VsZCBlbnN1cmUgYWxsIHRoZSBjb21tZW50cyByZWNlaXZlZCB3 ZXJlIGFkZHJlc3NlZCBpbiB0aGUgZHJhZnQsDQo+IEnigJlkIHJlY2hlY2sgdGhhdCBhbmQgdGhl IG5vcm1hbCBjaGVja3MgZm9yIGEgZHJhZnQgYW5kIHB1dCBpdCBvbiBhDQo+IHRlbGVjaGF0Lg0K PiANCj4gU2VjRGlzcGF0Y2ggc2VlbWVkIHVzZWZ1bCB0byBoYXZlIGEgaHVtIG9uIHJlc3RhcnRp bmcgYSBXRywgc28gd2UNCj4gY291bGQgYXZvaWQgYSBCb0YuIEZvciBzb21lIHRoYXQgYSBzZXBh cmF0ZSBXRyBpcyBuZWVkZWQsIGEgQm9GIG1heSBvcg0KPiBtYXkgbm90IGJlIG5lY2Vzc2FyeS4g V2UgaGF2ZSBzdGFydGVkIFdHcyBpbiB0aGUgcGFzdCB3aXRoIGxpc3QNCj4gZGlzY3Vzc2lvbiBv bmx5LCBzbyB0aGF04oCZcyBwb3NzaWJsZSBzdGlsbCB0b28uDQo+IA0KPiBJZiB3ZSB3ZW50IGFo ZWFkIHdpdGggU2VjRGlzcGF0Y2gsIEnigJlkIGV4cGVjdCB0aGUgY2hhaXJzIHRvIGNhbGwgYQ0K PiBkZWNpc2lvbiB3aXRoIGVhY2ggcHJvcG9zYWwgYW5kIGhhdmUgdGhpcyBnbyB0byB0aGUgbGlz dCBmb3INCj4gb2JqZWN0aW9ucy4gSWYgdGhlIHJlc3VsdCB3YXMgYSByZWNvbW1lbmRhdGlvbiBm b3IgQUQgc3BvbnNvcnNoaXAsIEkNCj4gd291bGQgZXhwZWN0IHRoYXQgdGhlIGRpc2N1c3Npb24g YXMgdG8gd2hvIHdvdWxkIHNwb25zb3Igd291bGQgaGFwcGVuDQo+IGFmdGVyIHRoZSBtZWV0aW5n IGJldHdlZW4gQURzIHdobyBjb3VsZCBjb25zaWRlciBhIGJhbGFuY2UgaW4gd29ya2xvYWQNCj4g d2hlbiBkaXZpZGluZyB0aGVtIHVwLg0KPiANCj4gTmFuY3kgYWxzbyBoYWQgc29tZSBpZGVhcyB0 byBzdHJlYW1saW5lIGFuZCBpbXByb3ZlIHRoZSBzZXNzaW9uIGlmDQo+IHRoaXMgZXhwZXJpbWVu dCBnb2VzIGZvcndhcmQsIHNvIGl04oCZbGwgYmUgZ29vZCB0byBnZXQgdGhhdCBkb2N1bWVudGVk Lg0KPiBJ4oCZbGwgbmVlZCB0byB0aGluayBhIGJpdCBtb3JlIG9uIGlmIEkgdGhpbmsgdGhpcyBz aG91bGQgZ28gZm9yd2FyZCwNCj4gYnV0IHdvdWxkIGxpa2UgZWFjaCBvZiB5b3VyIHRob3VnaHRz Lg0KPiANCj4gDQo+IA0KPiAtLQ0KPiANCj4gQmVzdCByZWdhcmRzLA0KPiBLYXRobGVlbg0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2Fh ZyBtYWlsaW5nIGxpc3QNCj4gc2FhZ0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NhYWcNCg== From nobody Mon Nov 20 06:37:08 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49299129A90 for ; Mon, 20 Nov 2017 06:37:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eMV_qlmlc964 for ; Mon, 20 Nov 2017 06:37:04 -0800 (PST) Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 72297129A8E for ; Mon, 20 Nov 2017 06:37:04 -0800 (PST) Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id vAKEb0vE011945; Mon, 20 Nov 2017 09:37:01 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu vAKEb0vE011945 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1511188621; bh=q0zHd0CeftoSBS+XA+3ehbvGuAoKWl2PIcHtEkLj7oc=; h=From:To:Subject:Date:References:In-Reply-To:From; b=OeuCfxVQ1Fiz83LjM/gRbujwyon1xsio9b911HF7WjZiZyWJ5Es2E22hPXuo3E6ZX +GA1bdYbznhiSxJ4Gl8/TjkJ6WH09U4SVzkSORfWBwboOGbMBrIACml5CAso1kg70q LPbAKCfNBiI8+hppqkL+/SIShnPT3IKhojlaXfZY= Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id vAKEaxEZ002105; Mon, 20 Nov 2017 09:36:59 -0500 Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0361.001; Mon, 20 Nov 2017 09:36:58 -0500 From: Roman Danyliw To: "Black, David" , Kathleen Moriarty , "saag@ietf.org" Thread-Topic: [saag] Thoughts on SecDispatch Experiment Thread-Index: AQHTX2VNKh0/bX/E+0C4fuhfhZdKCaMdDQEAgAA9ccA= Date: Mon, 20 Nov 2017 14:36:58 +0000 Message-ID: <359EC4B99E040048A7131E0F4E113AFC010500B041@marathon> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.64.22.6] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [saag] Thoughts on SecDispatch Experiment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 14:37:07 -0000 SGVsbG8hDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogc2FhZyBbbWFp bHRvOnNhYWctYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJsYWNrLCBEYXZpZA0KPiBT ZW50OiBTdW5kYXksIE5vdmVtYmVyIDE5LCAyMDE3IDExOjU3IFBNDQo+IFRvOiBLYXRobGVlbiBN b3JpYXJ0eSA8a2F0aGxlZW4ubW9yaWFydHkuaWV0ZkBnbWFpbC5jb20+OyBzYWFnQGlldGYub3Jn DQo+IFN1YmplY3Q6IFJlOiBbc2FhZ10gVGhvdWdodHMgb24gU2VjRGlzcGF0Y2ggRXhwZXJpbWVu dA0KDQpbc25pcF0NCg0KQXMgYW4gZXhwZXJpbWVudCwgSSB0aGluayBpdCB3YXMgYSBzdWNjZXNz Lg0KIA0KPiBUaGUgU2VjRGlzcGF0Y2ggcHJvY2VzcyBmZWx0IGxpa2UgaXQgY291bGQgdXNlIHNv bWUgbW9yZSBjbGFyaXR5LCBwYXJ0aWN1bGFybHkgaW4NCj4gZGVsaW5lYXRpbmcgcG9zc2libGUg b3V0Y29tZXMgaW4gYWR2YW5jZS4gICBJdCBhcHBlYXJlZCB0aGF0IHByb2Nlc3Mgd2FzDQo+IGJl aW5nIGludmVudGVkIG9uIHRoZSBmbHkgYXMgdGhlIHNlc3Npb24gd2VudCBhbG9uZywgZS5nLiwg cmVmZXJyYWwgdG8gQ0ZSRw0KPiBhbmQgY2xhcmlmaWNhdGlvbiBvZiBBRCBzcG9uc29yc2hpcCBy ZWNvbW1lbmRhdGlvbnMuIA0KDQorMS4gIEJlaW5nIGNsZWFyIG9uIHRoZSBwb3NzaWJsZSBvdXRj b21lcyBpbiBhZHZhbmNlIHdvdWxkIGhlbHAuICBBZGRpdGlvbmFsbHksIEknZCByZWNvbW1lbmQg dGhlIGZvbGxvd2luZzoNCg0KKiogRG9jdW1lbnRpbmcgdGhlIHdob2xlIHByb2Nlc3MgaW4gb25l IHBsYWNlIHRvIHNldCBleHBlY3RhdGlvbnMgb2YgdGhlIGRyYWZ0IHByb3BvbmVudHMgYW5kIGdl dCB0aGUgYmVzdCBmZWVkYmFjayBmcm9tIHRoZSBwcm9jZXNzIHBhcnRpY2lwYW50cyAoZS5nLiwg ZHJhZnQgcHJlc2NyZWVuaW5nIGNyaXRlcmlhL2RyYWZ0cyBwcmV2aW91c2x5IGRpc2N1c3NlZCBp biBvdGhlciBXR3M7IGlkZW50aWZ5IG91dGNvbWVzOyBkZXNjcmliZSB3aGF0IHRoZSBTZWNEaXNw YXRjaCBwcm9jZXNzIHdpbGwgbm90IGRvOyBndWlkYW5jZSBvbiB0aGUgZHJhZnQgcHJlc2VudGF0 aW9uIGdpdmVuIHRoZSBsaW1pdGVkIHRpbWUgc2xvdCkNCg0KKiogRG9jdW1lbnRpbmcgdGhlIGRl Y2lzaW9ucyBtYWRlIGR1cmluZyB0aGUgZGlzcGF0Y2ggcHJvY2VzcyAoYXJlIG1lZXRpbmcgbWlu dXRlcyBlbm91Z2g/KTsgYW5kIGlkZW50aWZ5aW5nIHdoYXQgdGhhdCBuZXh0IHN0ZXAgaXMgYW5k IHdobyBoYXMgaXQuDQoNClJvbWFuDQoNCj4gVGhhbmtzLCAtLURhdmlkDQo+IA0KPiA+IC0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogc2FhZyBbbWFpbHRvOnNhYWctYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEthdGhsZWVuDQo+ID4gTW9yaWFydHkNCj4gPiBTZW50 OiBGcmlkYXksIE5vdmVtYmVyIDE3LCAyMDE3IDEyOjMxIEFNDQo+ID4gVG86IHNhYWdAaWV0Zi5v cmcNCj4gPiBTdWJqZWN0OiBbc2FhZ10gVGhvdWdodHMgb24gU2VjRGlzcGF0Y2ggRXhwZXJpbWVu dA0KPiA+DQo+ID4gSGksDQo+ID4NCj4gPiBJbiB0aGUgaW50ZXJlc3Qgb2YgaW1wcm92aW5nIFNl Y0Rpc3BhdGNoIGluIHRoZSBldmVudCB3ZSBnbyBmb3J3YXJkDQo+ID4gd2l0aCB0aGlzIGFzIGEg V0csIEknbSBzaGFyaW5nIG15IHRob3VnaHRzIGFuZCBpZGVhcyBvZiBob3cgdG8gaW1wcm92ZQ0K PiA+IGl0LiAgWW91ciB0aG91Z2h0cyBhcmUgd2VsY29tZS4NCj4gPg0KPiA+IFNlY0Rpc3BhdGNo IEV4cGVyaW1lbnQgVGhvdWdodHMNCj4gPg0KPiA+IEFkZGl0aW9uYWwgcHJlLXNjcmVlbmluZyBv ZiBkcmFmdHMgd291bGQgYmUgbmVlZGVkIGZvciB0aGlzIHRvIGJlDQo+IHN1Y2Nlc3NmdWwuDQo+ ID4NCj4gPiBGb3IgU0FBRyBzZXNzaW9ucyBhbmQgQUQgc3BvbnNvcmVkIGRyYWZ0cywgd2hhdCB3 ZSBoYXZlIGRvbmUgaW4gdGhlDQo+ID4gcGFzdCBmZXcgeWVhcnMgaXMgdG8gd2FpdCBmb3IgcmVx dWVzdHMgdG8gY29tZSBpbiwgd2UgZGlkbuKAmXQgc29saWNpdA0KPiA+IHRoZW0uIFRoZW4gd2Xi gJlkIHJldmlldyB0aGUgYXNzb2NpYXRlZCBkcmFmdChzKS4gSUYgd2UgdGhvdWdodCBpdCB3YXMN Cj4gPiByZWFkeSBhbmQgd29ydGh3aGlsZSwgd2XigJlkIGFzayBmb3IgZGlzY3Vzc2lvbiBvbiB0 aGUgbGlzdC4gSUYgdGhlcmUNCj4gPiB3YXMgaW50ZXJlc3QgYW5kIHRpbWUsIHdl4oCZZCBwdXQg aXQgb24gdGhlIGFnZW5kYS4NCj4gPg0KPiA+IFRoZSBwcmUtc2NyZWVuaW5nIHdvdWxkIGludm9s dmUgYXNraW5nIGlmL3doZXJlIHRoaXMgaGFkIGJlZW4NCj4gPiBwcmVzZW50ZWQgYmVmb3JlIGFu ZCB0aGUgb3V0Y29tZS4gV2UgbWlnaHQgY2hlY2sgbGlzdCB0cmFmZmljIG9uIHRoZQ0KPiA+IGRy YWZ0IGFuZCBtaWdodCBjaGVjayB3aXRoIHRoZSBjaGFpcnMgb2YgYXNzb2NpYXRlZCBXR3MgdG8g Z2V0IHRoZWlyDQo+ID4gdGhvdWdodHMuDQo+ID4NCj4gPiBTdGVwaGVuIGFuZCBJIHdvdWxkIGRp c2N1c3MgQUQgc3BvbnNvciBkcmFmdCByZXF1ZXN0cywgd2hpY2ggbWlnaHQgYmUNCj4gPiBzZXBh cmF0ZSBmcm9tIFNBQUcgc2xvdCByZXF1ZXN0cy4gVGhlcmUgd2VyZSB0aW1lcyBvbmUgb2YgdXMg d291bGQNCj4gPiBqdXN0IGFjY2VwdCBvbmUgdGhhdCB3ZSB0aG91Z2h0IHdhcyBzZW5zaWJsZSBh bmQgdGhvdWdodCB0aGF0DQo+ID4gYWRkaXRpb25hbCBwcm9jZXNzIGFyb3VuZCBpdCB3YXNu4oCZ dCBuZWVkZWQuIEZvciBzb21lIG90aGVycywgd2UgbWlnaHQNCj4gPiBkaXNjdXNzIHRoZSByZXF1 ZXN0IGFuZCBzZWUgd2hvIGNvdWxkIHRha2UgaXQgb24sIHNwbGl0dGluZyB1cCB0aGUNCj4gPiB3 b3JrIGV2ZW5seS4NCj4gPg0KPiA+IFRoZW4gbXkgcHJvY2VzcyBmb3IgQUQgc3BvbnNvcmVkIGRy YWZ0cyAoZGlmZmVyZW50IGZyb20gU3RlcGhlbuKAmXMpIHdhcw0KPiA+IHRvIGVpdGhlciBhc2sg dGhlIGF1dGhvcnMgdG8gZmluZCBhIHNoZXBoZXJkIG9yIHRvIGFzc2lnbiBvbmUgaWYgdGhleQ0K PiA+IHdlcmUgbm90IGFibGUgdG8gZmluZCBzb21lb25lIHJlYXNvbmFibGUgb24gdGhlaXIgb3du LiBJIHVzZWQgdGhpcyBhcw0KPiA+IGFuIG9wcG9ydHVuaXR5IHRvIHRyYWluIHBvc3NpYmxlIFdH IGNoYWlycyBhbmQgaW4gc29tZSBjYXNlcyBmb2xrcyB3aG8NCj4gPiBtaWdodCBiZSBpbnRlcmVz dGVkIHRvIGJlIGEgU2VjQUQgaW4gdGhlIGZ1dHVyZS4gVGhlIHNoZXBoZXJkIHdvdWxkDQo+ID4g cGVyZm9ybSBhIGRyYWZ0IHJldmlldywgbG9vayBhdCBkaXNjdXNzaW9ucyBvbiB0aGUgZHJhZnQs IGFzayBhbGwgdGhlDQo+ID4gcXVlc3Rpb25zIG9uIHRoZSBzaGVwaGVyZCByZXBvcnQsIGFuZCBw cm92aWRlIHRoZWlyIHRob3VnaHRzLiBJ4oCZZCB0aGVuDQo+ID4gcGVyZm9ybSBteSByZXZpZXcg YW5kIGlmIGFwcHJvcHJpYXRlIGtpY2sgb2ZmIGxhc3QgY2FsbC4gVGhlIHNoZXBoZXJkDQo+ID4g d291bGQgZW5zdXJlIGFsbCB0aGUgY29tbWVudHMgcmVjZWl2ZWQgd2VyZSBhZGRyZXNzZWQgaW4g dGhlIGRyYWZ0LA0KPiA+IEnigJlkIHJlY2hlY2sgdGhhdCBhbmQgdGhlIG5vcm1hbCBjaGVja3Mg Zm9yIGEgZHJhZnQgYW5kIHB1dCBpdCBvbiBhDQo+ID4gdGVsZWNoYXQuDQo+ID4NCj4gPiBTZWNE aXNwYXRjaCBzZWVtZWQgdXNlZnVsIHRvIGhhdmUgYSBodW0gb24gcmVzdGFydGluZyBhIFdHLCBz byB3ZQ0KPiA+IGNvdWxkIGF2b2lkIGEgQm9GLiBGb3Igc29tZSB0aGF0IGEgc2VwYXJhdGUgV0cg aXMgbmVlZGVkLCBhIEJvRiBtYXkgb3INCj4gPiBtYXkgbm90IGJlIG5lY2Vzc2FyeS4gV2UgaGF2 ZSBzdGFydGVkIFdHcyBpbiB0aGUgcGFzdCB3aXRoIGxpc3QNCj4gPiBkaXNjdXNzaW9uIG9ubHks IHNvIHRoYXTigJlzIHBvc3NpYmxlIHN0aWxsIHRvby4NCj4gPg0KPiA+IElmIHdlIHdlbnQgYWhl YWQgd2l0aCBTZWNEaXNwYXRjaCwgSeKAmWQgZXhwZWN0IHRoZSBjaGFpcnMgdG8gY2FsbCBhDQo+ ID4gZGVjaXNpb24gd2l0aCBlYWNoIHByb3Bvc2FsIGFuZCBoYXZlIHRoaXMgZ28gdG8gdGhlIGxp c3QgZm9yDQo+ID4gb2JqZWN0aW9ucy4gSWYgdGhlIHJlc3VsdCB3YXMgYSByZWNvbW1lbmRhdGlv biBmb3IgQUQgc3BvbnNvcnNoaXAsIEkNCj4gPiB3b3VsZCBleHBlY3QgdGhhdCB0aGUgZGlzY3Vz c2lvbiBhcyB0byB3aG8gd291bGQgc3BvbnNvciB3b3VsZCBoYXBwZW4NCj4gPiBhZnRlciB0aGUg bWVldGluZyBiZXR3ZWVuIEFEcyB3aG8gY291bGQgY29uc2lkZXIgYSBiYWxhbmNlIGluIHdvcmts b2FkDQo+ID4gd2hlbiBkaXZpZGluZyB0aGVtIHVwLg0KPiA+DQo+ID4gTmFuY3kgYWxzbyBoYWQg c29tZSBpZGVhcyB0byBzdHJlYW1saW5lIGFuZCBpbXByb3ZlIHRoZSBzZXNzaW9uIGlmDQo+ID4g dGhpcyBleHBlcmltZW50IGdvZXMgZm9yd2FyZCwgc28gaXTigJlsbCBiZSBnb29kIHRvIGdldCB0 aGF0IGRvY3VtZW50ZWQuDQo+ID4gSeKAmWxsIG5lZWQgdG8gdGhpbmsgYSBiaXQgbW9yZSBvbiBp ZiBJIHRoaW5rIHRoaXMgc2hvdWxkIGdvIGZvcndhcmQsDQo+ID4gYnV0IHdvdWxkIGxpa2UgZWFj aCBvZiB5b3VyIHRob3VnaHRzLg0KPiA+DQo+ID4NCj4gPg0KPiA+IC0tDQo+ID4NCj4gPiBCZXN0 IHJlZ2FyZHMsDQo+ID4gS2F0aGxlZW4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gc2FhZyBtYWlsaW5nIGxpc3QNCj4gPiBzYWFn QGlldGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWFn DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNh YWcgbWFpbGluZyBsaXN0DQo+IHNhYWdAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zYWFnDQo= From nobody Mon Nov 20 08:14:01 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E989B129B6C for ; Mon, 20 Nov 2017 08:13:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 K4V3pM9vgRIZ for ; Mon, 20 Nov 2017 08:13:58 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 754F5129B64 for ; Mon, 20 Nov 2017 08:13:50 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id r39so15318271qtr.13 for ; Mon, 20 Nov 2017 08:13:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=dGPpMAyKDzun/jC4UzTUdkW9QTCGEnRKGY/wh/lr2eI=; b=e65+FOrlM/5FL+AaCuNL0H1cgchJDujTvas9lSjbVWeA0zEa+RxxstwkJk6kZExKvJ WysLKT9raoK6NG9iAapDa3P4SxE0Z0t60MGDYF6qvq//ZHHiLXvXQ76yd7Hxde/KnXRr b4KJXnknIlktNJmliKgRsOsWjhTF/1XcR1pMChPhcSjFzIB5DOYVKNedJ5pbYRDmV8RE UmCl06RS9HrlLcn9W8BCF0KEVh9HW4HeoH7qHC6qzPzwFbjWyK2RUoQMMwqM43CJSmYJ Af+JwJOjfOIl0e7KVxCwJu/a4l42kDEJGS/y83w/kx2tXWZ81M/UJc+ZICJ/Ipw4HgQI 8vcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=dGPpMAyKDzun/jC4UzTUdkW9QTCGEnRKGY/wh/lr2eI=; b=bqlBlzncvAQPc6Zb+lHp182ubqqy1RwpFTHY+zv49A8mSxX0CFhCifSemxSvPAToyz sER2ZWsz/w14hQYZAL1Rzz4gtubvZQQRzIA2EA0DS0knH2Pe5/nyaIoOVZ+0Cwo/FARy nMFWijlWkjZGUAaIjr0DieYtH2fSbAzxMNqQxazebLNYJXtTErQEbTaGEac97iRHq3UC 2AbRH8bjMQ3kvBiagyloVxP7/wU+wHWH7/zheXF2QWIZkyBb2lZhbnRwIyWnj30ACBEX O9ETWSKFlTrMuASPEkdRpKrYLgt+2Vv5qA0vsnu1nKfNPuwEew2L68JR0ANg9GbByp98 Nzmw== X-Gm-Message-State: AJaThX7jbi+RVyjDUAIENjjM69PRkW1o9yzufifcP/S8LouX6rXPBREZ vxgd/HItaZ9L/IQ44JfW7vyG64BafX3z0yTnBCw= X-Google-Smtp-Source: AGs4zMb6tWIy9jfMZK3vkOVPnoIBvA7tfxs3uIQdOEbwPAEb6/t+pI1ehLpNoXc32Uda+Ji+wAMfcdKV/taK+E8xLVY= X-Received: by 10.237.37.162 with SMTP id x31mr22807951qtc.58.1511194429594; Mon, 20 Nov 2017 08:13:49 -0800 (PST) MIME-Version: 1.0 Sender: barryleiba.mailing.lists@gmail.com Received: by 10.237.52.225 with HTTP; Mon, 20 Nov 2017 08:13:49 -0800 (PST) In-Reply-To: References: From: Barry Leiba Date: Tue, 21 Nov 2017 00:13:49 +0800 X-Google-Sender-Auth: UtWtmBy1Z_xiMWLgtc3d72UiIX8 Message-ID: To: "=JeffH" Cc: IETF SAAG Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [saag] SAAG collision with DOH.. X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 16:13:59 -0000 > ..is a bummer. just sayin' :( Yes. I had already spoke with Alexey about putting SAAG in the DOH conflict list next time. Barry From nobody Mon Nov 20 09:02:46 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13640129BFC; Mon, 20 Nov 2017 09:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUHbaMsMAtzW; Mon, 20 Nov 2017 09:02:42 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 1CA7F129C40; Mon, 20 Nov 2017 09:02:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D04E42CD39; Mon, 20 Nov 2017 19:02:31 +0200 (EET) (envelope-from jari.arkko@piuha.net) X-Virus-Scanned: amavisd-new at piuha.net Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxZF0qbCN7lC; Mon, 20 Nov 2017 19:02:31 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 5AAE02CD0D; Mon, 20 Nov 2017 19:02:31 +0200 (EET) (envelope-from jari.arkko@piuha.net) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: Date: Mon, 20 Nov 2017 19:02:30 +0200 Cc: Mohit Sethi , Security Area Advisory Group , emu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2DE75B43-BB07-4A15-BC81-442DFA0521C4@piuha.net> References: <3dbe94b9-4b2d-1479-8433-8b040cb1cfba@ericsson.com> <4c6c9bc8-6056-c03d-a0f6-f1f32fabef39@ericsson.com> <00d401d35114$de589760$9b09c620$@augustcellars.com> <8D84F942-5D10-4DB8-8EB7-3EB8A8AEE17E@gmail.com> <58815EFC-3CF9-4F62-A7E3-6E76FBAA295A@piuha.net> To: Bernard Aboba X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [saag] [Reap] [Emu] EAP - TLS 1.3 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 17:02:45 -0000 I think it would be perhaps useful to take some sort of reset on this = thread :-) I think there are at least three groups of people talking = past each other, and making assumptions that may not be correct. While this isn=E2=80=99t really a topic that I=E2=80=99m driving, let me = make a first cut at doing that reset. But I may not be correct either, = feel free to suggest a better description of where the world is. But = this is what I am seeing: 1. First, I don=E2=80=99t think I=E2=80=99ve seen any demand for any = special pre-shared key EAP TLS version (from 3GPP or otherwise). =46rom = what I understand, if 3GPP wants to use EAP-TLS, they=E2=80=99d do it = mostly for the certificates. 2. EAP-TLS continues to be important in the world, with lots of = deployment, and potentially more coming down the line. 3. Anything we do should ensure installed base continues to work. 4. Documenting what the implications of using TLS 1.3 in EAP-TLS are = seems useful advice. I don=E2=80=99t know how trivial this is, but at = least there should be some security implications. 5. If there=E2=80=99s any need to profile algorithms or TLS versions or = anything like that for any use case, it should be taken separately. And = perhaps that=E2=80=99s something that any individual deployment can just = do on their own. Jari P.S. I took Kathleen=E2=80=99s advice from earlier in this thread and = start reducing the number of lists this discussion is copied on. From nobody Mon Nov 20 10:03:34 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2471E12E041 for ; Mon, 20 Nov 2017 10:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 OGf0z7ZC_vmG for ; Mon, 20 Nov 2017 10:03:30 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 BE95D12E039 for ; Mon, 20 Nov 2017 10:03:30 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id h42so15758153qtk.11 for ; Mon, 20 Nov 2017 10:03:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=V8CG3UEeFbhDbRN5lz5Y+fSd8077quS6yg6D3BIiRTw=; b=c2Zrjamo0PgDhoEUEKWNfcsQw/s/kq0Z952XXN+xIDUrzlxTXN/4H60ykTkWWyY8ws 4zKXnt0wVo/BaR7BWmxaXJKALtQwXykosMr/0ZpbswYoTOK285VtAGGxilzpqHLstJaw 5LRLkMyQMAeVzqK21nsMlflsiveTp8iMmnJkhfY1MqQL9Tu58RCMhiMJ8NisfWOh/cb5 ApO9IidE0eVSpAbrZqCnpT7Za5jVT6iRV+TLW0lUquyicnkWn/HvpELlEzw4f5ETqe8D WUh9hwTR0WAixjjS6m9FNSHMgohVvvv1GOVSq/Q/6EEVzdX+rTiMJHJxZrtzKsdBqK5N cA2Q== 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=V8CG3UEeFbhDbRN5lz5Y+fSd8077quS6yg6D3BIiRTw=; b=Csy2DVWODE6beHhHLIlbtGjQhX4OgjtMhC3rVQ+azrWPI364hScltUNqkwgL5a8XR6 gqbWttPTced9aH+jsP3NXt5GBRYGPD5Z112jRWM/5oMvTvejsvMUc81CxoGOjE8SwWVc lmEbpvq6siJDSV8LxVPG3XyGaQ6W456HnJ1yIMQrOxtKGWYpQ/XQZxdCVINaClJPLrDx 5nt7Fm00OmVu5xapAyi6YAaqzwKNbb8X3vEwOfmz6NEpfAgVcX7kzkTD4I5UInbryIpa 36zGpmmCet0sADHcVn9Ly2f+JXTPhIGw3/9MJWtuXsKG0AfMya3Yux3Nr6CIOi1G9jHI x7yA== X-Gm-Message-State: AJaThX4eiYulnaCLmyjXBBxqFd0EfJUdHSGASee6fNQXuvV1jIHAhqDj b1591nBarVoTQTFDjwO7MEg= X-Google-Smtp-Source: AGs4zMZpx+So9AFu519B5n/lRHmJ5zEgN5r2SfBcvkFWOJLmrdNnZY326enTSRGz7bWBpP1Nhat5LA== X-Received: by 10.200.46.55 with SMTP id r52mr23262714qta.304.1511201009834; Mon, 20 Nov 2017 10:03:29 -0800 (PST) Received: from [192.168.1.187] (209-6-112-84.s338.c3-0.arl-ubr1.sbo-arl.ma.cable.rcncustomer.com. [209.6.112.84]) by smtp.gmail.com with ESMTPSA id m50sm7680274qtm.31.2017.11.20.10.03.28 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Nov 2017 10:03:28 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (14F89) In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC010500B041@marathon> Date: Mon, 20 Nov 2017 13:03:26 -0500 Cc: "Black, David" , "saag@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <359EC4B99E040048A7131E0F4E113AFC010500B041@marathon> To: Roman Danyliw Archived-At: Subject: Re: [saag] Thoughts on SecDispatch Experiment X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Nov 2017 18:03:33 -0000 Thank you, David and Roman for your helpful feedback. Inline. Sent from my mobile device > On Nov 20, 2017, at 9:36 AM, Roman Danyliw wrote: >=20 > Hello! >=20 >> -----Original Message----- >> From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Black, David >> Sent: Sunday, November 19, 2017 11:57 PM >> To: Kathleen Moriarty ; saag@ietf.org >> Subject: Re: [saag] Thoughts on SecDispatch Experiment >=20 > [snip] >=20 > As an experiment, I think it was a success. >=20 >> The SecDispatch process felt like it could use some more clarity, particu= larly in >> delineating possible outcomes in advance. It appeared that process was >> being invented on the fly as the session went along, e.g., referral to CFR= G >> and clarification of AD sponsorship recommendations.=20 >=20 > +1. Being clear on the possible outcomes in advance would help. =20 Yes, it's on the proposed charter text. As a WG, that would have been more c= lear I suspect. > Additionally, I'd recommend the following: >=20 > ** Documenting the whole process in one place to set expectations of the d= raft proponents and get the best feedback from the process participants (e.g= ., draft prescreening criteria/drafts previously discussed in other WGs; ide= ntify outcomes; describe what the SecDispatch process will not do; guidance o= n the draft presentation given the limited time slot) I agree and was thinking it would be helpful to capture the feedback and org= anize it to post on a wiki page. I guess that could be the one for SecDispa= tch if we charter it. =20 >=20 > ** Documenting the decisions made during the dispatch process (are meeting= minutes enough?); and identifying what that next step is and who has it. Meeting minutes and confirmation to the list would be good enough, I think. Thank you, Kathleen=20 >=20 > Roman >=20 >> Thanks, --David >>=20 >>> -----Original Message----- >>> From: saag [mailto:saag-bounces@ietf.org] On Behalf Of Kathleen >>> Moriarty >>> Sent: Friday, November 17, 2017 12:31 AM >>> To: saag@ietf.org >>> Subject: [saag] Thoughts on SecDispatch Experiment >>>=20 >>> Hi, >>>=20 >>> In the interest of improving SecDispatch in the event we go forward >>> with this as a WG, I'm sharing my thoughts and ideas of how to improve >>> it. Your thoughts are welcome. >>>=20 >>> SecDispatch Experiment Thoughts >>>=20 >>> Additional pre-screening of drafts would be needed for this to be >> successful. >>>=20 >>> For SAAG sessions and AD sponsored drafts, what we have done in the >>> past few years is to wait for requests to come in, we didn=E2=80=99t sol= icit >>> them. Then we=E2=80=99d review the associated draft(s). IF we thought it= was >>> ready and worthwhile, we=E2=80=99d ask for discussion on the list. IF th= ere >>> was interest and time, we=E2=80=99d put it on the agenda. >>>=20 >>> The pre-screening would involve asking if/where this had been >>> presented before and the outcome. We might check list traffic on the >>> draft and might check with the chairs of associated WGs to get their >>> thoughts. >>>=20 >>> Stephen and I would discuss AD sponsor draft requests, which might be >>> separate from SAAG slot requests. There were times one of us would >>> just accept one that we thought was sensible and thought that >>> additional process around it wasn=E2=80=99t needed. For some others, we m= ight >>> discuss the request and see who could take it on, splitting up the >>> work evenly. >>>=20 >>> Then my process for AD sponsored drafts (different from Stephen=E2=80=99= s) was >>> to either ask the authors to find a shepherd or to assign one if they >>> were not able to find someone reasonable on their own. I used this as >>> an opportunity to train possible WG chairs and in some cases folks who >>> might be interested to be a SecAD in the future. The shepherd would >>> perform a draft review, look at discussions on the draft, ask all the >>> questions on the shepherd report, and provide their thoughts. I=E2=80=99= d then >>> perform my review and if appropriate kick off last call. The shepherd >>> would ensure all the comments received were addressed in the draft, >>> I=E2=80=99d recheck that and the normal checks for a draft and put it on= a >>> telechat. >>>=20 >>> SecDispatch seemed useful to have a hum on restarting a WG, so we >>> could avoid a BoF. For some that a separate WG is needed, a BoF may or >>> may not be necessary. We have started WGs in the past with list >>> discussion only, so that=E2=80=99s possible still too. >>>=20 >>> If we went ahead with SecDispatch, I=E2=80=99d expect the chairs to call= a >>> decision with each proposal and have this go to the list for >>> objections. If the result was a recommendation for AD sponsorship, I >>> would expect that the discussion as to who would sponsor would happen >>> after the meeting between ADs who could consider a balance in workload >>> when dividing them up. >>>=20 >>> Nancy also had some ideas to streamline and improve the session if >>> this experiment goes forward, so it=E2=80=99ll be good to get that docum= ented. >>> I=E2=80=99ll need to think a bit more on if I think this should go forwa= rd, >>> but would like each of your thoughts. >>>=20 >>>=20 >>>=20 >>> -- >>>=20 >>> Best regards, >>> Kathleen >>>=20 >>> _______________________________________________ >>> saag mailing list >>> saag@ietf.org >>> https://www.ietf.org/mailman/listinfo/saag >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag From nobody Sun Nov 26 09:03:23 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 808B7129438; Sun, 26 Nov 2017 09:03:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 398qCYvwOlXs; Sun, 26 Nov 2017 09:03:15 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::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 E4C23129435; Sun, 26 Nov 2017 09:03:14 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id g130so25622602wme.0; Sun, 26 Nov 2017 09:03:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=K4ZDXmQoM3Wrnz8yK/0H2AuMdpO7FbP6e4RqjITTa/0=; b=qtzINDQXr/e0THMwLVh9arnyQkUulDB6EqJ+o4VDNjoWNuRhrgunsICa66Sa/pLbw8 UeJKKFxc0cbMUk/rkOsE4YPZqpPwJMBFMAQD6ptOQiapX4mR6wvFpSXNQ8lUDfVbh5aG HK2yPt+8roFf4Cl8PwOsyDHCF4oBBxXygdWFPIhGFhEMzMHmEXcvsMgN68V64SGZnDEX Qts6axmTzKYhMm19DZ/TV03T3gwDFl8vZnRfPHGrGfN6ZLXMdIhZGIj4ecImfXG6Qjx1 B7SoKFklZ5w4f+v4vYOOkzIi/jxuhmHSaTZYxsay+K1mXRwzduWTBJedfSfdfjilYhau Deag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=K4ZDXmQoM3Wrnz8yK/0H2AuMdpO7FbP6e4RqjITTa/0=; b=e6aN0tu8IiW5c7O6XstLnl8FWeboM6oLmR4EqK2fR4ekUbETNyMirVvyw2gjmyTTZZ tJz8lfj+IgPqAjqZODDLwgeSbH2ZR/WiK9HMKeFAaxrR+FpnA9iCru/Teaps9JbaCBdK Bhh6RxQiibnCzX5dMBz0mYIDtzSDiXtR9gxcR7VkYeO5uPqUNIUxbbUn4okz1ZVg4CHz lMuWWjIi2dy/l4+hnIcwRpKpu7x43B02ihJHBvIgoDK6va3YzgHudFj6vilY0xlQAt1y 8fgYV9kWm43yqlxmMeiLWJ4xVmtD2rV4UrBpuF3cAZ/o8+lOQDCnUyDN8+6pLmf8W1Nx pRgg== X-Gm-Message-State: AJaThX4jGbOJ8gfeFjyVQLN1WW5xuKMIo4cKzlsswnHyWJxFcmWTs9Jz NvLsEozVRmfycZR6vSHgvJPuZRTiU6sHb3zg8lhv2VHc X-Google-Smtp-Source: AGs4zMYw9Q3OolGqjb8J1vPyeJ93+//toS9Zm+MWQKk4c418E9vBRzdm+clvFAUM+LwHIlpze9ZqizuOhMhn59A03Uk= X-Received: by 10.80.208.195 with SMTP id g3mr48518595edf.246.1511715793362; Sun, 26 Nov 2017 09:03:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.139.216 with HTTP; Sun, 26 Nov 2017 09:03:12 -0800 (PST) In-Reply-To: References: <150522092693.4724.2532571098567577114.idtracker@ietfa.amsl.com> From: Dmitry Belyavsky Date: Sun, 26 Nov 2017 20:03:12 +0300 Message-ID: To: Nikos Mavrogiannopoulos Cc: LAMPS , pkix@ietf.org, dev-security-policy@lists.mozilla.org, "saag@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1cd2fadd64dc055ee5c28b" Archived-At: Subject: Re: [saag] Fwd: New Version Notification for draft-belyavskiy-certificate-limitation-policy-04.txt X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Nov 2017 17:03:17 -0000 --94eb2c1cd2fadd64dc055ee5c28b Content-Type: text/plain; charset="UTF-8" Hello, I've just uploaded the new version of my draft. The main difference from the previous one is more or less described syntax of specific limitations mentioned in text. The answers on the question raised by Nikos are below. ================= A new version of I-D, draft-belyavskiy-certificate-limitation-policy-05.txt has been successfully submitted by Dmitry Belyavskiy and posted to the IETF repository. Name: draft-belyavskiy-certificate-limitation-policy Revision: 05 Title: Certificate Limitation Policy Document date: 2017-11-25 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-belyavskiy- certificate-limitation-policy-05.txt Status: https://datatracker.ietf.org/doc/draft-belyavskiy- certificate-limitation-policy/ Htmlized: https://tools.ietf.org/html/draft-belyavskiy-certificate- limitation-policy-05 Htmlized: https://datatracker.ietf.org/doc/html/draft-belyavskiy- certificate-limitation-policy-05 Diff: https://www.ietf.org/rfcdiff?url2=draft-belyavskiy- certificate-limitation-policy-05 Abstract: The document provides a specification of the application-level trust model. Being provided at the application level, the limitations of trust can be distributed separately using cryptographically protected format instead of hardcoding the checks into the application itself. ================== On Thu, Oct 12, 2017 at 3:03 PM, Nikos Mavrogiannopoulos via dev-security-policy wrote: > On Sat, Oct 7, 2017 at 8:37 PM, Dmitry Belyavsky > wrote: > > Dear Nicos, > > > > Sorry for the delay with my response. > > > > On Fri, Sep 22, 2017 at 11:06 AM, Nikos Mavrogiannopoulos < > nmav@gnutls.org> > > wrote: > >> > >> On Wed, Sep 20, 2017 at 3:21 PM, Dmitry Belyavsky > >> wrote: > >> > > > > Well, the specification I suggest should allow applying CLPs issued by > major > > vendors (Mozilla etc). > > For this purposes the CLPs should be validable => signed. > > Hi, > If mozilla or any other organization is willing to deploy such PKI, > that would be great. However for the majority of software, I'd expect > that such files are distributed using the same channel as software, > and thus using the same authentication mechanism for it rather than a > new PKI. For a software distributor to use that optional signing could > work. > I got your point. I'll think about allowing local CLPs to be unsigned. > > >> One problem with that is the fact that the existing CRL extensions are > >> about extending attributes of the CRL, rather than adding/removing > >> attributes to the certificate in question. > > For this purposes I implied that the limitations are provided not by > > extensions, > > but as SEQUENCE of limitations related to the certificates. > > > > Was I wrong in the ASN1 scheme in the current version of my draft? > > I do not think that the presented ASN.1 description is valid. > The "limitations SEQUENCE," doesn't define anything in ASN.1 > (i..e, it is a sequence of what?). > I (hopefully) clarified the ASN.1 description in the new version. > > >> > >> To bring the stapled extensions to your proposal, you'd need the > >> Extensions and Extension fields from RFC5280, and > >> add into limitedCertificates structure (I'll split it on the example > >> below for clarity) the following field. > >> > >> LimitedCertificates ::= SEQUENCE OF LimitedCertificate > >> > >> LimitedCertificate ::= SEQUENCE { > >> userCertificate CertificateSerialNumber, > >> certificateIssuer Name, > >> limitationDate Time, > >> limitationPropagation Enum, > >> fingerprint SEQUENCE { > >> fingerprintAlgorithm AlgorithmIdentifier, > >> fingerprintValue OCTET STRING > >> } OPTIONAL, > >> limitations SEQUENCE, > >> } OPTIONAL, > >> }; > >> > >> > >> stapledExtensions Extensions; <----- NEW > >> } > > > > > > Sorry, I do not get the difference between the purposes of the field > > 'limitations' > > and 'stapledExtensions'. > > I cannot answer this as I cannot see the syntax of the limitations > field. I thought it was a field intended to spark discussion rather > than anything specific. > Now, when the syntax is provided, I hope it's specific enough to continue the discussion. -- SY, Dmitry Belyavsky --94eb2c1cd2fadd64dc055ee5c28b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I've just uploaded the new v= ersion of my draft.

The main difference from the p= revious one is more or less described syntax of=C2=A0
specific li= mitations mentioned in text.=C2=A0

The answers= on the question raised by Nikos are below.

=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
A new version of I-D, draft-belyavskiy-certificate-limitation-po= licy-05.txt
has been successfully submitted by Dmitry Belyavskiy and posted to t= he
IE= TF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0draft-belyavskiy-certificate-limitation-policy
Revision:=C2=A0 =C2=A0 = =C2=A0 =C2=A005
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Certificate Limitation = Policy
Document date:=C2=A0 2017-11-25
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Indiv= idual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 9
URL:=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0=C2=A0https://www.ietf.org/inte= rnet-drafts/draft-belyavskiy-certificate-limitation-policy-0= 5.txt
St= atus:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ie= tf.org/doc/draft-belyavskiy-certificate-limitation-policy/Htmlized:=C2= =A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-b= elyavskiy-certificate-limitation-policy-05
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2= =A0https://datatracker.ietf.org/doc/html/draft-be= lyavskiy-certificate-limitation-policy-05
Diff:=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2= =3Ddraft-belyavskiy-certificate-limitation-policy-05

Abstract:
=C2=A0 =C2=A0The document provides a specification of the a= pplication-level trust
=C2=A0 =C2=A0model.=C2=A0 Being provided at the applicati= on level, the limitations of
=C2=A0 =C2=A0trust can be distributed separately us= ing cryptographically protected
=C2=A0 =C2=A0format instead of hardcoding the ch= ecks into the application itself.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /div>

On Thu, Oct 12, 2017 at 3:03 PM, Nik= os Mavrogiannopoulos via dev-security-policy <dev-sec= urity-policy@lists.mozilla.org> wrote:
On Sat, Oct 7, 2017 at 8:37 PM, Dmitry Belyavsky <beldmit@gmail.com> wrote:
> Dear Nicos,
>
> Sorry for the delay with my response.
>
> On Fri, Sep 22, 2017 at 11:06 AM, Nikos Mavrogiannopoulos <nmav@gnutls.org>
> wrote:
>>
>> On Wed, Sep 20, 2017 at 3:21 PM, Dmitry Belyavsky <beldmit@gmail.com>
>> wrote:
>>
>
> Well, the specification I suggest should allow applying CLPs issued by= major
> vendors (Mozilla etc).
> For this purposes the CLPs should be validable =3D> signed.

Hi,
=C2=A0If mozilla or any other organization is willing to deploy such PKI, that would be great. However for the majority of software, I'd expect that such files are distributed using the same channel as software,
and thus using the same authentication mechanism for it rather than a
new PKI. For a software distributor to use that optional signing could
work.

I got your point. I'll think = about allowing local CLPs to be unsigned.
=C2=A0

>> One problem with that is the fact that the existing CRL extensions= are
>> about extending attributes of the CRL, rather than adding/removing=
>> attributes to the certificate in question.
> For this purposes I implied that the limitations are provided not by > extensions,
> but as SEQUENCE of limitations related to the certificates.
>
> Was I wrong in the ASN1 scheme in the current version of my draft?

I do not think that the presented ASN.1 description is valid.
The "limitations=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SEQUENCE," doe= sn't define anything in ASN.1
(i..e, it is a sequence of what?).

I (h= opefully) clarified the ASN.1 description in the new version.
=C2= =A0

>>
>> To bring the stapled extensions to your proposal, you'd need t= he
>> Extensions and Extension fields from RFC5280, and
>> add into limitedCertificates structure (I'll split it on the e= xample
>> below for clarity) the following field.
>>
>> LimitedCertificates=C2=A0 ::=3D=C2=A0 =C2=A0SEQUENCE OF LimitedCer= tificate
>>
>> LimitedCertificate ::=3D SEQUENCE {
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0userC= ertificate=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0CertificateSerialNumber,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0certi= ficateIssuer=C2=A0 =C2=A0 =C2=A0 =C2=A0Name,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0limit= ationDate=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Time,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0limit= ationPropagation=C2=A0 =C2=A0Enum,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0finge= rprint SEQUENCE {
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0fingerprintAlgorithm AlgorithmIdentifier,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0fingerprintValue=C2=A0 =C2=A0 =C2=A0OCTET STRING
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } OPTION= AL,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0limit= ations=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SEQUENCE,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 } OPTIONAL,
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 };
>>
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0stapl= edExtensions Extensions; <----- NEW
>> }
>
>
> Sorry, I do not get the difference between the purposes of the field > 'limitations'
> and 'stapledExtensions'.

I cannot answer this as I cannot see the syntax of the limitations field. I thought it was a field intended to spark discussion rather
than anything specific.

Now, when the s= yntax is provided, I hope it's specific enough to continue the discussi= on.

--=C2=A0
SY, Dmitry Belyavsky
--94eb2c1cd2fadd64dc055ee5c28b-- From nobody Mon Nov 27 07:44:45 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAA08128B90 for ; Mon, 27 Nov 2017 07:44:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.921 X-Spam-Level: X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 PsjQxffcK2wD for ; Mon, 27 Nov 2017 07:44:41 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92B48128B8E for ; Mon, 27 Nov 2017 07:44:41 -0800 (PST) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 40F887CB8A; Mon, 27 Nov 2017 15:44:41 +0000 (UTC) Received: from bofh7.nohats.ca (unknown [10.40.205.111]) by smtp.corp.redhat.com (Postfix) with ESMTP id 030C25D753; Mon, 27 Nov 2017 15:44:39 +0000 (UTC) To: Yakov Shafranovich , saag@ietf.org Cc: Ed Overflow References: From: Paul Wouters Message-ID: <7edb2f5d-a5b5-5c3f-ba16-df95f2858326@redhat.com> Date: Mon, 27 Nov 2017 10:44:38 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Mon, 27 Nov 2017 15:44:41 +0000 (UTC) Archived-At: Subject: Re: [saag] Proposal for "security.txt" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 15:44:43 -0000 On 10/15/2017 09:59 PM, Yakov Shafranovich wrote: > [I am posting this as per my emails with the sec ADs] > > Ed Foudil and others within the security community are working on an > Internet draft proposing a new standard for providing security contact > information via a standard file, similar to robots.txt. The draft can > be found here: > https://tools.ietf.org/html/draft-foudil-securitytxt-00 This seems like a terrible idea. If a web service is compromised before a researcher finds it, the security.txt could have been modified to NOT alert the actual security staff of this web service. It might even alert the hackers to wipe the server for fear of being identified. So any researcher would have to attempt to reach the proper people via an out-of-band security method anyway and they MUST NOT use the security.txt file for this. Doing something in RDAP for a security contact similar to how we have abuse contacts seems like a much better idea. Paul From nobody Mon Nov 27 09:13:24 2017 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A349112895E for ; Mon, 27 Nov 2017 09:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 WcSsSWLvywjz for ; Mon, 27 Nov 2017 09:13:20 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC976126557 for ; Mon, 27 Nov 2017 09:13:20 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id D86CA20008 for ; Mon, 27 Nov 2017 12:15:42 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 40FA082B25 for ; Mon, 27 Nov 2017 12:13:19 -0500 (EST) From: Michael Richardson To: saag@ietf.org In-Reply-To: <7edb2f5d-a5b5-5c3f-ba16-df95f2858326@redhat.com> References: <7edb2f5d-a5b5-5c3f-ba16-df95f2858326@redhat.com> X-Mailer: MH-E 8.6; nmh 1.7-RC3; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] Proposal for "security.txt" X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Nov 2017 17:13:23 -0000 --=-=-= Content-Type: text/plain Paul Wouters wrote: > On 10/15/2017 09:59 PM, Yakov Shafranovich wrote: >> [I am posting this as per my emails with the sec ADs] >> >> Ed Foudil and others within the security community are working on an >> Internet draft proposing a new standard for providing security contact >> information via a standard file, similar to robots.txt. The draft can >> be found here: >> https://tools.ietf.org/html/draft-foudil-securitytxt-00 > This seems like a terrible idea. > If a web service is compromised before a researcher finds it, the security.txt > could have been modified to NOT alert the actual security staff of this > web service. It might even alert the hackers to wipe the server for You have have identified that the contents need to be digitally signed! So security.txt needs to be security.txt.asc/security.smime or some other clearsigned digital signature format. The keys to verify this need to be in DNS(SEC). At which point, I think one might as well move the contents into TXT records. > being identified. So any researcher would have to attempt to reach the proper people > via an out-of-band security method anyway and they MUST NOT use the security.txt > file for this. > Doing something in RDAP for a security contact similar to how we have abuse contacts > seems like a much better idea. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAlocR64ACgkQgItw+93Q 3WUNCggAqIdR3mesRCR80PNHGC626vVbJLFW23FH0NneJcLADnyYBd5eBW88mS5I OpLceu5sTXfPDvLG/tzgvzds6b0P81r08fxQaTkrOkifO1FEYX8nOCoLMTWvqhJB kEbKbyLjlNYkylXbzdJonQoD9SdJO4A+Yo9FTC1IbK9MN1h+iSp+Ci6hzBsEzhft kCx+Gc9SokF9tNDKZ6iaqgJ+iSIQUshQZAO1ChSZZO38tcUXhz+IF/VSVZOUd6Ux aG5qcg/rfR9lE4bknNdiiEHMr0Eudgcd684rgaCas+74XTg3seET+VxArhBtsCXt 9zI8SjGQAY0XVqoAUwI3uCvaHS24Rg== =pPbI -----END PGP SIGNATURE----- --=-=-=--